Update README #200

slaven-s · 2015-08-18T19:04:38Z

Hi,

I added section "Books" and a link to the Learn Linux in a Month of Lunches written by Steven Ovadia for Manning Publications. We believe this book is a great resource and all members of community will benefit from this information. If you find this inappropriate, please let me know where I can publish it.

Hi, I added section "Books" and a link to the Learn Linux in a Month of Lunches written by Steven Ovadia for Manning Publications. We believe this book is a great resource and all members of community will benefit from this information. If you find this inappropriate, please let me know where I can publish it.

shelt · 2015-08-23T06:32:40Z

Pull requests are not accepted on Github. In any case, this is hardly the type of thing that belongs in the kernel README.

marctmiller · 2015-08-23T08:09:21Z

bull fucking shit
On Aug 23, 2015 1:32 AM, "Sam Shelton" [email protected] wrote:

Pull requests are not accepted on Github
#17 (comment). In any
case, this is hardly the type of thing that belongs in the kernel README.

—
Reply to this email directly or view it on GitHub
#200 (comment).

LandonPowell · 2015-08-24T17:21:35Z

Are you trying to shill your book in the kernel readme? Like Shelt said though, Torvalds said "I don't do github pull requests."

yuxuanchen1997 · 2015-08-27T23:16:26Z

Don't leave commercials on a non-profit open source project! The kernel readme as well.

f123h456 · 2015-09-14T09:00:36Z

OK
----- Original Message -----
From: Alex [email protected]
To: torvalds/linux [email protected]
Subject: Re: [linux] Update README (#200)
Date: 2015-09-14 16:52

Hi there , whoever maintains the github repo please add on the top of readme info that PR through github isn't accepted and include the reason!

—
Reply to this email directly or view it on GitHub.

zhouyongtao · 2015-09-28T06:48:44Z

不相关的PR也提交？

yuxuanchen1997 · 2015-09-28T10:55:29Z

Okay, here is the thing.

Some one is trying to add commercial on it and we didn't grant.

He/She must be in the wrong place.

Unable to handle kernel paging request at virtual address 2e116007 pgd = c0004000 [2e116007] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 4.12.0-rc3-00153-gb6bc6724488a torvalds#200 Hardware name: Generic DRA74X (Flattened Device Tree) task: c0d0adc0 task.stack: c0d00000 PC is at __mod_node_page_state+0x2c/0xc8 LR is at __per_cpu_offset+0x0/0x8 pc : [<c0271de8>] lr : [<c0d07da4>] psr: 600000d3 sp : c0d01eec ip : 00000000 fp : c15782f4 r10: 00000000 r9 : c1591280 r8 : 00004000 r7 : 00000001 r6 : 00000006 r5 : 2e116000 r4 : 00000007 r3 : 00000007 r2 : 00000001 r1 : 00000006 r0 : c0dc27c0 Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 8000406a DAC: 00000051 Process swapper (pid: 0, stack limit = 0xc0d00218) Stack: (0xc0d01eec to 0xc0d02000) 1ee0: 600000d3 c0dc27c0 c0271efc 00000001 c0d58864 1f00: ef470000 00008000 00004000 c029fbb0 01000000 c1572b5c 00002000 00000000 1f20: 00000001 00000001 00008000 c029f584 00000000 c0d58864 00008000 00008000 1f40: 01008000 c0c23790 c15782f4 a00000d3 c0d58864 c02a0364 00000000 c0819388 1f60: c0d58864 000000c0 01000000 c1572a58 c0aa57a4 00000080 00002000 c0dca000 1f80: efffe980 c0c53a48 00000000 c0c23790 c1572a58 c0c59e48 c0c59de8 c1572b5c 1fa0: c0dca000 c0c257a4 00000000 ffffffff c0dca000 c0d07940 c0dca000 c0c00a9c 1fc0: ffffffff ffffffff 00000000 c0c00680 00000000 c0c53a48 c0dca214 c0d07958 1fe0: c0c53a44 c0d0caa4 8000406a 412fc0f2 00000000 8000807c 00000000 00000000 [<c0271de8>] (__mod_node_page_state) from [<c0271efc>] (mod_node_page_state+0x2c/0x4c) [<c0271efc>] (mod_node_page_state) from [<c029fbb0>] (cache_alloc_refill+0x5b8/0x828) [<c029fbb0>] (cache_alloc_refill) from [<c02a0364>] (kmem_cache_alloc+0x24c/0x2d0) [<c02a0364>] (kmem_cache_alloc) from [<c0c23790>] (create_kmalloc_cache+0x20/0x8c) [<c0c23790>] (create_kmalloc_cache) from [<c0c257a4>] (kmem_cache_init+0xac/0x11c) [<c0c257a4>] (kmem_cache_init) from [<c0c00a9c>] (start_kernel+0x1b8/0x3c0) [<c0c00a9c>] (start_kernel) from [<8000807c>] (0x8000807c) Code: e79e5103 e28c3001 e0833001 e1a04003 (e19440d5) ---[ end trace 0000000000000000 ]--- The zone counters work earlier than the node counters because the zones have special boot pagesets, whereas the nodes do not. Add boot nodestats against which we account until the dynamic per-cpu allocator is available. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Johannes Weiner <[email protected]> Reported-by: Michael Ellerman <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Vladimir Davydov <[email protected]> Cc: Rik van Riel <[email protected]> Signed-off-by: Andrew Morton <[email protected]>

Newly added igmpv3_get_srcaddr() needs to be called under rcu lock. Timer callbacks do not ensure this locking. ============================= WARNING: suspicious RCU usage 4.15.0+ torvalds#200 Not tainted ----------------------------- ./include/linux/inetdevice.h:216 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by syzkaller616973/4074: #0: (&mm->mmap_sem){++++}, at: [<00000000bfce669e>] __do_page_fault+0x32d/0xc90 arch/x86/mm/fault.c:1355 #1: ((&im->timer)){+.-.}, at: [<00000000619d2f71>] lockdep_copy_map include/linux/lockdep.h:178 [inline] #1: ((&im->timer)){+.-.}, at: [<00000000619d2f71>] call_timer_fn+0x1c6/0x820 kernel/time/timer.c:1316 #2: (&(&im->lock)->rlock){+.-.}, at: [<000000005f833c5c>] spin_lock_bh include/linux/spinlock.h:315 [inline] #2: (&(&im->lock)->rlock){+.-.}, at: [<000000005f833c5c>] igmpv3_send_report+0x98/0x5b0 net/ipv4/igmp.c:600 stack backtrace: CPU: 0 PID: 4074 Comm: syzkaller616973 Not tainted 4.15.0+ torvalds#200 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:53 lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4592 __in_dev_get_rcu include/linux/inetdevice.h:216 [inline] igmpv3_get_srcaddr net/ipv4/igmp.c:329 [inline] igmpv3_newpack+0xeef/0x12e0 net/ipv4/igmp.c:389 add_grhead.isra.27+0x235/0x300 net/ipv4/igmp.c:432 add_grec+0xbd3/0x1170 net/ipv4/igmp.c:565 igmpv3_send_report+0xd5/0x5b0 net/ipv4/igmp.c:605 igmp_send_report+0xc43/0x1050 net/ipv4/igmp.c:722 igmp_timer_expire+0x322/0x5c0 net/ipv4/igmp.c:831 call_timer_fn+0x228/0x820 kernel/time/timer.c:1326 expire_timers kernel/time/timer.c:1363 [inline] __run_timers+0x7ee/0xb70 kernel/time/timer.c:1666 run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692 __do_softirq+0x2d7/0xb85 kernel/softirq.c:285 invoke_softirq kernel/softirq.c:365 [inline] irq_exit+0x1cc/0x200 kernel/softirq.c:405 exiting_irq arch/x86/include/asm/apic.h:541 [inline] smp_apic_timer_interrupt+0x16b/0x700 arch/x86/kernel/apic/apic.c:1052 apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:938 Fixes: a46182b ("net: igmp: Use correct source address on IGMPv3 reports") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: syzbot <[email protected]> Signed-off-by: David S. Miller <[email protected]>

[ Upstream commit e7aadb2 ] Newly added igmpv3_get_srcaddr() needs to be called under rcu lock. Timer callbacks do not ensure this locking. ============================= WARNING: suspicious RCU usage 4.15.0+ torvalds#200 Not tainted ----------------------------- ./include/linux/inetdevice.h:216 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by syzkaller616973/4074: #0: (&mm->mmap_sem){++++}, at: [<00000000bfce669e>] __do_page_fault+0x32d/0xc90 arch/x86/mm/fault.c:1355 #1: ((&im->timer)){+.-.}, at: [<00000000619d2f71>] lockdep_copy_map include/linux/lockdep.h:178 [inline] #1: ((&im->timer)){+.-.}, at: [<00000000619d2f71>] call_timer_fn+0x1c6/0x820 kernel/time/timer.c:1316 #2: (&(&im->lock)->rlock){+.-.}, at: [<000000005f833c5c>] spin_lock_bh include/linux/spinlock.h:315 [inline] #2: (&(&im->lock)->rlock){+.-.}, at: [<000000005f833c5c>] igmpv3_send_report+0x98/0x5b0 net/ipv4/igmp.c:600 stack backtrace: CPU: 0 PID: 4074 Comm: syzkaller616973 Not tainted 4.15.0+ torvalds#200 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:53 lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4592 __in_dev_get_rcu include/linux/inetdevice.h:216 [inline] igmpv3_get_srcaddr net/ipv4/igmp.c:329 [inline] igmpv3_newpack+0xeef/0x12e0 net/ipv4/igmp.c:389 add_grhead.isra.27+0x235/0x300 net/ipv4/igmp.c:432 add_grec+0xbd3/0x1170 net/ipv4/igmp.c:565 igmpv3_send_report+0xd5/0x5b0 net/ipv4/igmp.c:605 igmp_send_report+0xc43/0x1050 net/ipv4/igmp.c:722 igmp_timer_expire+0x322/0x5c0 net/ipv4/igmp.c:831 call_timer_fn+0x228/0x820 kernel/time/timer.c:1326 expire_timers kernel/time/timer.c:1363 [inline] __run_timers+0x7ee/0xb70 kernel/time/timer.c:1666 run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692 __do_softirq+0x2d7/0xb85 kernel/softirq.c:285 invoke_softirq kernel/softirq.c:365 [inline] irq_exit+0x1cc/0x200 kernel/softirq.c:405 exiting_irq arch/x86/include/asm/apic.h:541 [inline] smp_apic_timer_interrupt+0x16b/0x700 arch/x86/kernel/apic/apic.c:1052 apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:938 Fixes: a46182b ("net: igmp: Use correct source address on IGMPv3 reports") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: syzbot <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

GIT e237f98a9c134c3d600353f21e07db915516875b commit 140995c9762dafd3247ce232273fe19cf9d8b38b Author: Thierry Reding <[email protected]> Date: Mon Feb 5 13:54:36 2018 +0100 net: mediatek: Explicitly include pinctrl headers The Mediatek ethernet driver fails to build after commit 23c35f48f5fb ("pinctrl: remove include file from <linux/device.h>") because it relies on the pinctrl/consumer.h and pinctrl/devinfo.h being pulled in by the device.h header implicitly. Include these headers explicitly to avoid the build failure. Cc: Linus Walleij <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> commit 8fb572acb2191bd14fc1363bf73461a994842e6f Author: Thierry Reding <[email protected]> Date: Mon Feb 5 13:47:50 2018 +0100 mmc: meson-gx-mmc: Explicitly include pinctr/consumer.h The Meson GX MMC driver fails to build after commit 23c35f48f5fb ("pinctrl: remove include file from <linux/device.h>") because it relies on the pinctrl/consumer.h being pulled in by the device.h header implicitly. Include the header explicitly to avoid the build failure. Cc: Linus Walleij <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> commit 1c16a9ce01487a98052d37a94e4c411b4fd9617b Author: Thierry Reding <[email protected]> Date: Mon Feb 5 13:47:49 2018 +0100 drm/rockchip: lvds: Explicitly include pinctrl headers The Rockchip LVDS driver fails to build after commit 23c35f48f5fb ("pinctrl: remove include file from <linux/device.h>") because it relies on the pinctrl/consumer.h and pinctrl/devinfo.h being pulled in by the device.h header implicitly. Include these headers explicitly to avoid the build failure. Cc: Linus Walleij <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> commit 567af7fc9d87df3228ef59864f77fe100ec0cee3 Author: Stephen Rothwell <[email protected]> Date: Mon Feb 5 09:24:30 2018 +1100 pinctrl: files should directly include apis they use Fixes: 23c35f48f5fb ("pinctrl: remove include file from <linux/device.h>") Signed-off-by: Stephen Rothwell <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> commit 9b6faee074702bbbc207e7027b9416c2d8fea9fe Author: Amir Goldstein <[email protected]> Date: Tue Jan 30 13:54:45 2018 +0200 ovl: check ERR_PTR() return value from ovl_encode_fh() Another fix for an issue reported by 0-day robot. Reported-by: Dan Carpenter <[email protected]> Fixes: 8ed5eec9d6c4 ("ovl: encode pure upper file handles") Signed-off-by: Amir Goldstein <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]> commit 2aed489d163a6559e07dbc238882c9970ae0f65b Author: Amir Goldstein <[email protected]> Date: Sun Jan 28 02:35:48 2018 +0200 ovl: fix regression in fsnotify of overlay merge dir A re-factoring patch in NFS export series has passed the wrong argument to ovl_get_inode() causing a regression in the very recent fix to fsnotify of overlay merge dir. The regression has caused merge directory inodes to be hashed by upper instead of lower real inode, when NFS export and directory indexing is disabled. That caused an inotify watch to become obsolete after directory copy up and drop caches. LTP test inotify07 was improved to catch this regression. The regression also caused multiple redirect dirs to same origin not to be detected on lookup with NFS export disabled. An xfstest was added to cover this case. Fixes: 0aceb53e73be ("ovl: do not pass overlay dentry to ovl_get_inode()") Signed-off-by: Amir Goldstein <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]> commit 0ae7d327a64b262443b7d3ebee5831e4dde47b89 Author: Georgi Djakov <[email protected]> Date: Tue Dec 5 17:47:00 2017 +0200 dt-bindings: mailbox: qcom: Document the APCS clock binding Update the binding documentation for APCS to mention that the APCS hardware block also expose a clock controller functionality. The APCS clock controller is a mux and half-integer divider. It has the main CPU PLL as an input and provides the clock for the application CPU. Signed-off-by: Georgi Djakov <[email protected]> Reviewed-by: Rob Herring <[email protected]> Acked-by: Bjorn Andersson <[email protected]> Signed-off-by: Jassi Brar <[email protected]> commit c815d769b598196bdbd104a7e049d07ae6fba0d2 Author: Georgi Djakov <[email protected]> Date: Tue Dec 5 17:46:57 2017 +0200 mailbox: qcom: Create APCS child device for clock controller There is a clock controller functionality provided by the APCS hardware block of msm8916 devices. The device-tree would represent an APCS node with both mailbox and clock provider properties. Create a platform child device for the clock controller functionality so the driver can probe and use APCS as parent. Signed-off-by: Georgi Djakov <[email protected]> Acked-by: Bjorn Andersson <[email protected]> Signed-off-by: Jassi Brar <[email protected]> commit c6a8b171ca8e338a3012420041346f0e50f7f649 Author: Georgi Djakov <[email protected]> Date: Tue Dec 5 17:46:56 2017 +0200 mailbox: qcom: Convert APCS IPC driver to use regmap This hardware block provides more functionalities that just IPC. Convert it to regmap to allow other child platform devices to use the same regmap. Signed-off-by: Georgi Djakov <[email protected]> Acked-by: Bjorn Andersson <[email protected]> Signed-off-by: Jassi Brar <[email protected]> commit b2ac58f90540e39324e7a29a7ad471407ae0bf48 Author: KarimAllah Ahmed <[email protected]> Date: Sat Feb 3 15:56:23 2018 +0100 KVM/SVM: Allow direct access to MSR_IA32_SPEC_CTRL [ Based on a patch from Paolo Bonzini <[email protected]> ] ... basically doing exactly what we do for VMX: - Passthrough SPEC_CTRL to guests (if enabled in guest CPUID) - Save and restore SPEC_CTRL around VMExit and VMEntry only if the guest actually used it. Signed-off-by: KarimAllah Ahmed <[email protected]> Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Darren Kenny <[email protected]> Reviewed-by: Konrad Rzeszutek Wilk <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Jun Nakajima <[email protected]> Cc: [email protected] Cc: Dave Hansen <[email protected]> Cc: Tim Chen <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Asit Mallick <[email protected]> Cc: Arjan Van De Ven <[email protected]> Cc: Greg KH <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Dan Williams <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Ashok Raj <[email protected]> Link: https://lkml.kernel.org/r/[email protected] commit d28b387fb74da95d69d2615732f50cceb38e9a4d Author: KarimAllah Ahmed <[email protected]> Date: Thu Feb 1 22:59:45 2018 +0100 KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL [ Based on a patch from Ashok Raj <[email protected]> ] Add direct access to MSR_IA32_SPEC_CTRL for guests. This is needed for guests that will only mitigate Spectre V2 through IBRS+IBPB and will not be using a retpoline+IBPB based approach. To avoid the overhead of saving and restoring the MSR_IA32_SPEC_CTRL for guests that do not actually use the MSR, only start saving and restoring when a non-zero is written to it. No attempt is made to handle STIBP here, intentionally. Filtering STIBP may be added in a future patch, which may require trapping all writes if we don't want to pass it through directly to the guest. [dwmw2: Clean up CPUID bits, save/restore manually, handle reset] Signed-off-by: KarimAllah Ahmed <[email protected]> Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Darren Kenny <[email protected]> Reviewed-by: Konrad Rzeszutek Wilk <[email protected]> Reviewed-by: Jim Mattson <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Jun Nakajima <[email protected]> Cc: [email protected] Cc: Dave Hansen <[email protected]> Cc: Tim Chen <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Asit Mallick <[email protected]> Cc: Arjan Van De Ven <[email protected]> Cc: Greg KH <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Dan Williams <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Ashok Raj <[email protected]> Link: https://lkml.kernel.org/r/[email protected] commit 28c1c9fabf48d6ad596273a11c46e0d0da3e14cd Author: KarimAllah Ahmed <[email protected]> Date: Thu Feb 1 22:59:44 2018 +0100 KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES Intel processors use MSR_IA32_ARCH_CAPABILITIES MSR to indicate RDCL_NO (bit 0) and IBRS_ALL (bit 1). This is a read-only MSR. By default the contents will come directly from the hardware, but user-space can still override it. [dwmw2: The bit in kvm_cpuid_7_0_edx_x86_features can be unconditional] Signed-off-by: KarimAllah Ahmed <[email protected]> Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Paolo Bonzini <[email protected]> Reviewed-by: Darren Kenny <[email protected]> Reviewed-by: Jim Mattson <[email protected]> Reviewed-by: Konrad Rzeszutek Wilk <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Jun Nakajima <[email protected]> Cc: [email protected] Cc: Dave Hansen <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Asit Mallick <[email protected]> Cc: Arjan Van De Ven <[email protected]> Cc: Greg KH <[email protected]> Cc: Dan Williams <[email protected]> Cc: Tim Chen <[email protected]> Cc: Ashok Raj <[email protected]> Link: https://lkml.kernel.org/r/[email protected] commit 15d45071523d89b3fb7372e2135fbd72f6af9506 Author: Ashok Raj <[email protected]> Date: Thu Feb 1 22:59:43 2018 +0100 KVM/x86: Add IBPB support The Indirect Branch Predictor Barrier (IBPB) is an indirect branch control mechanism. It keeps earlier branches from influencing later ones. Unlike IBRS and STIBP, IBPB does not define a new mode of operation. It's a command that ensures predicted branch targets aren't used after the barrier. Although IBRS and IBPB are enumerated by the same CPUID enumeration, IBPB is very different. IBPB helps mitigate against three potential attacks: * Mitigate guests from being attacked by other guests. - This is addressed by issing IBPB when we do a guest switch. * Mitigate attacks from guest/ring3->host/ring3. These would require a IBPB during context switch in host, or after VMEXIT. The host process has two ways to mitigate - Either it can be compiled with retpoline - If its going through context switch, and has set !dumpable then there is a IBPB in that path. (Tim's patch: https://patchwork.kernel.org/patch/10192871) - The case where after a VMEXIT you return back to Qemu might make Qemu attackable from guest when Qemu isn't compiled with retpoline. There are issues reported when doing IBPB on every VMEXIT that resulted in some tsc calibration woes in guest. * Mitigate guest/ring0->host/ring0 attacks. When host kernel is using retpoline it is safe against these attacks. If host kernel isn't using retpoline we might need to do a IBPB flush on every VMEXIT. Even when using retpoline for indirect calls, in certain conditions 'ret' can use the BTB on Skylake-era CPUs. There are other mitigations available like RSB stuffing/clearing. * IBPB is issued only for SVM during svm_free_vcpu(). VMX has a vmclear and SVM doesn't. Follow discussion here: https://lkml.org/lkml/2018/1/15/146 Please refer to the following spec for more details on the enumeration and control. Refer here to get documentation about mitigations. https://software.intel.com/en-us/side-channel-security-support [peterz: rebase and changelog rewrite] [karahmed: - rebase - vmx: expose PRED_CMD if guest has it in CPUID - svm: only pass through IBPB if guest has it in CPUID - vmx: support !cpu_has_vmx_msr_bitmap()] - vmx: support nested] [dwmw2: Expose CPUID bit too (AMD IBPB only for now as we lack IBRS) PRED_CMD is a write-only MSR] Signed-off-by: Ashok Raj <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: KarimAllah Ahmed <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Konrad Rzeszutek Wilk <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Andi Kleen <[email protected]> Cc: [email protected] Cc: Asit Mallick <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Arjan Van De Ven <[email protected]> Cc: Greg KH <[email protected]> Cc: Jun Nakajima <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Dan Williams <[email protected]> Cc: Tim Chen <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] commit b7b27aa011a1df42728d1768fc181d9ce69e6911 Author: KarimAllah Ahmed <[email protected]> Date: Thu Feb 1 22:59:42 2018 +0100 KVM/x86: Update the reverse_cpuid list to include CPUID_7_EDX [dwmw2: Stop using KF() for bits in it, too] Signed-off-by: KarimAllah Ahmed <[email protected]> Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Paolo Bonzini <[email protected]> Reviewed-by: Konrad Rzeszutek Wilk <[email protected]> Reviewed-by: Jim Mattson <[email protected]> Cc: [email protected] Cc: Radim Krčmář <[email protected]> Link: https://lkml.kernel.org/r/[email protected] commit 23c35f48f5fbe33f68904138b23fee64df7d2f0f Author: Linus Torvalds <[email protected]> Date: Fri Feb 2 16:44:14 2018 -0800 pinctrl: remove include file from <linux/device.h> When pulling the recent pinctrl merge, I was surprised by how a pinctrl-only pull request ended up rebuilding basically the whole kernel. The reason for that ended up being that <linux/device.h> included <linux/pinctrl/devinfo.h>, so any change to that file ended up causing pretty much every driver out there to be rebuilt. The reason for that was because 'struct device' has this in it: #ifdef CONFIG_PINCTRL struct dev_pin_info *pins; #endif but we already avoid header includes for these kinds of things in that header file, preferring to just use a forward-declaration of the structure instead. Exactly to avoid this kind of header dependency. Since some drivers seem to expect that <linux/pinctrl/devinfo.h> header to come in automatically, move the include to <linux/pinctrl/pinctrl.h> instead. It might be better to just make the includes more targeted, but I'm not going to review every driver. It would definitely be good to have a tool for finding and minimizing header dependencies automatically - or at least help with them. Right now we almost certainly end up having way too many of these things, and it's hard to test every single configuration. FWIW, you can get a sense of the "hotness" of a header file with something like this after doing a full build: find . -name '.*.o.cmd' -print0 | xargs -0 tail --lines=+2 | grep -v 'wildcard ' | tr ' \\' '\n' | sort | uniq -c | sort -n | less -S which isn't exact (there are other things in those '*.o.cmd' than just the dependencies, and the "--lines=+2" only removes the header), but might a useful approximation. With this patch, <linux/pinctrl/devinfo.h> drops to "only" having 833 users in the current x86-64 allmodconfig. In contrast, <linux/device.h> has 14857 build files including it directly or indirectly. Of course, the headers that absolutely _everybody_ includes (things like <linux/types.h> etc) get a score of 23000+. Cc: Linus Walleij <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> commit a81114d03e4a529c4b68293249f75438b3c1783f Author: Ard Biesheuvel <[email protected]> Date: Sat Feb 3 11:25:20 2018 +0100 firmware: dmi: handle missing DMI data gracefully Currently, when booting a kernel with DMI support on a platform that has no DMI tables, the following output is emitted into the kernel log: [ 0.128818] DMI not present or invalid. ... [ 1.306659] dmi: Firmware registration failed. ... [ 2.908681] dmi-sysfs: dmi entry is absent. The first one is a pr_info(), but the subsequent ones are pr_err()s that complain about a condition that is not really an error to begin with. So let's clean this up, and give up silently if dma_available is not set. Signed-off-by: Ard Biesheuvel <[email protected]> Acked-by: Martin Hundebøll <[email protected]> Signed-off-by: Jean Delvare <[email protected]> commit a7770ae194569e96a93c48aceb304edded9cc648 Author: Jean Delvare <[email protected]> Date: Sat Feb 3 11:25:20 2018 +0100 firmware: dmi_scan: Fix handling of empty DMI strings The handling of empty DMI strings looks quite broken to me: * Strings from 1 to 7 spaces are not considered empty. * True empty DMI strings (string index set to 0) are not considered empty, and result in allocating a 0-char string. * Strings with invalid index also result in allocating a 0-char string. * Strings starting with 8 spaces are all considered empty, even if non-space characters follow (sounds like a weird thing to do, but I have actually seen occurrences of this in DMI tables before.) * Strings which are considered empty are reported as 8 spaces, instead of being actually empty. Some of these issues are the result of an off-by-one error in memcmp, the rest is incorrect by design. So let's get it square: missing strings and strings made of only spaces, regardless of their length, should be treated as empty and no memory should be allocated for them. All other strings are non-empty and should be allocated. Signed-off-by: Jean Delvare <[email protected]> Fixes: 79da4721117f ("x86: fix DMI out of memory problems") Cc: Parag Warudkar <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Thomas Gleixner <[email protected]> commit 7117794feb1602ea5efca1c7bfd5b78c3278d29d Author: Jean Delvare <[email protected]> Date: Sat Feb 3 11:25:20 2018 +0100 firmware: dmi_scan: Drop dmi_initialized I don't think it makes sense to check for a possible bad initialization order at run time on every system when it is all decided at build time. A more efficient way to make sure developers do not introduce new calls to dmi_check_system() too early in the initialization sequence is to simply document the expected call order. That way, developers have a chance to get it right immediately, without having to test-boot their kernel, wonder why it does not work, and parse the kernel logs for a warning message. And we get rid of the run-time performance penalty as a nice side effect. Signed-off-by: Jean Delvare <[email protected]> Cc: Ingo Molnar <[email protected]> commit 8cf4e6a04f734e831c2ac7f405071d1cde690ba8 Author: Jean Delvare <[email protected]> Date: Sat Feb 3 11:25:20 2018 +0100 firmware: dmi: Optimize dmi_matches Function dmi_matches can me made a bit faster: * The documented purpose of dmi_initialized is to catch too early calls to dmi_check_system(). I'm not fully convinced it justifies slowing down the initialization of all systems out there, but at least the check should not have been moved from dmi_check_system() to dmi_matches(). dmi_matches() is being called for every entry of the table passed to dmi_check_system(), causing the same redundant check to be performed again and again. So move it back to dmi_check_system(), reverting this specific portion of commit d7b1956fed33 ("DMI: Introduce dmi_first_match to make the interface more flexible"). * Don't check for the exact_match flag again when we already know its value. Signed-off-by: Jean Delvare <[email protected]> Fixes: d7b1956fed33 ("DMI: Introduce dmi_first_match to make the interface more flexible") Cc: Jani Nikula <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Cc: Jeff Garzik <[email protected]> commit edbe69ef2c90fc86998a74b08319a01c508bd497 Author: Roman Gushchin <[email protected]> Date: Fri Feb 2 15:26:57 2018 +0000 Revert "defer call to mem_cgroup_sk_alloc()" This patch effectively reverts commit 9f1c2674b328 ("net: memcontrol: defer call to mem_cgroup_sk_alloc()"). Moving mem_cgroup_sk_alloc() to the inet_csk_accept() completely breaks memcg socket memory accounting, as packets received before memcg pointer initialization are not accounted and are causing refcounting underflow on socket release. Actually the free-after-use problem was fixed by commit c0576e397508 ("net: call cgroup_sk_alloc() earlier in sk_clone_lock()") for the cgroup pointer. So, let's revert it and call mem_cgroup_sk_alloc() just before cgroup_sk_alloc(). This is safe, as we hold a reference to the socket we're cloning, and it holds a reference to the memcg. Also, let's drop BUG_ON(mem_cgroup_is_root()) check from mem_cgroup_sk_alloc(). I see no reasons why bumping the root memcg counter is a good reason to panic, and there are no realistic ways to hit it. Signed-off-by: Roman Gushchin <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: David S. Miller <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Tejun Heo <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 4db428a7c9ab07e08783e0fcdc4ca0f555da0567 Author: Eric Dumazet <[email protected]> Date: Fri Feb 2 10:27:27 2018 -0800 soreuseport: fix mem leak in reuseport_add_sock() reuseport_add_sock() needs to deal with attaching a socket having its own sk_reuseport_cb, after a prior setsockopt(SO_ATTACH_REUSEPORT_?BPF) Without this fix, not only a WARN_ONCE() was issued, but we were also leaking memory. Thanks to sysbot and Eric Biggers for providing us nice C repros. ------------[ cut here ]------------ socket already in reuseport group WARNING: CPU: 0 PID: 3496 at net/core/sock_reuseport.c:119 reuseport_add_sock+0x742/0x9b0 net/core/sock_reuseport.c:117 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 3496 Comm: syzkaller869503 Not tainted 4.15.0-rc6+ #245 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:53 panic+0x1e4/0x41c kernel/panic.c:183 __warn+0x1dc/0x200 kernel/panic.c:547 report_bug+0x211/0x2d0 lib/bug.c:184 fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178 fixup_bug arch/x86/kernel/traps.c:247 [inline] do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315 invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1079 Fixes: ef456144da8e ("soreuseport: define reuseport groups") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: [email protected] Acked-by: Craig Gallek <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit cfabb1779d725c6d719793e44f5c50382eae6227 Author: Arnd Bergmann <[email protected]> Date: Fri Feb 2 16:45:44 2018 +0100 net: qlge: use memmove instead of skb_copy_to_linear_data gcc-8 points out that the skb_copy_to_linear_data() argument points to the skb itself, which makes it run into a problem with overlapping memcpy arguments: In file included from include/linux/ip.h:20, from drivers/net/ethernet/qlogic/qlge/qlge_main.c:26: drivers/net/ethernet/qlogic/qlge/qlge_main.c: In function 'ql_realign_skb': include/linux/skbuff.h:3378:2: error: 'memcpy' source argument is the same as destination [-Werror=restrict] memcpy(skb->data, from, len); It's unclear to me what the best solution is, maybe it ought to use a different helper that adjusts the skb data in a safe way. Simply using memmove() here seems like the easiest workaround. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 11f711081af0eb54190dc0de96ba4a9cd494666b Author: Arnd Bergmann <[email protected]> Date: Fri Feb 2 16:44:47 2018 +0100 net: qed: use correct strncpy() size passing the strlen() of the source string as the destination length is pointless, and gcc-8 now warns about it: drivers/net/ethernet/qlogic/qed/qed_debug.c: In function 'qed_grc_dump': include/linux/string.h:253: error: 'strncpy' specified bound depends on the length of the source argument [-Werror=stringop-overflow=] This changes qed_grc_dump_big_ram() to instead uses the length of the destination buffer, and use strscpy() to guarantee nul-termination. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 1a91649fd35ff53a646981e212496f1ae92a8487 Author: Arnd Bergmann <[email protected]> Date: Fri Feb 2 16:18:37 2018 +0100 net: cxgb4: avoid memcpy beyond end of source buffer Building with link-time-optimizations revealed that the cxgb4 driver does a fixed-size memcpy() from a variable-length constant string into the network interface name: In function 'memcpy', inlined from 'cfg_queues_uld.constprop' at drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:335:2, inlined from 'cxgb4_register_uld.constprop' at drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:719:9: include/linux/string.h:350:3: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter __read_overflow2(); ^ I can see two equally workable solutions: either we use a strncpy() instead of the memcpy() to stop at the end of the input, or we make the source buffer fixed length as well. This implements the latter. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 058a6c033488494a6b1477b05fe8e1a16e344462 Author: Paolo Abeni <[email protected]> Date: Fri Feb 2 16:02:22 2018 +0100 cls_u32: add missing RCU annotation. In a couple of points of the control path, n->ht_down is currently accessed without the required RCU annotation. The accesses are safe, but sparse complaints. Since we already held the rtnl lock, let use rtnl_dereference(). Fixes: a1b7c5fd7fe9 ("net: sched: add cls_u32 offload hooks for netdevs") Fixes: de5df63228fc ("net: sched: cls_u32 changes to knode must appear atomic to readers") Signed-off-by: Paolo Abeni <[email protected]> Acked-by: Cong Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit aece4770fba62102951891c2f349a255c83eacb9 Author: Hayes Wang <[email protected]> Date: Fri Feb 2 16:43:36 2018 +0800 r8152: set rx mode early when linking on Set rx mode before calling netif_wake_queue() when linking on to avoid the device missing the receiving packets. The transmission may start after calling netif_wake_queue(), and the packets of resopnse may reach before calling rtl8152_set_rx_mode() which let the device could receive packets. Then, the packets of response would be missed. Signed-off-by: Hayes Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit ea6499e160a74ea813e53e7bef2ccb22df1e4929 Author: Hayes Wang <[email protected]> Date: Fri Feb 2 16:43:35 2018 +0800 r8152: fix wrong checksum status for received IPv4 packets The device could only check the checksum of TCP and UDP packets. Therefore, for the IPv4 packets excluding TCP and UDP, the check of checksum is necessary, even though the IP checksum is correct. Take ICMP for example, The IP checksum may be correct, but the ICMP checksum may be wrong. Signed-off-by: Hayes Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 1d8ef0c07664dc48f2ff19a90b62dd3f6f425547 Author: Edwin Peer <[email protected]> Date: Thu Feb 1 19:41:43 2018 -0800 nfp: fix TLV offset calculation The data pointer in the config space TLV parser already includes NFP_NET_CFG_TLV_BASE, it should not be added again. Incorrect offset values were only used in printed user output, rendering the bug merely cosmetic. Fixes: 73a0329b057e ("nfp: add TLV capabilities to the BAR") Signed-off-by: Edwin Peer <[email protected]> Reviewed-by: Jakub Kicinski <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 328008a72d38b5bde6491e463405c34a81a65d3e Author: Arnd Bergmann <[email protected]> Date: Fri Feb 2 15:56:18 2018 +0100 x86/power: Fix swsusp_arch_resume prototype The declaration for swsusp_arch_resume marks it as 'asmlinkage', but the definition in x86-32 does not, and it fails to include the header with the declaration. This leads to a warning when building with link-time-optimizations: kernel/power/power.h:108:23: error: type of 'swsusp_arch_resume' does not match original declaration [-Werror=lto-type-mismatch] extern asmlinkage int swsusp_arch_resume(void); ^ arch/x86/power/hibernate_32.c:148:0: note: 'swsusp_arch_resume' was previously declared here int swsusp_arch_resume(void) This moves the declaration into a globally visible header file and fixes up both x86 definitions to match it. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Len Brown <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Nicolas Pitre <[email protected]> Cc: [email protected] Cc: "Rafael J. Wysocki" <[email protected]> Cc: Pavel Machek <[email protected]> Cc: Bart Van Assche <[email protected]> Link: https://lkml.kernel.org/r/[email protected] commit ebfc15019cfa72496c674ffcb0b8ef10790dcddc Author: Arnd Bergmann <[email protected]> Date: Fri Feb 2 15:56:17 2018 +0100 x86/dumpstack: Avoid uninitlized variable In some configurations, 'partial' does not get initialized, as shown by this gcc-8 warning: arch/x86/kernel/dumpstack.c: In function 'show_trace_log_lvl': arch/x86/kernel/dumpstack.c:156:4: error: 'partial' may be used uninitialized in this function [-Werror=maybe-uninitialized] show_regs_if_on_stack(&stack_info, regs, partial); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This initializes it to false, to get the previous behavior in this case. Fixes: a9cdbe72c4e8 ("x86/dumpstack: Fix partial register dumps") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Nicolas Pitre <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Vlastimil Babka <[email protected]> Link: https://lkml.kernel.org/r/[email protected] commit af189c95a371b59f493dbe0f50c0a09724868881 Author: Darren Kenny <[email protected]> Date: Fri Feb 2 19:12:20 2018 +0000 x86/speculation: Fix typo IBRS_ATT, which should be IBRS_ALL Fixes: 117cc7a908c83 ("x86/retpoline: Fill return stack buffer on vmexit") Signed-off-by: Darren Kenny <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Konrad Rzeszutek Wilk <[email protected]> Cc: Tom Lendacky <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Masami Hiramatsu <[email protected]> Cc: Arjan van de Ven <[email protected]> Cc: David Woodhouse <[email protected]> Link: https://lkml.kernel.org/r/[email protected] commit 4bf5d56d429cbc96c23d809a08f63cd29e1a702e Author: Arnd Bergmann <[email protected]> Date: Fri Feb 2 22:39:23 2018 +0100 x86/pti: Mark constant arrays as __initconst I'm seeing build failures from the two newly introduced arrays that are marked 'const' and '__initdata', which are mutually exclusive: arch/x86/kernel/cpu/common.c:882:43: error: 'cpu_no_speculation' causes a section type conflict with 'e820_table_firmware_init' arch/x86/kernel/cpu/common.c:895:43: error: 'cpu_no_meltdown' causes a section type conflict with 'e820_table_firmware_init' The correct annotation is __initconst. Fixes: fec9434a12f3 ("x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Ricardo Neri <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Thomas Garnier <[email protected]> Cc: David Woodhouse <[email protected]> Link: https://lkml.kernel.org/r/[email protected] commit 1d51877578799bfe0fcfe189d8233c9fccf05931 Author: Arnd Bergmann <[email protected]> Date: Fri Feb 2 16:03:04 2018 +0100 block: skd: fix incorrect linux/slab_def.h inclusion skd includes slab_def.h to get access to the slab cache object size. However, including this header breaks when we use SLUB or SLOB instead of the SLAB allocator, since the structure layout is completely different, as shown by this warning when we build this driver in one of the invalid configurations with link-time optimizations enabled: include/linux/slab.h:715:0: error: type of 'kmem_cache_size' does not match original declaration [-Werror=lto-type-mismatch] unsigned int kmem_cache_size(struct kmem_cache *s); mm/slab_common.c:77:14: note: 'kmem_cache_size' was previously declared here unsigned int kmem_cache_size(struct kmem_cache *s) ^ mm/slab_common.c:77:14: note: code may be misoptimized unless -fno-strict-aliasing is used include/linux/slab.h:147:0: error: type of 'kmem_cache_destroy' does not match original declaration [-Werror=lto-type-mismatch] void kmem_cache_destroy(struct kmem_cache *); mm/slab_common.c:858:6: note: 'kmem_cache_destroy' was previously declared here void kmem_cache_destroy(struct kmem_cache *s) ^ mm/slab_common.c:858:6: note: code may be misoptimized unless -fno-strict-aliasing is used include/linux/slab.h:140:0: error: type of 'kmem_cache_create' does not match original declaration [-Werror=lto-type-mismatch] struct kmem_cache *kmem_cache_create(const char *name, size_t size, mm/slab_common.c:534:1: note: 'kmem_cache_create' was previously declared here kmem_cache_create(const char *name, size_t size, size_t align, ^ This removes the header inclusion and instead uses the kmem_cache_size() interface to get the size in a reliable way. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Jens Axboe <[email protected]> commit 60f91826ca62bcf85d6d5fc90941337282787671 Author: Kemi Wang <[email protected]> Date: Tue Oct 24 09:16:42 2017 +0800 buffer: Avoid setting buffer bits that are already set It's expensive to set buffer flags that are already set, because that causes a costly cache line transition. A common case is setting the "verified" flag during ext4 writes. This patch checks for the flag being set first. With the AIM7/creat-clo benchmark testing on a 48G ramdisk based-on ext4 file system, we see 3.3%(15431->15936) improvement of aim7.jobs-per-min on a 2-sockets broadwell platform. What the benchmark does is: it forks 3000 processes, and each process do the following: a) open a new file b) close the file c) delete the file until loop=100*1000 times. The original patch is contributed by Andi Kleen. Signed-off-by: Andi Kleen <[email protected]> Tested-by: Kemi Wang <[email protected]> Signed-off-by: Kemi Wang <[email protected]> Signed-off-by: Jens Axboe <[email protected]> commit 9005c6834c0ffdfe46afa76656bd9276cca864f6 Author: KarimAllah Ahmed <[email protected]> Date: Thu Feb 1 11:27:21 2018 +0000 x86/spectre: Simplify spectre_v2 command line parsing [dwmw2: Use ARRAY_SIZE] Signed-off-by: KarimAllah Ahmed <[email protected]> Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: [email protected] Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] commit 66f793099a636862a71c59d4a6ba91387b155e0c Author: David Woodhouse <[email protected]> Date: Thu Feb 1 11:27:20 2018 +0000 x86/retpoline: Avoid retpolines for built-in __init functions There's no point in building init code with retpolines, since it runs before any potentially hostile userspace does. And before the retpoline is actually ALTERNATIVEd into place, for much of it. Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] commit e2598077dc6a26c9644393e5c21f22a90dbdccdb Author: Mimi Zohar <[email protected]> Date: Tue Jan 23 10:00:41 2018 -0500 ima: re-initialize iint->atomic_flags Intermittently security.ima is not being written for new files. This patch re-initializes the new slab iint->atomic_flags field before freeing it. Fixes: commit 0d73a55208e9 ("ima: re-introduce own integrity cache lock") Signed-off-by: Mimi Zohar <[email protected]> Signed-off-by: James Morris <[email protected]> commit 7825cd83fad7a30328bc874062eb19bdb2fbb38b Author: Mimi Zohar <[email protected]> Date: Wed Jan 31 22:14:36 2018 -0500 maintainers: update trusted keys Adding James Bottomley as the new maintainer for trusted keys. Signed-off-by: Mimi Zohar <[email protected]> Signed-off-by: James Morris <[email protected]> commit 76883f7988e6d06a97232e979bc7aaa7846a134b Author: Darrick J. Wong <[email protected]> Date: Wed Jan 31 09:47:25 2018 -0800 xfs: remove experimental tag for reverse mapping Reverse mapping has had a while to soak, so remove the experimental tag. Now that we've landed space metadata cross-referencing in scrub, the feature actually has a purpose. Reject rmap filesystems with an rt device until the code to support it is actually implemented. Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Dave Chinner <[email protected]> Reviewed-by: Bill O'Donnell <[email protected]> commit c14632ddac98dca7ab1740461fae330d09909560 Author: Darrick J. Wong <[email protected]> Date: Wed Jan 31 16:38:18 2018 -0800 xfs: don't allow reflink + realtime filesystems We don't support realtime filesystems with reflink either, so fail those mounts. Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Bill O'Donnell <[email protected]> commit b6e03c10bf3ff08c7678a946a2208b60e66f4426 Author: Darrick J. Wong <[email protected]> Date: Wed Jan 31 14:21:56 2018 -0800 xfs: don't allow DAX on reflink filesystems Now that reflink is no longer experimental, reject attempts to mount with DAX until that whole mess gets sorted out. Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Bill O'Donnell <[email protected]> Reviewed-by: Dave Chinner <[email protected]> commit 494370ccaae891de0a99b3c23b2df482c95cab8c Author: Eric Sandeen <[email protected]> Date: Wed Jan 31 11:31:10 2018 -0800 xfs: add scrub to XFS_BUILD_OPTIONS Advertise this config option along with the others. Signed-off-by: Eric Sandeen <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]> commit bea99a500773fdfdb16b7dbfbaa00af7a6f0dc3b Author: Keith Busch <[email protected]> Date: Thu Feb 1 14:41:15 2018 -0700 blk-mq-sched: Enable merging discard bio into request Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Jens Axboe <[email protected]> commit 445251d0f4d329aa061f323546cd6388a3bb7ab5 Author: Jens Axboe <[email protected]> Date: Thu Feb 1 14:01:02 2018 -0700 blk-mq: fix discard merge with scheduler attached I ran into an issue on my laptop that triggered a bug on the discard path: WARNING: CPU: 2 PID: 207 at drivers/nvme/host/core.c:527 nvme_setup_cmd+0x3d3/0x430 Modules linked in: rfcomm fuse ctr ccm bnep arc4 binfmt_misc snd_hda_codec_hdmi nls_iso8859_1 nls_cp437 vfat snd_hda_codec_conexant fat snd_hda_codec_generic iwlmvm snd_hda_intel snd_hda_codec snd_hwdep mac80211 snd_hda_core snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq x86_pkg_temp_thermal intel_powerclamp kvm_intel uvcvideo iwlwifi btusb snd_seq_device videobuf2_vmalloc btintel videobuf2_memops kvm snd_timer videobuf2_v4l2 bluetooth irqbypass videobuf2_core aesni_intel aes_x86_64 crypto_simd cryptd snd glue_helper videodev cfg80211 ecdh_generic soundcore hid_generic usbhid hid i915 psmouse e1000e ptp pps_core xhci_pci xhci_hcd intel_gtt CPU: 2 PID: 207 Comm: jbd2/nvme0n1p7- Tainted: G U 4.15.0+ #176 Hardware name: LENOVO 20FBCTO1WW/20FBCTO1WW, BIOS N1FET59W (1.33 ) 12/19/2017 RIP: 0010:nvme_setup_cmd+0x3d3/0x430 RSP: 0018:ffff880423e9f838 EFLAGS: 00010217 RAX: 0000000000000000 RBX: ffff880423e9f8c8 RCX: 0000000000010000 RDX: ffff88022b200010 RSI: 0000000000000002 RDI: 00000000327f0000 RBP: ffff880421251400 R08: ffff88022b200000 R09: 0000000000000009 R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000ffff R13: ffff88042341e280 R14: 000000000000ffff R15: ffff880421251440 FS: 0000000000000000(0000) GS:ffff880441500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055b684795030 CR3: 0000000002e09006 CR4: 00000000001606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: nvme_queue_rq+0x40/0xa00 ? __sbitmap_queue_get+0x24/0x90 ? blk_mq_get_tag+0xa3/0x250 ? wait_woken+0x80/0x80 ? blk_mq_get_driver_tag+0x97/0xf0 blk_mq_dispatch_rq_list+0x7b/0x4a0 ? deadline_remove_request+0x49/0xb0 blk_mq_do_dispatch_sched+0x4f/0xc0 blk_mq_sched_dispatch_requests+0x106/0x170 __blk_mq_run_hw_queue+0x53/0xa0 __blk_mq_delay_run_hw_queue+0x83/0xa0 blk_mq_run_hw_queue+0x6c/0xd0 blk_mq_sched_insert_request+0x96/0x140 __blk_mq_try_issue_directly+0x3d/0x190 blk_mq_try_issue_directly+0x30/0x70 blk_mq_make_request+0x1a4/0x6a0 generic_make_request+0xfd/0x2f0 ? submit_bio+0x5c/0x110 submit_bio+0x5c/0x110 ? __blkdev_issue_discard+0x152/0x200 submit_bio_wait+0x43/0x60 ext4_process_freed_data+0x1cd/0x440 ? account_page_dirtied+0xe2/0x1a0 ext4_journal_commit_callback+0x4a/0xc0 jbd2_journal_commit_transaction+0x17e2/0x19e0 ? kjournald2+0xb0/0x250 kjournald2+0xb0/0x250 ? wait_woken+0x80/0x80 ? commit_timeout+0x10/0x10 kthread+0x111/0x130 ? kthread_create_worker_on_cpu+0x50/0x50 ? do_group_exit+0x3a/0xa0 ret_from_fork+0x1f/0x30 Code: 73 89 c1 83 ce 10 c1 e1 10 09 ca 83 f8 04 0f 87 0f ff ff ff 8b 4d 20 48 8b 7d 00 c1 e9 09 48 01 8c c7 00 08 00 00 e9 f8 fe ff ff <0f> ff 4c 89 c7 41 bc 0a 00 00 00 e8 0d 78 d6 ff e9 a1 fc ff ff ---[ end trace 50d361cc444506c8 ]--- print_req_error: I/O error, dev nvme0n1, sector 847167488 Decoding the assembly, the request claims to have 0xffff segments, while nvme counts two. This turns out to be because we don't check for a data carrying request on the mq scheduler path, and since blk_phys_contig_segment() returns true for a non-data request, we decrement the initial segment count of 0 and end up with 0xffff in the unsigned short. There are a few issues here: 1) We should initialize the segment count for a discard to 1. 2) The discard merging is currently using the data limits for segments and sectors. Fix this up by having attempt_merge() correctly identify the request, and by initializing the segment count correctly for discards. This can only be triggered with mq-deadline on discard capable devices right now, which isn't a common configuration. Signed-off-by: Jens Axboe <[email protected]> commit babcbbc7c4e2fa7fa76417ece7c57083bee971f1 Author: Andrey Ryabinin <[email protected]> Date: Thu Feb 1 21:00:52 2018 +0300 fs: dcache: Revert "manually unpoison dname after allocation to shut up kasan's reports" This reverts commit df4c0e36f1b1782b0611a77c52cc240e5c4752dd. It's no longer needed since dentry_string_cmp() now uses read_word_at_a_time() to avoid kasan's reports. Signed-off-by: Andrey Ryabinin <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> commit bfe7aa6c39b12a6ab1e95f50271c53e47d6dd060 Author: Andrey Ryabinin <[email protected]> Date: Thu Feb 1 21:00:51 2018 +0300 fs/dcache: Use read_word_at_a_time() in dentry_string_cmp() dentry_string_cmp() performs the word-at-a-time reads from 'cs' and may read slightly more than it was requested in kmallac(). Normally this would make KASAN to report out-of-bounds access, but this was workarounded by commit df4c0e36f1b1 ("fs: dcache: manually unpoison dname after allocation to shut up kasan's reports"). This workaround is not perfect, since it allows out-of-bounds access to dentry's name for all the code, not just in dentry_string_cmp(). So it would be better to use read_word_at_a_time() instead and revert commit df4c0e36f1b1. Signed-off-by: Andrey Ryabinin <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> commit 1a3241ff10d038ecd096d03380327f2a0b5840a6 Author: Andrey Ryabinin <[email protected]> Date: Thu Feb 1 21:00:50 2018 +0300 lib/strscpy: Shut up KASAN false-positives in strscpy() strscpy() performs the word-at-a-time optimistic reads. So it may may access the memory past the end of the object, which is perfectly fine since strscpy() doesn't use that (past-the-end) data and makes sure the optimistic read won't cross a page boundary. Use new read_word_at_a_time() to shut up the KASAN. Note that this potentially could hide some bugs. In example bellow, stscpy() will copy more than we should (1-3 extra uninitialized bytes): char dst[8]; char *src; src = kmalloc(5, GFP_KERNEL); memset(src, 0xff, 5); strscpy(dst, src, 8); Signed-off-by: Andrey Ryabinin <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> commit 7f1e541fc8d57a143dd5df1d0a1276046e08c083 Author: Andrey Ryabinin <[email protected]> Date: Thu Feb 1 21:00:49 2018 +0300 compiler.h: Add read_word_at_a_time() function. Sometimes we know that it's safe to do potentially out-of-bounds access because we know it won't cross a page boundary. Still, KASAN will report this as a bug. Add read_word_at_a_time() function which is supposed to be used in such cases. In read_word_at_a_time() KASAN performs relaxed check - only the first byte of access is validated. Signed-off-by: Andrey Ryabinin <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> commit bdb5ac801af3d81d36732c2f640d6a1d3df83826 Author: Andrey Ryabinin <[email protected]> Date: Thu Feb 1 21:00:48 2018 +0300 compiler.h, kasan: Avoid duplicating __read_once_size_nocheck() Instead of having two identical __read_once_size_nocheck() functions with different attributes, consolidate all the difference in new macro __no_kasan_or_inline and use it. No functional changes. Signed-off-by: Andrey Ryabinin <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> commit 743ffffefac1c670c6618742c923f6275d819604 Author: Alexander Monakov <[email protected]> Date: Thu Feb 1 22:45:17 2018 +0300 net: pxa168_eth: add netconsole support This implements ndo_poll_controller callback which is necessary to enable netconsole. Signed-off-by: Alexander Monakov <[email protected]> Cc: Russell King <[email protected]> Cc: Sebastian Hesselbarth <[email protected]> Cc: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit e7aadb27a5415e8125834b84a74477bfbee4eff5 Author: Eric Dumazet <[email protected]> Date: Thu Feb 1 10:26:57 2018 -0800 net: igmp: add a missing rcu locking section Newly added igmpv3_get_srcaddr() needs to be called under rcu lock. Timer callbacks do not ensure this locking. ============================= WARNING: suspicious RCU usage 4.15.0+ #200 Not tainted ----------------------------- ./include/linux/inetdevice.h:216 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by syzkaller616973/4074: #0: (&mm->mmap_sem){++++}, at: [<00000000bfce669e>] __do_page_fault+0x32d/0xc90 arch/x86/mm/fault.c:1355 #1: ((&im->timer)){+.-.}, at: [<00000000619d2f71>] lockdep_copy_map include/linux/lockdep.h:178 [inline] #1: ((&im->timer)){+.-.}, at: [<00000000619d2f71>] call_timer_fn+0x1c6/0x820 kernel/time/timer.c:1316 #2: (&(&im->lock)->rlock){+.-.}, at: [<000000005f833c5c>] spin_lock_bh include/linux/spinlock.h:315 [inline] #2: (&(&im->lock)->rlock){+.-.}, at: [<000000005f833c5c>] igmpv3_send_report+0x98/0x5b0 net/ipv4/igmp.c:600 stack backtrace: CPU: 0 PID: 4074 Comm: syzkaller616973 Not tainted 4.15.0+ #200 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:53 lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4592 __in_dev_get_rcu include/linux/inetdevice.h:216 [inline] igmpv3_get_srcaddr net/ipv4/igmp.c:329 [inline] igmpv3_newpack+0xeef/0x12e0 net/ipv4/igmp.c:389 add_grhead.isra.27+0x235/0x300 net/ipv4/igmp.c:432 add_grec+0xbd3/0x1170 net/ipv4/igmp.c:565 igmpv3_send_report+0xd5/0x5b0 net/ipv4/igmp.c:605 igmp_send_report+0xc43/0x1050 net/ipv4/igmp.c:722 igmp_timer_expire+0x322/0x5c0 net/ipv4/igmp.c:831 call_timer_fn+0x228/0x820 kernel/time/timer.c:1326 expire_timers kernel/time/timer.c:1363 [inline] __run_timers+0x7ee/0xb70 kernel/time/timer.c:1666 run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692 __do_softirq+0x2d7/0xb85 kernel/softirq.c:285 invoke_softirq kernel/softirq.c:365 [inline] irq_exit+0x1cc/0x200 kernel/softirq.c:405 exiting_irq arch/x86/include/asm/apic.h:541 [inline] smp_apic_timer_interrupt+0x16b/0x700 arch/x86/kernel/apic/apic.c:1052 apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:938 Fixes: a46182b00290 ("net: igmp: Use correct source address on IGMPv3 reports") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: syzbot <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit a107311d7fdf6b826f3737c4a90fd0e0046e7a3a Author: Desnes Augusto Nunes do Rosario <[email protected]> Date: Thu Feb 1 16:04:30 2018 -0200 ibmvnic: fix firmware version when no firmware level has been provided by the VIOS server Older versions of VIOS servers do not send the firmware level in the VPD buffer for the ibmvnic driver. Thus, not only the current message is mis- leading but the firmware version in the ethtool will be NULL. Therefore, this patch fixes the firmware string and its warning. Fixes: 4e6759be28e4 ("ibmvnic: Feature implementation of VPD for the ibmvnic driver") Signed-off-by: Desnes A. Nunes do Rosario <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 5e264e2b532966bfcfe8869a3fccc9876ec2122c Author: Colin Ian King <[email protected]> Date: Thu Feb 1 17:29:21 2018 +0000 vmxnet3: remove redundant initialization of pointer 'rq' Pointer rq is being initialized but this value is never read, it is being updated inside a for-loop. Remove the initialization and move it into the scope of the for-loop. Cleans up clang warning: drivers/net/vmxnet3/vmxnet3_drv.c:2763:27: warning: Value stored to 'rq' during its initialization is never read Signed-off-by: Colin Ian King <[email protected]> Acked-by: Shrikrishna Khare <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 3b51cc75eba28a7b2ca013f8255a4fd425b12b26 Author: Colin Ian King <[email protected]> Date: Thu Feb 1 17:10:18 2018 +0000 lan78xx: remove redundant initialization of pointer 'phydev' Pointer phydev is initialized and this value is never read, phydev is immediately updated to a new value, hence this initialization is redundant and can be removed Cleans up clang warning: drivers/net/usb/lan78xx.c:2009:21: warning: Value stored to 'phydev' during its initialization is never read Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit f14d244f6147066c65dd98caa08aab0135ab1cc4 Author: Colin Ian King <[email protected]> Date: Thu Feb 1 16:58:42 2018 +0000 net: jme: remove unused initialization of 'rxdesc' Pointer rxdesc is assigned a value that is never read, it is overwritten by a new assignment inside a while loop hence the initial assignment is redundant and can be removed. Cleans up clang warning: drivers/net/ethernet/jme.c:1074:17: warning: Value stored to 'rxdesc' during its initialization is never read Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 7ac07fdaf840f9b141c6d5c286805107227c0e68 Author: Andreas Gruenbacher <[email protected]> Date: Mon Jan 8 22:35:43 2018 +0100 gfs2: Glock dump performance regression fix Restore an optimization removed in commit 7f19449553 "Fix debugfs glocks dump": keep the glock hash table iterator active while the glock dump file is held open. This avoids having to rescan the hash table from the start for each read, with quadratically rising runtime. In addition, use rhastable_walk_peek for resuming a glock dump at the current position: when a glock doesn't fit in the provided buffer anymore, the next read must revisit the same glock. Finally, also restart the dump from the first entry when we notice that the hash table has been resized in gfs2_glock_seq_start. Signed-off-by: Andreas Gruenbacher <[email protected]> Signed-off-by: Bob Peterson <[email protected]> commit dcb2cd55cf43fe06ada66265c1e088a4b08d3e3d Author: Andreas Gruenbacher <[email protected]> Date: Thu Feb 1 11:12:13 2018 +0100 gfs2: Fix the crc32c dependency Depend on LIBCRC32C which uses the crypto API to select the appropriate crc32c implementation. With the CRYPTO and CRYPTO_CRC32C dependencies, gfs2 would still need to use the crypto API directly like ext4 and btrfs do, which isn't necessary. Signed-off-by: Andreas Gruenbacher <[email protected]> Signed-off-by: Bob Peterson <[email protected]> commit 0b1dfa4cc6c60052b2c30ead316fa84c46d3c43c Author: Eric Biggers <[email protected]> Date: Fri Jan 19 13:45:24 2018 -0800 fscrypt: fix build with pre-4.6 gcc versions gcc versions prior to 4.6 require an extra level of braces when using a designated initializer for a member in an anonymous struct or union. This caused a compile error with the 'struct qstr' initialization in __fscrypt_encrypt_symlink(). Fix it by using QSTR_INIT(). Reported-by: Andrew Morton <[email protected]> Fixes: 76e81d6d5048 ("fscrypt: new helper functions for ->symlink()") Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> commit 1640eea35e8dcf0cb437f03c56868a97d0666df3 Author: Julia Lawall <[email protected]> Date: Thu Feb 1 10:20:55 2018 +0100 Coccinelle: coccicheck: fix typo Correct spelling of "coccinelle". Signed-off-by: Julia Lawall <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> commit 7973bfd8758d05c85ee32052a3d7d5d0549e91b4 Author: Christian Brauner <[email protected]> Date: Thu Feb 1 12:56:00 2018 +0100 rtnetlink: remove check for IFLA_IF_NETNSID RTM_NEWLINK supports the IFLA_IF_NETNSID property since 5bb8ed075428b71492734af66230aa0c07fcc515 so we should not error out when it is passed. Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit a83165f00f16c0e0ef5b7cec3cbd0d4788699265 Author: Jiri Pirko <[email protected]> Date: Thu Feb 1 12:21:15 2018 +0100 rocker: fix possible null pointer dereference in rocker_router_fib_event_work Currently, rocker user may experience following null pointer derefence bug: [ 3.062141] BUG: unable to handle kernel NULL pointer dereference at 00000000000000d0 [ 3.065163] IP: rocker_router_fib_event_work+0x36/0x110 [rocker] The problem is uninitialized rocker->wops pointer that is initialized only with the first initialized port. So move the port initialization before registering the fib events. Fixes: 936bd486564a ("rocker: use FIB notifications instead of switchdev calls") Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 0ba987181028ab41cdc68fa91b74c98d97b93ff3 Author: Geert Uytterhoeven <[email protected]> Date: Thu Feb 1 11:26:23 2018 +0100 inet: Avoid unitialized variable warning in inet_unhash() With gcc-4.1.2: net/ipv4/inet_hashtables.c: In function ‘inet_unhash’: net/ipv4/inet_hashtables.c:628: warning: ‘ilb’ may be used uninitialized in this function While this is a false positive, it can easily be avoided by using the pointer itself as the canary variable. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 367dc6586d2d9c0c347b567f7efec57f59c376fd Author: Geert Uytterhoeven <[email protected]> Date: Thu Feb 1 11:25:27 2018 +0100 net: bridge: Fix uninitialized error in br_fdb_sync_static() With gcc-4.1.2.: net/bridge/br_fdb.c: In function ‘br_fdb_sync_static’: net/bridge/br_fdb.c:996: warning: ‘err’ may be used uninitialized in this function Indeed, if the list is empty, err will be uninitialized, and will be propagated up as the function return value. Fix this by preinitializing err to zero. Fixes: eb7935830d00b9e0 ("net: bridge: use rhashtable for fdbs") Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 9382fe71c0058465e942a633869629929102843d Author: Ed Swierk <[email protected]> Date: Wed Jan 31 18:48:02 2018 -0800 openvswitch: Remove padding from packet before L3+ conntrack processing IPv4 and IPv6 packets may arrive with lower-layer padding that is not included in the L3 length. For example, a short IPv4 packet may have up to 6 bytes of padding following the IP payload when received on an Ethernet device with a minimum packet length of 64 bytes. Higher-layer processing functions in netfilter (e.g. nf_ip_checksum(), and help() in nf_conntrack_ftp) assume skb->len reflects the length of the L3 header and payload, rather than referring back to ip_hdr->tot_len or ipv6_hdr->payload_len, and get confused by lower-layer padding. In the normal IPv4 receive path, ip_rcv() trims the packet to ip_hdr->tot_len before invoking netfilter hooks. In the IPv6 receive path, ip6_rcv() does the same using ipv6_hdr->payload_len. Similarly in the br_netfilter receive path, br_validate_ipv4() and br_validate_ipv6() trim the packet to the L3 length before invoking netfilter hooks. Currently in the OVS conntrack receive path, ovs_ct_execute() pulls the skb to the L3 header but does not trim it to the L3 length before calling nf_conntrack_in(NF_INET_PRE_ROUTING). When nf_conntrack_proto_tcp encounters a packet with lower-layer padding, nf_ip_checksum() fails causing a "nf_ct_tcp: bad TCP checksum" log message. While extra zero bytes don't affect the checksum, the length in the IP pseudoheader does. That length is based on skb->len, and without trimming, it doesn't match the length the sender used when computing the checksum. In ovs_ct_execute(), trim the skb to…

[ Upstream commit e7aadb2 ] Newly added igmpv3_get_srcaddr() needs to be called under rcu lock. Timer callbacks do not ensure this locking. ============================= WARNING: suspicious RCU usage 4.15.0+ torvalds#200 Not tainted ----------------------------- ./include/linux/inetdevice.h:216 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by syzkaller616973/4074: #0: (&mm->mmap_sem){++++}, at: [<00000000bfce669e>] __do_page_fault+0x32d/0xc90 arch/x86/mm/fault.c:1355 #1: ((&im->timer)){+.-.}, at: [<00000000619d2f71>] lockdep_copy_map include/linux/lockdep.h:178 [inline] #1: ((&im->timer)){+.-.}, at: [<00000000619d2f71>] call_timer_fn+0x1c6/0x820 kernel/time/timer.c:1316 #2: (&(&im->lock)->rlock){+.-.}, at: [<000000005f833c5c>] spin_lock_bh include/linux/spinlock.h:315 [inline] #2: (&(&im->lock)->rlock){+.-.}, at: [<000000005f833c5c>] igmpv3_send_report+0x98/0x5b0 net/ipv4/igmp.c:600 stack backtrace: CPU: 0 PID: 4074 Comm: syzkaller616973 Not tainted 4.15.0+ torvalds#200 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:53 lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4592 __in_dev_get_rcu include/linux/inetdevice.h:216 [inline] igmpv3_get_srcaddr net/ipv4/igmp.c:329 [inline] igmpv3_newpack+0xeef/0x12e0 net/ipv4/igmp.c:389 add_grhead.isra.27+0x235/0x300 net/ipv4/igmp.c:432 add_grec+0xbd3/0x1170 net/ipv4/igmp.c:565 igmpv3_send_report+0xd5/0x5b0 net/ipv4/igmp.c:605 igmp_send_report+0xc43/0x1050 net/ipv4/igmp.c:722 igmp_timer_expire+0x322/0x5c0 net/ipv4/igmp.c:831 call_timer_fn+0x228/0x820 kernel/time/timer.c:1326 expire_timers kernel/time/timer.c:1363 [inline] __run_timers+0x7ee/0xb70 kernel/time/timer.c:1666 run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692 __do_softirq+0x2d7/0xb85 kernel/softirq.c:285 invoke_softirq kernel/softirq.c:365 [inline] irq_exit+0x1cc/0x200 kernel/softirq.c:405 exiting_irq arch/x86/include/asm/apic.h:541 [inline] smp_apic_timer_interrupt+0x16b/0x700 arch/x86/kernel/apic/apic.c:1052 apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:938 Fixes: a46182b ("net: igmp: Use correct source address on IGMPv3 reports") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: syzbot <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit e7aadb2 ] Newly added igmpv3_get_srcaddr() needs to be called under rcu lock. Timer callbacks do not ensure this locking. ============================= WARNING: suspicious RCU usage 4.15.0+ torvalds#200 Not tainted ----------------------------- ./include/linux/inetdevice.h:216 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by syzkaller616973/4074: #0: (&mm->mmap_sem){++++}, at: [<00000000bfce669e>] __do_page_fault+0x32d/0xc90 arch/x86/mm/fault.c:1355 #1: ((&im->timer)){+.-.}, at: [<00000000619d2f71>] lockdep_copy_map include/linux/lockdep.h:178 [inline] #1: ((&im->timer)){+.-.}, at: [<00000000619d2f71>] call_timer_fn+0x1c6/0x820 kernel/time/timer.c:1316 #2: (&(&im->lock)->rlock){+.-.}, at: [<000000005f833c5c>] spin_lock_bh include/linux/spinlock.h:315 [inline] #2: (&(&im->lock)->rlock){+.-.}, at: [<000000005f833c5c>] igmpv3_send_report+0x98/0x5b0 net/ipv4/igmp.c:600 stack backtrace: CPU: 0 PID: 4074 Comm: syzkaller616973 Not tainted 4.15.0+ torvalds#200 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:53 lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4592 __in_dev_get_rcu include/linux/inetdevice.h:216 [inline] igmpv3_get_srcaddr net/ipv4/igmp.c:329 [inline] igmpv3_newpack+0xeef/0x12e0 net/ipv4/igmp.c:389 add_grhead.isra.27+0x235/0x300 net/ipv4/igmp.c:432 add_grec+0xbd3/0x1170 net/ipv4/igmp.c:565 igmpv3_send_report+0xd5/0x5b0 net/ipv4/igmp.c:605 igmp_send_report+0xc43/0x1050 net/ipv4/igmp.c:722 igmp_timer_expire+0x322/0x5c0 net/ipv4/igmp.c:831 call_timer_fn+0x228/0x820 kernel/time/timer.c:1326 expire_timers kernel/time/timer.c:1363 [inline] __run_timers+0x7ee/0xb70 kernel/time/timer.c:1666 run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692 __do_softirq+0x2d7/0xb85 kernel/softirq.c:285 invoke_softirq kernel/softirq.c:365 [inline] irq_exit+0x1cc/0x200 kernel/softirq.c:405 exiting_irq arch/x86/include/asm/apic.h:541 [inline] smp_apic_timer_interrupt+0x16b/0x700 arch/x86/kernel/apic/apic.c:1052 apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:938 Fixes: a46182b ("net: igmp: Use correct source address on IGMPv3 reports") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: syzbot <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

commit e7aadb2 upstream. Newly added igmpv3_get_srcaddr() needs to be called under rcu lock. Timer callbacks do not ensure this locking. ============================= WARNING: suspicious RCU usage 4.15.0+ torvalds#200 Not tainted ----------------------------- ./include/linux/inetdevice.h:216 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by syzkaller616973/4074: #0: (&mm->mmap_sem){++++}, at: [<00000000bfce669e>] __do_page_fault+0x32d/0xc90 arch/x86/mm/fault.c:1355 #1: ((&im->timer)){+.-.}, at: [<00000000619d2f71>] lockdep_copy_map include/linux/lockdep.h:178 [inline] #1: ((&im->timer)){+.-.}, at: [<00000000619d2f71>] call_timer_fn+0x1c6/0x820 kernel/time/timer.c:1316 #2: (&(&im->lock)->rlock){+.-.}, at: [<000000005f833c5c>] spin_lock_bh include/linux/spinlock.h:315 [inline] #2: (&(&im->lock)->rlock){+.-.}, at: [<000000005f833c5c>] igmpv3_send_report+0x98/0x5b0 net/ipv4/igmp.c:600 stack backtrace: CPU: 0 PID: 4074 Comm: syzkaller616973 Not tainted 4.15.0+ torvalds#200 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:53 lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4592 __in_dev_get_rcu include/linux/inetdevice.h:216 [inline] igmpv3_get_srcaddr net/ipv4/igmp.c:329 [inline] igmpv3_newpack+0xeef/0x12e0 net/ipv4/igmp.c:389 add_grhead.isra.27+0x235/0x300 net/ipv4/igmp.c:432 add_grec+0xbd3/0x1170 net/ipv4/igmp.c:565 igmpv3_send_report+0xd5/0x5b0 net/ipv4/igmp.c:605 igmp_send_report+0xc43/0x1050 net/ipv4/igmp.c:722 igmp_timer_expire+0x322/0x5c0 net/ipv4/igmp.c:831 call_timer_fn+0x228/0x820 kernel/time/timer.c:1326 expire_timers kernel/time/timer.c:1363 [inline] __run_timers+0x7ee/0xb70 kernel/time/timer.c:1666 run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692 __do_softirq+0x2d7/0xb85 kernel/softirq.c:285 invoke_softirq kernel/softirq.c:365 [inline] irq_exit+0x1cc/0x200 kernel/softirq.c:405 exiting_irq arch/x86/include/asm/apic.h:541 [inline] smp_apic_timer_interrupt+0x16b/0x700 arch/x86/kernel/apic/apic.c:1052 apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:938 Fixes: a46182b ("net: igmp: Use correct source address on IGMPv3 reports") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: syzbot <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Ben Hutchings <[email protected]>

[ Upstream commit e7aadb2 ] Newly added igmpv3_get_srcaddr() needs to be called under rcu lock. Timer callbacks do not ensure this locking. ============================= WARNING: suspicious RCU usage 4.15.0+ torvalds#200 Not tainted ----------------------------- ./include/linux/inetdevice.h:216 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by syzkaller616973/4074: #0: (&mm->mmap_sem){++++}, at: [<00000000bfce669e>] __do_page_fault+0x32d/0xc90 arch/x86/mm/fault.c:1355 MIPS#1: ((&im->timer)){+.-.}, at: [<00000000619d2f71>] lockdep_copy_map include/linux/lockdep.h:178 [inline] MIPS#1: ((&im->timer)){+.-.}, at: [<00000000619d2f71>] call_timer_fn+0x1c6/0x820 kernel/time/timer.c:1316 MIPS#2: (&(&im->lock)->rlock){+.-.}, at: [<000000005f833c5c>] spin_lock_bh include/linux/spinlock.h:315 [inline] MIPS#2: (&(&im->lock)->rlock){+.-.}, at: [<000000005f833c5c>] igmpv3_send_report+0x98/0x5b0 net/ipv4/igmp.c:600 stack backtrace: CPU: 0 PID: 4074 Comm: syzkaller616973 Not tainted 4.15.0+ torvalds#200 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:53 lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4592 __in_dev_get_rcu include/linux/inetdevice.h:216 [inline] igmpv3_get_srcaddr net/ipv4/igmp.c:329 [inline] igmpv3_newpack+0xeef/0x12e0 net/ipv4/igmp.c:389 add_grhead.isra.27+0x235/0x300 net/ipv4/igmp.c:432 add_grec+0xbd3/0x1170 net/ipv4/igmp.c:565 igmpv3_send_report+0xd5/0x5b0 net/ipv4/igmp.c:605 igmp_send_report+0xc43/0x1050 net/ipv4/igmp.c:722 igmp_timer_expire+0x322/0x5c0 net/ipv4/igmp.c:831 call_timer_fn+0x228/0x820 kernel/time/timer.c:1326 expire_timers kernel/time/timer.c:1363 [inline] __run_timers+0x7ee/0xb70 kernel/time/timer.c:1666 run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692 __do_softirq+0x2d7/0xb85 kernel/softirq.c:285 invoke_softirq kernel/softirq.c:365 [inline] irq_exit+0x1cc/0x200 kernel/softirq.c:405 exiting_irq arch/x86/include/asm/apic.h:541 [inline] smp_apic_timer_interrupt+0x16b/0x700 arch/x86/kernel/apic/apic.c:1052 apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:938 Fixes: a46182b ("net: igmp: Use correct source address on IGMPv3 reports") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: syzbot <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e7aadb2 upstream. Newly added igmpv3_get_srcaddr() needs to be called under rcu lock. Timer callbacks do not ensure this locking. ============================= WARNING: suspicious RCU usage 4.15.0+ torvalds#200 Not tainted ----------------------------- ./include/linux/inetdevice.h:216 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by syzkaller616973/4074: #0: (&mm->mmap_sem){++++}, at: [<00000000bfce669e>] __do_page_fault+0x32d/0xc90 arch/x86/mm/fault.c:1355 #1: ((&im->timer)){+.-.}, at: [<00000000619d2f71>] lockdep_copy_map include/linux/lockdep.h:178 [inline] #1: ((&im->timer)){+.-.}, at: [<00000000619d2f71>] call_timer_fn+0x1c6/0x820 kernel/time/timer.c:1316 #2: (&(&im->lock)->rlock){+.-.}, at: [<000000005f833c5c>] spin_lock_bh include/linux/spinlock.h:315 [inline] #2: (&(&im->lock)->rlock){+.-.}, at: [<000000005f833c5c>] igmpv3_send_report+0x98/0x5b0 net/ipv4/igmp.c:600 stack backtrace: CPU: 0 PID: 4074 Comm: syzkaller616973 Not tainted 4.15.0+ torvalds#200 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:53 lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4592 __in_dev_get_rcu include/linux/inetdevice.h:216 [inline] igmpv3_get_srcaddr net/ipv4/igmp.c:329 [inline] igmpv3_newpack+0xeef/0x12e0 net/ipv4/igmp.c:389 add_grhead.isra.27+0x235/0x300 net/ipv4/igmp.c:432 add_grec+0xbd3/0x1170 net/ipv4/igmp.c:565 igmpv3_send_report+0xd5/0x5b0 net/ipv4/igmp.c:605 igmp_send_report+0xc43/0x1050 net/ipv4/igmp.c:722 igmp_timer_expire+0x322/0x5c0 net/ipv4/igmp.c:831 call_timer_fn+0x228/0x820 kernel/time/timer.c:1326 expire_timers kernel/time/timer.c:1363 [inline] __run_timers+0x7ee/0xb70 kernel/time/timer.c:1666 run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692 __do_softirq+0x2d7/0xb85 kernel/softirq.c:285 invoke_softirq kernel/softirq.c:365 [inline] irq_exit+0x1cc/0x200 kernel/softirq.c:405 exiting_irq arch/x86/include/asm/apic.h:541 [inline] smp_apic_timer_interrupt+0x16b/0x700 arch/x86/kernel/apic/apic.c:1052 apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:938 Fixes: a46182b ("net: igmp: Use correct source address on IGMPv3 reports") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: syzbot <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Ben Hutchings <[email protected]>

As described in the previous cset, all we had to do was to touch the augmented_syscalls.c eBPF program, fire up 'perf trace' with that new eBPF script in system wide mode and wait for 'open' syscalls, in addition to 'openat' ones to see that it works: # perf trace -e tools/perf/examples/bpf/augmented_syscalls.c 0.000 StreamT~s torvalds#200/16150 openat(dfd: CWD, filename: /home/acme/.mozilla/firefox/fqxhj76d.default/prefs.js, flags: CREAT|EXCL|TRUNC|WRONLY, mode: IRUSR|IWUSR) 0.065 StreamT~s torvalds#200/16150 openat(dfd: CWD, filename: /home/acme/.mozilla/firefox/fqxhj76d.default/prefs-1.js, flags: CREAT|EXCL|TRUNC|WRONLY, mode: IRUSR|IWUSR) 0.435 StreamT~s torvalds#200/16150 openat(dfd: CWD, filename: /home/acme/.mozilla/firefox/fqxhj76d.default/prefs-1.js, flags: CREAT|TRUNC|WRONLY, mode: IRUSR|IWUSR) 1.875 perf/16772 openat(dfd: CWD, filename: /sys/kernel/debug/tracing/events/syscalls/sys_enter_openat/form) 1227.260 gnome-shell/1463 openat(dfd: CWD, filename: /proc/self/stat) 1227.397 gnome-shell/2125 openat(dfd: CWD, filename: /proc/self/stat) 7227.619 gnome-shell/1463 openat(dfd: CWD, filename: /proc/self/stat) 7227.661 gnome-shell/2125 openat(dfd: CWD, filename: /proc/self/stat) 10018.079 gnome-shell/1463 openat(dfd: CWD, filename: /proc/self/stat) 10018.514 perf/16772 openat(dfd: CWD, filename: /proc/1237/status) 10018.568 perf/16772 openat(dfd: CWD, filename: /proc/1237/status) 10022.409 gnome-shell/2125 openat(dfd: CWD, filename: /proc/self/stat) 10090.044 NetworkManager/1237 openat(dfd: CWD, filename: /proc/2125/stat) 10090.351 NetworkManager/1237 open(filename: /etc/passwd, flags: CLOEXEC) 10090.407 perf/16772 openat(dfd: CWD, filename: /sys/kernel/debug/tracing/events/syscalls/sys_enter_open/format) 10091.763 NetworkManager/1237 openat(dfd: CWD, filename: /proc/2125/stat) 10091.812 NetworkManager/1237 open(filename: /etc/passwd, flags: CLOEXEC) 10092.807 NetworkManager/1237 openat(dfd: CWD, filename: /proc/2125/stat) 10092.851 NetworkManager/1237 open(filename: /etc/passwd, flags: CLOEXEC) 10094.650 NetworkManager/1237 openat(dfd: CWD, filename: /proc/1463/stat) 10094.926 NetworkManager/1237 open(filename: /etc/passwd, flags: CLOEXEC) 10096.010 NetworkManager/1237 openat(dfd: CWD, filename: /proc/1463/stat) 10096.057 NetworkManager/1237 open(filename: /etc/passwd, flags: CLOEXEC) 10097.056 NetworkManager/1237 openat(dfd: CWD, filename: /proc/1463/stat) 10097.099 NetworkManager/1237 open(filename: /etc/passwd, flags: CLOEXEC) 13228.345 gnome-shell/1463 openat(dfd: CWD, filename: /proc/self/stat) 13232.734 gnome-shell/2125 openat(dfd: CWD, filename: /proc/self/stat) 15198.956 lighttpd/16748 open(filename: /proc/loadavg, mode: ISGID|IXOTH) ^C# It even catches 'perf' itself looking at the sys_enter_open and sys_enter_openat tracefs format dictionaries when it first finds them in the trace... :-) Cc: Adrian Hunter <[email protected]> Cc: David Ahern <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Wang Nan <[email protected]> Link: https://lkml.kernel.org/n/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>

Update 5.4.x+fslc to v5.4.85

…from plsdk-2787 to processor-sdk-linux-4.19.y * commit '04f983a885eb2c0416dca12aee6a7e91aef57251': net: prueth: Introduce prueth switchdev driver net: prueth: Add TI PRUSS Ethernet driver support of switch firmware

This commit fixes the following checkpatch.pl warnings: WARNING: do not add new typedefs torvalds#47: FILE: hal/HalBtcOutSrc.h:47: +typedef enum _BTC_POWERSAVE_TYPE { WARNING: do not add new typedefs torvalds#54: FILE: hal/HalBtcOutSrc.h:54: +typedef enum _BTC_BT_REG_TYPE { WARNING: do not add new typedefs torvalds#63: FILE: hal/HalBtcOutSrc.h:63: +typedef enum _BTC_CHIP_INTERFACE { WARNING: do not add new typedefs torvalds#71: FILE: hal/HalBtcOutSrc.h:71: +typedef enum _BTC_CHIP_TYPE { WARNING: do not add new typedefs torvalds#81: FILE: hal/HalBtcOutSrc.h:81: +typedef enum _BTC_MSG_TYPE { WARNING: do not add new typedefs torvalds#167: FILE: hal/HalBtcOutSrc.h:167: +typedef struct _BTC_BOARD_INFO { WARNING: do not add new typedefs torvalds#177: FILE: hal/HalBtcOutSrc.h:177: +typedef enum _BTC_DBG_OPCODE { WARNING: do not add new typedefs torvalds#187: FILE: hal/HalBtcOutSrc.h:187: +typedef enum _BTC_RSSI_STATE { WARNING: do not add new typedefs torvalds#200: FILE: hal/HalBtcOutSrc.h:200: +typedef enum _BTC_WIFI_ROLE { WARNING: do not add new typedefs torvalds#208: FILE: hal/HalBtcOutSrc.h:208: +typedef enum _BTC_WIFI_BW_MODE { WARNING: do not add new typedefs torvalds#215: FILE: hal/HalBtcOutSrc.h:215: +typedef enum _BTC_WIFI_TRAFFIC_DIR { WARNING: do not add new typedefs torvalds#221: FILE: hal/HalBtcOutSrc.h:221: +typedef enum _BTC_WIFI_PNP { WARNING: do not add new typedefs torvalds#228: FILE: hal/HalBtcOutSrc.h:228: +typedef enum _BT_WIFI_COEX_STATE { WARNING: do not add new typedefs torvalds#239: FILE: hal/HalBtcOutSrc.h:239: +typedef enum _BTC_GET_TYPE { WARNING: do not add new typedefs torvalds#281: FILE: hal/HalBtcOutSrc.h:281: +typedef enum _BTC_SET_TYPE { WARNING: do not add new typedefs torvalds#321: FILE: hal/HalBtcOutSrc.h:321: +typedef enum _BTC_DBG_DISP_TYPE { WARNING: do not add new typedefs torvalds#328: FILE: hal/HalBtcOutSrc.h:328: +typedef enum _BTC_NOTIFY_TYPE_IPS { WARNING: do not add new typedefs torvalds#334: FILE: hal/HalBtcOutSrc.h:334: +typedef enum _BTC_NOTIFY_TYPE_LPS { WARNING: do not add new typedefs torvalds#340: FILE: hal/HalBtcOutSrc.h:340: +typedef enum _BTC_NOTIFY_TYPE_SCAN { WARNING: do not add new typedefs torvalds#346: FILE: hal/HalBtcOutSrc.h:346: +typedef enum _BTC_NOTIFY_TYPE_ASSOCIATE { WARNING: do not add new typedefs torvalds#352: FILE: hal/HalBtcOutSrc.h:352: +typedef enum _BTC_NOTIFY_TYPE_MEDIA_STATUS { WARNING: do not add new typedefs torvalds#358: FILE: hal/HalBtcOutSrc.h:358: +typedef enum _BTC_NOTIFY_TYPE_SPECIAL_PACKET { WARNING: do not add new typedefs torvalds#366: FILE: hal/HalBtcOutSrc.h:366: +typedef enum _BTC_NOTIFY_TYPE_STACK_OPERATION { WARNING: do not add new typedefs torvalds#374: FILE: hal/HalBtcOutSrc.h:374: +typedef enum _BTC_ANTENNA_POS { WARNING: do not add new typedefs torvalds#412: FILE: hal/HalBtcOutSrc.h:412: +typedef struct _BTC_BT_INFO { WARNING: do not add new typedefs torvalds#440: FILE: hal/HalBtcOutSrc.h:440: +typedef struct _BTC_STACK_INFO { WARNING: do not add new typedefs torvalds#455: FILE: hal/HalBtcOutSrc.h:455: +typedef struct _BTC_BT_LINK_INFO { WARNING: do not add new typedefs torvalds#468: FILE: hal/HalBtcOutSrc.h:468: +typedef struct _BTC_STATISTICS { WARNING: do not add new typedefs torvalds#487: FILE: hal/HalBtcOutSrc.h:487: +typedef struct _BTC_COEXIST { Signed-off-by: Marco Cesati <[email protected]>

This commit fixes the following checkpatch.pl warnings: WARNING: do not add new typedefs torvalds#47: FILE: hal/HalBtcOutSrc.h:47: +typedef enum _BTC_POWERSAVE_TYPE { WARNING: do not add new typedefs torvalds#54: FILE: hal/HalBtcOutSrc.h:54: +typedef enum _BTC_BT_REG_TYPE { WARNING: do not add new typedefs torvalds#63: FILE: hal/HalBtcOutSrc.h:63: +typedef enum _BTC_CHIP_INTERFACE { WARNING: do not add new typedefs torvalds#71: FILE: hal/HalBtcOutSrc.h:71: +typedef enum _BTC_CHIP_TYPE { WARNING: do not add new typedefs torvalds#81: FILE: hal/HalBtcOutSrc.h:81: +typedef enum _BTC_MSG_TYPE { WARNING: do not add new typedefs torvalds#167: FILE: hal/HalBtcOutSrc.h:167: +typedef struct _BTC_BOARD_INFO { WARNING: do not add new typedefs torvalds#177: FILE: hal/HalBtcOutSrc.h:177: +typedef enum _BTC_DBG_OPCODE { WARNING: do not add new typedefs torvalds#187: FILE: hal/HalBtcOutSrc.h:187: +typedef enum _BTC_RSSI_STATE { WARNING: do not add new typedefs torvalds#200: FILE: hal/HalBtcOutSrc.h:200: +typedef enum _BTC_WIFI_ROLE { WARNING: do not add new typedefs torvalds#208: FILE: hal/HalBtcOutSrc.h:208: +typedef enum _BTC_WIFI_BW_MODE { WARNING: do not add new typedefs torvalds#215: FILE: hal/HalBtcOutSrc.h:215: +typedef enum _BTC_WIFI_TRAFFIC_DIR { WARNING: do not add new typedefs torvalds#221: FILE: hal/HalBtcOutSrc.h:221: +typedef enum _BTC_WIFI_PNP { WARNING: do not add new typedefs torvalds#228: FILE: hal/HalBtcOutSrc.h:228: +typedef enum _BT_WIFI_COEX_STATE { WARNING: do not add new typedefs torvalds#239: FILE: hal/HalBtcOutSrc.h:239: +typedef enum _BTC_GET_TYPE { WARNING: do not add new typedefs torvalds#281: FILE: hal/HalBtcOutSrc.h:281: +typedef enum _BTC_SET_TYPE { WARNING: do not add new typedefs torvalds#321: FILE: hal/HalBtcOutSrc.h:321: +typedef enum _BTC_DBG_DISP_TYPE { WARNING: do not add new typedefs torvalds#328: FILE: hal/HalBtcOutSrc.h:328: +typedef enum _BTC_NOTIFY_TYPE_IPS { WARNING: do not add new typedefs torvalds#334: FILE: hal/HalBtcOutSrc.h:334: +typedef enum _BTC_NOTIFY_TYPE_LPS { WARNING: do not add new typedefs torvalds#340: FILE: hal/HalBtcOutSrc.h:340: +typedef enum _BTC_NOTIFY_TYPE_SCAN { WARNING: do not add new typedefs torvalds#346: FILE: hal/HalBtcOutSrc.h:346: +typedef enum _BTC_NOTIFY_TYPE_ASSOCIATE { WARNING: do not add new typedefs torvalds#352: FILE: hal/HalBtcOutSrc.h:352: +typedef enum _BTC_NOTIFY_TYPE_MEDIA_STATUS { WARNING: do not add new typedefs torvalds#358: FILE: hal/HalBtcOutSrc.h:358: +typedef enum _BTC_NOTIFY_TYPE_SPECIAL_PACKET { WARNING: do not add new typedefs torvalds#366: FILE: hal/HalBtcOutSrc.h:366: +typedef enum _BTC_NOTIFY_TYPE_STACK_OPERATION { WARNING: do not add new typedefs torvalds#374: FILE: hal/HalBtcOutSrc.h:374: +typedef enum _BTC_ANTENNA_POS { WARNING: do not add new typedefs torvalds#412: FILE: hal/HalBtcOutSrc.h:412: +typedef struct _BTC_BT_INFO { WARNING: do not add new typedefs torvalds#440: FILE: hal/HalBtcOutSrc.h:440: +typedef struct _BTC_STACK_INFO { WARNING: do not add new typedefs torvalds#455: FILE: hal/HalBtcOutSrc.h:455: +typedef struct _BTC_BT_LINK_INFO { WARNING: do not add new typedefs torvalds#468: FILE: hal/HalBtcOutSrc.h:468: +typedef struct _BTC_STATISTICS { WARNING: do not add new typedefs torvalds#487: FILE: hal/HalBtcOutSrc.h:487: +typedef struct _BTC_COEXIST { Signed-off-by: Marco Cesati <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>

The code added by commit 8979b02 ("tpm: Fix reference count to main device") tries to take an extra reference to the main device only for TPM2 by looking at the flags, but the flags are actually not set at the time when tpm_chip_alloc() is called, so no extra reference is ever taken, leading to a use-after-free if the TPM modules are removed when the tpmrm device is in use. ================================================================== BUG: KASAN: use-after-free in __mutex_lock+0xe0/0xbd0 Read of size 8 at addr ffff888116c6acc0 by task sh/1210 CPU: 0 PID: 1210 Comm: sh Not tainted 5.13.0-rc5+ torvalds#200 Call Trace: __mutex_lock+0xe0/0xbd0 tpm2_del_space+0x24/0xa0 [tpm] tpmrm_release+0x3f/0x50 [tpm] __fput+0x110/0x3c0 task_work_run+0x94/0xd0 do_exit+0x683/0x13e0 do_syscall_64+0x3c/0x80 Allocated by task 1153: kasan_save_stack+0x19/0x40 __kasan_kmalloc+0x7f/0xa0 tpm_chip_alloc+0x3b/0x360 [tpm] tpmm_chip_alloc+0x11/0x70 [tpm] tpm_tis_core_init+0xce/0x570 [tpm_tis_core] pnp_device_probe+0x9c/0x100 ... Freed by task 1243: kfree+0x121/0x340 device_release+0x59/0xf0 kobject_put+0xa5/0x120 release_nodes+0x37f/0x3f0 driver_detach+0x7c/0xf0 bus_remove_driver+0x86/0x110 __x64_sys_delete_module+0x27b/0x320 ... ================================================================== The real fix to the problem which that commit tried to solve is to make tpmm_chip_alloc() put the ->devs device in the devm release function, since that is never done anywhere currently. This is safe since device_initialize() is always called on ->devs. No conditional reference taking is needed. Fixes: 8979b02 ("tpm: Fix reference count to main device") Signed-off-by: Vincent Whitchurch <[email protected]>

As described in the previous cset, all we had to do was to touch the augmented_syscalls.c eBPF program, fire up 'perf trace' with that new eBPF script in system wide mode and wait for 'open' syscalls, in addition to 'openat' ones to see that it works: # perf trace -e tools/perf/examples/bpf/augmented_syscalls.c 0.000 StreamT~s torvalds#200/16150 openat(dfd: CWD, filename: /home/acme/.mozilla/firefox/fqxhj76d.default/prefs.js, flags: CREAT|EXCL|TRUNC|WRONLY, mode: IRUSR|IWUSR) 0.065 StreamT~s torvalds#200/16150 openat(dfd: CWD, filename: /home/acme/.mozilla/firefox/fqxhj76d.default/prefs-1.js, flags: CREAT|EXCL|TRUNC|WRONLY, mode: IRUSR|IWUSR) 0.435 StreamT~s torvalds#200/16150 openat(dfd: CWD, filename: /home/acme/.mozilla/firefox/fqxhj76d.default/prefs-1.js, flags: CREAT|TRUNC|WRONLY, mode: IRUSR|IWUSR) 1.875 perf/16772 openat(dfd: CWD, filename: /sys/kernel/debug/tracing/events/syscalls/sys_enter_openat/form) 1227.260 gnome-shell/1463 openat(dfd: CWD, filename: /proc/self/stat) 1227.397 gnome-shell/2125 openat(dfd: CWD, filename: /proc/self/stat) 7227.619 gnome-shell/1463 openat(dfd: CWD, filename: /proc/self/stat) 7227.661 gnome-shell/2125 openat(dfd: CWD, filename: /proc/self/stat) 10018.079 gnome-shell/1463 openat(dfd: CWD, filename: /proc/self/stat) 10018.514 perf/16772 openat(dfd: CWD, filename: /proc/1237/status) 10018.568 perf/16772 openat(dfd: CWD, filename: /proc/1237/status) 10022.409 gnome-shell/2125 openat(dfd: CWD, filename: /proc/self/stat) 10090.044 NetworkManager/1237 openat(dfd: CWD, filename: /proc/2125/stat) 10090.351 NetworkManager/1237 open(filename: /etc/passwd, flags: CLOEXEC) 10090.407 perf/16772 openat(dfd: CWD, filename: /sys/kernel/debug/tracing/events/syscalls/sys_enter_open/format) 10091.763 NetworkManager/1237 openat(dfd: CWD, filename: /proc/2125/stat) 10091.812 NetworkManager/1237 open(filename: /etc/passwd, flags: CLOEXEC) 10092.807 NetworkManager/1237 openat(dfd: CWD, filename: /proc/2125/stat) 10092.851 NetworkManager/1237 open(filename: /etc/passwd, flags: CLOEXEC) 10094.650 NetworkManager/1237 openat(dfd: CWD, filename: /proc/1463/stat) 10094.926 NetworkManager/1237 open(filename: /etc/passwd, flags: CLOEXEC) 10096.010 NetworkManager/1237 openat(dfd: CWD, filename: /proc/1463/stat) 10096.057 NetworkManager/1237 open(filename: /etc/passwd, flags: CLOEXEC) 10097.056 NetworkManager/1237 openat(dfd: CWD, filename: /proc/1463/stat) 10097.099 NetworkManager/1237 open(filename: /etc/passwd, flags: CLOEXEC) 13228.345 gnome-shell/1463 openat(dfd: CWD, filename: /proc/self/stat) 13232.734 gnome-shell/2125 openat(dfd: CWD, filename: /proc/self/stat) 15198.956 lighttpd/16748 open(filename: /proc/loadavg, mode: ISGID|IXOTH) ^C# It even catches 'perf' itself looking at the sys_enter_open and sys_enter_openat tracefs format dictionaries when it first finds them in the trace... :-) Cc: Adrian Hunter <[email protected]> Cc: David Ahern <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Wang Nan <[email protected]> Link: https://lkml.kernel.org/n/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>

PD#150471: hdmitx: driver defect clean up: torvalds#168 torvalds#186 torvalds#200 torvalds#211 torvalds#192 Change-Id: Iffafec12c39cd98f8260a99417cb709ccc94935d Signed-off-by: Yi Zhou <[email protected]>

commit 9242b5f upstream ANBZ: torvalds#200 Introduce REG_LIVE_DONE to check the liveness propagation and prepare the states for merging. See algorithm description in clean_live_states(). Signed-off-by: Alexei Starovoitov <[email protected]> Acked-by: Jakub Kicinski <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Signed-off-by: Qiao Ma <[email protected]> Acked-by: Tony Lu <[email protected]>

commit 06ee711 upstream ANBZ: torvalds#200 In order to understand the verifier bottlenecks add various stats and extend log_level: log_level 1 and 2 are kept as-is: bit 0 - level=1 - print every insn and verifier state at branch points bit 1 - level=2 - print every insn and verifier state at every insn bit 2 - level=4 - print verifier error and stats at the end of verification When verifier rejects the program the libbpf is trying to load the program twice. Once with log_level=0 (no messages, only error code is reported to user space) and second time with log_level=1 to tell the user why the verifier rejected it. With introduction of bit 2 - level=4 the libbpf can choose to always use that level and load programs once, since the verification speed is not affected and in case of error the verbose message will be available. Note that the verifier stats are not part of uapi just like all other verbose messages. They're expected to change in the future. Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Signed-off-by: Qiao Ma <[email protected]> Acked-by: Tony Lu <[email protected]>

commit 9f4686c upstream ANBZ: torvalds#200 Branch instructions, branch targets and calls in a bpf program are the places where the verifier remembers states that led to successful verification of the program. These states are used to prune brute force program analysis. For unprivileged programs there is a limit of 64 states per such 'branching' instructions (maximum length is tracked by max_states_per_insn counter introduced in the previous patch). Simply reducing this threshold to 32 or lower increases insn_processed metric to the point that small valid programs get rejected. For root programs there is no limit and cilium programs can have max_states_per_insn to be 100 or higher. Walking 100+ states multiplied by number of 'branching' insns during verification consumes significant amount of cpu time. Turned out simple LRU-like mechanism can be used to remove states that unlikely will be helpful in future search pruning. This patch introduces hit_cnt and miss_cnt counters: hit_cnt - this many times this state successfully pruned the search miss_cnt - this many times this state was not equivalent to other states (and that other states were added to state list) The heuristic introduced in this patch is: if (sl->miss_cnt > sl->hit_cnt * 3 + 3) /* drop this state from future considerations */ Higher numbers increase max_states_per_insn (allow more states to be considered for pruning) and slow verification speed, but do not meaningfully reduce insn_processed metric. Lower numbers drop too many states and insn_processed increases too much. Many different formulas were considered. This one is simple and works well enough in practice. (the analysis was done on selftests/progs/* and on cilium programs) The end result is this heuristic improves verification speed by 10 times. Large synthetic programs that used to take a second more now take 1/10 of a second. In cases where max_states_per_insn used to be 100 or more, now it's ~10. There is a slight increase in insn_processed for cilium progs: before after bpf_lb-DLB_L3.o 1831 1838 bpf_lb-DLB_L4.o 3029 3218 bpf_lb-DUNKNOWN.o 1064 1064 bpf_lxc-DDROP_ALL.o 26309 26935 bpf_lxc-DUNKNOWN.o 33517 34439 bpf_netdev.o 9713 9721 bpf_overlay.o 6184 6184 bpf_lcx_jit.o 37335 39389 And 2-3 times improvement in the verification speed. Signed-off-by: Alexei Starovoitov <[email protected]> Reviewed-by: Jakub Kicinski <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Signed-off-by: Qiao Ma <[email protected]> Acked-by: Tony Lu <[email protected]>

commit 5d83902 upstream ANBZ: torvalds#200 clean up explored_states to prep for introduction of hashtable No functional changes. Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Signed-off-by: Qiao Ma <[email protected]> Acked-by: Tony Lu <[email protected]>

commit a8f500a upstream ANBZ: torvalds#200 split explored_states into prune_point boolean mark and link list of explored states. This removes STATE_LIST_MARK hack and allows marks to be separate from states. Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Signed-off-by: Qiao Ma <[email protected]> Acked-by: Tony Lu <[email protected]>

commit dc2a4eb upstream ANBZ: torvalds#200 All prune points inside a callee bpf function most likely will have different callsites. For example, if function foo() is called from two callsites the half of explored states in all prune points in foo() will be useless for subsequent walking of one of those callsites. Fortunately explored_states pruning heuristics keeps the number of states per prune point small, but walking these states is still a waste of cpu time when the callsite of the current state is different from the callsite of the explored state. To improve pruning logic convert explored_states into hash table and use simple insn_idx ^ callsite hash to select hash bucket. This optimization has no effect on programs without bpf2bpf calls and drastically improves programs with calls. In the later case it reduces total memory consumption in 1M scale tests by almost 3 times (peak_states drops from 5752 to 2016). Care should be taken when comparing the states for equivalency. Since the same hash bucket can now contain states with different indices the insn_idx has to be part of verifier_state and compared. Different hash table sizes and different hash functions were explored, but the results were not significantly better vs this patch. They can be improved in the future. Hit/miss heuristic is not counting index miscompare as a miss. Otherwise verifier stats become unstable when experimenting with different hash functions. Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Signed-off-by: Qiao Ma <[email protected]> Acked-by: Tony Lu <[email protected]>

commit 2589726 upstream ANBZ: torvalds#200 [BackportNotes] - remove a verbose_linfo() statement since not implemented yet. - replace a "return 0;" statement to a "return push_jmp_history(env, cur);" in is_state_visited() because a follow-up patch has been backported before: > (commit b5dc016("bpf: precise scalar_value tracking")) Allow the verifier to validate the loops by simulating their execution. Exisiting programs have used '#pragma unroll' to unroll the loops by the compiler. Instead let the verifier simulate all iterations of the loop. In order to do that introduce parentage chain of bpf_verifier_state and 'branches' counter for the number of branches left to explore. See more detailed algorithm description in bpf_verifier.h This algorithm borrows the key idea from Edward Cree approach: https://patchwork.ozlabs.org/patch/877222/ Additional state pruning heuristics make such brute force loop walk practical even for large loops. Signed-off-by: Alexei Starovoitov <[email protected]> Acked-by: Andrii Nakryiko <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Signed-off-by: Qiao Ma <[email protected]> Acked-by: Tony Lu <[email protected]>

commit 7640ead upstream ANBZ: torvalds#200 Currently for liveness and state pruning the register parentage chains don't include states of the callee. This makes some sense as the callee can't access those registers. However, this means that READs done after the callee returns will not propagate into the states of the callee. Callee will then perform pruning disregarding differences in caller state. Example: 0: (85) call bpf_user_rnd_u32 1: (b7) r8 = 0 2: (55) if r0 != 0x0 goto pc+1 3: (b7) r8 = 1 4: (bf) r1 = r8 5: (85) call pc+4 6: (15) if r8 == 0x1 goto pc+1 7: (05) *(u64 *)(r9 - 8) = r3 8: (b7) r0 = 0 9: (95) exit 10: (15) if r1 == 0x0 goto pc+0 11: (95) exit Here we acquire unknown state with call to get_random() [1]. Then we store this random state in r8 (either 0 or 1) [1 - 3], and make a call on line 5. Callee does nothing but a trivial conditional jump (to create a pruning point). Upon return caller checks the state of r8 and either performs an unsafe read or not. Verifier will first explore the path with r8 == 1, creating a pruning point at [11]. The parentage chain for r8 will include only callers states so once verifier reaches [6] it will mark liveness only on states in the caller, and not [11]. Now when verifier walks the paths with r8 == 0 it will reach [11] and since REG_LIVE_READ on r8 was not propagated there it will prune the walk entirely (stop walking the entire program, not just the callee). Since [6] was never walked with r8 == 0, [7] will be considered dead and replaced with "goto -1" causing hang at runtime. This patch weaves the callee's explored states onto the callers parentage chain. Rough parentage for r8 would have looked like this before: [0] [1] [2] [3] [4] [5] [10] [11] [6] [7] | | ,---|----. | | | sl0: sl0: / sl0: \ sl0: sl0: sl0: fr0: r8 <-- fr0: r8<+--fr0: r8 `fr0: r8 ,fr0: r8<-fr0: r8 \ fr1: r8 <- fr1: r8 / \__________________/ after: [0] [1] [2] [3] [4] [5] [10] [11] [6] [7] | | | | | | sl0: sl0: sl0: sl0: sl0: sl0: fr0: r8 <-- fr0: r8 <- fr0: r8 <- fr0: r8 <-fr0: r8<-fr0: r8 fr1: r8 <- fr1: r8 Now the mark from instruction 6 will travel through callees states. Note that we don't have to connect r0 because its overwritten by callees state on return and r1 - r5 because those are not alive any more once a call is made. v2: - don't connect the callees registers twice (Alexei: suggestion & code) - add more details to the comment (Ed & Alexei) v1: don't unnecessarily link caller saved regs (Jiong) Fixes: f4d7e40 ("bpf: introduce function calls (verification)") Reported-by: David Beckett <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Jiong Wang <[email protected]> Reviewed-by: Edward Cree <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Qiao Ma <[email protected]> Acked-by: Tony Lu <[email protected]>

commit eea1c22 upstream ANBZ: torvalds#200 The commit 7640ead partially resolved the issue of callees incorrectly pruning the callers. With introduction of bounded loops and jmps_processed heuristic single verifier state may contain multiple branches and calls. It's possible that new verifier state (for future pruning) will be allocated inside callee. Then callee will exit (still within the same verifier state). It will go back to the caller and there R6-R9 registers will be read and will trigger mark_reg_read. But the reg->live for all frames but the top frame is not set to LIVE_NONE. Hence mark_reg_read will fail to propagate liveness into parent and future walking will incorrectly conclude that the states are equivalent because LIVE_READ is not set. In other words the rule for parent/live should be: whenever register parentage chain is set the reg->live should be set to LIVE_NONE. is_state_visited logic already follows this rule for spilled registers. Fixes: 7640ead ("bpf: verifier: make sure callees don't prune with caller differences") Fixes: f4d7e40 ("bpf: introduce function calls (verification)") Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Signed-off-by: Qiao Ma <[email protected]> Acked-by: Tony Lu <[email protected]>

commit 0d3679e upstream ANBZ: torvalds#200 This set of tests is a rewrite of Edward's earlier tests: https://patchwork.ozlabs.org/patch/877221/ Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Signed-off-by: Qiao Ma <[email protected]> Acked-by: Tony Lu <[email protected]>

BPF CI has reported the following failure: Error: torvalds#200/79 sockmap_listen/sockmap VSOCK test_vsock_redir Error: torvalds#200/79 sockmap_listen/sockmap VSOCK test_vsock_redir ./test_progs:vsock_unix_redir_connectible:1506: egress: write: Transport endpoint is not connected vsock_unix_redir_connectible:FAIL:1506 ./test_progs:vsock_unix_redir_connectible:1506: ingress: write: Transport endpoint is not connected vsock_unix_redir_connectible:FAIL:1506 ./test_progs:vsock_unix_redir_connectible:1506: egress: write: Transport endpoint is not connected vsock_unix_redir_connectible:FAIL:1506 ./test_progs:vsock_unix_redir_connectible:1514: ingress: recv() err, errno=11 vsock_unix_redir_connectible:FAIL:1514 ./test_progs:vsock_unix_redir_connectible:1518: ingress: vsock socket map failed, a != b vsock_unix_redir_connectible:FAIL:1518 ./test_progs:vsock_unix_redir_connectible:1525: ingress: want pass count 1, have 0 It’s because the recv(... MSG_DONTWAIT) syscall in the test case is called before the queued work sk_psock_backlog() in the kernel finishes executing. So the data to be read is still queued in psock->ingress_skb and cannot be read by the user program. Therefore, the non-blocking recv() reads nothing and reports an EAGAIN error. So replace recv(... MSG_DONTWAIT) with xrecv_nonblock(), which calls select() to wait for data to be readable or timeout before calls recv(). Fixes: d61bd8c ("selftests/bpf: add a test case for vsock sockmap") Signed-off-by: Xu Kuohai <[email protected]>

BPF CI has reported the following failure: Error: torvalds#200/79 sockmap_listen/sockmap VSOCK test_vsock_redir Error: torvalds#200/79 sockmap_listen/sockmap VSOCK test_vsock_redir ./test_progs:vsock_unix_redir_connectible:1506: egress: write: Transport endpoint is not connected vsock_unix_redir_connectible:FAIL:1506 ./test_progs:vsock_unix_redir_connectible:1506: ingress: write: Transport endpoint is not connected vsock_unix_redir_connectible:FAIL:1506 ./test_progs:vsock_unix_redir_connectible:1506: egress: write: Transport endpoint is not connected vsock_unix_redir_connectible:FAIL:1506 ./test_progs:vsock_unix_redir_connectible:1514: ingress: recv() err, errno=11 vsock_unix_redir_connectible:FAIL:1514 ./test_progs:vsock_unix_redir_connectible:1518: ingress: vsock socket map failed, a != b vsock_unix_redir_connectible:FAIL:1518 ./test_progs:vsock_unix_redir_connectible:1525: ingress: want pass count 1, have 0 It’s because the recv(... MSG_DONTWAIT) syscall in the test case is called before the queued work sk_psock_backlog() in the kernel finishes executing. So the data to be read is still queued in psock->ingress_skb and cannot be read by the user program. Therefore, the non-blocking recv() reads nothing and reports an EAGAIN error. So replace recv(... MSG_DONTWAIT) with xrecv_nonblock(), which calls select() to wait for data to be readable or timeout before calls recv(). Fixes: d61bd8c ("selftests/bpf: add a test case for vsock sockmap") Signed-off-by: Xu Kuohai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin KaFai Lau <[email protected]>

commit 90f0074 upstream. BPF CI has reported the following failure: Error: torvalds#200/79 sockmap_listen/sockmap VSOCK test_vsock_redir Error: torvalds#200/79 sockmap_listen/sockmap VSOCK test_vsock_redir ./test_progs:vsock_unix_redir_connectible:1506: egress: write: Transport endpoint is not connected vsock_unix_redir_connectible:FAIL:1506 ./test_progs:vsock_unix_redir_connectible:1506: ingress: write: Transport endpoint is not connected vsock_unix_redir_connectible:FAIL:1506 ./test_progs:vsock_unix_redir_connectible:1506: egress: write: Transport endpoint is not connected vsock_unix_redir_connectible:FAIL:1506 ./test_progs:vsock_unix_redir_connectible:1514: ingress: recv() err, errno=11 vsock_unix_redir_connectible:FAIL:1514 ./test_progs:vsock_unix_redir_connectible:1518: ingress: vsock socket map failed, a != b vsock_unix_redir_connectible:FAIL:1518 ./test_progs:vsock_unix_redir_connectible:1525: ingress: want pass count 1, have 0 It’s because the recv(... MSG_DONTWAIT) syscall in the test case is called before the queued work sk_psock_backlog() in the kernel finishes executing. So the data to be read is still queued in psock->ingress_skb and cannot be read by the user program. Therefore, the non-blocking recv() reads nothing and reports an EAGAIN error. So replace recv(... MSG_DONTWAIT) with xrecv_nonblock(), which calls select() to wait for data to be readable or timeout before calls recv(). Fixes: d61bd8c ("selftests/bpf: add a test case for vsock sockmap") Signed-off-by: Xu Kuohai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin KaFai Lau <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

slaven-s closed this Sep 28, 2015

otavio added a commit to OSSystems/linux that referenced this pull request Jan 22, 2021

Merge pull request torvalds#200 from zandrey/5.4.x+fslc

4d72b6a

Update 5.4.x+fslc to v5.4.85

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update README #200

Update README #200

slaven-s commented Aug 18, 2015

shelt commented Aug 23, 2015

marctmiller commented Aug 23, 2015

LandonPowell commented Aug 24, 2015

yuxuanchen1997 commented Aug 27, 2015

f123h456 commented Sep 14, 2015

zhouyongtao commented Sep 28, 2015

yuxuanchen1997 commented Sep 28, 2015

Update README #200

Update README #200

Conversation

slaven-s commented Aug 18, 2015

shelt commented Aug 23, 2015

marctmiller commented Aug 23, 2015

LandonPowell commented Aug 24, 2015

yuxuanchen1997 commented Aug 27, 2015

f123h456 commented Sep 14, 2015

zhouyongtao commented Sep 28, 2015

yuxuanchen1997 commented Sep 28, 2015