linux-kernel - Re: [patch 3/3] vfs: make d_path() consistent across mount operations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <200806231650.16692.agruen@suse.de>
Date:	Mon, 23 Jun 2008 16:50:16 +0200
From:	Andreas Gruenbacher <agruen@...e.de>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Miklos Szeredi <miklos@...redi.hu>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, John Johansen <jjohansen@...e.de>,
	Christoph Hellwig <hch@...radead.org>
Subject: Re: [patch 3/3] vfs: make d_path() consistent across mount operations

On Monday 23 June 2008 16:01:44 Al Viro wrote:
> Umm...  I don't see problems with doing that, but I hope you realize that
> the notion of "ever having that name" is not the same as "pathnam
> resolution on that name ever leading to that file" - path_walk() is *NOT*
> atomic wrt rename() (or mount --move, indeed) and it's quite possible to
> walk into subdirectory, have it moved under you, then see .. as the next
> pathname component and step out into new parent.

Yes, that's understood. Relative lookups don't visit all 
directories up to the root (unless via ".."), so there can be 
infinite time between walking down a directory and computing 
a pathname for it.

> Said that, it makes sense to avoid dropping/regaining the lock in that
> case - it's less work and I don't believe that it would increase contention
> on vfsmount_lock.  So I'm applying that one, just be careful with
> assumptions about consistency, etc. in the general area.

Thanks.

Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/