linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the userns tree with Linus' tree
@ 2014-04-09  2:40 Stephen Rothwell
  0 siblings, 0 replies; 19+ messages in thread
From: Stephen Rothwell @ 2014-04-09  2:40 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: linux-next, linux-kernel, Miklos Szeredi

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

Hi Eric,

Today's linux-next merge of the userns tree got a conflict in fs/dcache.c
between commit da1ce0670c14 ("vfs: add cross-rename") from Linus' tree
and commit f43d102a391d ("vfs: Lazily remove mounts on unlinked files and
directories") from the userns tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).  This matches the conflict resolution you sent to Linus.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/dcache.c
index 40707d88a945,5b78bd98649c..000000000000
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@@ -2701,10 -2631,8 +2663,8 @@@ static struct dentry *__d_unalias(struc
  		goto out_err;
  	m2 = &alias->d_parent->d_inode->i_mutex;
  out_unalias:
- 	if (likely(!d_mountpoint(alias))) {
- 		__d_move(alias, dentry, false);
- 		ret = alias;
- 	}
 -	__d_move(alias, dentry);
++	__d_move(alias, dentry, false);
+ 	ret = alias;
  out_err:
  	spin_unlock(&inode->i_lock);
  	if (m2)

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the userns tree with Linus' tree
  2021-06-25  8:22 Stephen Rothwell
@ 2021-06-28  7:16 ` Stephen Rothwell
  0 siblings, 0 replies; 19+ messages in thread
From: Stephen Rothwell @ 2021-06-28  7:16 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Alexey Gladkov, Linux Kernel Mailing List,
	Linux Next Mailing List, Peter Zijlstra, Thomas Gleixner,
	Linus Torvalds

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

Hi all,

On Fri, 25 Jun 2021 18:22:19 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the userns tree got a conflict in:
> 
>   kernel/signal.c
> 
> between commits:
> 
>   69995ebbb9d3 ("signal: Hand SIGQUEUE_PREALLOC flag to __sigqueue_alloc()")
>   4bad58ebc8bc ("signal: Allow tasks to cache one sigqueue struct")
>   399f8dd9a866 ("signal: Prevent sigqueue caching after task got released")
> 
> from Linus' tree and commit:
> 
>   d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of ucounts")
> 
> from the userns tree.

Since commits

  4bad58ebc8bc ("signal: Allow tasks to cache one sigqueue struct")
  399f8dd9a866 ("signal: Prevent sigqueue caching after task got released")

have been reverted in Linus' tree, the conflict resolution is a bit
simpler now:

diff --cc kernel/signal.c
index 20d1d896d5b0,9a6dab712123..de0920353d30
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@@ -408,12 -410,11 +408,12 @@@ void task_join_group_stop(struct task_s
   *   appropriate lock must be held to stop the target task from exiting
   */
  static struct sigqueue *
 -__sigqueue_alloc(int sig, struct task_struct *t, gfp_t flags, int override_rlimit)
 +__sigqueue_alloc(int sig, struct task_struct *t, gfp_t gfp_flags,
 +		 int override_rlimit, const unsigned int sigqueue_flags)
  {
  	struct sigqueue *q = NULL;
- 	struct user_struct *user;
- 	int sigpending;
+ 	struct ucounts *ucounts = NULL;
+ 	long sigpending;
  
  	/*
  	 * Protect access to @t credentials. This can go away when all
@@@ -424,27 -425,26 +424,26 @@@
  	 * changes from/to zero.
  	 */
  	rcu_read_lock();
- 	user = __task_cred(t)->user;
- 	sigpending = atomic_inc_return(&user->sigpending);
+ 	ucounts = task_ucounts(t);
+ 	sigpending = inc_rlimit_ucounts(ucounts, UCOUNT_RLIMIT_SIGPENDING, 1);
  	if (sigpending == 1)
- 		get_uid(user);
+ 		ucounts = get_ucounts(ucounts);
  	rcu_read_unlock();
  
- 	if (override_rlimit || likely(sigpending <= task_rlimit(t, RLIMIT_SIGPENDING))) {
+ 	if (override_rlimit || (sigpending < LONG_MAX && sigpending <= task_rlimit(t, RLIMIT_SIGPENDING))) {
 -		q = kmem_cache_alloc(sigqueue_cachep, flags);
 +		q = kmem_cache_alloc(sigqueue_cachep, gfp_flags);
  	} else {
  		print_dropped_signal(sig);
  	}
  
  	if (unlikely(q == NULL)) {
- 		if (atomic_dec_and_test(&user->sigpending))
- 			free_uid(user);
+ 		if (ucounts && dec_rlimit_ucounts(ucounts, UCOUNT_RLIMIT_SIGPENDING, 1))
+ 			put_ucounts(ucounts);
  	} else {
  		INIT_LIST_HEAD(&q->list);
 -		q->flags = 0;
 +		q->flags = sigqueue_flags;
- 		q->user = user;
+ 		q->ucounts = ucounts;
  	}
- 
  	return q;
  }
  

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: manual merge of the userns tree with Linus' tree
@ 2021-06-25  8:22 Stephen Rothwell
  2021-06-28  7:16 ` Stephen Rothwell
  0 siblings, 1 reply; 19+ messages in thread
From: Stephen Rothwell @ 2021-06-25  8:22 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Alexey Gladkov, Linux Kernel Mailing List,
	Linux Next Mailing List, Peter Zijlstra, Thomas Gleixner

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

Hi all,

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

  kernel/signal.c

between commits:

  69995ebbb9d3 ("signal: Hand SIGQUEUE_PREALLOC flag to __sigqueue_alloc()")
  4bad58ebc8bc ("signal: Allow tasks to cache one sigqueue struct")
  399f8dd9a866 ("signal: Prevent sigqueue caching after task got released")

from Linus' tree and commit:

  d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of ucounts")

from the userns 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/signal.c
index 782951c06660,9a6dab712123..000000000000
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@@ -408,12 -410,11 +408,12 @@@ void task_join_group_stop(struct task_s
   *   appropriate lock must be held to stop the target task from exiting
   */
  static struct sigqueue *
 -__sigqueue_alloc(int sig, struct task_struct *t, gfp_t flags, int override_rlimit)
 +__sigqueue_alloc(int sig, struct task_struct *t, gfp_t gfp_flags,
 +		 int override_rlimit, const unsigned int sigqueue_flags)
  {
  	struct sigqueue *q = NULL;
- 	struct user_struct *user;
- 	int sigpending;
+ 	struct ucounts *ucounts = NULL;
+ 	long sigpending;
  
  	/*
  	 * Protect access to @t credentials. This can go away when all
@@@ -424,42 -425,26 +424,41 @@@
  	 * changes from/to zero.
  	 */
  	rcu_read_lock();
- 	user = __task_cred(t)->user;
- 	sigpending = atomic_inc_return(&user->sigpending);
+ 	ucounts = task_ucounts(t);
+ 	sigpending = inc_rlimit_ucounts(ucounts, UCOUNT_RLIMIT_SIGPENDING, 1);
  	if (sigpending == 1)
- 		get_uid(user);
+ 		ucounts = get_ucounts(ucounts);
  	rcu_read_unlock();
  
- 	if (override_rlimit || likely(sigpending <= task_rlimit(t, RLIMIT_SIGPENDING))) {
+ 	if (override_rlimit || (sigpending < LONG_MAX && sigpending <= task_rlimit(t, RLIMIT_SIGPENDING))) {
 -		q = kmem_cache_alloc(sigqueue_cachep, flags);
 +		/*
 +		 * Preallocation does not hold sighand::siglock so it can't
 +		 * use the cache. The lockless caching requires that only
 +		 * one consumer and only one producer run at a time.
 +		 *
 +		 * For the regular allocation case it is sufficient to
 +		 * check @q for NULL because this code can only be called
 +		 * if the target task @t has not been reaped yet; which
 +		 * means this code can never observe the error pointer which is
 +		 * written to @t->sigqueue_cache in exit_task_sigqueue_cache().
 +		 */
 +		q = READ_ONCE(t->sigqueue_cache);
 +		if (!q || sigqueue_flags)
 +			q = kmem_cache_alloc(sigqueue_cachep, gfp_flags);
 +		else
 +			WRITE_ONCE(t->sigqueue_cache, NULL);
  	} else {
  		print_dropped_signal(sig);
  	}
  
  	if (unlikely(q == NULL)) {
- 		if (atomic_dec_and_test(&user->sigpending))
- 			free_uid(user);
+ 		if (ucounts && dec_rlimit_ucounts(ucounts, UCOUNT_RLIMIT_SIGPENDING, 1))
+ 			put_ucounts(ucounts);
  	} else {
  		INIT_LIST_HEAD(&q->list);
 -		q->flags = 0;
 +		q->flags = sigqueue_flags;
- 		q->user = user;
+ 		q->ucounts = ucounts;
  	}
- 
  	return q;
  }
  
@@@ -507,9 -452,11 +506,11 @@@ static void __sigqueue_free(struct sigq
  {
  	if (q->flags & SIGQUEUE_PREALLOC)
  		return;
- 	if (atomic_dec_and_test(&q->user->sigpending))
- 		free_uid(q->user);
+ 	if (q->ucounts && dec_rlimit_ucounts(q->ucounts, UCOUNT_RLIMIT_SIGPENDING, 1)) {
+ 		put_ucounts(q->ucounts);
+ 		q->ucounts = NULL;
+ 	}
 -	kmem_cache_free(sigqueue_cachep, q);
 +	sigqueue_cache_or_free(q);
  }
  
  void flush_sigqueue(struct sigpending *queue)

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

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

* linux-next: manual merge of the userns tree with Linus' tree
@ 2021-05-26  4:51 Stephen Rothwell
  0 siblings, 0 replies; 19+ messages in thread
From: Stephen Rothwell @ 2021-05-26  4:51 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Alexey Gladkov, Linux Kernel Mailing List,
	Linux Next Mailing List, Peter Zijlstra (Intel),
	Thomas Gleixner

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

Hi all,

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

  kernel/signal.c

between commits:

  69995ebbb9d3 ("signal: Hand SIGQUEUE_PREALLOC flag to __sigqueue_alloc()")
  4bad58ebc8bc ("signal: Allow tasks to cache one sigqueue struct")

from Linus' tree and commit:

  d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of ucounts")

from the userns 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/signal.c
index f7c6ffcbd044,9a6dab712123..000000000000
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@@ -408,12 -410,11 +408,12 @@@ void task_join_group_stop(struct task_s
   *   appropriate lock must be held to stop the target task from exiting
   */
  static struct sigqueue *
 -__sigqueue_alloc(int sig, struct task_struct *t, gfp_t flags, int override_rlimit)
 +__sigqueue_alloc(int sig, struct task_struct *t, gfp_t gfp_flags,
 +		 int override_rlimit, const unsigned int sigqueue_flags)
  {
  	struct sigqueue *q = NULL;
- 	struct user_struct *user;
- 	int sigpending;
+ 	struct ucounts *ucounts = NULL;
+ 	long sigpending;
  
  	/*
  	 * Protect access to @t credentials. This can go away when all
@@@ -424,36 -425,26 +424,35 @@@
  	 * changes from/to zero.
  	 */
  	rcu_read_lock();
- 	user = __task_cred(t)->user;
- 	sigpending = atomic_inc_return(&user->sigpending);
+ 	ucounts = task_ucounts(t);
+ 	sigpending = inc_rlimit_ucounts(ucounts, UCOUNT_RLIMIT_SIGPENDING, 1);
  	if (sigpending == 1)
- 		get_uid(user);
+ 		ucounts = get_ucounts(ucounts);
  	rcu_read_unlock();
  
- 	if (override_rlimit || likely(sigpending <= task_rlimit(t, RLIMIT_SIGPENDING))) {
+ 	if (override_rlimit || (sigpending < LONG_MAX && sigpending <= task_rlimit(t, RLIMIT_SIGPENDING))) {
 -		q = kmem_cache_alloc(sigqueue_cachep, flags);
 +		/*
 +		 * Preallocation does not hold sighand::siglock so it can't
 +		 * use the cache. The lockless caching requires that only
 +		 * one consumer and only one producer run at a time.
 +		 */
 +		q = READ_ONCE(t->sigqueue_cache);
 +		if (!q || sigqueue_flags)
 +			q = kmem_cache_alloc(sigqueue_cachep, gfp_flags);
 +		else
 +			WRITE_ONCE(t->sigqueue_cache, NULL);
  	} else {
  		print_dropped_signal(sig);
  	}
  
  	if (unlikely(q == NULL)) {
- 		if (atomic_dec_and_test(&user->sigpending))
- 			free_uid(user);
+ 		if (ucounts && dec_rlimit_ucounts(ucounts, UCOUNT_RLIMIT_SIGPENDING, 1))
+ 			put_ucounts(ucounts);
  	} else {
  		INIT_LIST_HEAD(&q->list);
 -		q->flags = 0;
 +		q->flags = sigqueue_flags;
- 		q->user = user;
+ 		q->ucounts = ucounts;
  	}
- 
  	return q;
  }
  
@@@ -492,9 -452,11 +491,11 @@@ static void __sigqueue_free(struct sigq
  {
  	if (q->flags & SIGQUEUE_PREALLOC)
  		return;
- 	if (atomic_dec_and_test(&q->user->sigpending))
- 		free_uid(q->user);
+ 	if (q->ucounts && dec_rlimit_ucounts(q->ucounts, UCOUNT_RLIMIT_SIGPENDING, 1)) {
+ 		put_ucounts(q->ucounts);
+ 		q->ucounts = NULL;
+ 	}
 -	kmem_cache_free(sigqueue_cachep, q);
 +	sigqueue_cache_or_free(q);
  }
  
  void flush_sigqueue(struct sigpending *queue)

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

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

* linux-next: manual merge of the userns tree with Linus' tree
@ 2021-05-26  4:38 Stephen Rothwell
  0 siblings, 0 replies; 19+ messages in thread
From: Stephen Rothwell @ 2021-05-26  4:38 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Alexey Gladkov, Amir Goldstein, Jan Kara,
	Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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

  include/linux/user_namespace.h

between commit:

  5b8fea65d197 ("fanotify: configurable limits via sysfs")

from Linus' tree and commits:

  21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts")
  6e52a9f0532f ("Reimplement RLIMIT_MSGQUEUE on top of ucounts")
  d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of ucounts")
  d7c9e99aee48 ("Reimplement RLIMIT_MEMLOCK on top of ucounts")

from the userns 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/user_namespace.h
index 1d08dbbcfe32,61794ae32fa8..000000000000
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@@ -49,11 -49,11 +49,15 @@@ enum ucount_type 
  #ifdef CONFIG_INOTIFY_USER
  	UCOUNT_INOTIFY_INSTANCES,
  	UCOUNT_INOTIFY_WATCHES,
 +#endif
 +#ifdef CONFIG_FANOTIFY
 +	UCOUNT_FANOTIFY_GROUPS,
 +	UCOUNT_FANOTIFY_MARKS,
  #endif
+ 	UCOUNT_RLIMIT_NPROC,
+ 	UCOUNT_RLIMIT_MSGQUEUE,
+ 	UCOUNT_RLIMIT_SIGPENDING,
+ 	UCOUNT_RLIMIT_MEMLOCK,
  	UCOUNT_COUNTS,
  };
  

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

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

* linux-next: manual merge of the userns tree with Linus' tree
@ 2021-05-26  4:32 Stephen Rothwell
  0 siblings, 0 replies; 19+ messages in thread
From: Stephen Rothwell @ 2021-05-26  4:32 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Alexey Gladkov, Amir Goldstein, Jan Kara,
	Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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

  include/linux/sched/user.h

between commit:

  5b8fea65d197 ("fanotify: configurable limits via sysfs")

from Linus' tree and commits:

  21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts")
  d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of ucounts")

from the userns 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/sched/user.h
index 3632c5d6ec55,82bd2532da6b..000000000000
--- a/include/linux/sched/user.h
+++ b/include/linux/sched/user.h
@@@ -12,8 -12,9 +12,6 @@@
   */
  struct user_struct {
  	refcount_t __count;	/* reference count */
- 	atomic_t processes;	/* How many processes does this user have? */
- 	atomic_t sigpending;	/* How many pending signals does this user have? */
 -#ifdef CONFIG_FANOTIFY
 -	atomic_t fanotify_listeners;
 -#endif
  #ifdef CONFIG_EPOLL
  	atomic_long_t epoll_watches; /* The number of file descriptors currently watched */
  #endif

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

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

* Re: linux-next: manual merge of the userns tree with Linus' tree
  2016-11-22 17:44 ` Eric W. Biederman
@ 2016-11-22 22:56   ` Stephen Rothwell
  0 siblings, 0 replies; 19+ messages in thread
From: Stephen Rothwell @ 2016-11-22 22:56 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: linux-next, linux-kernel, Lorenzo Stoakes

Hi Eric,

On Tue, 22 Nov 2016 11:44:25 -0600 ebiederm@xmission.com (Eric W. Biederman) wrote:
>
> > I just used the version of the userns tree from next-20161117 for today.
> > Please merge v4.9-rc2 and fix up the conflicts (or just rebase onto
> > v4.9-rc2).  
> 
> Will do.  Thank you.

Thanks.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: manual merge of the userns tree with Linus' tree
  2016-11-22  8:17 Stephen Rothwell
@ 2016-11-22 17:44 ` Eric W. Biederman
  2016-11-22 22:56   ` Stephen Rothwell
  0 siblings, 1 reply; 19+ messages in thread
From: Eric W. Biederman @ 2016-11-22 17:44 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Lorenzo Stoakes

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

> Hi Eric,
>
> Today's linux-next merge of the userns tree got conflicts in:
>
>   arch/alpha/kernel/ptrace.c
>   arch/blackfin/kernel/ptrace.c
>   arch/cris/arch-v32/kernel/ptrace.c
>   arch/ia64/kernel/ptrace.c
>   arch/mips/kernel/ptrace32.c
>   arch/powerpc/kernel/ptrace32.c
>   include/linux/mm.h
>   kernel/ptrace.c
>   mm/memory.c
>   mm/nommu.c
>
> between commit:
>
>   442486ec1096 ("mm: replace __access_remote_vm() write parameter with gup_flags")
> (and others)
>
> from Linus' tree and commit:
>
>   0cabf9a438e1 ("ptrace: Don't allow accessing an undumpable mm")
>
> from the userns tree.
>
> I just used the version of the userns tree from next-20161117 for today.
> Please merge v4.9-rc2 and fix up the conflicts (or just rebase onto
> v4.9-rc2).

Will do.  Thank you.

Eric

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

* linux-next: manual merge of the userns tree with Linus' tree
@ 2016-11-22  8:17 Stephen Rothwell
  2016-11-22 17:44 ` Eric W. Biederman
  0 siblings, 1 reply; 19+ messages in thread
From: Stephen Rothwell @ 2016-11-22  8:17 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: linux-next, linux-kernel, Lorenzo Stoakes

Hi Eric,

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

  arch/alpha/kernel/ptrace.c
  arch/blackfin/kernel/ptrace.c
  arch/cris/arch-v32/kernel/ptrace.c
  arch/ia64/kernel/ptrace.c
  arch/mips/kernel/ptrace32.c
  arch/powerpc/kernel/ptrace32.c
  include/linux/mm.h
  kernel/ptrace.c
  mm/memory.c
  mm/nommu.c

between commit:

  442486ec1096 ("mm: replace __access_remote_vm() write parameter with gup_flags")
(and others)

from Linus' tree and commit:

  0cabf9a438e1 ("ptrace: Don't allow accessing an undumpable mm")

from the userns tree.

I just used the version of the userns tree from next-20161117 for today.
Please merge v4.9-rc2 and fix up the conflicts (or just rebase onto
v4.9-rc2).

-- 
Cheers,
Stephen Rothwell

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

* linux-next: manual merge of the userns tree with Linus' tree
@ 2016-07-08  6:13 Stephen Rothwell
  0 siblings, 0 replies; 19+ messages in thread
From: Stephen Rothwell @ 2016-07-08  6:13 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: linux-next, linux-kernel, Andreas Gruenbacher, J. Bruce Fields

Hi Eric,

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

  fs/posix_acl.c

between commit:

  485e71e8fb63 ("posix_acl: Add set_posix_acl")

from Linus' tree and commit:

  0d4d717f2583 ("vfs: Verify acls are valid within superblock's s_user_ns.")

from the userns 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/posix_acl.c
index edc452c2a563,647c28180675..000000000000
--- a/fs/posix_acl.c
+++ b/fs/posix_acl.c
@@@ -833,24 -839,6 +833,24 @@@ set_posix_acl(struct inode *inode, int 
  	if (!inode_owner_or_capable(inode))
  		return -EPERM;
  
 +	if (acl) {
- 		int ret = posix_acl_valid(acl);
++		int ret = posix_acl_valid(inode->i_sb->s_user_ns, acl);
 +		if (ret)
 +			return ret;
 +	}
 +	return inode->i_op->set_acl(inode, acl, type);
 +}
 +EXPORT_SYMBOL(set_posix_acl);
 +
 +static int
 +posix_acl_xattr_set(const struct xattr_handler *handler,
 +		    struct dentry *unused, struct inode *inode,
 +		    const char *name, const void *value,
 +		    size_t size, int flags)
 +{
 +	struct posix_acl *acl = NULL;
 +	int ret;
 +
  	if (value) {
  		acl = posix_acl_from_xattr(&init_user_ns, value, size);
  		if (IS_ERR(acl))

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

* linux-next: manual merge of the userns tree with Linus' tree
@ 2016-06-24  4:41 Stephen Rothwell
  0 siblings, 0 replies; 19+ messages in thread
From: Stephen Rothwell @ 2016-06-24  4:41 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: linux-next, linux-kernel, Jann Horn, Linus

Hi Eric,

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

  fs/proc/root.c

between commit:

  e54ad7f1ee26 ("proc: prevent stacking filesystems on top")

from Linus' tree and commit:

  e94591d0d90c ("proc: Convert proc_mount to use mount_ns")

from the userns tree.

I fixed it up (I used the userns version of this file and added the
following patch) 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.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 24 Jun 2016 14:27:47 +1000
Subject: [PATCH] proc: fixup for "prevent stacking filesystems on top"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/proc/inode.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/fs/proc/inode.c b/fs/proc/inode.c
index a5b2c33745b7..6b1843e78bd7 100644
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -463,6 +463,13 @@ int proc_fill_super(struct super_block *s, void *data, int silent)
 	struct inode *root_inode;
 	int ret;
 
+	/*
+	 * procfs isn't actually a stacking filesystem; however, there is
+	 * too much magic going on inside it to permit stacking things on
+	 * top of it
+	 */
+	s->s_stack_depth = FILESYSTEM_MAX_STACK_DEPTH;
+
 	if (!proc_parse_options(data, ns))
 		return -EINVAL;
 
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: manual merge of the userns tree with Linus' tree
  2014-04-17  8:44   ` Eric W. Biederman
@ 2014-04-22  1:37     ` Stephen Rothwell
  0 siblings, 0 replies; 19+ messages in thread
From: Stephen Rothwell @ 2014-04-22  1:37 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: Al Viro, linux-next, linux-kernel, David Howells

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

On Thu, 17 Apr 2014 01:44:21 -0700 ebiederm@xmission.com (Eric W. Biederman) wrote:
>
> Al Viro <viro@ZenIV.linux.org.uk> writes:
> 
> > On Thu, Apr 17, 2014 at 03:06:57PM +1000, Stephen Rothwell wrote:
> >> Hi Eric,
> >> 
> >> Today's linux-next merge of the userns tree got a conflict in
> >> fs/namespace.c between various commits from Linus' tree and various
> >> commits from the userns tree.
> >> 
> >> I fixed it up (hopefully - see below) and can carry the fix as necessary
> >> (no action is required).
> >
> > Various commits include this:
> > commit 38129a13e6e71f666e0468e99fdd932a687b4d7e
> > Author: Al Viro <viro@zeniv.linux.org.uk>
> > Date:   Thu Mar 20 21:10:51 2014 -0400
> >
> >     switch mnt_hash to hlist
> >
> > present in v3.14...  It's been there since before the merge window.
> 
> And the code that is in conflict is even older.  
> 
> I just figured out of an abundance of caution I would make certain the
> code was out there for automatic and semi-automatic things to pound on
> before I resent my pull request to Linus, now that I have fixed the
> stack overflow issue you were complaining about.
> 
> I suspect something about fixing mntput caused Stephen to loose his
> trivial resolution for this trivial conflict.

That would be the three extra commits you added that touched that file -
it throws "git rerere" off and I didn't recognise the source of the
problem.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the userns tree with Linus' tree
  2014-04-17  5:25 ` Al Viro
@ 2014-04-17  8:44   ` Eric W. Biederman
  2014-04-22  1:37     ` Stephen Rothwell
  0 siblings, 1 reply; 19+ messages in thread
From: Eric W. Biederman @ 2014-04-17  8:44 UTC (permalink / raw)
  To: Al Viro; +Cc: Stephen Rothwell, linux-next, linux-kernel, David Howells

Al Viro <viro@ZenIV.linux.org.uk> writes:

> On Thu, Apr 17, 2014 at 03:06:57PM +1000, Stephen Rothwell wrote:
>> Hi Eric,
>> 
>> Today's linux-next merge of the userns tree got a conflict in
>> fs/namespace.c between various commits from Linus' tree and various
>> commits from the userns tree.
>> 
>> I fixed it up (hopefully - see below) and can carry the fix as necessary
>> (no action is required).
>
> Various commits include this:
> commit 38129a13e6e71f666e0468e99fdd932a687b4d7e
> Author: Al Viro <viro@zeniv.linux.org.uk>
> Date:   Thu Mar 20 21:10:51 2014 -0400
>
>     switch mnt_hash to hlist
>
> present in v3.14...  It's been there since before the merge window.

And the code that is in conflict is even older.  

I just figured out of an abundance of caution I would make certain the
code was out there for automatic and semi-automatic things to pound on
before I resent my pull request to Linus, now that I have fixed the
stack overflow issue you were complaining about.

I suspect something about fixing mntput caused Stephen to loose his
trivial resolution for this trivial conflict.

Eric

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

* Re: linux-next: manual merge of the userns tree with Linus' tree
  2014-04-17  5:06 Stephen Rothwell
@ 2014-04-17  5:25 ` Al Viro
  2014-04-17  8:44   ` Eric W. Biederman
  0 siblings, 1 reply; 19+ messages in thread
From: Al Viro @ 2014-04-17  5:25 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Eric W. Biederman, linux-next, linux-kernel, David Howells

On Thu, Apr 17, 2014 at 03:06:57PM +1000, Stephen Rothwell wrote:
> Hi Eric,
> 
> Today's linux-next merge of the userns tree got a conflict in
> fs/namespace.c between various commits from Linus' tree and various
> commits from the userns tree.
> 
> I fixed it up (hopefully - see below) and can carry the fix as necessary
> (no action is required).

Various commits include this:
commit 38129a13e6e71f666e0468e99fdd932a687b4d7e
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Thu Mar 20 21:10:51 2014 -0400

    switch mnt_hash to hlist

present in v3.14...  It's been there since before the merge window.

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

* linux-next: manual merge of the userns tree with Linus' tree
@ 2014-04-17  5:06 Stephen Rothwell
  2014-04-17  5:25 ` Al Viro
  0 siblings, 1 reply; 19+ messages in thread
From: Stephen Rothwell @ 2014-04-17  5:06 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: linux-next, linux-kernel, Al Viro, David Howells

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

Hi Eric,

Today's linux-next merge of the userns tree got a conflict in
fs/namespace.c between various commits from Linus' tree and various
commits from the userns tree.

I fixed it up (hopefully - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/namespace.c
index 182bc41cd887,128c051041be..000000000000
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@@ -667,13 -632,47 +668,47 @@@ struct vfsmount *lookup_mnt(struct pat
  	return m;
  }
  
- static struct mountpoint *new_mountpoint(struct dentry *dentry)
+ /*
+  * __is_local_mountpoint - Test to see if dentry is a mountpoint in the
+  *                         current mount namespace.
+  *
+  * The common case is dentries are not mountpoints at all and that
+  * test is handled inline.  For the slow case when we are actually
+  * dealing with a mountpoint of some kind, walk through all of the
+  * mounts in the current mount namespace and test to see if the dentry
+  * is a mountpoint.
+  *
+  * The mount_hashtable is not usable in the context because we
+  * need to identify all mounts that may be in the current mount
+  * namespace not just a mount that happens to have some specified
+  * parent mount.
+  */
+ bool __is_local_mountpoint(struct dentry *dentry)
+ {
+ 	struct mnt_namespace *ns = current->nsproxy->mnt_ns;
+ 	struct mount *mnt;
+ 	bool is_covered = false;
+ 
+ 	if (!d_mountpoint(dentry))
+ 		goto out;
+ 
+ 	down_read(&namespace_sem);
+ 	list_for_each_entry(mnt, &ns->list, mnt_list) {
+ 		is_covered = (mnt->mnt_mountpoint == dentry);
+ 		if (is_covered)
+ 			break;
+ 	}
+ 	up_read(&namespace_sem);
+ out:
+ 	return is_covered;
+ }
+ 
+ static struct mountpoint *lookup_mountpoint(struct dentry *dentry)
  {
 -	struct list_head *chain = mountpoint_hashtable + hash(NULL, dentry);
 +	struct hlist_head *chain = mp_hash(dentry);
  	struct mountpoint *mp;
- 	int ret;
  
 -	list_for_each_entry(mp, chain, m_hash) {
 +	hlist_for_each_entry(mp, chain, m_hash) {
  		if (mp->m_dentry == dentry) {
  			/* might be worth a WARN_ON() */
  			if (d_unlinked(dentry))
@@@ -695,7 -702,8 +738,8 @@@ static struct mountpoint *new_mountpoin
  
  	mp->m_dentry = dentry;
  	mp->m_count = 1;
 -	list_add(&mp->m_hash, chain);
 +	hlist_add_head(&mp->m_hash, chain);
+ 	INIT_LIST_HEAD(&mp->m_list);
  	return mp;
  }
  
@@@ -748,7 -757,8 +793,8 @@@ static void detach_mnt(struct mount *mn
  	mnt->mnt_parent = mnt;
  	mnt->mnt_mountpoint = mnt->mnt.mnt_root;
  	list_del_init(&mnt->mnt_child);
 -	list_del_init(&mnt->mnt_hash);
 +	hlist_del_init_rcu(&mnt->mnt_hash);
+ 	list_del_init(&mnt->mnt_mp_list);
  	put_mountpoint(mnt->mnt_mp);
  	mnt->mnt_mp = NULL;
  }
@@@ -936,9 -943,35 +983,25 @@@ static struct mount *clone_mnt(struct m
  	return ERR_PTR(err);
  }
  
 -static void delayed_free(struct rcu_head *head)
 -{
 -	struct mount *mnt = container_of(head, struct mount, mnt_rcu);
 -	kfree(mnt->mnt_devname);
 -#ifdef CONFIG_SMP
 -	free_percpu(mnt->mnt_pcp);
 -#endif
 -	kmem_cache_free(mnt_cache, mnt);
 -}
 -
+ static void cleanup_mnt(struct mount *mnt)
+ {
+ 	fsnotify_vfsmount_delete(&mnt->mnt);
+ 	dput(mnt->mnt.mnt_root);
+ 	deactivate_super(mnt->mnt.mnt_sb);
+ 	mnt_free_id(mnt);
+ 	complete(mnt->mnt_undone);
 -	call_rcu(&mnt->mnt_rcu, delayed_free);
++	call_rcu(&mnt->mnt_rcu, delayed_free_vfsmnt);
+ }
+ 
+ static void cleanup_mnt_work(struct work_struct *work)
+ {
+ 	cleanup_mnt(container_of(work, struct mount, mnt_cleanup_work));
+ }
+ 
  static void mntput_no_expire(struct mount *mnt)
  {
- put_again:
+ 	struct completion undone;
+ 
  	rcu_read_lock();
  	mnt_add_count(mnt, -1);
  	if (likely(mnt->mnt_ns)) { /* shouldn't be the last one */

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the userns tree with Linus' tree
@ 2014-04-09  2:45 Stephen Rothwell
  0 siblings, 0 replies; 19+ messages in thread
From: Stephen Rothwell @ 2014-04-09  2:45 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: linux-next, linux-kernel, Al Viro

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

Hi Eric,

Today's linux-next merge of the userns tree got a conflict in
fs/namespace.c between commits  from Linus' tree and commits from the
userns tree.

I fixed it up (I used the conflict resolution that your sent to Linus -
see below) and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/namespace.c
index 2ffc5a2905d4,52f4174e294c..000000000000
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@@ -665,13 -632,47 +666,47 @@@ struct vfsmount *lookup_mnt(struct pat
  	return m;
  }
  
- static struct mountpoint *new_mountpoint(struct dentry *dentry)
+ /*
+  * __is_local_mountpoint - Test to see if dentry is a mountpoint in the
+  *                         current mount namespace.
+  *
+  * The common case is dentries are not mountpoints at all and that
+  * test is handled inline.  For the slow case when we are actually
+  * dealing with a mountpoint of some kind, walk through all of the
+  * mounts in the current mount namespace and test to see if the dentry
+  * is a mountpoint.
+  *
+  * The mount_hashtable is not usable in the context because we
+  * need to identify all mounts that may be in the current mount
+  * namespace not just a mount that happens to have some specified
+  * parent mount.
+  */
+ bool __is_local_mountpoint(struct dentry *dentry)
+ {
+ 	struct mnt_namespace *ns = current->nsproxy->mnt_ns;
+ 	struct mount *mnt;
+ 	bool is_covered = false;
+ 
+ 	if (!d_mountpoint(dentry))
+ 		goto out;
+ 
+ 	down_read(&namespace_sem);
+ 	list_for_each_entry(mnt, &ns->list, mnt_list) {
+ 		is_covered = (mnt->mnt_mountpoint == dentry);
+ 		if (is_covered)
+ 			break;
+ 	}
+ 	up_read(&namespace_sem);
+ out:
+ 	return is_covered;
+ }
+ 
+ static struct mountpoint *lookup_mountpoint(struct dentry *dentry)
  {
 -	struct list_head *chain = mountpoint_hashtable + hash(NULL, dentry);
 +	struct hlist_head *chain = mp_hash(dentry);
  	struct mountpoint *mp;
- 	int ret;
  
 -	list_for_each_entry(mp, chain, m_hash) {
 +	hlist_for_each_entry(mp, chain, m_hash) {
  		if (mp->m_dentry == dentry) {
  			/* might be worth a WARN_ON() */
  			if (d_unlinked(dentry))
@@@ -680,6 -681,14 +715,14 @@@
  			return mp;
  		}
  	}
+ 	return NULL;
+ }
+ 
+ static struct mountpoint *new_mountpoint(struct dentry *dentry)
+ {
 -	struct list_head *chain = mountpoint_hashtable + hash(NULL, dentry);
++	struct hlist_head *chain = mp_hash(dentry);
+ 	struct mountpoint *mp;
+ 	int ret;
  
  	mp = kmalloc(sizeof(struct mountpoint), GFP_KERNEL);
  	if (!mp)
@@@ -693,7 -702,8 +736,8 @@@
  
  	mp->m_dentry = dentry;
  	mp->m_count = 1;
 -	list_add(&mp->m_hash, chain);
 +	hlist_add_head(&mp->m_hash, chain);
+ 	INIT_LIST_HEAD(&mp->m_list);
  	return mp;
  }
  
@@@ -746,7 -757,8 +791,8 @@@ static void detach_mnt(struct mount *mn
  	mnt->mnt_parent = mnt;
  	mnt->mnt_mountpoint = mnt->mnt.mnt_root;
  	list_del_init(&mnt->mnt_child);
 -	list_del_init(&mnt->mnt_hash);
 +	hlist_del_init_rcu(&mnt->mnt_hash);
+ 	list_del_init(&mnt->mnt_mp_list);
  	put_mountpoint(mnt->mnt_mp);
  	mnt->mnt_mp = NULL;
  }


[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the userns tree with Linus' tree
@ 2014-04-09  2:39 Stephen Rothwell
  0 siblings, 0 replies; 19+ messages in thread
From: Stephen Rothwell @ 2014-04-09  2:39 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: linux-next, linux-kernel

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

Hi Eric,

Today's linux-next merge of the userns tree got a conflict in fs/namei.c
between commits from Linus' tree and commits 3dd905eaa258 ("vfs: Don't
allow overwriting mounts in the current mount namespace") and
f43d102a391d ("vfs: Lazily remove mounts on unlinked files and
directories") from the userns tree.

I fixed it up (I used the conflict resolution that you sent to Linus -
see below) and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/namei.c
index 88339f59efb5,384fcc6a5606..000000000000
--- a/fs/namei.c
+++ b/fs/namei.c
@@@ -4082,33 -4045,17 +4085,33 @@@ int vfs_rename(struct inode *old_dir, s
  	if (error)
  		return error;
  
 +	old_name = fsnotify_oldname_init(old_dentry->d_name.name);
  	dget(new_dentry);
 -	lock_two_nondirectories(source, target);
 +	if (!is_dir || (flags & RENAME_EXCHANGE))
 +		lock_two_nondirectories(source, target);
 +	else if (target)
 +		mutex_lock(&target->i_mutex);
  
  	error = -EBUSY;
- 	if (d_mountpoint(old_dentry) || d_mountpoint(new_dentry))
+ 	if (is_local_mountpoint(old_dentry) || is_local_mountpoint(new_dentry))
  		goto out;
  
 -	error = try_break_deleg(source, delegated_inode);
 -	if (error)
 -		goto out;
 -	if (target) {
 +	if (max_links && new_dir != old_dir) {
 +		error = -EMLINK;
 +		if (is_dir && !new_is_dir && new_dir->i_nlink >= max_links)
 +			goto out;
 +		if ((flags & RENAME_EXCHANGE) && !is_dir && new_is_dir &&
 +		    old_dir->i_nlink >= max_links)
 +			goto out;
 +	}
 +	if (is_dir && !(flags & RENAME_EXCHANGE) && target)
 +		shrink_dcache_parent(new_dentry);
 +	if (!is_dir) {
 +		error = try_break_deleg(source, delegated_inode);
 +		if (error)
 +			goto out;
 +	}
 +	if (target && !new_is_dir) {
  		error = try_break_deleg(target, delegated_inode);
  		if (error)
  			goto out;
@@@ -4123,31 -4064,73 +4126,32 @@@
  	if (error)
  		goto out;
  
 -	if (target) {
 +	if (!(flags & RENAME_EXCHANGE) && target) {
 +		if (is_dir)
 +			target->i_flags |= S_DEAD;
  		dont_mount(new_dentry);
+ 		detach_mounts(new_dentry);
  	}
 -	if (!(old_dir->i_sb->s_type->fs_flags & FS_RENAME_DOES_D_MOVE))
 -		d_move(old_dentry, new_dentry);
 +	if (!(old_dir->i_sb->s_type->fs_flags & FS_RENAME_DOES_D_MOVE)) {
 +		if (!(flags & RENAME_EXCHANGE))
 +			d_move(old_dentry, new_dentry);
 +		else
 +			d_exchange(old_dentry, new_dentry);
 +	}
  out:
 -	unlock_two_nondirectories(source, target);
 +	if (!is_dir || (flags & RENAME_EXCHANGE))
 +		unlock_two_nondirectories(source, target);
 +	else if (target)
 +		mutex_unlock(&target->i_mutex);
  	dput(new_dentry);
 -	return error;
 -}
 -
 -/**
 - * vfs_rename - rename a filesystem object
 - * @old_dir:	parent of source
 - * @old_dentry:	source
 - * @new_dir:	parent of destination
 - * @new_dentry:	destination
 - * @delegated_inode: returns an inode needing a delegation break
 - *
 - * The caller must hold multiple mutexes--see lock_rename()).
 - *
 - * If vfs_rename discovers a delegation in need of breaking at either
 - * the source or destination, it will return -EWOULDBLOCK and return a
 - * reference to the inode in delegated_inode.  The caller should then
 - * break the delegation and retry.  Because breaking a delegation may
 - * take a long time, the caller should drop all locks before doing
 - * so.
 - *
 - * Alternatively, a caller may pass NULL for delegated_inode.  This may
 - * be appropriate for callers that expect the underlying filesystem not
 - * to be NFS exported.
 - */
 -int vfs_rename(struct inode *old_dir, struct dentry *old_dentry,
 -	       struct inode *new_dir, struct dentry *new_dentry,
 -	       struct inode **delegated_inode)
 -{
 -	int error;
 -	int is_dir = d_is_directory(old_dentry) || d_is_autodir(old_dentry);
 -	const unsigned char *old_name;
 -
 -	if (old_dentry->d_inode == new_dentry->d_inode)
 - 		return 0;
 - 
 -	error = may_delete(old_dir, old_dentry, is_dir);
 -	if (error)
 -		return error;
 -
 -	if (!new_dentry->d_inode)
 -		error = may_create(new_dir, new_dentry);
 -	else
 -		error = may_delete(new_dir, new_dentry, is_dir);
 -	if (error)
 -		return error;
 -
 -	if (!old_dir->i_op->rename)
 -		return -EPERM;
 -
 -	old_name = fsnotify_oldname_init(old_dentry->d_name.name);
 -
 -	if (is_dir)
 -		error = vfs_rename_dir(old_dir,old_dentry,new_dir,new_dentry);
 -	else
 -		error = vfs_rename_other(old_dir,old_dentry,new_dir,new_dentry,delegated_inode);
 -	if (!error)
 +	if (!error) {
  		fsnotify_move(old_dir, new_dir, old_name, is_dir,
 -			      new_dentry->d_inode, old_dentry);
 +			      !(flags & RENAME_EXCHANGE) ? target : NULL, old_dentry);
 +		if (flags & RENAME_EXCHANGE) {
 +			fsnotify_move(new_dir, old_dir, old_dentry->d_name.name,
 +				      new_is_dir, NULL, new_dentry);
 +		}
 +	}
  	fsnotify_oldname_free(old_name);
  
  	return error;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the userns tree with Linus' tree
  2012-05-22  7:44 Stephen Rothwell
@ 2012-05-22 14:29 ` Eric W. Biederman
  0 siblings, 0 replies; 19+ messages in thread
From: Eric W. Biederman @ 2012-05-22 14:29 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Linus

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

> Hi Eric,
>
> Today's linux-next merge of the userns tree got a conflict in fs/stat.c
> between commit a52dd971f947 ("vfs: de-crapify "cp_new_stat()" function")
> from Linus' tree and commit a7c1938e22c0 ("userns: Convert stat to return
> values mapped from kuids and kgids") from the userns tree.
>
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.

Looks good thanks.

Eric

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

* linux-next: manual merge of the userns tree with Linus' tree
@ 2012-05-22  7:44 Stephen Rothwell
  2012-05-22 14:29 ` Eric W. Biederman
  0 siblings, 1 reply; 19+ messages in thread
From: Stephen Rothwell @ 2012-05-22  7:44 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: linux-next, linux-kernel, Linus

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

Hi Eric,

Today's linux-next merge of the userns tree got a conflict in fs/stat.c
between commit a52dd971f947 ("vfs: de-crapify "cp_new_stat()" function")
from Linus' tree and commit a7c1938e22c0 ("userns: Convert stat to return
values mapped from kuids and kgids") from the userns tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/stat.c
index 0cef336,31acca5..0000000
--- a/fs/stat.c
+++ b/fs/stat.c
@@@ -224,9 -215,17 +224,9 @@@ static int cp_new_stat(struct kstat *st
  	tmp.st_nlink = stat->nlink;
  	if (tmp.st_nlink != stat->nlink)
  		return -EOVERFLOW;
- 	SET_UID(tmp.st_uid, stat->uid);
- 	SET_GID(tmp.st_gid, stat->gid);
+ 	SET_UID(tmp.st_uid, from_kuid_munged(current_user_ns(), stat->uid));
+ 	SET_GID(tmp.st_gid, from_kgid_munged(current_user_ns(), stat->gid));
 -#if BITS_PER_LONG == 32
 -	tmp.st_rdev = old_encode_dev(stat->rdev);
 -#else
 -	tmp.st_rdev = new_encode_dev(stat->rdev);
 -#endif
 -#if BITS_PER_LONG == 32
 -	if (stat->size > MAX_NON_LFS)
 -		return -EOVERFLOW;
 -#endif	
 +	tmp.st_rdev = encode_dev(stat->rdev);
  	tmp.st_size = stat->size;
  	tmp.st_atime = stat->atime.tv_sec;
  	tmp.st_mtime = stat->mtime.tv_sec;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

end of thread, other threads:[~2021-06-28  7:16 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-09  2:40 linux-next: manual merge of the userns tree with Linus' tree Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2021-06-25  8:22 Stephen Rothwell
2021-06-28  7:16 ` Stephen Rothwell
2021-05-26  4:51 Stephen Rothwell
2021-05-26  4:38 Stephen Rothwell
2021-05-26  4:32 Stephen Rothwell
2016-11-22  8:17 Stephen Rothwell
2016-11-22 17:44 ` Eric W. Biederman
2016-11-22 22:56   ` Stephen Rothwell
2016-07-08  6:13 Stephen Rothwell
2016-06-24  4:41 Stephen Rothwell
2014-04-17  5:06 Stephen Rothwell
2014-04-17  5:25 ` Al Viro
2014-04-17  8:44   ` Eric W. Biederman
2014-04-22  1:37     ` Stephen Rothwell
2014-04-09  2:45 Stephen Rothwell
2014-04-09  2:39 Stephen Rothwell
2012-05-22  7:44 Stephen Rothwell
2012-05-22 14:29 ` Eric W. Biederman

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