search for: repeat_lock

Hi Steven, Hi ext3-users list! We encountered a reproduceable problem with ext3: When issuing a FIBMAP ioctl for a block written right before while the FS is under high load (RH build universe), the assertion !journal->j_running_transaction fails at the bottom of journal_flush() in fs/jbd/journal.c. We encountered this problem with the arch=s390x (64 bit big endian) bootloader zipl, I'll

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

...ext3 filesystem read-only. We often do this and haven't seen this bug before, so I suspect some kind of race. It appears to be related to a message posted to this list in January 2002 by Carsted Otte [https://listman.redhat.com/pipermail/ext3-users/2002-January/002572.html]. I noticed the repeat_lock patch given by Stephen Tweedie later in that thread. I don't have the original source used to build this kernel (2.4.19-FW25), but it appears that the patch has been applied in 2.4.20 at least, so this may not be the same problem. The full decoded oops is attached. Currently we have no way...