From: Peter Staubach <staubach@redhat.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: linux-kernel Mailing List <linux-kernel@vger.kernel.org>,
ext4 development <linux-ext4@vger.kernel.org>,
dmonakhov@sw.ru, alex@clusterfs.com,
Al Viro <viro@ftp.linux.org.uk>
Subject: Re: [PATCH] return ENOENT from ext3_link when racing with unlink
Date: Tue, 16 Jan 2007 17:01:04 -0500 [thread overview]
Message-ID: <45AD4B20.70507@redhat.com> (raw)
In-Reply-To: <45ABC572.2070206@redhat.com>
Eric Sandeen wrote:
> An update from the earlier thread, [PATCH] [RFC] remove ext3 inode
> from orphan list when link and unlink race
>
> I think this is better than the original idea of trying to handle the
> race;
> I've seen that the orphan inode list can get corrupted, but there may
> well
> be other implications of the race which haven't yet been exposed. I
> think
> it's safer to simply return -ENOENT in this race window, and avoid other
> potential problems. Anything wrong with this?
>
> Thanks for the comments suggesting this approach in the prior thread.
>
> Thanks,
>
> -Eric
>
> ---
>
> Return -ENOENT from ext[34]_link if we've raced with unlink and
> i_nlink is 0. Doing otherwise has the potential to corrupt the
> orphan inode list, because we'd wind up with an inode with a
> non-zero link count on the list, and it will never get properly
> cleaned up & removed from the orphan list before it is freed.
>
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>
> Index: linux-2.6.19/fs/ext3/namei.c
> ===================================================================
> --- linux-2.6.19.orig/fs/ext3/namei.c
> +++ linux-2.6.19/fs/ext3/namei.c
> @@ -2191,6 +2191,8 @@ static int ext3_link (struct dentry * ol
>
> if (inode->i_nlink >= EXT3_LINK_MAX)
> return -EMLINK;
> + if (inode->i_nlink == 0)
> + return -ENOENT;
>
> retry:
> handle = ext3_journal_start(dir, EXT3_DATA_TRANS_BLOCKS(dir->i_sb) +
> Index: linux-2.6.19/fs/ext4/namei.c
> ===================================================================
> --- linux-2.6.19.orig/fs/ext4/namei.c
> +++ linux-2.6.19/fs/ext4/namei.c
> @@ -2189,6 +2189,8 @@ static int ext4_link (struct dentry * ol
>
> if (inode->i_nlink >= EXT4_LINK_MAX)
> return -EMLINK;
> + if (inode->i_nlink == 0)
> + return -ENOENT;
>
> retry:
> handle = ext4_journal_start(dir, EXT4_DATA_TRANS_BLOCKS(dir->i_sb) +
>
Just out of curosity, what keeps i_nlink from going to 0 immediately
after the new test is executed?
Thanx...
ps
next prev parent reply other threads:[~2007-01-16 22:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-15 18:18 [PATCH] return ENOENT from ext3_link when racing with unlink Eric Sandeen
2007-01-16 22:01 ` Peter Staubach [this message]
2007-01-16 22:07 ` Alex Tomas
2007-01-16 22:15 ` Peter Staubach
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=45AD4B20.70507@redhat.com \
--to=staubach@redhat.com \
--cc=alex@clusterfs.com \
--cc=dmonakhov@sw.ru \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=viro@ftp.linux.org.uk \
/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.