lkml.org 
[lkml]   [2002]   [Feb]   [14]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateThu, 14 Feb 2002 19:33:19 -0600
FromKen Brownfield <>
SubjectRe: [BUG] + [PATCH]: handling bad inodes in 2.4.x kernels
One could argue that a corrupt filesystem is a corrupt filesystem, but
I've seen this behavior first hand (without using debugfs,
unfortunately).  I think it's worth someone with filesystem fu taking a
look at this patch.  Or "seconded", whatever. :)

-- 
Ken.
brownfld@irridia.com

On Wed, Feb 13, 2002 at 06:29:27PM +0100, Daniel Mack wrote:
| i already wrote this a few days ago but did not get any response yet.
| since i believe this is a serious bug, i'm posting this again...
| 
| the bug is about the handling of bad inodes in at least the 2.4.16, .17,
| .18-pre9 and .9 kernel releases (i suspect all 2.4 kernels are affected)
| and causes the names_cache to get confused.
| you can easily reproduce this effect by making an inode bad using debugfs
| (or using a bad one if you have, of course) and open() it with the flag
| O_CREAT set. watching /proc/slabinfo will show you the weirdness.
| consider /tmp/bad is a bad inode:
| 
| # cd /tmp
| # ls | grep bad
| bad
| # cat bad
| cat: bad: Input/output error
| # cat /proc/slabinfo | grep names
| names_cache 0 2 4096 0 2 1 : 2 333 2 0 0
| # echo foo >bad
| sh: bad: Input/output error
| # cat /proc/slabinfo | grep names
| names_cache 4294967295 2 4096 1 2 1
| 
| boom! 4294967295 == (unsigned long) -1, the cache length is growing backwards.
| this "echo foo >bad" opens the file with O_CREAT set which forces the effect.
| 
| what confuses me is that the system remains stable after that happened, the
| only effect i got was that i wasn't able to rename() a file on any filesystem
| anymore. what the rename() syscall does on kernel side is getting memory from
| the names_cache twice by calling __getname() which gives out the same pointer
| twice when the kernel is poisoned this way.
| anyway, it's an ugly bug that needs to get fixed.
| 
| the bug is most likely in fs/namei.c, open_namei() - at least i fixed my
| machine here with this:
| 
| --- linux-2.4.17-orig/fs/namei.c Wed Oct 17 23:46:29 2001
| +++ linux-2.4.17-uml/fs/namei.c Fri Feb 8 02:53:36 2002
| @@ -1052,6 +1052,11 @@
|         error = -ENOENT;
|         if (!dentry->d_inode)
|                 goto exit_dput;
| +
| + error = -EIO;
| + if (is_bad_inode(dentry->d_inode))
| + goto exit_dput;
| +
|         if (dentry->d_inode->i_op && dentry->d_inode->i_op->follow_link)
|                 goto do_link;
| 
| an open() does not make any sense on a bad inode so i see no reason for
| not breaking the branch at this point.
| 
| any comments? please let me know if you're able to trigger this effect
| on older 2.4 kernels. btw, version 2.2.19 is not tainted.
| 
| greets,
| daniel
| 
| 
| -
| To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
| the body of a message to majordomo@vger.kernel.org
| More majordomo info at  http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:18    [from the cache]
©2003-2008