linux-next.vger.kernel.org archive mirror
 help / color / mirror / 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; 11+ 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] 11+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the userns tree
  2021-10-11  6:41 Stephen Rothwell
@ 2021-10-11 14:03 ` Eric W. Biederman
  0 siblings, 0 replies; 11+ messages in thread
From: Eric W. Biederman @ 2021-10-11 14:03 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Kernel Mailing List,
	Linux Next Mailing List, Nicholas Piggin

Stephen Rothwell <sfr@canb.auug.org.au> writes:

> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
>   kernel/exit.c
>
> between commits:
>
>   d67e03e36161 ("exit: Factor coredump_exit_mm out of exit_mm")
>   92307383082d ("coredump:  Don't perform any cleanups before dumping core")
>
> from the userns tree and commit:
>
>   27692e64c49c ("lazy tlb: introduce lazy mm refcount helper functions")
>
> 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.

Thanks.  This looks like a trivial conflict, and the resolution looks
correct.

Eric


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

* linux-next: manual merge of the akpm-current tree with the userns tree
@ 2021-10-11  6:41 Stephen Rothwell
  2021-10-11 14:03 ` Eric W. Biederman
  0 siblings, 1 reply; 11+ messages in thread
From: Stephen Rothwell @ 2021-10-11  6:41 UTC (permalink / raw)
  To: Andrew Morton, Eric W. Biederman
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Nicholas Piggin

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

Hi all,

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

  kernel/exit.c

between commits:

  d67e03e36161 ("exit: Factor coredump_exit_mm out of exit_mm")
  92307383082d ("coredump:  Don't perform any cleanups before dumping core")

from the userns tree and commit:

  27692e64c49c ("lazy tlb: introduce lazy mm refcount helper functions")

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 kernel/exit.c
index f702a6a63686,8e7b41702ad6..000000000000
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@@ -480,8 -440,42 +480,8 @@@ static void exit_mm(void
  	if (!mm)
  		return;
  	sync_mm_rss(mm);
 -	/*
 -	 * Serialize with any possible pending coredump.
 -	 * We must hold mmap_lock around checking core_state
 -	 * and clearing tsk->mm.  The core-inducing thread
 -	 * will increment ->nr_threads for each thread in the
 -	 * group with ->mm != NULL.
 -	 */
  	mmap_read_lock(mm);
- 	mmgrab(mm);
 -	core_state = mm->core_state;
 -	if (core_state) {
 -		struct core_thread self;
 -
 -		mmap_read_unlock(mm);
 -
 -		self.task = current;
 -		if (self.task->flags & PF_SIGNALED)
 -			self.next = xchg(&core_state->dumper.next, &self);
 -		else
 -			self.task = NULL;
 -		/*
 -		 * Implies mb(), the result of xchg() must be visible
 -		 * to core_state->dumper.
 -		 */
 -		if (atomic_dec_and_test(&core_state->nr_threads))
 -			complete(&core_state->startup);
 -
 -		for (;;) {
 -			set_current_state(TASK_UNINTERRUPTIBLE);
 -			if (!self.task) /* see coredump_finish() */
 -				break;
 -			freezable_schedule();
 -		}
 -		__set_current_state(TASK_RUNNING);
 -		mmap_read_lock(mm);
 -	}
+ 	mmgrab_lazy_tlb(mm);
  	BUG_ON(mm != current->active_mm);
  	/* more a memory barrier than a real lock */
  	task_lock(current);

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

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

* linux-next: manual merge of the akpm-current tree with the userns tree
@ 2020-07-09  7:57 Stephen Rothwell
  0 siblings, 0 replies; 11+ messages in thread
From: Stephen Rothwell @ 2020-07-09  7:57 UTC (permalink / raw)
  To: Andrew Morton, Eric W. Biederman
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Tetsuo Handa

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

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

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

^ permalink raw reply	[flat|nested] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ messages in thread

end of thread, other threads:[~2021-10-11 14:05 UTC | newest]

Thread overview: 11+ 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 --
2021-10-11  6:41 Stephen Rothwell
2021-10-11 14:03 ` Eric W. Biederman
2020-07-09  7:57 Stephen Rothwell
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).