Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 110533 - Assertion failure in journal_flush() at journal.c:1250: "!journal->j_running_transaction"
Assertion failure in journal_flush() at journal.c:1250: "!journal->j_running_...
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Stephen Tweedie
Brian Brock
Depends On:
Blocks: 133089
  Show dependency treegraph
Reported: 2003-11-20 15:41 EST by Wendy Cheng
Modified: 2007-11-30 17:06 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-17 14:34:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Wendy Cheng 2003-11-20 15:41:24 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1)

Description of problem:
The do_emergency_sync() within sysrq.c does a remount-readonly journal
flushing without setting up a barrier against new fs updates coming
in. This ends up crashing the system (IT#29619) in the following route:

Assertion failure in journal_flush_Rsmp_ee97f7e7() at journal.c:1250:
------------[ cut here ]------------
kernel BUG at journal.c:1250!
invalid operand: 0000
Kernel 2.4.9-e.12enterprise
CPU:    2
EIP:    0010:[<f880682b>]    Tainted: P
EFLAGS: 00010282
EIP is at journal_flush_Rsmp_ee97f7e7 [jbd] 0x10b
eax: 00000021   ebx: 00001965   ecx: c02f61a4   edx: 004c3eb5
esi: f39f6c00   edi: 00000000   ebp: 0008e000   esp: f7539f60
ds: 0018   es: 0018   ss: 0018
Process bdflush (pid: 13, stackpage=f7539000)
Stack: f880a381 000004e2 f39fa800 f39fa800 f39fa8e8 f881a1d1 f39f6c00
      f881a58b f39fa800 f397c400 0000c703 f39fa870 f39fa800 00000001
      f39fa800 f7539fac 00000000 00000001 f39fa800 00000001 00000002
Call Trace: [<f880a381>] .LC63 [jbd] 0x28b
[<f881a1d1>] ext3_mark_recovery_complete [ext3] 0x11
[<f881a58b>] ext3_remount [ext3] 0xab
[<c019831f>] go_sync [kernel] 0xef
[<c019843f>] do_emergency_sync [kernel] 0xaf
[<c014b96f>] bdflush [kernel] 0x8f
[<c0105000>] stext [kernel] 0x0
[<c0105000>] stext [kernel] 0x0
[<c0105836>] kernel_thread [kernel] 0x26
[<c014b8e0>] bdflush [kernel] 0x0

Code: 0f 0b 58 5a 8b 5e 30 85 db 74 34 68 20 9b 80 f8 68 e3 04 00
<0>Kernel panic: not continuing
<0>Rebooting in 120 seconds..

Version-Release number of selected component (if applicable):
e.12 and above 

How reproducible:
Didn't try

Additional info:

Stephen Tweedie is aware of this problem.
Comment 1 Arjan van de Ven 2003-11-20 16:06:18 EST
which kernel modules are in use here ?

Comment 2 Wendy Cheng 2003-11-20 16:34:44 EST
drivers/char/sysrq.c and ext3. 
Comment 3 Arjan van de Ven 2003-11-20 16:36:27 EST
ext3 doesn't taint the kernel; something else does.
Is there a sysreport of this machine available ?
Comment 4 Wendy Cheng 2003-11-20 17:40:25 EST
The kernel is tainted but it is not relevant here (though I have to
admire your good eyes). This crash is obvious.

The journal_flush() initiated by sysrq bypasses the expected fs
barrier logic to allow new ext3-fs requests to clobber the journal
control block (in this case,it is j_running_transaction). According to
“sct”, the current journal_flush() only expects the following three

1.“remount-ro” (it checks for writable file descriptors before
2.“unmount” (it checks potential activities on the fs before flushing)
3."LVM" (the VFSlock for LVM snapshot quiescing sets a journal barrier
   before the flush).

The “forced remount-ro” initiated by sysrq doesn't do any of these.
Fix the bug, please.
Comment 9 Wendy Cheng 2004-02-12 22:04:31 EST
Why do we need to do this "sync" when the sysadm hit the "sysrq" key ?
Isn't it overkill ? 
Comment 10 Stephen Tweedie 2004-02-13 06:30:48 EST
We don't, in general.  But "sysrq-s" is the documented combination to
force an emergency sync, so in that case we don't have much choice
about it!

Note You need to log in before you can comment on or make changes to this bug.