Red Hat Bugzilla – Bug 222229
kernel BUG at fs/dquot.c:422!
Last modified: 2007-11-16 20:14:55 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
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
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):
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.
Kernel panic mentioned in the summary area
No Kernel panic
*** This bug has been marked as a duplicate of 209639 ***
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.
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) 
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:
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.
Pulling in ack from 209639