linux-kernel - Re: [PATCH 0/6 v7] overlay filesystem

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <E1Q27qg-0001kq-IO@pomaz-ex.szeredi.hu>
Date:	Tue, 22 Mar 2011 21:06:38 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Al Viro <viro@...IV.linux.org.uk>
CC:	miklos@...redi.hu, torvalds@...ux-foundation.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, apw@...onical.com, nbd@...nwrt.org,
	neilb@...e.de
Subject: Re: [PATCH 0/6 v7] overlay filesystem - request for inclusion

On Tue, 22 Mar 2011, Al Viro wrote:
> Proceeding with rename is not interesting; proceeding with copyup is.
> 
> Who said that by the time we get to copy_up_locked you will still have
> dentry (and upper) match lowerpath?  Or that ->d_parent on overlay and
> on upper will change in sync, for that matter - there are two d_move()
> calls involved...

If rename is involved, than rename itself already did the copy up.
And that's checked before proceeding with the actual copy up.  If
there was no rename, then that guarantees that things are in sync, at
least for the duration of the copy up.

Is that not enough?

Thanks,
Miklos
--
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/