Re: linux-next: manual merge of the userns tree with the tip tree
Hi all,
On Fri, 11 Dec 2020 18:24:53 +1100 Stephen Rothwell
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..
> --- 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
pgpjh2nkojkEe.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the userns tree with the tip tree
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..
--- 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);
pgpVlMu_YJpPS.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the userns tree with the tip tree
Stephen Rothwell writes:
> Hi all,
>
> On Mon, 15 Oct 2018 15:11:59 +1100 Stephen Rothwell
> 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..
>> --- 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
Hi all,
On Mon, 15 Oct 2018 15:11:59 +1100 Stephen Rothwell
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..
> --- 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
pgpyWC9PVw9ze.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the userns tree with the tip tree
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..
--- 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
linux-next: manual merge of the userns tree with the tip tree
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..
--- 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;
}
pgppLdWNwHt8A.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the userns tree with the tip tree
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 Rothwells...@canb.auug.org.au
diff --cc drivers/firmware/efi/efi.c
index ca617f40574a,e14363d12690..
--- 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
pgp94BhuWX4gF.pgp
Description: OpenPGP digital signature
