lkml.org 
[lkml]   [2011]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/6 v7] overlay filesystem - request for inclusion
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...


\
 
 \ /
  Last update: 2011-03-22 20:55    [W:0.073 / U:2.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site