Bug 232107
| Summary: | GFS2 panics if you try to rm -rf the lost+found directory | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Josef Bacik <jbacik> | ||||||||
| Component: | kernel | Assignee: | Don Zickus <dzickus> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Dean Jansa <djansa> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | medium | ||||||||||
| Version: | 5.1 | CC: | bmarzins, kanderso, lwang, nobody+wcheng, rkenna, rpeterso, swhiteho | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | RHBA-2007-0959 | Doc Type: | Bug Fix | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2007-11-07 19:44:08 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: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Josef Bacik
2007-03-13 21:26:36 UTC
It looks like the problem is related to the way we count the number of entries in a directory during readdir. We are making the assumption that ip->i_di.di_entries is correct which means that: 1. In the case that there are more entries than that, we may potentially run off the end of our buffer which is passed to sort(). 2. In the case that there are fewer entries we might pass uninitialised pointers to sort() (the array of pointers is kmalloced) which appears to be whats happened here. I suspect that there is a bug in fsck's routine for creating the lost+found directory, but either way GFS2 shouldn't panic like this. The fix for case 2 is trivial, fixing case 1 is not so easy. Looking through the source for fsck, the most likely cause that I've not been able so far to eliminate as a possibility is that the "updated" variable is not being set correctly somewhere. Otherwise it looks as if its doing all the right things. Created attachment 150028 [details]
Patch to detect and reject corrupt directories
This patch will detect and reject directories where the number of entries in
the directory (in the inode for stuffed directories, or the leaf block for
exhash) doesn't match the actual number of entries on that disk block. If this
should happen a warning message is printed pointing out the location of the
error.
If you still have the (corrupt) filesystem available, please test it with this
patch to see if this will do the "right thing", i.e. return -EIO to readdir
rather than crashing as it does currently.
Josef, are you in a position to test this patch or does the offending fs image no longer exist? It seems to work ok for me when I tested the patch on correct filesystems, so I think it should be ok to apply, but it would be nice to know if it fixes the problem that you reported first. yes i saved the bad image so bob could poke around on it. i will test the patch sometime next week, my queue is overflowing atm. This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release. Rob, Kevin, can you set the rest of the flags on this bug from ? to +. Thanks, Steve. Created attachment 154453 [details]
First part of patch for RHEL 5.1
This is the first part of the patch for RHEL 5.1
Created attachment 154454 [details]
Second part of patch
Here is part two of the patch.
in 2.6.18-19.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5 An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0959.html |