Bug 222229
| Summary: | kernel BUG at fs/dquot.c:422! | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Rhys McMurdo <rmcmurdo> |
| Component: | kernel | Assignee: | Eric Sandeen <esandeen> |
| Status: | CLOSED DUPLICATE | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.4 | CC: | jbaron |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-01-23 20:18:31 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
*** 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: 2.6.9-42.22 -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: http://people.redhat.com/~jbaron/rhel4/ 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. Thanks, -Eric Pulling in ack from 209639 |
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] SMP 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: http://bugs.centos.org/view.php?id=1601 Version-Release number of selected component (if applicable): 2.6.9-42 2.6.9-42.0.3 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: