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

[Al Viro]

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  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/