Bug 222229 - kernel BUG at fs/dquot.c:422!
kernel BUG at fs/dquot.c:422!
Status: CLOSED DUPLICATE of bug 209639
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2007-01-10 17:57 EST by Rhys McMurdo
Modified: 2007-11-16 20:14 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-01-23 15:18:31 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 Rhys McMurdo 2007-01-10 17:57:13 EST
Description of problem:

We have noticed that under heavy IO, dquot appears to fail. This has been
detected during account migrations with Cpanel, which uses disk quota's for all
of the users. A dump of the bug is provided below:

kernel BUG at fs/dquot.c:422!
invalid operand: 0000 [#1]
Modules linked in: ipt_owner ipt_REJECT iptable_filter ip_tables autofs4 i2c_dev
i2c_core sunrpc md5 ipv6 dm_mirror dm_mod button battery ac uhci_hcd ehci_hcd
e1000 ext3 jbd ata_piix libata 3w_9xxx sd_mod scsi_mod
CPU:    0
EIP:    0060:[<c01823d3>]    Not tainted VLI
EFLAGS: 00010202   (2.6.9-42.ELsmp)
EIP is at invalidate_dquots+0x3d/0xc3
eax: 00000001   ebx: c3976b90   ecx: f7c8aa80   edx: c3976e60
esi: e9704718   edi: 00000000   ebp: f7f44400   esp: e8944eec
ds: 007b   es: 007b   ss: 0068
Process quotaoff (pid: 17601, threadinfo=e8944000 task=c44bc930)
Stack: f7f444ac f7f444ac f7f44400 00000000 c0183b78 00000000 00000000 f7f44400
       00000000 00800003 c0185d16 00000000 c0166267 80000300 c6d6bb80 e8944000
       f7937c2c fffffff4 c016f070 e8944f50 fffffff4 00000000 c0166484 f7f57080
Call Trace:
 [<c0183b78>] vfs_quota_off+0x92/0x115
 [<c0185d16>] do_quotactl+0x10d/0x4aa
 [<c0166267>] getname+0x5b/0xb2
 [<c016f070>] dput+0x34/0x1a7
 [<c0166484>] path_release+0xa/0x2d
 [<c016215b>] lookup_bdev+0x66/0x74
 [<c02d2cb2>] __cond_resched+0x14/0x39
 [<c01a7b69>] capable+0x15/0x2c
 [<c0185ae1>] check_quotactl_valid+0x231/0x23b
 [<c0186174>] sys_quotactl+0xc1/0xd8
 [<c02d4703>] syscall_call+0x7/0xb
Code: 8b 35 b4 e6 32 c0 81 fe b4 e6 32 c0 0f 84 91 00 00 00 8d 5e f8 8b 36 39 6b
4c 75 ea 0f bf 43 60 39 f8 75 e2 8b 43 38 85 c0 74 08 <0f> 0b a6 01 f7 9c 2e c0
8b 53 04 85 d2 74 18 8b 03 85 c0 89 02
 <0>Fatal exception: panic in 5 seconds
Kernel panic - not syncing: Fatal exception

We were going to upgrade to 2.6.9-42.0.3ELsmp, however it appears the bug is
replicated in that version as well:


Version-Release number of selected component (if applicable):

How reproducible:

Only reproducible during periods where partitions with usrquota are under heavy
IO. This was replicated fairly regulary during Cpanel migrations, but not during
  the standard load the server is put under in day-to-day operations.

Steps to Reproduce:

Please see above. 
Actual results:

Kernel panic mentioned in the summary area

Expected results:

No Kernel panic

Additional info:
Comment 1 Jason Baron 2007-01-23 15:18:31 EST

*** This bug has been marked as a duplicate of 209639 ***
Comment 2 Johnny Hughes 2007-02-02 05:07:46 EST
OK ... I understand that there are reasons for private bugs ... but is it a good
policy to close public bugs that as dups and not leave a public tracking mechanism.

This bug and 205001 have both been closed as dups ... and now people without
access to your private bugs have no way to track this.

Unless this bug is a major security issue, I would think since it has been
mentioned twice in public posts, that it should be able to be tracked both
publicly and privately.

Comment 3 Johnny Hughes 2007-02-02 06:02:08 EST
Doing further research and looking at RHEL test kernels ... this bug seems fixed
in the kernel version:

-Fix BUG() check in invalidate_dquots() (David Milburn) [209639]

Therefore, I assume that it will be fixed when the official kernel is > 2.6.9-42.22.

New RHEL test kernels show up here from time to time:
Comment 4 Eric Sandeen 2007-02-02 09:31:11 EST
Re: the cloning to a private bug, sorry about that, let me see what the best way
to handle that is.  The other reason for private bugs is for customer
confidentiality; people sometimes don't want competitors to know they have
trouble with their systems, etc.  Or sometimes there are testcases which reveal
too much about their operations.

We're not trying to shut anyone out though, just properly account for bugs, so
I'll see what I can do.

Comment 5 Jay Turner 2007-02-08 08:43:07 EST
Pulling in ack from 209639

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