Linux-Next Archive on lore.kernel.org
 help / color / Atom feed
* linux-next: manual merge of the akpm-current tree with the userns tree
@ 2020-05-22 11:55 Stephen Rothwell
  0 siblings, 0 replies; 8+ messages in thread
From: Stephen Rothwell @ 2020-05-22 11:55 UTC (permalink / raw)
  To: Andrew Morton, Eric W. Biederman
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Christoph Hellwig


[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

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..000000000000
--- 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, &i_arg, bprm);
+ 		retval = copy_string_kernel(i_arg, bprm);
  		if (retval < 0)
  			return retval;
  		bprm->argc++;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* linux-next: manual merge of the akpm-current tree with the userns tree
@ 2020-05-12 10:53 Stephen Rothwell
  0 siblings, 0 replies; 8+ messages in thread
From: Stephen Rothwell @ 2020-05-12 10:53 UTC (permalink / raw)
  To: Andrew Morton, Eric W. Biederman
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Christoph Hellwig


[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]

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..000000000000
--- 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);
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the userns tree
  2017-01-26  1:43   ` Andrew Morton
@ 2017-01-26  3:55     ` Stephen Rothwell
  0 siblings, 0 replies; 8+ messages in thread
From: Stephen Rothwell @ 2017-01-26  3:55 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Eric W. Biederman, linux-next, linux-kernel, Aleksa Sarai

Hi Andrew,

On Wed, 25 Jan 2017 17:43:22 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 26 Jan 2017 13:59:23 +1300 ebiederm@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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the userns tree
  2017-01-26  0:59 ` Eric W. Biederman
@ 2017-01-26  1:43   ` Andrew Morton
  2017-01-26  3:55     ` Stephen Rothwell
  0 siblings, 1 reply; 8+ messages in thread
From: Andrew Morton @ 2017-01-26  1:43 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Stephen Rothwell, linux-next, linux-kernel, Aleksa Sarai

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

> Stephen Rothwell <sfr@canb.auug.org.au> 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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the userns tree
  2017-01-25  5:08 Stephen Rothwell
@ 2017-01-26  0:59 ` Eric W. Biederman
  2017-01-26  1:43   ` Andrew Morton
  0 siblings, 1 reply; 8+ messages in thread
From: Eric W. Biederman @ 2017-01-26  0:59 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, Aleksa Sarai

Stephen Rothwell <sfr@canb.auug.org.au> 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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* linux-next: manual merge of the akpm-current tree with the userns tree
@ 2017-01-25  5:08 Stephen Rothwell
  2017-01-26  0:59 ` Eric W. Biederman
  0 siblings, 1 reply; 8+ messages in thread
From: Stephen Rothwell @ 2017-01-25  5:08 UTC (permalink / raw)
  To: Andrew Morton, Eric W. Biederman; +Cc: linux-next, linux-kernel, Aleksa Sarai

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the userns tree
  2016-09-30  7:42 Stephen Rothwell
@ 2016-09-30  9:48 ` Ian Kent
  0 siblings, 0 replies; 8+ messages in thread
From: Ian Kent @ 2016-09-30  9:48 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton, Eric W. Biederman
  Cc: linux-next, linux-kernel

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.
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* linux-next: manual merge of the akpm-current tree with the userns tree
@ 2016-09-30  7:42 Stephen Rothwell
  2016-09-30  9:48 ` Ian Kent
  0 siblings, 1 reply; 8+ messages in thread
From: Stephen Rothwell @ 2016-09-30  7:42 UTC (permalink / raw)
  To: Andrew Morton, Eric W. Biederman; +Cc: linux-next, linux-kernel, Ian Kent

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..000000000000
--- 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 */

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, back to index

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-22 11:55 linux-next: manual merge of the akpm-current tree with the userns tree Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2020-05-12 10:53 Stephen Rothwell
2017-01-25  5:08 Stephen Rothwell
2017-01-26  0:59 ` Eric W. Biederman
2017-01-26  1:43   ` Andrew Morton
2017-01-26  3:55     ` Stephen Rothwell
2016-09-30  7:42 Stephen Rothwell
2016-09-30  9:48 ` Ian Kent

Linux-Next Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-next/0 linux-next/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-next linux-next/ https://lore.kernel.org/linux-next \
		linux-next@vger.kernel.org
	public-inbox-index linux-next

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-next


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git