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

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

[Stephen Rothwell]

[-- 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 --]

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

[Eric W. Biederman]

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

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

[Stephen Rothwell]

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

Hi all,

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

  include/linux/kthread.h
  kernel/kthread.c

between commit:

  40966e316f86 ("kthread: Ensure struct kthread is present for all kthreads")

from the userns tree and commit:

  1ac41b3d9ad8 ("kthread: dynamically allocate memory to store kthread's full name")

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/kthread.h
index 4f3433afb54b,a1810374eaa9..000000000000
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@@ -33,7 -33,8 +33,8 @@@ struct task_struct *kthread_create_on_c
  					  unsigned int cpu,
  					  const char *namefmt);
  
+ void get_kthread_comm(char *buf, size_t buf_size, struct task_struct *tsk);
 -void set_kthread_struct(struct task_struct *p);
 +bool set_kthread_struct(struct task_struct *p);
  
  void kthread_set_per_cpu(struct task_struct *k, int cpu);
  bool kthread_is_per_cpu(struct task_struct *k);
diff --cc kernel/kthread.c
index c14707d15341,8be710f2d83d..000000000000
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@@ -94,7 -95,19 +96,19 @@@ static inline struct kthread *__to_kthr
  	return kthread;
  }
  
+ void get_kthread_comm(char *buf, size_t buf_size, struct task_struct *tsk)
+ {
+ 	struct kthread *kthread = to_kthread(tsk);
+ 
+ 	if (!kthread || !kthread->full_name) {
+ 		__get_task_comm(buf, buf_size, tsk);
+ 		return;
+ 	}
+ 
+ 	strscpy_pad(buf, kthread->full_name, buf_size);
+ }
+ 
 -void set_kthread_struct(struct task_struct *p)
 +bool set_kthread_struct(struct task_struct *p)
  {
  	struct kthread *kthread;
  
@@@ -122,13 -128,17 +136,17 @@@ void free_kthread_struct(struct task_st
  	struct kthread *kthread;
  
  	/*
 -	 * Can be NULL if this kthread was created by kernel_thread()
 -	 * or if kmalloc() in kthread() failed.
 +	 * Can be NULL if kmalloc() in set_kthread_struct() failed.
  	 */
  	kthread = to_kthread(k);
+ 	if (!kthread)
+ 		return;
+ 
  #ifdef CONFIG_BLK_CGROUP
- 	WARN_ON_ONCE(kthread && kthread->blkcg_css);
+ 	WARN_ON_ONCE(kthread->blkcg_css);
  #endif
 +	k->set_child_tid = (__force void __user *)NULL;
+ 	kfree(kthread->full_name);
  	kfree(kthread);
  }
  

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

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

[Stephen Rothwell]

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

Hi all,

On Tue, 21 Dec 2021 22:07:34 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the akpm-current tree got conflicts in:
> 
>   include/linux/kthread.h
>   kernel/kthread.c
> 
> between commit:
> 
>   40966e316f86 ("kthread: Ensure struct kthread is present for all kthreads")
> 
> from the userns tree and commit:
> 
>   1ac41b3d9ad8 ("kthread: dynamically allocate memory to store kthread's full name")
> 
> from the akpm-current tree.

With the addition of commit

  329b30af470a ("kthread: Generalize pf_io_worker so it can point to struct kthread")

to the userns tree, the resolution is now as below.

-- 
Cheers,
Stephen Rothwell

diff --cc kernel/kthread.c
index 261a3c3b9c6c,8be710f2d83d..000000000000
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@@ -94,7 -95,19 +96,19 @@@ static inline struct kthread *__to_kthr
  	return kthread;
  }
  
+ void get_kthread_comm(char *buf, size_t buf_size, struct task_struct *tsk)
+ {
+ 	struct kthread *kthread = to_kthread(tsk);
+ 
+ 	if (!kthread || !kthread->full_name) {
+ 		__get_task_comm(buf, buf_size, tsk);
+ 		return;
+ 	}
+ 
+ 	strscpy_pad(buf, kthread->full_name, buf_size);
+ }
+ 
 -void set_kthread_struct(struct task_struct *p)
 +bool set_kthread_struct(struct task_struct *p)
  {
  	struct kthread *kthread;
  
@@@ -118,13 -128,17 +132,17 @@@ void free_kthread_struct(struct task_st
  	struct kthread *kthread;
  
  	/*
 -	 * Can be NULL if this kthread was created by kernel_thread()
 -	 * or if kmalloc() in kthread() failed.
 +	 * Can be NULL if kmalloc() in set_kthread_struct() failed.
  	 */
  	kthread = to_kthread(k);
+ 	if (!kthread)
+ 		return;
+ 
  #ifdef CONFIG_BLK_CGROUP
- 	WARN_ON_ONCE(kthread && kthread->blkcg_css);
+ 	WARN_ON_ONCE(kthread->blkcg_css);
  #endif
 +	k->worker_private = NULL;
+ 	kfree(kthread->full_name);
  	kfree(kthread);
  }
  

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

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Eric W. Biederman]

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

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

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

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

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