[lkml]   [2013]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: linux-next: build failure after merge of the userns tree
On Thu, Nov 07, 2013 at 11:27:32PM -0800, Christoph Hellwig wrote:
> On Fri, Nov 08, 2013 at 05:58:48PM +1100, Stephen Rothwell wrote:
> > Hi Eric,
> >
> > After merging the userns tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > fs/namei.c: In function 'covered':
> > fs/namei.c:3528:2: error: too many arguments to function '__lookup_mnt'
> > is_covered = d_mountpoint(dentry) && __lookup_mnt(mnt, dentry, 1);
> > ^
> >
> > Caused by my incomplete merge resolution between commits 474279dc0f77
> > ("split __lookup_mnt() in two functions") from the vfs tree and
> > a3b4491433f2 ("vfs: Don't allow overwriting mounts in the current mount
> > namespace") from the userns tree.
> Btw, I don't think the userns tree has any business touching lookup
> and mount semantics in namei.c without an explicit VFS signoff.
> Please drop the tree for now.

I'll probably put some form of that stuff through the vfs.git - the idea
is sane, but I would really like to see Eric's answer to the question
I've asked about the checks he adds in the first commit in this series;
AFAICS, to make them non-racy one needs to change locking rules for mount(2).
As it is, we have namespace_sem held exclusive _and_ ->i_mutex of mountpoint
to be held for all places where we turn something into a mountpoint. His code
appears to assume that we are actually using ->i_mutex on _parent_ instead;
either that, or these checks are deliberately racy.

I'm not saying that change of lock_mount(9) behaviour is out of question -
we could change these locking rules, but such change isn't there in that
series and it's not even discussed there.

 \ /
  Last update: 2013-11-08 17:41    [W:0.043 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site