Re: [PATCH 0/6 v7] overlay filesystem - request for inclusion

From: Al Viro
Date: Tue Mar 22 2011 - 15:53:43 EST

On Tue, Mar 22, 2011 at 08:43:17PM +0100, Miklos Szeredi wrote:
> In copy up it does:
> -> lock parent on upper
> -> lock child on upper
> So a setattr with copy up would go like this:
> -> lock child on overlayfs
> -> lock parent on upper
> ->lock child on upper
> -> lock child on upper
> > > Protection is exactly as for userspace callers. AFAICT.
> >
> > Pardon? You traverse the chain of ancestors; fine, but who says it stays
> > anywhere near being relevant as you go?
> Not quite sure I understand.
> There are no assumptions about locks in overlayfs keeping anything
> relevant in upper/lower fs. Everything is re-checked and re-locked on
> the upper layer before proceeding with the rename.

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...
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at