From: "J. R. Okajima" <hooanon05@yahoo.co.jp>
To: Nick Piggin <npiggin@gmail.com>
Cc: Nick Piggin <npiggin@kernel.dk>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: vfs-scale, general questions
Date: Thu, 20 Jan 2011 18:05:15 +0900 [thread overview]
Message-ID: <13379.1295514315@jrobl> (raw)
In-Reply-To: <AANLkTi=CqLm=33acFV42N8VbNK9=hwXV9iegKn-jjGJS@mail.gmail.com>
(Some of mail destinations are removed since this is not nfs specific
anymore.)
Nick Piggin:
> > - getcwd(2) needs d_lock?
> > =A0It acquires rename_lock and then tests whether the pwd is removed by
> > =A0d_unhashed(). If a race condition between vfs_rename_dir() which may
> > =A0unhash/rehash the dentry happens, then getcwd() may return the wrong
> > =A0result due to unprotected d_unhashed() call, I am afraid. rename_lock
> > =A0doesn't help this case.
>
> We have the lock in write mode there, so it should exclude that
> particular race. But I need to take another look at this code I
> think, I'm not sure it's completely right, so I would appreciate reviews.
You might think about the race around d_move, but what I meant is the
race between d_unlinked and unhash/rehash.
- getcwd return -ENOENT when pwd is unhashed.
- vfs_rename_dir()
+ makes the existing target unhashed.
+ FS ->rename() is called, here let's assume an error happened. so the
target dir is surely alive and reachable, nothing have been changed.
+ vfs_rename_dir() rehashes it again.
During this unhashed period, getcwd(2) may be issued.
And I am afraid it may return an error incorrectly.
About other issues, I will reply when I have time.
J. R. Okajima
next prev parent reply other threads:[~2011-01-20 9:05 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-13 12:06 NFS root lockups with -next 20110113 Mark Brown
2011-01-13 13:22 ` J. R. Okajima
2011-01-13 13:28 ` Santosh Shilimkar
2011-01-13 13:28 ` Santosh Shilimkar
2011-01-13 13:45 ` J. R. Okajima
2011-01-13 13:45 ` J. R. Okajima
2011-01-14 3:59 ` Nick Piggin
2011-01-14 3:59 ` Nick Piggin
2011-01-14 4:41 ` J. R. Okajima
2011-01-14 4:41 ` J. R. Okajima
2011-01-19 6:43 ` vfs-scale, general questions (Re: NFS root lockups with -next 20110113) J. R. Okajima
2011-01-19 6:43 ` J. R. Okajima
2011-01-19 7:21 ` Nick Piggin
2011-01-19 7:21 ` Nick Piggin
2011-01-20 9:05 ` J. R. Okajima [this message]
2011-01-20 11:15 ` vfs-scale, general questions Miklos Szeredi
2011-01-21 6:38 ` J. R. Okajima
2011-02-11 3:49 ` vfs-scale, general questions (Re: NFS root lockups with -next 20110113) Ian Kent
2011-02-11 3:49 ` Ian Kent
2011-02-13 2:19 ` J. R. Okajima
2011-01-13 13:35 ` NFS root lockups with -next 20110113 Mark Brown
2011-01-13 13:35 ` Mark Brown
2011-01-13 13:35 ` Mark Brown
2011-01-13 13:41 ` Santosh Shilimkar
2011-01-13 13:41 ` Santosh Shilimkar
2011-01-13 13:41 ` Santosh Shilimkar
2011-01-13 13:41 ` Santosh Shilimkar
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=13379.1295514315@jrobl \
--to=hooanon05@yahoo.co.jp \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@gmail.com \
--cc=npiggin@kernel.dk \
/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.