From: Vasily Averin <vvs@sw.ru>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
devel@openvz.org, linux-ext4@vger.kernel.org,
Stephen Tweedie <sct@redhat.com>,
adilger@clusterfs.com
Subject: Re: [RFC PATCH ext3/ext4] orphan list corruption due bad inode
Date: Tue, 05 Jun 2007 10:11:12 +0400 [thread overview]
Message-ID: <4664FE80.4080801@sw.ru> (raw)
In-Reply-To: <20070604190340.dba85bb0.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Mon, 04 Jun 2007 09:19:10 +0400 Vasily Averin <vvs@sw.ru> wrote:
>> diff --git a/fs/ext3/namei.c b/fs/ext3/namei.c
>> index 9bb046d..e3ac8c3 100644
>> --- a/fs/ext3/namei.c
>> +++ b/fs/ext3/namei.c
>> @@ -1019,6 +1019,11 @@ static struct dentry *ext3_lookup(struct inode * dir, struct dentry *dentry, str
>>
>> if (!inode)
>> return ERR_PTR(-EACCES);
>> +
>> + if (is_bad_inode(inode)) {
>> + iput(inode);
>> + return ERR_PTR(-ENOENT);
>> + }
>> }
>> return d_splice_alias(inode, dentry);
>> }
> Seems reasonable. So this prevents the bad inodes from getting onto the
> orphan list in the first place?
make_bad_inode() is called from ext3_read_inode() that is called from iget() only.
When we found that inode is bad we will call iput ASAP. I expect it should be
enough to exclude any chances to call any functions that can include this inode
into orphan list.
ext3_lookup
iget
ext3_read_inode
make_bad_inode
is_bad_inode? --> iput
However am I probably err?
Probably is better to add is_bad_inode check to ext3_orphan_add()?
thank you,
Vasily Averin
next prev parent reply other threads:[~2007-06-05 6:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-04 5:19 [RFC PATCH ext3/ext4] orphan list corruption due bad inode Vasily Averin
2007-06-05 2:03 ` Andrew Morton
2007-06-05 3:52 ` Andreas Dilger
2007-06-05 6:11 ` Vasily Averin [this message]
2007-06-05 6:13 ` Christoph Hellwig
2007-06-05 7:31 ` Vasily Averin
2007-06-05 3:15 ` Eric Sandeen
2007-06-05 6:49 ` Vasily Averin
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=4664FE80.4080801@sw.ru \
--to=vvs@sw.ru \
--cc=adilger@clusterfs.com \
--cc=akpm@linux-foundation.org \
--cc=devel@openvz.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sct@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.