Re: [PATCH] nfs_unlink() race (was: nfs_refresh_inode: inode number mismatch)

From: Linus Torvalds (
Date: Mon Jun 09 2003 - 10:53:09 EST

Good job.

On Mon, 9 Jun 2003, Frank Cusack wrote:
> 1) Don't unhash the dentry after silly-renaming. In 2.2, each fs is
> responsible for doing a d_delete(), in 2.4 it happens in the VFS and
> I think it was just an oversight that the 2.4 VFS doesn't consider
> sillyrename (considering the code and comments that are cruft).
> This preserves the unlinked-but-open semantic, but breaks rmdir. So
> it's not a clear winner from a semantics POV. dentry->d_count is
> always correct, which sounds like a plus.
> The patch to make this work is utterly simple, which is a big plus.

I think your #1 is "obviously correct", but the fact that it breaks rmdir
sounds like a bummer. However, since it only breaks rmdir when
silly-renames exist - and since silly-renames should only happen when you
have a file descriptor still open - I'd be inclined to say that this is
the right behaviour.

> 2b) Since this is really only a problem when the parent dir goes away,
> do the same as above but only scan the queue in nfs_rmdir(), and
> mark any entries whose d_parent is "us".
> I've included this in favor of (2a) because it's simpler and should
> give better performance in the common case.

This sounds like a hack, even if it happens to work.

I dunno. I'm personally inclined to prefer (1), since that seems to just
fix a bug in the VFS layer and doesn't introduce any conceptual
complexity. But I think I'd let Trond make the final decision, I don't
hate (2b) enough to say "over my dead body!".



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun Jun 15 2003 - 22:00:20 EST