From: Ken Brownfield <brownfld@irridia.com>
To: Daniel Mack <daniel@yoobay.net>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: [BUG] + [PATCH]: handling bad inodes in 2.4.x kernels
Date: Thu, 14 Feb 2002 19:33:19 -0600 [thread overview]
Message-ID: <20020214193319.C1518@asooo.flowerfire.com> (raw)
In-Reply-To: <20020213182927.I15910@chaos.intra>
In-Reply-To: <20020213182927.I15910@chaos.intra>; from daniel@yoobay.net on Wed, Feb 13, 2002 at 06:29:27PM +0100
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/
next prev parent reply other threads:[~2002-02-15 1:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-13 17:29 Daniel Mack
2002-02-15 1:33 ` Ken Brownfield [this message]
2002-02-15 2:13 ` Daniel Mack
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020214193319.C1518@asooo.flowerfire.com \
--to=brownfld@irridia.com \
--cc=daniel@yoobay.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®