From: Christopher Li <chrisl@vmware.com>
To: "Theodore Ts'o" <tytso@mit.edu>,
Jeremy Fitzhardinge <jeremy@goop.org>,
Ext2 devel <ext2-devel@lists.sourceforge.net>,
Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Fix bug in ext3 htree rename: doesn't delete old name, leaves ino with bad nlink
Date: Wed, 6 Nov 2002 17:58:37 -0800 [thread overview]
Message-ID: <20021106175837.B7778@vmware.com> (raw)
In-Reply-To: <20021106224112.GA10130@think.thunk.org>; from tytso@mit.edu on Wed, Nov 06, 2002 at 05:41:12PM -0500
On Wed, Nov 06, 2002 at 05:41:12PM -0500, Theodore Ts'o wrote:
> On Wed, Nov 06, 2002 at 05:24:55PM -0800, Christopher Li wrote:
> >
> > I think we have the lock on ext3_rename. I might be wrong.
> > If other process can change the dir between the add new entry
> > and delete old entry. We should also need to check the entry have
> > been delete from other process in case fall into dead loop?
>
> We take the BKL, yes; but if we need to sleep waiting for a block to
> be read in, that's when another process can run. Yes, that means
> another process could end up deleting the entry out from under us ---
> or make some other change to the directory. I was actually quite
Then the correct fix for the rename problem is very nasty then.
I thought about remove entry first then add new entry. Then if
add new entry fail abort the whole transaction. It looks nasty
also if it sleep in between, the file goes nowhere.
> nervous about this, so I spent some time auditing the code paths of
> when do_split() might sleep, to make sure it would never leave the
> directory in an unstable condition.
>
> Things will actually get easier once we fine-grain lock ext3 (and
> remove the BKL), since we'll very likely end up locking the directory
> during an insert, rename, or delete, and so we don't have to worry
> about things happening in an interleaved fashion.
Agree.
>
> I wasn't able to find your e-mail address in the source file....
> grep -i chrisl fs/ext3/*.c didn't turn up anything?
Sorry, indeed I did not put my email address there. Never mind.
Chris
next prev parent reply other threads:[~2002-11-06 22:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-05 4:47 bug in ext3 htree rename: doesn't delete old name, leaves ino with bad nlink Jeremy Fitzhardinge
2002-11-05 21:24 ` [Ext2-devel] " chrisl
2002-11-06 5:02 ` Jeremy Fitzhardinge
2002-11-06 8:25 ` [PATCH] Fix " chrisl
2002-11-06 8:44 ` Andrew Morton
2002-11-06 21:40 ` Theodore Ts'o
2002-11-07 1:24 ` Christopher Li
2002-11-06 22:41 ` Theodore Ts'o
2002-11-06 22:47 ` Alexander Viro
2002-11-07 2:44 ` Theodore Ts'o
2002-11-07 1:58 ` Christopher Li [this message]
2002-11-06 23:27 ` [Ext2-devel] " Andreas Dilger
-- strict thread matches above, loose matches on Subject: below --
2002-11-07 5:40 [PATCH] Fix bug in ext3 htree rename: doesn't delete old name , " Christopher Li
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=20021106175837.B7778@vmware.com \
--to=chrisl@vmware.com \
--cc=ext2-devel@lists.sourceforge.net \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/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