linux-next: manual merge of the userns tree with the tip tree

linux-next: manual merge of the userns tree with the tip tree

[Stephen Rothwell]

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

Hi Eric,

Today's linux-next merge of the userns tree got a conflict in
include/linux/sched.h between commit 50954a1f450e ("sched/numa: Provide
sysctl knob to disable numa scheduling and turn it off by default") from
the tip tree and commit 7b44ab978b77 ("userns: Disassociate user_struct
from the user_namespace") 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 include/linux/sched.h
index 37a7cd8,5fdc1eb..0000000
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@@ -90,7 -90,7 +90,8 @@@ struct sched_param 
  #include <linux/latencytop.h>
  #include <linux/cred.h>
  #include <linux/llist.h>
 +#include <linux/jump_label.h>
+ #include <linux/uidgid.h>
  
  #include <asm/processor.h>
  

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

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

[Eric W. Biederman]

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

> Hi Eric,
>
> Today's linux-next merge of the userns tree got a conflict in
> include/linux/sched.h between commit 50954a1f450e ("sched/numa: Provide
> sysctl knob to disable numa scheduling and turn it off by default") from
> the tip tree and commit 7b44ab978b77 ("userns: Disassociate user_struct
> from the user_namespace") from the userns tree.
>
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.

It looks reasonable.  Thanks.

Eric

linux-next: manual merge of the userns tree with the tip tree

[Stephen Rothwell]

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

Hi all,

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

  arch/x86/kernel/process.c

between commit:

  3a24a60854d2 ("x86/32: Remove lazy GS macros")

from the tip tree and commit:

  5bd2e97c868a ("fork: Generalize PF_IO_WORKER handling")

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 arch/x86/kernel/process.c
index 4037aaaf0260,d20eaad52a85..000000000000
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@@ -193,10 -193,14 +195,10 @@@ int copy_thread(struct task_struct *p, 
  	if (sp)
  		childregs->sp = sp;
  
- 	if (unlikely(p->flags & PF_IO_WORKER)) {
 -#ifdef CONFIG_X86_32
 -	task_user_gs(p) = get_user_gs(current_pt_regs());
 -#endif
 -
+ 	if (unlikely(args->fn)) {
  		/*
- 		 * An IO thread is a user space thread, but it doesn't
- 		 * return to ret_after_fork().
+ 		 * A user space thread, but it doesn't return to
+ 		 * ret_after_fork().
  		 *
  		 * In order to indicate that to tools like gdb,
  		 * we reset the stack and instruction pointers.

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

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

[Stephen Rothwell]

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

Hi all,

On Fri, 11 Dec 2020 18:24:53 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the userns tree got a conflict in:
> 
>   kernel/events/core.c
> 
> between commit:
> 
>   78af4dc949da ("perf: Break deadlock involving exec_update_mutex")
> 
> from the tip tree and commit:
> 
>   f7cfd871ae0c ("exec: Transform exec_update_mutex into a rw_semaphore")
> 
> 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.
> 
> diff --cc kernel/events/core.c
> index 19ae6c931c52,55b2330b556c..000000000000
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@@ -11958,24 -11864,6 +11958,24 @@@ SYSCALL_DEFINE5(perf_event_open
>   		goto err_context;
>   	}
>   
>  +	if (task) {
> - 		err = mutex_lock_interruptible(&task->signal->exec_update_mutex);
> ++		err = down_read_interruptible(&task->signal->exec_update_lock);
>  +		if (err)
>  +			goto err_file;
>  +
>  +		/*
>  +		 * Preserve ptrace permission check for backwards compatibility.
>  +		 *
> - 		 * We must hold exec_update_mutex across this and any potential
> ++		 * We must hold exec_update_lock across this and any potential
>  +		 * perf_install_in_context() call for this new event to
>  +		 * serialize against exec() altering our credentials (and the
>  +		 * perf_event_exit_task() that could imply).
>  +		 */
>  +		err = -EACCES;
>  +		if (!perfmon_capable() && !ptrace_may_access(task, PTRACE_MODE_READ_REALCREDS))
>  +			goto err_cred;
>  +	}
>  +
>   	if (move_group) {
>   		gctx = __perf_event_ctx_lock_double(group_leader, ctx);
>   
> @@@ -12151,10 -12039,7 +12151,10 @@@ err_locked
>   	if (move_group)
>   		perf_event_ctx_unlock(group_leader, gctx);
>   	mutex_unlock(&ctx->mutex);
>  -/* err_file: */
>  +err_cred:
>  +	if (task)
> - 		mutex_unlock(&task->signal->exec_update_mutex);
> ++		up_read(&task->signal->exec_update_lock);
>  +err_file:
>   	fput(event_file);
>   err_context:
>   	perf_unpin_context(ctx);

This is now a conflict between the userns tree and Linus's tree.

-- 
Cheers,
Stephen Rothwell

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

linux-next: manual merge of the userns tree with the tip tree

[Stephen Rothwell]

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

Hi all,

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

  kernel/events/core.c

between commit:

  78af4dc949da ("perf: Break deadlock involving exec_update_mutex")

from the tip tree and commit:

  f7cfd871ae0c ("exec: Transform exec_update_mutex into a rw_semaphore")

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/events/core.c
index 19ae6c931c52,55b2330b556c..000000000000
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@@ -11958,24 -11864,6 +11958,24 @@@ SYSCALL_DEFINE5(perf_event_open
  		goto err_context;
  	}
  
 +	if (task) {
- 		err = mutex_lock_interruptible(&task->signal->exec_update_mutex);
++		err = down_read_interruptible(&task->signal->exec_update_lock);
 +		if (err)
 +			goto err_file;
 +
 +		/*
 +		 * Preserve ptrace permission check for backwards compatibility.
 +		 *
- 		 * We must hold exec_update_mutex across this and any potential
++		 * We must hold exec_update_lock across this and any potential
 +		 * perf_install_in_context() call for this new event to
 +		 * serialize against exec() altering our credentials (and the
 +		 * perf_event_exit_task() that could imply).
 +		 */
 +		err = -EACCES;
 +		if (!perfmon_capable() && !ptrace_may_access(task, PTRACE_MODE_READ_REALCREDS))
 +			goto err_cred;
 +	}
 +
  	if (move_group) {
  		gctx = __perf_event_ctx_lock_double(group_leader, ctx);
  
@@@ -12151,10 -12039,7 +12151,10 @@@ err_locked
  	if (move_group)
  		perf_event_ctx_unlock(group_leader, gctx);
  	mutex_unlock(&ctx->mutex);
 -/* err_file: */
 +err_cred:
 +	if (task)
- 		mutex_unlock(&task->signal->exec_update_mutex);
++		up_read(&task->signal->exec_update_lock);
 +err_file:
  	fput(event_file);
  err_context:
  	perf_unpin_context(ctx);

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

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

[Eric W. Biederman]

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

> Hi all,
>
> On Mon, 15 Oct 2018 15:11:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Today's linux-next merge of the userns tree got a conflict in:
>> 
>>   arch/x86/mm/fault.c
>> 
>> between commit:
>> 
>>   164477c2331b ("x86/mm: Clarify hardware vs. software "error_code"")
>> (and others from that series)
>> 
>> from the tip tree and commits:
>> 
>>   768fd9c69bb5 ("signal/x86: Remove pkey parameter from bad_area_nosemaphore")
>>   25c102d803ea ("signal/x86: Remove pkey parameter from mm_fault_error")
>> 
>> from the userns tree.
>> 
>> I fixed it up (I think - 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 arch/x86/mm/fault.c
>> index c2e3e5127ebc,8d77700a7883..000000000000
>> --- a/arch/x86/mm/fault.c
>> +++ b/arch/x86/mm/fault.c
>>  +/* Handle faults in the user portion of the address space */
>>  +static inline
>>  +void do_user_addr_fault(struct pt_regs *regs,
>>  +			unsigned long hw_error_code,
>>  +			unsigned long address)
>>  +{
>>  +	unsigned long sw_error_code;
>>  +	struct vm_area_struct *vma;
>>  +	struct task_struct *tsk;
>>  +	struct mm_struct *mm;
>>  +	vm_fault_t fault, major = 0;
>>  +	unsigned int flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
>>  +	u32 pkey;
>
> I missed removing the above line.

Yes.  At first glance with the above change it looks like you got it.

Eric

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

[Stephen Rothwell]

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

Hi all,

On Mon, 15 Oct 2018 15:11:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the userns tree got a conflict in:
> 
>   arch/x86/mm/fault.c
> 
> between commit:
> 
>   164477c2331b ("x86/mm: Clarify hardware vs. software "error_code"")
> (and others from that series)
> 
> from the tip tree and commits:
> 
>   768fd9c69bb5 ("signal/x86: Remove pkey parameter from bad_area_nosemaphore")
>   25c102d803ea ("signal/x86: Remove pkey parameter from mm_fault_error")
> 
> from the userns tree.
> 
> I fixed it up (I think - 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 arch/x86/mm/fault.c
> index c2e3e5127ebc,8d77700a7883..000000000000
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
>  +/* Handle faults in the user portion of the address space */
>  +static inline
>  +void do_user_addr_fault(struct pt_regs *regs,
>  +			unsigned long hw_error_code,
>  +			unsigned long address)
>  +{
>  +	unsigned long sw_error_code;
>  +	struct vm_area_struct *vma;
>  +	struct task_struct *tsk;
>  +	struct mm_struct *mm;
>  +	vm_fault_t fault, major = 0;
>  +	unsigned int flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
>  +	u32 pkey;

I missed removing the above line.

-- 
Cheers,
Stephen Rothwell

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

linux-next: manual merge of the userns tree with the tip tree

[Stephen Rothwell]

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

Hi Eric,

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

  arch/x86/mm/fault.c

between commit:

  164477c2331b ("x86/mm: Clarify hardware vs. software "error_code"")
(and others from that series)

from the tip tree and commits:

  768fd9c69bb5 ("signal/x86: Remove pkey parameter from bad_area_nosemaphore")
  25c102d803ea ("signal/x86: Remove pkey parameter from mm_fault_error")

from the userns tree.

I fixed it up (I think - 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 arch/x86/mm/fault.c
index c2e3e5127ebc,8d77700a7883..000000000000
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@@ -968,19 -884,40 +892,41 @@@ bad_area_access_error(struct pt_regs *r
  	 * But, doing it this way allows compiler optimizations
  	 * if pkeys are compiled out.
  	 */
- 	if (bad_area_access_from_pkeys(error_code, vma))
- 		__bad_area(regs, error_code, address, vma, SEGV_PKUERR);
- 	else
- 		__bad_area(regs, error_code, address, vma, SEGV_ACCERR);
+ 	if (bad_area_access_from_pkeys(error_code, vma)) {
+ 		/*
+ 		 * A protection key fault means that the PKRU value did not allow
+ 		 * access to some PTE.  Userspace can figure out what PKRU was
+ 		 * from the XSAVE state.  This function captures the pkey from
+ 		 * the vma and passes it to userspace so userspace can discover
+ 		 * which protection key was set on the PTE.
+ 		 *
+ 		 * If we get here, we know that the hardware signaled a X86_PF_PK
+ 		 * fault and that there was a VMA once we got in the fault
+ 		 * handler.  It does *not* guarantee that the VMA we find here
+ 		 * was the one that we faulted on.
+ 		 *
+ 		 * 1. T1   : mprotect_key(foo, PAGE_SIZE, pkey=4);
+ 		 * 2. T1   : set PKRU to deny access to pkey=4, touches page
+ 		 * 3. T1   : faults...
+ 		 * 4.    T2: mprotect_key(foo, PAGE_SIZE, pkey=5);
+ 		 * 5. T1   : enters fault handler, takes mmap_sem, etc...
+ 		 * 6. T1   : reaches here, sees vma_pkey(vma)=5, when we really
+ 		 *	     faulted on a pte with its pkey=4.
+ 		 */
+ 		u32 pkey = vma_pkey(vma);
+ 
+ 		__bad_area(regs, error_code, address, pkey, SEGV_PKUERR);
+ 	} else {
+ 		__bad_area(regs, error_code, address, 0, SEGV_ACCERR);
+ 	}
  }
  
 +/* Handle faults in the kernel portion of the address space */
  static void
  do_sigbus(struct pt_regs *regs, unsigned long error_code, unsigned long address,
- 	  u32 *pkey, unsigned int fault)
+ 	  unsigned int fault)
  {
  	struct task_struct *tsk = current;
- 	int code = BUS_ADRERR;
  
  	/* Kernel mode? Handle exceptions or die: */
  	if (!(error_code & X86_PF_USER)) {
@@@ -1238,74 -1187,41 +1191,74 @@@ do_kern_addr_fault(struct pt_regs *regs
  	 * only copy the information from the master page table,
  	 * nothing more.
  	 *
 -	 * This verifies that the fault happens in kernel space
 -	 * (error_code & 4) == 0, and that the fault was not a
 -	 * protection error (error_code & 9) == 0.
 +	 * Before doing this on-demand faulting, ensure that the
 +	 * fault is not any of the following:
 +	 * 1. A fault on a PTE with a reserved bit set.
 +	 * 2. A fault caused by a user-mode access.  (Do not demand-
 +	 *    fault kernel memory due to user-mode accesses).
 +	 * 3. A fault caused by a page-level protection violation.
 +	 *    (A demand fault would be on a non-present page which
 +	 *     would have X86_PF_PROT==0).
  	 */
 -	if (unlikely(fault_in_kernel_space(address))) {
 -		if (!(error_code & (X86_PF_RSVD | X86_PF_USER | X86_PF_PROT))) {
 -			if (vmalloc_fault(address) >= 0)
 -				return;
 -		}
 -
 -		/* Can handle a stale RO->RW TLB: */
 -		if (spurious_fault(error_code, address))
 +	if (!(hw_error_code & (X86_PF_RSVD | X86_PF_USER | X86_PF_PROT))) {
 +		if (vmalloc_fault(address) >= 0)
  			return;
 +	}
  
 -		/* kprobes don't want to hook the spurious faults: */
 -		if (kprobes_fault(regs))
 -			return;
 -		/*
 -		 * Don't take the mm semaphore here. If we fixup a prefetch
 -		 * fault we could otherwise deadlock:
 -		 */
 -		bad_area_nosemaphore(regs, error_code, address);
 +	/* Was the fault spurious, caused by lazy TLB invalidation? */
 +	if (spurious_kernel_fault(hw_error_code, address))
 +		return;
  
 +	/* kprobes don't want to hook the spurious faults: */
 +	if (kprobes_fault(regs))
  		return;
 -	}
 +
 +	/*
 +	 * Note, despite being a "bad area", there are quite a few
 +	 * acceptable reasons to get here, such as erratum fixups
 +	 * and handling kernel code that can fault, like get_user().
 +	 *
 +	 * Don't take the mm semaphore here. If we fixup a prefetch
 +	 * fault we could otherwise deadlock:
 +	 */
- 	bad_area_nosemaphore(regs, hw_error_code, address, NULL);
++	bad_area_nosemaphore(regs, hw_error_code, address);
 +}
 +NOKPROBE_SYMBOL(do_kern_addr_fault);
 +
 +/* Handle faults in the user portion of the address space */
 +static inline
 +void do_user_addr_fault(struct pt_regs *regs,
 +			unsigned long hw_error_code,
 +			unsigned long address)
 +{
 +	unsigned long sw_error_code;
 +	struct vm_area_struct *vma;
 +	struct task_struct *tsk;
 +	struct mm_struct *mm;
 +	vm_fault_t fault, major = 0;
 +	unsigned int flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
 +	u32 pkey;
 +
 +	tsk = current;
 +	mm = tsk->mm;
  
  	/* kprobes don't want to hook the spurious faults: */
  	if (unlikely(kprobes_fault(regs)))
  		return;
  
 -	if (unlikely(error_code & X86_PF_RSVD))
 -		pgtable_bad(regs, error_code, address);
 +	/*
 +	 * Reserved bits are never expected to be set on
 +	 * entries in the user portion of the page tables.
 +	 */
 +	if (unlikely(hw_error_code & X86_PF_RSVD))
 +		pgtable_bad(regs, hw_error_code, address);
  
 -	if (unlikely(smap_violation(error_code, regs))) {
 -		bad_area_nosemaphore(regs, error_code, address);
 +	/*
 +	 * Check for invalid kernel (supervisor) access to user
 +	 * pages in the user address space.
 +	 */
 +	if (unlikely(smap_violation(hw_error_code, regs))) {
- 		bad_area_nosemaphore(regs, hw_error_code, address, NULL);
++		bad_area_nosemaphore(regs, hw_error_code, address);
  		return;
  	}
  
@@@ -1314,7 -1230,7 +1267,7 @@@
  	 * in a region with pagefaults disabled then we must not take the fault
  	 */
  	if (unlikely(faulthandler_disabled() || !mm)) {
- 		bad_area_nosemaphore(regs, hw_error_code, address, NULL);
 -		bad_area_nosemaphore(regs, error_code, address);
++		bad_area_nosemaphore(regs, hw_error_code, address);
  		return;
  	}
  
@@@ -1362,49 -1252,31 +1315,49 @@@
  
  	perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
  
 -	if (error_code & X86_PF_WRITE)
 +	if (sw_error_code & X86_PF_WRITE)
  		flags |= FAULT_FLAG_WRITE;
 -	if (error_code & X86_PF_INSTR)
 +	if (sw_error_code & X86_PF_INSTR)
  		flags |= FAULT_FLAG_INSTRUCTION;
  
 +#ifdef CONFIG_X86_64
 +	/*
 +	 * Instruction fetch faults in the vsyscall page might need
 +	 * emulation.  The vsyscall page is at a high address
 +	 * (>PAGE_OFFSET), but is considered to be part of the user
 +	 * address space.
 +	 *
 +	 * The vsyscall page does not have a "real" VMA, so do this
 +	 * emulation before we go searching for VMAs.
 +	 */
 +	if ((sw_error_code & X86_PF_INSTR) && is_vsyscall_vaddr(address)) {
 +		if (emulate_vsyscall(regs, address))
 +			return;
 +	}
 +#endif
 +
  	/*
 -	 * When running in the kernel we expect faults to occur only to
 -	 * addresses in user space.  All other faults represent errors in
 -	 * the kernel and should generate an OOPS.  Unfortunately, in the
 -	 * case of an erroneous fault occurring in a code path which already
 -	 * holds mmap_sem we will deadlock attempting to validate the fault
 -	 * against the address space.  Luckily the kernel only validly
 -	 * references user space from well defined areas of code, which are
 -	 * listed in the exceptions table.
 +	 * Kernel-mode access to the user address space should only occur
 +	 * on well-defined single instructions listed in the exception
 +	 * tables.  But, an erroneous kernel fault occurring outside one of
 +	 * those areas which also holds mmap_sem might deadlock attempting
 +	 * to validate the fault against the address space.
  	 *
 -	 * As the vast majority of faults will be valid we will only perform
 -	 * the source reference check when there is a possibility of a
 -	 * deadlock. Attempt to lock the address space, if we cannot we then
 -	 * validate the source. If this is invalid we can skip the address
 -	 * space check, thus avoiding the deadlock:
 +	 * Only do the expensive exception table search when we might be at
 +	 * risk of a deadlock.  This happens if we
 +	 * 1. Failed to acquire mmap_sem, and
 +	 * 2. The access did not originate in userspace.  Note: either the
 +	 *    hardware or earlier page fault code may set X86_PF_USER
 +	 *    in sw_error_code.
  	 */
  	if (unlikely(!down_read_trylock(&mm->mmap_sem))) {
 -		if (!(error_code & X86_PF_USER) &&
 +		if (!(sw_error_code & X86_PF_USER) &&
  		    !search_exception_tables(regs->ip)) {
 -			bad_area_nosemaphore(regs, error_code, address);
 +			/*
 +			 * Fault from code in kernel from
 +			 * which we do not expect faults.
 +			 */
- 			bad_area_nosemaphore(regs, sw_error_code, address, NULL);
++			bad_area_nosemaphore(regs, sw_error_code, address);
  			return;
  		}
  retry:
@@@ -1500,7 -1369,7 +1450,7 @@@ good_area
  
  	up_read(&mm->mmap_sem);
  	if (unlikely(fault & VM_FAULT_ERROR)) {
- 		mm_fault_error(regs, sw_error_code, address, &pkey, fault);
 -		mm_fault_error(regs, error_code, address, fault);
++		mm_fault_error(regs, sw_error_code, address, fault);
  		return;
  	}
  

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

linux-next: manual merge of the userns tree with the tip tree

[Stephen Rothwell]

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

Hi Eric,

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

  arch/x86/kernel/traps.c

between commits:

  76dee4a72849 ("x86/kprobes: Inline kprobe_exceptions_notify() into do_general_protection()")
  81fd9c18444e ("x86/fault: Plumb error code and fault address through to fault handlers")

from the tip tree and commits:

  6ace1098a68c ("signal/x86/traps: Factor out show_signal")
  79e21d654093 ("signal/x86/traps: Move more code into do_trap_no_signal so it can be reused")

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 arch/x86/kernel/traps.c
index 5bd0a997d81e,34a327f35976..000000000000
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@@ -202,11 -202,8 +202,8 @@@ do_trap_no_signal(struct task_struct *t
  						error_code, trapnr))
  				return 0;
  		}
- 		return -1;
- 	}
- 
- 	if (!user_mode(regs)) {
+ 	} else if (!user_mode(regs)) {
 -		if (fixup_exception(regs, trapnr))
 +		if (fixup_exception(regs, trapnr, error_code, 0))
  			return 0;
  
  		tsk->thread.error_code = error_code;
@@@ -560,19 -540,9 +544,19 @@@ do_general_protection(struct pt_regs *r
  
  		tsk->thread.error_code = error_code;
  		tsk->thread.trap_nr = X86_TRAP_GP;
 +
 +		/*
 +		 * To be potentially processing a kprobe fault and to
 +		 * trust the result from kprobe_running(), we have to
 +		 * be non-preemptible.
 +		 */
 +		if (!preemptible() && kprobe_running() &&
 +		    kprobe_fault_handler(regs, X86_TRAP_GP))
 +			return;
 +
- 		if (notify_die(DIE_GPF, "general protection fault", regs, error_code,
+ 		if (notify_die(DIE_GPF, desc, regs, error_code,
  			       X86_TRAP_GP, SIGSEGV) != NOTIFY_STOP)
- 			die("general protection fault", regs, error_code);
+ 			die(desc, regs, error_code);
  		return;
  	}
  

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

linux-next: manual merge of the userns tree with the tip tree

[Stephen Rothwell]

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

Hi Eric,

Today's linux-next merge of the userns tree got a conflict in
drivers/firmware/efi/efi.c between commit 0bb549052d33 ("efi: Add esrt
support") from the tip tree and commit c2f0fd2c640e ("sysfs: Create
mountpoints with sysfs_create_mount_point") from the userns tree.

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

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

diff --cc drivers/firmware/efi/efi.c
index ca617f40574a,e14363d12690..000000000000
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@@ -65,8 -64,7 +65,7 @@@ static int __init parse_efi_cmdline(cha
  }
  early_param("efi", parse_efi_cmdline);
  
 -static struct kobject *efi_kobj;
 +struct kobject *efi_kobj;
- static struct kobject *efivars_kobj;
  
  /*
   * Let's not leave out systab information that snuck into

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