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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
