From: Frank Cusack <fcusack@fcusack.com>
To: viro@parcelfarce.linux.theplanet.co.uk
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>,
torvalds@transmeta.com, marcelo@conectiva.com.br,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] nfs_unlink() race (was: nfs_refresh_inode: inode number mismatch)
Date: Tue, 10 Jun 2003 19:43:33 -0700 [thread overview]
Message-ID: <20030610194333.B18623@google.com> (raw)
In-Reply-To: <20030611022754.GC6754@parcelfarce.linux.theplanet.co.uk>; from viro@parcelfarce.linux.theplanet.co.uk on Wed, Jun 11, 2003 at 03:27:54AM +0100
On Wed, Jun 11, 2003 at 03:27:54AM +0100, viro@parcelfarce.linux.theplanet.co.uk wrote:
> On Wed, Jun 11, 2003 at 03:59:10AM +0200, Trond Myklebust wrote:
> > IOW we just want to prevent VFS from unhashing the dentry in the first
> > place: dentry aliasing cannot work together with sillyrename.
>
> Aliasing could be dealt with. They would have the same inode, so it's
> easy to detect.
dentry only contains the inode, not the fh. On the server, the inode
can go away and come back as a new fh, but with the same inode. Is
that detectable (would comparison hooks have to be added?)? Although,
I guess the inode is enough; you can do an NFS_I(inode)->fh to get
the fh, but I wouldn't guess you'd want that in the VFS. Bah, here
I go again ... forgive me if that's nonsense.
> The real problem is different: what happens if I take
> silly-renamed file and rename it away? You suddenly get ->dir and ->dentry
> if your nfs_unlinkdata having nothing to do with each other.
You could disallow rename if DCACHE_NFSFS_RENAMED is set. That would
be easy and makes sense as an "ok" thing to do. I mean, if you're not
going to allow unlinking of a sillyrenamed file, you may as well disallow
rename as well.
If that's not desirable (again, seems ok to me ... speaking as just a user)
then hey, in rename you just need to check the nfs_delete_queue.
> _If_ we want to be able to work with silly-renamed dentry, we need much
> more careful async unlink. Your current code assumes that these dentries
> won't go anywhere. AFAICS, dcache will not get into inconsistent state,
> but it will have very little to do with state of server...
OK, where else besides rename would the dentry change?
/fc
next prev parent reply other threads:[~2003-06-11 2:30 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-03 23:54 nfs_refresh_inode: inode number mismatch Frank Cusack
2003-06-04 14:19 ` Trond Myklebust
2003-06-04 21:20 ` Frank Cusack
2003-06-04 21:28 ` Trond Myklebust
2003-06-09 13:51 ` [PATCH] nfs_unlink() race (was: nfs_refresh_inode: inode number mismatch) Frank Cusack
2003-06-09 13:55 ` Frank Cusack
2003-06-09 15:53 ` Linus Torvalds
2003-06-09 16:40 ` Trond Myklebust
2003-06-09 20:46 ` Frank Cusack
2003-06-10 0:01 ` Trond Myklebust
2003-06-11 0:54 ` viro
2003-06-11 1:28 ` Frank Cusack
2003-06-11 1:47 ` viro
2003-06-11 2:32 ` Frank Cusack
2003-06-11 2:37 ` viro
2003-06-11 1:59 ` Trond Myklebust
2003-06-11 2:27 ` viro
2003-06-11 2:43 ` Frank Cusack [this message]
2003-06-11 2:50 ` Frank Cusack
2003-06-11 3:00 ` viro
2003-06-11 7:22 ` [PATCH] NFS sillyrename fixes (was: [PATCH] nfs_unlink() race) Frank Cusack
2003-06-13 0:19 ` [PATCH] NFS sillyrename fixes take 3 Frank Cusack
2003-06-11 3:00 ` [PATCH] nfs_unlink() race (was: nfs_refresh_inode: inode number mismatch) Trond Myklebust
2003-06-11 5:30 ` Linus Torvalds
2003-06-11 6:16 ` Andreas Dilger
2003-06-11 12:33 ` Alan Cox
2003-06-11 15:08 ` Linus Torvalds
2003-06-11 15:51 ` Alan Cox
2003-06-11 16:11 ` Linus Torvalds
2003-06-11 16:21 ` Alan Cox
2003-06-11 16:31 ` Linus Torvalds
2003-06-11 16:34 ` viro
2003-06-11 17:22 ` Alan Cox
2003-06-11 17:37 ` Trond Myklebust
2003-06-11 17:47 ` Trond Myklebust
2003-06-12 21:59 ` Jan Harkes
[not found] ` <16103.29804.198545.680701@charged.uio.no>
2003-06-11 22:24 ` Frank Cusack
2003-06-11 23:16 ` Trond Myklebust
2003-06-11 23:35 ` [PATCH] nfs_unlink() race Frank Cusack
2003-06-05 9:11 ` nfs_refresh_inode: inode number mismatch Adrian Cox
2003-06-05 9:13 ` Russell King
2003-06-05 13:51 ` Trond Myklebust
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=20030610194333.B18623@google.com \
--to=fcusack@fcusack.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
--cc=torvalds@transmeta.com \
--cc=trond.myklebust@fys.uio.no \
--cc=viro@parcelfarce.linux.theplanet.co.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).