From: Eric Sandeen <sandeen@redhat.com>
To: linux-kernel Mailing List <linux-kernel@vger.kernel.org>,
ext4 development <linux-ext4@vger.kernel.org>
Cc: dmonakhov@sw.ru, alex@clusterfs.com, Al Viro <viro@ftp.linux.org.uk>
Subject: [PATCH] return ENOENT from ext3_link when racing with unlink
Date: Mon, 15 Jan 2007 12:18:26 -0600 [thread overview]
Message-ID: <45ABC572.2070206@redhat.com> (raw)
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) +
next reply other threads:[~2007-01-15 18:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-15 18:18 Eric Sandeen [this message]
2007-01-16 22:01 ` [PATCH] return ENOENT from ext3_link when racing with unlink Peter Staubach
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=45ABC572.2070206@redhat.com \
--to=sandeen@redhat.com \
--cc=alex@clusterfs.com \
--cc=dmonakhov@sw.ru \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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.