similar to: Question concerning the EXT3 Journaling code

This version fixes three bugs in the 2nd patch of this series that caused kernel BUG when the system was under race. We weren't accounting with t_oustanding_credits correctly, and there were race conditions caused by the fact the I had overlooked the fact that __jbd2_log_wait_for_space() and jbd2_get_transaction() requires j_state_lock to be write locked. Theodore Ts'o (3): jbd2: Use

jbd2_journal_restart() would restart a handle. In this function, it calls start_this_handle(). Before calling start_this_handle()?subtract 1 from transaction->t_updates. If start_this_handle() succeeds, transaction->t_updates increases by 1 in it. But if start_this_handle() fails, transaction->t_updates does not increase. So, when commit the handle's transaction in

Hi all, and particularly Andrew and Stephen, I recently "upgraded' one of my NFS fileservers from (patched)2.4.18 to 2.4.23-pre7 (in order to resolve a HIMEM related memory pressure problem). Unfortunately I have experienced what appears to be a deadlock. The one I will describe was experienced while running 2.4.23-pre7, though I had a very similar problem in 2.4.22 (but

All, I am running into a situation in which one of my ext3 filesystems is getting hung during normal usage. There are three ext3 filesystems on a CompactFLASH. One is mounted as / and one as /tmp. In my test, I am copying a 100 MB file from /root to /tmp repeatedly. While doing this test, I eventually see the copying stop, and any attempts to access /tmp fail - if I even do ls /tmp the

I'm trying to use PXE to boot & install RedHat boxes. I have it working with one NIC card, but am having problems with a Dell Precision Workstation 530. According to the specs the card is as follows: integrated 3C920-based 10/100 3Com? Ethernet controller with Remote Wake Up capabilities (3C905C-TX compatible) The problem with this particular machine/NIC is that it's getting ARP

Hello, I''m not sure about this, when a device is set read-only, are journal commit still allowed then, or is this the reason, why the umount hangs forever? [44825.302262] LustreError: Skipped 572 previous similar messages [44882.668079] Lustre: Failing over pfs1work-OST0026 [44882.674578] Lustre: *** setting obd pfs1work-OST0026 device ''unknown-block(9,7)'' read-only

As part of migrating the FLUSH/FUA knob to the block layer, remove the journal flags and various conditionals in jbd2 that surround flush issue calls in favor of always issuing the flush. The block layer will handle gracefully the situation where a FLUSH or FUA request is issued to a device that doesn't support it. Signed-off-by: Darrick J. Wong <djwong at us.ibm.com> ---

On Fri 23-02-18 15:47:36, Mark Rutland wrote: > Hi all, > > While fuzzing arm64/v4.16-rc2 with syzkaller, I simultaneously hit a > number of splats in the block layer: > > * inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-R} usage in > jbd2_trans_will_send_data_barrier > > * BUG: sleeping function called from invalid context at mm/mempool.c:320 > > * WARNING:

Hi all, While fuzzing arm64/v4.16-rc2 with syzkaller, I simultaneously hit a number of splats in the block layer: * inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-R} usage in jbd2_trans_will_send_data_barrier * BUG: sleeping function called from invalid context at mm/mempool.c:320 * WARNING: CPU: 0 PID: 0 at block/blk.h:297 generic_make_request_checks+0x670/0x750 ... I've included the

Hi all, While fuzzing arm64/v4.16-rc2 with syzkaller, I simultaneously hit a number of splats in the block layer: * inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-R} usage in jbd2_trans_will_send_data_barrier * BUG: sleeping function called from invalid context at mm/mempool.c:320 * WARNING: CPU: 0 PID: 0 at block/blk.h:297 generic_make_request_checks+0x670/0x750 ... I've included the

I sent this report sometime ago to l-k and to the preempt-patch maintainer, but omitted to send a copy here, where some people could have clues about the problem - so here it is: ----- Forwarded message ----- To: linux-kernel@vger.kernel.org, Robert Love <rml@tech9.net> Subject: oops with 2.4.18 and preempt patch, on SMP + ext3 machine Coming back home tonight, I found my machine in a bad

From: Jan Kara <jack at suse.cz> If we race with commit code setting i_transaction to NULL, we could possibly dereference it. Proper locking requires the journal pointer (to access journal->j_list_lock), which we don't have. So we have to change the prototype of the function so that filesystem passes us the journal pointer. Also add a more detailed comment about why the function

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Background: Large NFS/mail server. Dual PIII/1GHZ. 4GB memory. Mylex AcceleRAID 352 RAID controller (uses DAC960 driver). Intel eepro100 network cards. RedHat 7.3 with all errata. Kernel-2.4.18-5smp. 2GB of memory is used by a RAM disk for mail queue. ext3 filesystems (switched to ext2 to see if that helps). one large (100GB data partition).

From: Jan Kara <jack at suse.cz> If we race with commit code setting i_transaction to NULL, we could possibly dereference it. Proper locking requires the journal pointer (to access journal->j_list_lock), which we don't have. So we have to change the prototype of the function so that filesystem passes us the journal pointer. Also add a more detailed comment about why the function

This patch contains the following possible cleanups: - make needlessly global functions static - #if 0 the following unused global functions: - journal.c: __journal_internal_check - journal.c: journal_ack_err - remove the following write-only global variable: - journal.c: current_journal - remove the following unneeded EXPORT_SYMBOL's: - journal.c: journal_check_used_features -

If we race with commit code setting i_transaction to NULL, we could possibly dereference it. Proper locking requires journal pointer (journal->j_list_lock) we don't have. So we have to change the prototype of the function so that filesystem passes us the journal pointer. Also add more detailed comment about why function does what it does how it should be used. Thanks to Dan Carpenter

Hello ext3-developers, Just to summarize, I reported a kernel bug message with ext3 on S/390 in transaction.c. I was able to reproduce it with a ext3 on LVM and on MD. Tom Rini reported a similar problem on PPC. (both big endian). I have sent a backtrace and with jbd-debug set to 5 I was not able to reproduce the problem until now. On S/390 there are some more debug possibilities. I would

I previously wrote: > I have come across what appears to be a bug in __invalidate_buffers() > w.r.t. the change in ext3-0.0.6 using BH_JDirty instead of BH_Dirty > for buffers held in the journal. If invalidate_buffers() is called > on a device (LVM likes to do this a lot, for whatever reason), it yanks > JDirty buffers out from underneath the journal layer, and causes an > oops

On Tue, Mar 17, 2009 at 02:02:33PM -0700, Randy Dunlap wrote: > Greg KH wrote: > > On Tue, Mar 17, 2009 at 01:26:47PM -0700, Randy Dunlap wrote: > >> Enable all possible OCFS2 kconfig options: > >> > >> > >> > >> In file included from fs/ocfs2/alloc.c:42: > >> fs/ocfs2/journal.h: In function 'ocfs2_begin_ordered_truncate': >

Package: xen-hypervisor-4.4-amd64 Version: 4.4.1-9+deb8u4 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? Running Backup Exec or a copy command to NFS-Share causes the VM regurarly to freeze. First message on VM-Console: ---------------------------------------------------------------------------------------------------------------