- Linux-stable-mirror - lists.linaro.org

Patch "KVM: PPC: Book3S HV: Drop locks before reading guest memory" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: PPC: Book3S HV: Drop locks before reading guest memory to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-ppc-book3s-hv-drop-locks-before-reading-guest-memory.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 36ee41d161c67a6fcf696d4817a0da31f778938c Mon Sep 17 00:00:00 2001 From: Paul Mackerras <paulus(a)ozlabs.org> Date: Tue, 30 Jan 2018 10:51:32 +1100 Subject: KVM: PPC: Book3S HV: Drop locks before reading guest memory From: Paul Mackerras <paulus(a)ozlabs.org> commit 36ee41d161c67a6fcf696d4817a0da31f778938c upstream. Running with CONFIG_DEBUG_ATOMIC_SLEEP reveals that HV KVM tries to read guest memory, in order to emulate guest instructions, while preempt is disabled and a vcore lock is held. This occurs in kvmppc_handle_exit_hv(), called from post_guest_process(), when emulating guest doorbell instructions on POWER9 systems, and also when checking whether we have hit a hypervisor breakpoint. Reading guest memory can cause a page fault and thus cause the task to sleep, so we need to avoid reading guest memory while holding a spinlock or when preempt is disabled. To fix this, we move the preempt_enable() in kvmppc_run_core() to before the loop that calls post_guest_process() for each vcore that has just run, and we drop and re-take the vcore lock around the calls to kvmppc_emulate_debug_inst() and kvmppc_emulate_doorbell_instr(). Dropping the lock is safe with respect to the iteration over the runnable vcpus in post_guest_process(); for_each_runnable_thread is actually safe to use locklessly. It is possible for a vcpu to become runnable and add itself to the runnable_threads array (code near the beginning of kvmppc_run_vcpu()) and then get included in the iteration in post_guest_process despite the fact that it has not just run. This is benign because vcpu->arch.trap and vcpu->arch.ceded will be zero. Fixes: 579006944e0d ("KVM: PPC: Book3S HV: Virtualize doorbell facility on POWER9") Signed-off-by: Paul Mackerras <paulus(a)ozlabs.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/kvm/book3s_hv.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) --- a/arch/powerpc/kvm/book3s_hv.c +++ b/arch/powerpc/kvm/book3s_hv.c @@ -1005,8 +1005,6 @@ static int kvmppc_emulate_doorbell_instr struct kvm *kvm = vcpu->kvm; struct kvm_vcpu *tvcpu; - if (!cpu_has_feature(CPU_FTR_ARCH_300)) - return EMULATE_FAIL; if (kvmppc_get_last_inst(vcpu, INST_GENERIC, &inst) != EMULATE_DONE) return RESUME_GUEST; if (get_op(inst) != 31) @@ -1056,6 +1054,7 @@ static int kvmppc_emulate_doorbell_instr return RESUME_GUEST; } +/* Called with vcpu->arch.vcore->lock held */ static int kvmppc_handle_exit_hv(struct kvm_run *run, struct kvm_vcpu *vcpu, struct task_struct *tsk) { @@ -1176,7 +1175,10 @@ static int kvmppc_handle_exit_hv(struct swab32(vcpu->arch.emul_inst) : vcpu->arch.emul_inst; if (vcpu->guest_debug & KVM_GUESTDBG_USE_SW_BP) { + /* Need vcore unlocked to call kvmppc_get_last_inst */ + spin_unlock(&vcpu->arch.vcore->lock); r = kvmppc_emulate_debug_inst(run, vcpu); + spin_lock(&vcpu->arch.vcore->lock); } else { kvmppc_core_queue_program(vcpu, SRR1_PROGILL); r = RESUME_GUEST; @@ -1191,8 +1193,13 @@ static int kvmppc_handle_exit_hv(struct */ case BOOK3S_INTERRUPT_H_FAC_UNAVAIL: r = EMULATE_FAIL; - if ((vcpu->arch.hfscr >> 56) == FSCR_MSGP_LG) + if (((vcpu->arch.hfscr >> 56) == FSCR_MSGP_LG) && + cpu_has_feature(CPU_FTR_ARCH_300)) { + /* Need vcore unlocked to call kvmppc_get_last_inst */ + spin_unlock(&vcpu->arch.vcore->lock); r = kvmppc_emulate_doorbell_instr(vcpu); + spin_lock(&vcpu->arch.vcore->lock); + } if (r == EMULATE_FAIL) { kvmppc_core_queue_program(vcpu, SRR1_PROGILL); r = RESUME_GUEST; @@ -2934,13 +2941,14 @@ static noinline void kvmppc_run_core(str /* make sure updates to secondary vcpu structs are visible now */ smp_mb(); + preempt_enable(); + for (sub = 0; sub < core_info.n_subcores; ++sub) { pvc = core_info.vc[sub]; post_guest_process(pvc, pvc == vc); } spin_lock(&vc->lock); - preempt_enable(); out: vc->vcore_state = VCORE_INACTIVE; Patches currently in stable-queue which might be from paulus(a)ozlabs.org are queue-4.15/kvm-ppc-book3s-hv-make-sure-we-don-t-re-enter-guest-without-xive-loaded.patch queue-4.15/kvm-ppc-book3s-hv-drop-locks-before-reading-guest-memory.patch queue-4.15/kvm-ppc-book3s-pr-fix-broken-select-due-to-misspelling.patch

7 years, 3 months

1
0
0 0

Patch "KVM: nVMX: Fix races when sending nested PI while dest enters/leaves L2" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: nVMX: Fix races when sending nested PI while dest enters/leaves L2 to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-nvmx-fix-races-when-sending-nested-pi-while-dest-enters-leaves-l2.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 6b6977117f50d60455ace86b2d256f6fb4f3de05 Mon Sep 17 00:00:00 2001 From: Liran Alon <liran.alon(a)oracle.com> Date: Thu, 9 Nov 2017 20:27:20 +0200 Subject: KVM: nVMX: Fix races when sending nested PI while dest enters/leaves L2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Liran Alon <liran.alon(a)oracle.com> commit 6b6977117f50d60455ace86b2d256f6fb4f3de05 upstream. Consider the following scenario: 1. CPU A calls vmx_deliver_nested_posted_interrupt() to send an IPI to CPU B via virtual posted-interrupt mechanism. 2. CPU B is currently executing L2 guest. 3. vmx_deliver_nested_posted_interrupt() calls kvm_vcpu_trigger_posted_interrupt() which will note that vcpu->mode == IN_GUEST_MODE. 4. Assume that before CPU A sends the physical POSTED_INTR_NESTED_VECTOR IPI, CPU B exits from L2 to L0 during event-delivery (valid IDT-vectoring-info). 5. CPU A now sends the physical IPI. The IPI is received in host and it's handler (smp_kvm_posted_intr_nested_ipi()) does nothing. 6. Assume that before CPU A sets pi_pending=true and KVM_REQ_EVENT, CPU B continues to run in L0 and reach vcpu_enter_guest(). As KVM_REQ_EVENT is not set yet, vcpu_enter_guest() will continue and resume L2 guest. 7. At this point, CPU A sets pi_pending=true and KVM_REQ_EVENT but it's too late! CPU B already entered L2 and KVM_REQ_EVENT will only be consumed at next L2 entry! Another scenario to consider: 1. CPU A calls vmx_deliver_nested_posted_interrupt() to send an IPI to CPU B via virtual posted-interrupt mechanism. 2. Assume that before CPU A calls kvm_vcpu_trigger_posted_interrupt(), CPU B is at L0 and is about to resume into L2. Further assume that it is in vcpu_enter_guest() after check for KVM_REQ_EVENT. 3. At this point, CPU A calls kvm_vcpu_trigger_posted_interrupt() which will note that vcpu->mode != IN_GUEST_MODE. Therefore, do nothing and return false. Then, will set pi_pending=true and KVM_REQ_EVENT. 4. Now CPU B continue and resumes into L2 guest without processing the posted-interrupt until next L2 entry! To fix both issues, we just need to change vmx_deliver_nested_posted_interrupt() to set pi_pending=true and KVM_REQ_EVENT before calling kvm_vcpu_trigger_posted_interrupt(). It will fix the first scenario by chaging step (6) to note that KVM_REQ_EVENT and pi_pending=true and therefore process nested posted-interrupt. It will fix the second scenario by two possible ways: 1. If kvm_vcpu_trigger_posted_interrupt() is called while CPU B has changed vcpu->mode to IN_GUEST_MODE, physical IPI will be sent and will be received when CPU resumes into L2. 2. If kvm_vcpu_trigger_posted_interrupt() is called while CPU B hasn't yet changed vcpu->mode to IN_GUEST_MODE, then after CPU B will change vcpu->mode it will call kvm_request_pending() which will return true and therefore force another round of vcpu_enter_guest() which will note that KVM_REQ_EVENT and pi_pending=true and therefore process nested posted-interrupt. Fixes: 705699a13994 ("KVM: nVMX: Enable nested posted interrupt processing") Signed-off-by: Liran Alon <liran.alon(a)oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com> Reviewed-by: Krish Sadhukhan <krish.sadhukhan(a)oracle.com> [Add kvm_vcpu_kick to also handle the case where L1 doesn't intercept L2 HLT and L2 executes HLT instruction. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/vmx.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -5323,14 +5323,15 @@ static int vmx_deliver_nested_posted_int if (is_guest_mode(vcpu) && vector == vmx->nested.posted_intr_nv) { - /* the PIR and ON have been set by L1. */ - kvm_vcpu_trigger_posted_interrupt(vcpu, true); /* * If a posted intr is not recognized by hardware, * we will accomplish it in the next vmentry. */ vmx->nested.pi_pending = true; kvm_make_request(KVM_REQ_EVENT, vcpu); + /* the PIR and ON have been set by L1. */ + if (!kvm_vcpu_trigger_posted_interrupt(vcpu, true)) + kvm_vcpu_kick(vcpu); return 0; } return -1; Patches currently in stable-queue which might be from liran.alon(a)oracle.com are queue-4.15/kvm-nvmx-fix-bug-of-injecting-l2-exception-into-l1.patch queue-4.15/kvm-nvmx-fix-races-when-sending-nested-pi-while-dest-enters-leaves-l2.patch

7 years, 3 months

1
0
0 0

Patch "KVM: nVMX: Fix bug of injecting L2 exception into L1" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: nVMX: Fix bug of injecting L2 exception into L1 to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-nvmx-fix-bug-of-injecting-l2-exception-into-l1.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5c7d4f9ad39d980728b39752304ce10bb2960cbf Mon Sep 17 00:00:00 2001 From: Liran Alon <liran.alon(a)oracle.com> Date: Sun, 19 Nov 2017 18:25:43 +0200 Subject: KVM: nVMX: Fix bug of injecting L2 exception into L1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Liran Alon <liran.alon(a)oracle.com> commit 5c7d4f9ad39d980728b39752304ce10bb2960cbf upstream. kvm_clear_exception_queue() should clear pending exception. This also includes exceptions which were only marked pending but not yet injected. This is because exception.pending is used for both L1 and L2 to determine if an exception should be raised to guest. Note that an exception which is pending but not yet injected will be raised again once the guest will be resumed. Consider the following scenario: 1) L0 KVM with ignore_msrs=false. 2) L1 prepare vmcs12 with the following: a) No intercepts on MSR (MSR_BITMAP exist and is filled with 0). b) No intercept for #GP. c) vmx-preemption-timer is configured. 3) L1 enters into L2. 4) L2 reads an unhandled MSR that exists in MSR_BITMAP (such as 0x1fff). L2 RDMSR could be handled as described below: 1) L2 exits to L0 on RDMSR and calls handle_rdmsr(). 2) handle_rdmsr() calls kvm_inject_gp() which sets KVM_REQ_EVENT, exception.pending=true and exception.injected=false. 3) vcpu_enter_guest() consumes KVM_REQ_EVENT and calls inject_pending_event() which calls vmx_check_nested_events() which sees that exception.pending=true but nested_vmx_check_exception() returns 0 and therefore does nothing at this point. However let's assume it later sees vmx-preemption-timer expired and therefore exits from L2 to L1 by calling nested_vmx_vmexit(). 4) nested_vmx_vmexit() calls prepare_vmcs12() which calls vmcs12_save_pending_event() but it does nothing as exception.injected is false. Also prepare_vmcs12() calls kvm_clear_exception_queue() which does nothing as exception.injected is already false. 5) We now return from vmx_check_nested_events() with 0 while still having exception.pending=true! 6) Therefore inject_pending_event() continues and we inject L2 exception to L1!... This commit will fix above issue by changing step (4) to clear exception.pending in kvm_clear_exception_queue(). Fixes: 664f8e26b00c ("KVM: X86: Fix loss of exception which has not yet been injected") Signed-off-by: Liran Alon <liran.alon(a)oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com> Reviewed-by: Krish Sadhukhan <krish.sadhukhan(a)oracle.com> Signed-off-by: Krish Sadhukhan <krish.sadhukhan(a)oracle.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/vmx.c | 1 - arch/x86/kvm/x86.h | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -11255,7 +11255,6 @@ static int vmx_check_nested_events(struc if (block_nested_events) return -EBUSY; nested_vmx_inject_exception_vmexit(vcpu, exit_qual); - vcpu->arch.exception.pending = false; return 0; } --- a/arch/x86/kvm/x86.h +++ b/arch/x86/kvm/x86.h @@ -12,6 +12,7 @@ static inline void kvm_clear_exception_queue(struct kvm_vcpu *vcpu) { + vcpu->arch.exception.pending = false; vcpu->arch.exception.injected = false; } Patches currently in stable-queue which might be from liran.alon(a)oracle.com are queue-4.15/kvm-nvmx-fix-bug-of-injecting-l2-exception-into-l1.patch queue-4.15/kvm-nvmx-fix-races-when-sending-nested-pi-while-dest-enters-leaves-l2.patch

7 years, 3 months

1
0
0 0

Patch "KVM: arm/arm64: Handle CPU_PM_ENTER_FAILED" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: arm/arm64: Handle CPU_PM_ENTER_FAILED to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-arm-arm64-handle-cpu_pm_enter_failed.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 58d6b15e9da5042a99c9c30ad725792e4569150e Mon Sep 17 00:00:00 2001 From: James Morse <james.morse(a)arm.com> Date: Mon, 22 Jan 2018 18:19:06 +0000 Subject: KVM: arm/arm64: Handle CPU_PM_ENTER_FAILED From: James Morse <james.morse(a)arm.com> commit 58d6b15e9da5042a99c9c30ad725792e4569150e upstream. cpu_pm_enter() calls the pm notifier chain with CPU_PM_ENTER, then if there is a failure: CPU_PM_ENTER_FAILED. When KVM receives CPU_PM_ENTER it calls cpu_hyp_reset() which will return us to the hyp-stub. If we subsequently get a CPU_PM_ENTER_FAILED, KVM does nothing, leaving the CPU running with the hyp-stub, at odds with kvm_arm_hardware_enabled. Add CPU_PM_ENTER_FAILED as a fallthrough for CPU_PM_EXIT, this reloads KVM based on kvm_arm_hardware_enabled. This is safe even if CPU_PM_ENTER never gets as far as KVM, as cpu_hyp_reinit() calls cpu_hyp_reset() to make sure the hyp-stub is loaded before reloading KVM. Fixes: 67f691976662 ("arm64: kvm: allows kvm cpu hotplug") CC: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com> Reviewed-by: Christoffer Dall <christoffer.dall(a)linaro.org> Signed-off-by: James Morse <james.morse(a)arm.com> Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- virt/kvm/arm/arm.c | 1 + 1 file changed, 1 insertion(+) --- a/virt/kvm/arm/arm.c +++ b/virt/kvm/arm/arm.c @@ -1239,6 +1239,7 @@ static int hyp_init_cpu_pm_notifier(stru cpu_hyp_reset(); return NOTIFY_OK; + case CPU_PM_ENTER_FAILED: case CPU_PM_EXIT: if (__this_cpu_read(kvm_arm_hardware_enabled)) /* The hardware was enabled before suspend. */ Patches currently in stable-queue which might be from james.morse(a)arm.com are queue-4.15/arm64-kpti-fix-the-interaction-between-asid-switching-and-software-pan.patch queue-4.15/kvm-arm-arm64-handle-cpu_pm_enter_failed.patch queue-4.15/arm64-cpufeature-__this_cpu_has_cap-shouldn-t-stop-early.patch

7 years, 3 months

1
0
0 0

Patch "kernel/relay.c: revert "kernel/relay.c: fix potential memory leak"" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled kernel/relay.c: revert "kernel/relay.c: fix potential memory leak" to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kernel-relay.c-revert-kernel-relay.c-fix-potential-memory-leak.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a1be1f3931bfe0a42b46fef77a04593c2b136e7f Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Tue, 6 Feb 2018 15:40:24 -0800 Subject: kernel/relay.c: revert "kernel/relay.c: fix potential memory leak" From: Eric Biggers <ebiggers(a)google.com> commit a1be1f3931bfe0a42b46fef77a04593c2b136e7f upstream. This reverts commit ba62bafe942b ("kernel/relay.c: fix potential memory leak"). This commit introduced a double free bug, because 'chan' is already freed by the line: kref_put(&chan->kref, relay_destroy_channel); This bug was found by syzkaller, using the BLKTRACESETUP ioctl. Link: http://lkml.kernel.org/r/20180127004759.101823-1-ebiggers3@gmail.com Fixes: ba62bafe942b ("kernel/relay.c: fix potential memory leak") Signed-off-by: Eric Biggers <ebiggers(a)google.com> Reported-by: syzbot <syzkaller(a)googlegroups.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Cc: Zhouyi Zhou <yizhouzhou(a)ict.ac.cn> Cc: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/relay.c | 1 - 1 file changed, 1 deletion(-) --- a/kernel/relay.c +++ b/kernel/relay.c @@ -611,7 +611,6 @@ free_bufs: kref_put(&chan->kref, relay_destroy_channel); mutex_unlock(&relay_channels_mutex); - kfree(chan); return NULL; } EXPORT_SYMBOL_GPL(relay_open); Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.15/pipe-fix-off-by-one-error-when-checking-buffer-limits.patch queue-4.15/crypto-hash-annotate-algorithms-taking-optional-key.patch queue-4.15/crypto-cryptd-pass-through-absence-of-setkey.patch queue-4.15/crypto-hash-prevent-using-keyed-hashes-without-setting-key.patch queue-4.15/ubifs-free-the-encrypted-symlink-target.patch queue-4.15/pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch queue-4.15/kernel-relay.c-revert-kernel-relay.c-fix-potential-memory-leak.patch queue-4.15/nfs-reject-request-for-id_legacy-key-without-auxdata.patch queue-4.15/crypto-poly1305-remove-setkey-method.patch queue-4.15/crypto-sha512-mb-initialize-pending-lengths-correctly.patch queue-4.15/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch queue-4.15/crypto-mcryptd-pass-through-absence-of-setkey.patch

7 years, 3 months

1
0
0 0

Patch "kernel/async.c: revert "async: simplify lowest_in_progress()"" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled kernel/async.c: revert "async: simplify lowest_in_progress()" to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kernel-async.c-revert-async-simplify-lowest_in_progress.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 4f7e988e63e336827f4150de48163bed05d653bd Mon Sep 17 00:00:00 2001 From: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Date: Tue, 6 Feb 2018 15:37:55 -0800 Subject: kernel/async.c: revert "async: simplify lowest_in_progress()" From: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> commit 4f7e988e63e336827f4150de48163bed05d653bd upstream. This reverts commit 92266d6ef60c ("async: simplify lowest_in_progress()") which was simply wrong: In the case where domain is NULL, we now use the wrong offsetof() in the list_first_entry macro, so we don't actually fetch the ->cookie value, but rather the eight bytes located sizeof(struct list_head) further into the struct async_entry. On 64 bit, that's the data member, while on 32 bit, that's a u64 built from func and data in some order. I think the bug happens to be harmless in practice: It obviously only affects callers which pass a NULL domain, and AFAICT the only such caller is async_synchronize_full() -> async_synchronize_full_domain(NULL) -> async_synchronize_cookie_domain(ASYNC_COOKIE_MAX, NULL) and the ASYNC_COOKIE_MAX means that in practice we end up waiting for the async_global_pending list to be empty - but it would break if somebody happened to pass (void*)-1 as the data element to async_schedule, and of course also if somebody ever does a async_synchronize_cookie_domain(, NULL) with a "finite" cookie value. Maybe the "harmless in practice" means this isn't -stable material. But I'm not completely confident my quick git grep'ing is enough, and there might be affected code in one of the earlier kernels that has since been removed, so I'll leave the decision to the stable guys. Link: http://lkml.kernel.org/r/20171128104938.3921-1-linux@rasmusvillemoes.dk Fixes: 92266d6ef60c "async: simplify lowest_in_progress()" Signed-off-by: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Acked-by: Tejun Heo <tj(a)kernel.org> Cc: Arjan van de Ven <arjan(a)linux.intel.com> Cc: Adam Wallis <awallis(a)codeaurora.org> Cc: Lai Jiangshan <laijs(a)cn.fujitsu.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/async.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) --- a/kernel/async.c +++ b/kernel/async.c @@ -84,20 +84,24 @@ static atomic_t entry_count; static async_cookie_t lowest_in_progress(struct async_domain *domain) { - struct list_head *pending; + struct async_entry *first = NULL; async_cookie_t ret = ASYNC_COOKIE_MAX; unsigned long flags; spin_lock_irqsave(&async_lock, flags); - if (domain) - pending = &domain->pending; - else - pending = &async_global_pending; + if (domain) { + if (!list_empty(&domain->pending)) + first = list_first_entry(&domain->pending, + struct async_entry, domain_list); + } else { + if (!list_empty(&async_global_pending)) + first = list_first_entry(&async_global_pending, + struct async_entry, global_list); + } - if (!list_empty(pending)) - ret = list_first_entry(pending, struct async_entry, - domain_list)->cookie; + if (first) + ret = first->cookie; spin_unlock_irqrestore(&async_lock, flags); return ret; Patches currently in stable-queue which might be from linux(a)rasmusvillemoes.dk are queue-4.15/kernel-async.c-revert-async-simplify-lowest_in_progress.patch

7 years, 3 months

1
0
0 0

Patch "kasan: rework Kconfig settings" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled kasan: rework Kconfig settings to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kasan-rework-kconfig-settings.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e7c52b84fb18f08ce49b6067ae6285aca79084a8 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Tue, 6 Feb 2018 15:41:41 -0800 Subject: kasan: rework Kconfig settings From: Arnd Bergmann <arnd(a)arndb.de> commit e7c52b84fb18f08ce49b6067ae6285aca79084a8 upstream. We get a lot of very large stack frames using gcc-7.0.1 with the default -fsanitize-address-use-after-scope --param asan-stack=1 options, which can easily cause an overflow of the kernel stack, e.g. drivers/gpu/drm/i915/gvt/handlers.c:2434:1: warning: the frame size of 46176 bytes is larger than 3072 bytes drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5650:1: warning: the frame size of 23632 bytes is larger than 3072 bytes lib/atomic64_test.c:250:1: warning: the frame size of 11200 bytes is larger than 3072 bytes drivers/gpu/drm/i915/gvt/handlers.c:2621:1: warning: the frame size of 9208 bytes is larger than 3072 bytes drivers/media/dvb-frontends/stv090x.c:3431:1: warning: the frame size of 6816 bytes is larger than 3072 bytes fs/fscache/stats.c:287:1: warning: the frame size of 6536 bytes is larger than 3072 bytes To reduce this risk, -fsanitize-address-use-after-scope is now split out into a separate CONFIG_KASAN_EXTRA Kconfig option, leading to stack frames that are smaller than 2 kilobytes most of the time on x86_64. An earlier version of this patch also prevented combining KASAN_EXTRA with KASAN_INLINE, but that is no longer necessary with gcc-7.0.1. All patches to get the frame size below 2048 bytes with CONFIG_KASAN=y and CONFIG_KASAN_EXTRA=n have been merged by maintainers now, so we can bring back that default now. KASAN_EXTRA=y still causes lots of warnings but now defaults to !COMPILE_TEST to disable it in allmodconfig, and it remains disabled in all other defconfigs since it is a new option. I arbitrarily raise the warning limit for KASAN_EXTRA to 3072 to reduce the noise, but an allmodconfig kernel still has around 50 warnings on gcc-7. I experimented a bit more with smaller stack frames and have another follow-up series that reduces the warning limit for 64-bit architectures to 1280 bytes (without CONFIG_KASAN). With earlier versions of this patch series, I also had patches to address the warnings we get with KASAN and/or KASAN_EXTRA, using a "noinline_if_stackbloat" annotation. That annotation now got replaced with a gcc-8 bugfix (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715) and a workaround for older compilers, which means that KASAN_EXTRA is now just as bad as before and will lead to an instant stack overflow in a few extreme cases. This reverts parts of commit 3f181b4d8652 ("lib/Kconfig.debug: disable -Wframe-larger-than warnings with KASAN=y"). Two patches in linux-next should be merged first to avoid introducing warnings in an allmodconfig build: 3cd890dbe2a4 ("media: dvb-frontends: fix i2c access helpers for KASAN") 16c3ada89cff ("media: r820t: fix r820t_write_reg for KASAN") Do we really need to backport this? I think we do: without this patch, enabling KASAN will lead to unavoidable kernel stack overflow in certain device drivers when built with gcc-7 or higher on linux-4.10+ or any version that contains a backport of commit c5caf21ab0cf8. Most people are probably still on older compilers, but it will get worse over time as they upgrade their distros. The warnings we get on kernels older than this should all be for code that uses dangerously large stack frames, though most of them do not cause an actual stack overflow by themselves.The asan-stack option was added in linux-4.0, and commit 3f181b4d8652 ("lib/Kconfig.debug: disable -Wframe-larger-than warnings with KASAN=y") effectively turned off the warning for allmodconfig kernels, so I would like to see this fix backported to any kernels later than 4.0. I have done dozens of fixes for individual functions with stack frames larger than 2048 bytes with asan-stack, and I plan to make sure that all those fixes make it into the stable kernels as well (most are already there). Part of the complication here is that asan-stack (from 4.0) was originally assumed to always require much larger stacks, but that turned out to be a combination of multiple gcc bugs that we have now worked around and fixed, but sanitize-address-use-after-scope (from v4.10) has a much higher inherent stack usage and also suffers from at least three other problems that we have analyzed but not yet fixed upstream, each of them makes the stack usage more severe than it should be. Link: http://lkml.kernel.org/r/20171221134744.2295529-1-arnd@arndb.de Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Acked-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org> Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Cc: Alexander Potapenko <glider(a)google.com> Cc: Dmitry Vyukov <dvyukov(a)google.com> Cc: Andrey Konovalov <andreyknvl(a)google.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- lib/Kconfig.debug | 2 +- lib/Kconfig.kasan | 11 +++++++++++ scripts/Makefile.kasan | 2 ++ 3 files changed, 14 insertions(+), 1 deletion(-) --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -217,7 +217,7 @@ config ENABLE_MUST_CHECK config FRAME_WARN int "Warn for stack frames larger than (needs gcc 4.4)" range 0 8192 - default 0 if KASAN + default 3072 if KASAN_EXTRA default 2048 if GCC_PLUGIN_LATENT_ENTROPY default 1280 if (!64BIT && PARISC) default 1024 if (!64BIT && !PARISC) --- a/lib/Kconfig.kasan +++ b/lib/Kconfig.kasan @@ -20,6 +20,17 @@ config KASAN Currently CONFIG_KASAN doesn't work with CONFIG_DEBUG_SLAB (the resulting kernel does not boot). +config KASAN_EXTRA + bool "KAsan: extra checks" + depends on KASAN && DEBUG_KERNEL && !COMPILE_TEST + help + This enables further checks in the kernel address sanitizer, for now + it only includes the address-use-after-scope check that can lead + to excessive kernel stack usage, frame size warnings and longer + compile time. + https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 has more + + choice prompt "Instrumentation type" depends on KASAN --- a/scripts/Makefile.kasan +++ b/scripts/Makefile.kasan @@ -30,7 +30,9 @@ else endif endif +ifdef CONFIG_KASAN_EXTRA CFLAGS_KASAN += $(call cc-option, -fsanitize-address-use-after-scope) +endif CFLAGS_KASAN_NOSANITIZE := -fno-builtin Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.15/kasan-rework-kconfig-settings.patch queue-4.15/mtd-cfi-convert-inline-functions-to-macros.patch queue-4.15/signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch queue-4.15/media-dvb-frontends-fix-i2c-access-helpers-for-kasan.patch queue-4.15/alpha-osf_sys.c-fix-put_tv32-regression.patch

7 years, 3 months

1
0
0 0

Patch "kasan: don't emit builtin calls when sanitization is off" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled kasan: don't emit builtin calls when sanitization is off to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kasan-don-t-emit-builtin-calls-when-sanitization-is-off.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 0e410e158e5baa1300bdf678cea4f4e0cf9d8b94 Mon Sep 17 00:00:00 2001 From: Andrey Konovalov <andreyknvl(a)google.com> Date: Tue, 6 Feb 2018 15:36:00 -0800 Subject: kasan: don't emit builtin calls when sanitization is off From: Andrey Konovalov <andreyknvl(a)google.com> commit 0e410e158e5baa1300bdf678cea4f4e0cf9d8b94 upstream. With KASAN enabled the kernel has two different memset() functions, one with KASAN checks (memset) and one without (__memset). KASAN uses some macro tricks to use the proper version where required. For example memset() calls in mm/slub.c are without KASAN checks, since they operate on poisoned slab object metadata. The issue is that clang emits memset() calls even when there is no memset() in the source code. They get linked with improper memset() implementation and the kernel fails to boot due to a huge amount of KASAN reports during early boot stages. The solution is to add -fno-builtin flag for files with KASAN_SANITIZE := n marker. Link: http://lkml.kernel.org/r/8ffecfffe04088c52c42b92739c2bd8a0bcb3f5e.151638459… Signed-off-by: Andrey Konovalov <andreyknvl(a)google.com> Acked-by: Nick Desaulniers <ndesaulniers(a)google.com> Cc: Masahiro Yamada <yamada.masahiro(a)socionext.com> Cc: Michal Marek <michal.lkml(a)markovi.net> Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Cc: Alexander Potapenko <glider(a)google.com> Cc: Dmitry Vyukov <dvyukov(a)google.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- Makefile | 3 ++- scripts/Makefile.kasan | 3 +++ scripts/Makefile.lib | 2 +- 3 files changed, 6 insertions(+), 2 deletions(-) --- a/Makefile +++ b/Makefile @@ -432,7 +432,8 @@ export MAKE AWK GENKSYMS INSTALLKERNEL P export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS -export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_KASAN CFLAGS_UBSAN +export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE +export CFLAGS_KASAN CFLAGS_KASAN_NOSANITIZE CFLAGS_UBSAN export KBUILD_AFLAGS AFLAGS_KERNEL AFLAGS_MODULE export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL --- a/scripts/Makefile.kasan +++ b/scripts/Makefile.kasan @@ -31,4 +31,7 @@ else endif CFLAGS_KASAN += $(call cc-option, -fsanitize-address-use-after-scope) + +CFLAGS_KASAN_NOSANITIZE := -fno-builtin + endif --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -121,7 +121,7 @@ endif ifeq ($(CONFIG_KASAN),y) _c_flags += $(if $(patsubst n%,, \ $(KASAN_SANITIZE_$(basetarget).o)$(KASAN_SANITIZE)y), \ - $(CFLAGS_KASAN)) + $(CFLAGS_KASAN), $(CFLAGS_KASAN_NOSANITIZE)) endif ifeq ($(CONFIG_UBSAN),y) Patches currently in stable-queue which might be from andreyknvl(a)google.com are queue-4.15/kasan-rework-kconfig-settings.patch queue-4.15/media-hdpvr-fix-an-error-handling-path-in-hdpvr_probe.patch queue-4.15/media-dvb-usb-v2-lmedm04-move-ts2020-attach-to-dm04_lme2510_tuner.patch queue-4.15/kasan-don-t-emit-builtin-calls-when-sanitization-is-off.patch queue-4.15/media-dvb-usb-v2-lmedm04-improve-logic-checking-of-warm-start.patch

7 years, 3 months

1
0
0 0

Patch "ipmi: use dynamic memory for DMI driver override" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ipmi: use dynamic memory for DMI driver override to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ipmi-use-dynamic-memory-for-dmi-driver-override.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5516e21a1e95e9b9f39985598431a25477d91643 Mon Sep 17 00:00:00 2001 From: John Garry <john.garry(a)huawei.com> Date: Thu, 18 Jan 2018 00:36:57 +0800 Subject: ipmi: use dynamic memory for DMI driver override From: John Garry <john.garry(a)huawei.com> commit 5516e21a1e95e9b9f39985598431a25477d91643 upstream. Currently a crash can be seen if we reach the "err" label in dmi_add_platform_ipmi(), calling platform_device_put(), like here: [ 7.270584] (null): ipmi:dmi: Unable to add resources: -16 [ 7.330229] ------------[ cut here ]------------ [ 7.334889] kernel BUG at mm/slub.c:3894! [ 7.338936] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 7.344475] Modules linked in: [ 7.347556] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-00004-gbe9cb7b-dirty #114 [ 7.355907] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT17 Nemo 2.0 RC0 11/29/2017 [ 7.365137] task: 00000000c211f6d3 task.stack: 00000000f276e9af [ 7.371116] pstate: 60000005 (nZCv daif -PAN -UAO) [ 7.375957] pc : kfree+0x194/0x1b4 [ 7.379389] lr : platform_device_release+0xcc/0xd8 [ 7.384225] sp : ffff0000092dba90 [ 7.387567] x29: ffff0000092dba90 x28: ffff000008a83000 [ 7.392933] x27: ffff0000092dbc10 x26: 00000000000000e6 [ 7.398297] x25: 0000000000000003 x24: ffff0000085b51e8 [ 7.403662] x23: 0000000000000100 x22: ffff7e0000234cc0 [ 7.409027] x21: ffff000008af3660 x20: ffff8017d21acc10 [ 7.414392] x19: ffff8017d21acc00 x18: 0000000000000002 [ 7.419757] x17: 0000000000000001 x16: 0000000000000008 [ 7.425121] x15: 0000000000000001 x14: 6666666678303d65 [ 7.430486] x13: 6469727265766f5f x12: 7265766972642e76 [ 7.435850] x11: 6564703e2d617020 x10: 6530326435373638 [ 7.441215] x9 : 3030303030303030 x8 : 3d76656420657361 [ 7.446580] x7 : ffff000008f59df8 x6 : ffff8017fbe0ea50 [ 7.451945] x5 : 0000000000000000 x4 : 0000000000000000 [ 7.457309] x3 : ffffffffffffffff x2 : 0000000000000000 [ 7.462674] x1 : 0fffc00000000800 x0 : ffff7e0000234ce0 [ 7.468039] Process swapper/0 (pid: 1, stack limit = 0x00000000f276e9af) [ 7.474809] Call trace: [ 7.477272] kfree+0x194/0x1b4 [ 7.480351] platform_device_release+0xcc/0xd8 [ 7.484837] device_release+0x34/0x90 [ 7.488531] kobject_put+0x70/0xcc [ 7.491961] put_device+0x14/0x1c [ 7.495304] platform_device_put+0x14/0x1c [ 7.499439] dmi_add_platform_ipmi+0x348/0x3ac [ 7.503923] scan_for_dmi_ipmi+0xfc/0x10c [ 7.507970] do_one_initcall+0x38/0x124 [ 7.511840] kernel_init_freeable+0x188/0x228 [ 7.516238] kernel_init+0x10/0x100 [ 7.519756] ret_from_fork+0x10/0x18 [ 7.523362] Code: f94002c0 37780080 f94012c0 37000040 (d4210000) [ 7.529552] ---[ end trace 11750e4787deef9e ]--- [ 7.534228] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 7.534228] This is because when the device is released in platform_device_release(), we try to free pdev.driver_override. This is a const string, hence the crash. Fix by using dynamic memory for pdev->driver_override. Signed-off-by: John Garry <john.garry(a)huawei.com> [Removed the free of driver_override from ipmi_si_remove_by_dev(). The free is done in platform_device_release(), and would result in a double free, and ipmi_si_remove_by_dev() is called by non-platform devices.] Signed-off-by: Corey Minyard <cminyard(a)mvista.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/char/ipmi/ipmi_dmi.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/char/ipmi/ipmi_dmi.c +++ b/drivers/char/ipmi/ipmi_dmi.c @@ -106,7 +106,10 @@ static void __init dmi_add_platform_ipmi pr_err("ipmi:dmi: Error allocation IPMI platform device\n"); return; } - pdev->driver_override = override; + pdev->driver_override = kasprintf(GFP_KERNEL, "%s", + override); + if (!pdev->driver_override) + goto err; if (type == IPMI_DMI_TYPE_SSIF) { set_prop_entry(p[pidx++], "i2c-addr", u16, base_addr); Patches currently in stable-queue which might be from john.garry(a)huawei.com are queue-4.15/ipmi-use-dynamic-memory-for-dmi-driver-override.patch

7 years, 3 months

1
0
0 0

Patch "HID: quirks: Fix keyboard + touchpad on Toshiba Click Mini not working" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled HID: quirks: Fix keyboard + touchpad on Toshiba Click Mini not working to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: hid-quirks-fix-keyboard-touchpad-on-toshiba-click-mini-not-working.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From edfc3722cfef4217c7fe92b272cbe0288ba1ff57 Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Wed, 17 Jan 2018 21:05:55 +0100 Subject: HID: quirks: Fix keyboard + touchpad on Toshiba Click Mini not working From: Hans de Goede <hdegoede(a)redhat.com> commit edfc3722cfef4217c7fe92b272cbe0288ba1ff57 upstream. The Toshiba Click Mini uses an i2c attached keyboard/touchpad combo (single i2c_hid device for both) which has a vid:pid of 04F3:0401, which is also used by a bunch of Elan touchpads which are handled by the drivers/input/mouse/elan_i2c driver, but that driver deals with pure touchpads and does not work for a combo device such as the one on the Toshiba Click Mini. The combo on the Mini has an ACPI id of ELAN0800, which is not claimed by the elan_i2c driver, so check for that and if it is found do not ignore the device. This fixes the keyboard/touchpad combo on the Mini not working (although with the touchpad in mouse emulation mode). Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Jiri Kosina <jkosina(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hid/hid-core.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -2643,7 +2643,6 @@ static const struct hid_device_id hid_ig { HID_USB_DEVICE(USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EARTHMATE) }, { HID_USB_DEVICE(USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EM_LT20) }, { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, 0x0400) }, - { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, 0x0401) }, { HID_USB_DEVICE(USB_VENDOR_ID_ESSENTIAL_REALITY, USB_DEVICE_ID_ESSENTIAL_REALITY_P5) }, { HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC5UH) }, { HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC4UM) }, @@ -2913,6 +2912,17 @@ bool hid_ignore(struct hid_device *hdev) strncmp(hdev->name, "www.masterkit.ru MA901", 22) == 0) return true; break; + case USB_VENDOR_ID_ELAN: + /* + * Many Elan devices have a product id of 0x0401 and are handled + * by the elan_i2c input driver. But the ACPI HID ELAN0800 dev + * is not (and cannot be) handled by that driver -> + * Ignore all 0x0401 devs except for the ELAN0800 dev. + */ + if (hdev->product == 0x0401 && + strncmp(hdev->name, "ELAN0800", 8) != 0) + return true; + break; } if (hdev->type == HID_TYPE_USBMOUSE && Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.15/ahci-add-pci-ids-for-intel-bay-trail-cherry-trail-and-apollo-lake-ahci.patch queue-4.15/bluetooth-btsdio-do-not-bind-to-non-removable-bcm43341.patch queue-4.15/hid-quirks-fix-keyboard-touchpad-on-toshiba-click-mini-not-working.patch queue-4.15/ahci-annotate-pci-ids-for-mobile-intel-chipsets-as-such.patch queue-4.15/bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.patch

7 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror