linux-next: manual merge of the akpm-current tree with the userns tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  fs/exec.c

between commit:

  25cf336de51b ("exec: Remove do_execve_file")

from the userns tree and commit:

  538d50d50815 ("umh: fix refcount underflow in fork_usermode_blob().")

from the akpm-current tree.

I fixed it up (I effectively dropped the akpm-current tree patch since
the former commit means that "file" is no longer passed the affected
function) and can carry the fix as necessary. This is now fixed as far as
linux-next is concerned, but any non trivial conflicts should be mentioned
to your upstream maintainer when your tree is submitted for merging.
You may also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgp4UyWZYnhAA.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the akpm-current tree with the userns tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  fs/binfmt_script.c

between commit:

  ccbb18b67323 ("exec/binfmt_script: Don't modify bprm->buf and then return 
-ENOEXEC")

from the userns tree and commit:

  e20ecf0e2723 ("exec: simplify the copy_strings_kernel calling convention")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/binfmt_script.c
index 0e8b953d12cf,c4fb7f52a46e..
--- a/fs/binfmt_script.c
+++ b/fs/binfmt_script.c
@@@ -110,10 -121,8 +110,10 @@@ static int load_script(struct linux_bin
if (retval < 0)
return retval;
bprm->argc++;
 +  *((char *)i_end) = '\0';
if (i_arg) {
 +  *((char *)i_sep) = '\0';
-   retval = copy_strings_kernel(1, _arg, bprm);
+   retval = copy_string_kernel(i_arg, bprm);
if (retval < 0)
return retval;
bprm->argc++;


pgpDtgpe6LLAU.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the akpm-current tree with the userns tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  include/linux/binfmts.h

between commit:

  96ecee29b0b5 ("exec: Merge install_exec_creds into setup_new_exec")

from the userns tree and commit:

  4bdbcefd2bd8 ("exec: simplify the copy_strings_kernel calling convention")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/binfmts.h
index 1b48e2154766,3d3afe094c97..
--- a/include/linux/binfmts.h
+++ b/include/linux/binfmts.h
@@@ -143,8 -144,8 +143,7 @@@ extern int setup_arg_pages(struct linux
  extern int transfer_args_to_stack(struct linux_binprm *bprm,
  unsigned long *sp_location);
  extern int bprm_change_interp(const char *interp, struct linux_binprm *bprm);
- extern int copy_strings_kernel(int argc, const char *const *argv,
-  struct linux_binprm *bprm);
+ int copy_string_kernel(const char *arg, struct linux_binprm *bprm);
 -extern void install_exec_creds(struct linux_binprm *bprm);
  extern void set_binfmt(struct linux_binfmt *new);
  extern ssize_t read_code(struct file *, unsigned long, loff_t, size_t);
  


pgpHeJxwrviNx.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the akpm-current tree with the userns tree

[Stephen Rothwell]

Hi Andrew,

On Wed, 25 Jan 2017 17:43:22 -0800 Andrew Morton  
wrote:
>
> On Thu, 26 Jan 2017 13:59:23 +1300 ebied...@xmission.com (Eric W. Biederman) 
> wrote:
> 
> > Andrew do you see merit in Aleksa's patch that I don't?  Otherwise can
> > you remove it from your tree?  
> 
> I have done so.

I'll drop it from linux-next on Monday (if there is no new mmotm by then).

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the akpm-current tree with the userns tree

[Stephen Rothwell]

Hi Andrew,

On Wed, 25 Jan 2017 17:43:22 -0800 Andrew Morton  
wrote:
>
> On Thu, 26 Jan 2017 13:59:23 +1300 ebied...@xmission.com (Eric W. Biederman) 
> wrote:
> 
> > Andrew do you see merit in Aleksa's patch that I don't?  Otherwise can
> > you remove it from your tree?  
> 
> I have done so.

I'll drop it from linux-next on Monday (if there is no new mmotm by then).

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the akpm-current tree with the userns tree

[Andrew Morton]

On Thu, 26 Jan 2017 13:59:23 +1300 ebied...@xmission.com (Eric W. Biederman) 
wrote:

> Stephen Rothwell  writes:
> 
> > Hi all,
> >
> > Today's linux-next merge of the akpm-current tree got a conflict in:
> >
> >   fs/proc/base.c
> >
> > between commit:
> >
> >   68eb94f16227 ("proc: Better ownership of files for non-dumpable tasks in 
> > user namespaces")
> >
> > from the userns tree and commit:
> >
> >   d15d29b5352f ("procfs: change the owner of non-dumpable and writeable 
> > files")
> >
> > from the akpm-current tree.
> >
> > I *think* that the former supercedes the latter?
> 
> Sort of.  After a long conversation it turns out what they are trying to
> do is orthogonal.
> 
> The first (mine) is handling the case of non-dumpable tasks in user
> namespaces.
> 
> The second by Aleksa Sarai is trying to trying to relax the permission
> checks in proc so that non-dumpable is not as strict, to sort out some
> runC issues where they are having challenges coding themselves into a
> corner.  In the case of /proc/self I think there may be a case but in
> general relaxing the permission checks in proc gives me the Heebie
> Jeebies.
> 
> Andrew do you see merit in Aleksa's patch that I don't?  Otherwise can
> you remove it from your tree?

I have done so.

Re: linux-next: manual merge of the akpm-current tree with the userns tree

[Andrew Morton]

On Thu, 26 Jan 2017 13:59:23 +1300 ebied...@xmission.com (Eric W. Biederman) 
wrote:

> Stephen Rothwell  writes:
> 
> > Hi all,
> >
> > Today's linux-next merge of the akpm-current tree got a conflict in:
> >
> >   fs/proc/base.c
> >
> > between commit:
> >
> >   68eb94f16227 ("proc: Better ownership of files for non-dumpable tasks in 
> > user namespaces")
> >
> > from the userns tree and commit:
> >
> >   d15d29b5352f ("procfs: change the owner of non-dumpable and writeable 
> > files")
> >
> > from the akpm-current tree.
> >
> > I *think* that the former supercedes the latter?
> 
> Sort of.  After a long conversation it turns out what they are trying to
> do is orthogonal.
> 
> The first (mine) is handling the case of non-dumpable tasks in user
> namespaces.
> 
> The second by Aleksa Sarai is trying to trying to relax the permission
> checks in proc so that non-dumpable is not as strict, to sort out some
> runC issues where they are having challenges coding themselves into a
> corner.  In the case of /proc/self I think there may be a case but in
> general relaxing the permission checks in proc gives me the Heebie
> Jeebies.
> 
> Andrew do you see merit in Aleksa's patch that I don't?  Otherwise can
> you remove it from your tree?

I have done so.

Re: linux-next: manual merge of the akpm-current tree with the userns tree

[Eric W. Biederman]

Stephen Rothwell  writes:

> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
>   fs/proc/base.c
>
> between commit:
>
>   68eb94f16227 ("proc: Better ownership of files for non-dumpable tasks in 
> user namespaces")
>
> from the userns tree and commit:
>
>   d15d29b5352f ("procfs: change the owner of non-dumpable and writeable 
> files")
>
> from the akpm-current tree.
>
> I *think* that the former supercedes the latter?

Sort of.  After a long conversation it turns out what they are trying to
do is orthogonal.

The first (mine) is handling the case of non-dumpable tasks in user
namespaces.

The second by Aleksa Sarai is trying to trying to relax the permission
checks in proc so that non-dumpable is not as strict, to sort out some
runC issues where they are having challenges coding themselves into a
corner.  In the case of /proc/self I think there may be a case but in
general relaxing the permission checks in proc gives me the Heebie
Jeebies.

Andrew do you see merit in Aleksa's patch that I don't?  Otherwise can
you remove it from your tree?

> I fixed it up (I just used the former) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

Stephen thank you for pointing this out.

Eric

Re: linux-next: manual merge of the akpm-current tree with the userns tree

[Eric W. Biederman]

Stephen Rothwell  writes:

> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
>   fs/proc/base.c
>
> between commit:
>
>   68eb94f16227 ("proc: Better ownership of files for non-dumpable tasks in 
> user namespaces")
>
> from the userns tree and commit:
>
>   d15d29b5352f ("procfs: change the owner of non-dumpable and writeable 
> files")
>
> from the akpm-current tree.
>
> I *think* that the former supercedes the latter?

Sort of.  After a long conversation it turns out what they are trying to
do is orthogonal.

The first (mine) is handling the case of non-dumpable tasks in user
namespaces.

The second by Aleksa Sarai is trying to trying to relax the permission
checks in proc so that non-dumpable is not as strict, to sort out some
runC issues where they are having challenges coding themselves into a
corner.  In the case of /proc/self I think there may be a case but in
general relaxing the permission checks in proc gives me the Heebie
Jeebies.

Andrew do you see merit in Aleksa's patch that I don't?  Otherwise can
you remove it from your tree?

> I fixed it up (I just used the former) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

Stephen thank you for pointing this out.

Eric

linux-next: manual merge of the akpm-current tree with the userns tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  fs/proc/base.c

between commit:

  68eb94f16227 ("proc: Better ownership of files for non-dumpable tasks in user 
namespaces")

from the userns tree and commit:

  d15d29b5352f ("procfs: change the owner of non-dumpable and writeable files")

from the akpm-current tree.

I *think* that the former supercedes the latter?

I fixed it up (I just used the former) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the akpm-current tree with the userns tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  fs/proc/base.c

between commit:

  68eb94f16227 ("proc: Better ownership of files for non-dumpable tasks in user 
namespaces")

from the userns tree and commit:

  d15d29b5352f ("procfs: change the owner of non-dumpable and writeable files")

from the akpm-current tree.

I *think* that the former supercedes the latter?

I fixed it up (I just used the former) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the akpm-current tree with the userns tree

[Ian Kent]

On Fri, 2016-09-30 at 17:42 +1000, Stephen Rothwell wrote:
> Hi Andrew,

Hi Stephen,

> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   include/linux/mount.h
> 
> between commit:
> 
>   312ddcb332c3 ("mnt: Add a per mount namespace limit on the number of
> mounts")
> 
> from the userns tree and commit:
> 
>   a0461d15d75c ("vfs: make is_local_mountpoint() usable by others")
> 
> from the akpm-current tree.

Yes, this is a problem.

There is a fundamental flaw in the series surrounding commit a0461d15d75c.

In discussion with Eric it was decided a different approach was needed and I'm
holding back on posting an updated series because I was worried something like
this might happen and didn't want to make matters worse.

I definitely don't want this series to go to the Linus tree and it would be
great if you could drop it from the next tree. Eric's patch should then apply
without change.

I had asked Andrew to drop the series but he must have missed my request.

And I thought they had already been dropped but I must have been looking at an
incorrect branch. I'll need to look at the akpm repo. again.

In the meantime all I can offer is the patch names corresponding to the
descriptions.

They are:
fs-make-is_local_mountpoint-usable-by-others.patch
fs-add-have_local_submounts.patch
autofs-make-mountpoint-checks-namespace-aware.patch
fs-remove-unused-have_submounts-function.patch

Sorry for the inconvenience.
Ian

> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

Re: linux-next: manual merge of the akpm-current tree with the userns tree

[Ian Kent]

On Fri, 2016-09-30 at 17:42 +1000, Stephen Rothwell wrote:
> Hi Andrew,

Hi Stephen,

> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   include/linux/mount.h
> 
> between commit:
> 
>   312ddcb332c3 ("mnt: Add a per mount namespace limit on the number of
> mounts")
> 
> from the userns tree and commit:
> 
>   a0461d15d75c ("vfs: make is_local_mountpoint() usable by others")
> 
> from the akpm-current tree.

Yes, this is a problem.

There is a fundamental flaw in the series surrounding commit a0461d15d75c.

In discussion with Eric it was decided a different approach was needed and I'm
holding back on posting an updated series because I was worried something like
this might happen and didn't want to make matters worse.

I definitely don't want this series to go to the Linus tree and it would be
great if you could drop it from the next tree. Eric's patch should then apply
without change.

I had asked Andrew to drop the series but he must have missed my request.

And I thought they had already been dropped but I must have been looking at an
incorrect branch. I'll need to look at the akpm repo. again.

In the meantime all I can offer is the patch names corresponding to the
descriptions.

They are:
fs-make-is_local_mountpoint-usable-by-others.patch
fs-add-have_local_submounts.patch
autofs-make-mountpoint-checks-namespace-aware.patch
fs-remove-unused-have_submounts-function.patch

Sorry for the inconvenience.
Ian

> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

linux-next: manual merge of the akpm-current tree with the userns tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in:

  include/linux/mount.h

between commit:

  312ddcb332c3 ("mnt: Add a per mount namespace limit on the number of mounts")

from the userns tree and commit:

  a0461d15d75c ("vfs: make is_local_mountpoint() usable by others")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/mount.h
index 1172cce949a4,575b7453325a..
--- a/include/linux/mount.h
+++ b/include/linux/mount.h
@@@ -96,6 -97,12 +97,14 @@@ extern void mark_mounts_for_expiry(stru
  
  extern dev_t name_to_dev_t(const char *name);
  
 +extern unsigned int sysctl_mount_max;
 +
+ extern bool __is_local_mountpoint(struct dentry *dentry);
+ static inline bool is_local_mountpoint(struct dentry *dentry)
+ {
+   if (!d_mountpoint(dentry))
+   return false;
+ 
+   return __is_local_mountpoint(dentry);
+ }
  #endif /* _LINUX_MOUNT_H */

linux-next: manual merge of the akpm-current tree with the userns tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in:

  include/linux/mount.h

between commit:

  312ddcb332c3 ("mnt: Add a per mount namespace limit on the number of mounts")

from the userns tree and commit:

  a0461d15d75c ("vfs: make is_local_mountpoint() usable by others")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/mount.h
index 1172cce949a4,575b7453325a..
--- a/include/linux/mount.h
+++ b/include/linux/mount.h
@@@ -96,6 -97,12 +97,14 @@@ extern void mark_mounts_for_expiry(stru
  
  extern dev_t name_to_dev_t(const char *name);
  
 +extern unsigned int sysctl_mount_max;
 +
+ extern bool __is_local_mountpoint(struct dentry *dentry);
+ static inline bool is_local_mountpoint(struct dentry *dentry)
+ {
+   if (!d_mountpoint(dentry))
+   return false;
+ 
+   return __is_local_mountpoint(dentry);
+ }
  #endif /* _LINUX_MOUNT_H */