Bug 268521 - RFE: GFS report block device errors as block device errors, not filesystem errors
RFE: GFS report block device errors as block device errors, not filesystem er...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gfs-kmod (Show other bugs)
5.0
All All
medium Severity low
: ---
: ---
Assigned To: Robert Peterson
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-30 15:16 EDT by Corey Marthaler
Modified: 2010-01-11 22:27 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-11 16:44:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Corey Marthaler 2007-08-30 15:16:18 EDT
Description of problem:
This appears to be the same as the gfs2 bug 253948. I didn't have the debug or
oops_ok mount option set so I didn't expect the system to panic due to a I/O
error. Is this a regression? This was fixed a long time ago?



GFS: fsid=TAFT_CLUSTER:2.3: fatal: assertion "x <= length" failed
GFS: fsid=TAFT_CLUSTER:2.3:   function = blkalloc_internal
GFS: fsid=TAFT_CLUSTER:2.3:   file =
/builddir/build/BUILD/gfs-kmod-0.1.19/_kmod_build_/src/gfs8
GFS: fsid=TAFT_CLUSTER:2.3:   time = 1188489777
GFS: fsid=TAFT_CLUSTER:2.3: about to withdraw from the cluster
GFS: fsid=TAFT_CLUSTER:2.3: telling LM to withdraw
Aug 30 11:02:57 taft-03 kernel: GFS: fsid=TAFT_CLUSTER:2.3: fatal: assertion "x
<= length" faild
Aug 30 11:02:57 taft-03 kernel: GFS: fsid=TAFT_CLUSTER:2.3:   function =
blkalloc_internal
Aug 30 11:02:57 taft-03 kernel: GFS: fsid=TAFT_CLUSTER:2.3:   file =
/builddir/build/BUILD/gfs-8
Aug 30 11:02:57 taft-03 kernel: GFS: fsid=TAFT_CLUSTER:2.3:   time = 1188489777
Aug 30 11:02:57 taft-03 kernel: GFS: fsid=TAFT_CLUSTER:2.3: about to withdraw
from the cluster
Aug 30 11:02:57 taft-03 kernel: GFS: fsid=TAFT_CLUSTER:2.3: telling LM to withdraw
----------- [cut here ] --------- [please bite here ] ---------
Kernel BUG at fs/locks.c:1991
invalid opcode: 0000 [1] SMP
last sysfs file: /fs/gfs/TAFT_CLUSTER:4/lock_module/recover_done
CPU 0
Modules linked in: gfs(U) autofs4 hidp rfcomm l2cap bluetooth lock_dlm gfs2 dlm
configfs sunrpcd
Pid: 10460, comm: doio Not tainted 2.6.18-40.el5 #1
RIP: 0010:[<ffffffff8002703d>]  [<ffffffff8002703d>] locks_remove_flock+0xe4/0x122
RSP: 0018:ffff8101ceccddb8  EFLAGS: 00010246
RAX: ffff81021487f6b8 RBX: ffff81019b2e1380 RCX: ffff8101ceccddb8
RDX: 0000000000000000 RSI: ffff8101ceccddb8 RDI: ffffffff802fdea0
RBP: ffff81021aa89280 R08: 0000000000000000 R09: 0000000000000000
R10: ffff8101ceccddb8 R11: 00000000000000b0 R12: ffff81019b2e1280
R13: ffff81019b2e1280 R14: ffff81021043e780 R15: ffff8101994849c0
FS:  0000000000000000(0000) GS:ffffffff80396000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000304c295770 CR3: 0000000000201000 CR4: 00000000000006e0
Process doio (pid: 10460, threadinfo ffff8101ceccc000, task ffff8101b2e17040)
Stack:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
 0000000000000000 0000000000000000 00000000000028dc 0000000000000000
 0000000000000000 0000000000000000 ffff81021aa89280 0000000000000202
Call Trace:
 [<ffffffff800122c2>] __fput+0x94/0x198
 [<ffffffff800237b1>] filp_close+0x5c/0x64
 [<ffffffff800384cf>] put_files_struct+0x6c/0xc3
 [<ffffffff80014f6e>] do_exit+0x2d2/0x89d
 [<ffffffff80046e11>] cpuset_exit+0x0/0x6c
 [<ffffffff8005b28d>] tracesys+0xd5/0xe0


Code: 0f 0b 68 62 df 28 80 c2 c7 07 48 89 c3 48 8b 03 48 85 c0 75
RIP  [<ffffffff8002703d>] locks_remove_flock+0xe4/0x122
 RSP <ffff8101ceccddb8>
 <0>Kernel panic - not syncing: Fatal exception


Version-Release number of selected component (if applicable):
2.6.18-40.el5
Comment 2 Robert Peterson 2009-05-11 14:25:02 EDT
Hey Corey, I'm just revisiting this bug record.  I should have spotted
this months ago, but:  In the problem description, the kernel panic
shown was due to a BUG() statement in vfs function locks_remove_flock.
In other words it was vfs, not gfs, that decided to panic the kernel.
The question is: Do you still perceive a problem in how GFS handles
block device errors in RHEL5?  If so, can I get a more recent example?
I'm wondering if this should really be against gfs.
Comment 3 Corey Marthaler 2009-05-11 16:30:40 EDT
This bug is almost 2 years old, you can probably just close it.
Comment 4 Robert Peterson 2009-05-11 16:44:25 EDT
Thanks, Corey.  I'll close it as WONTFIX.  We can always change
our minds later if it makes sense.

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