Added (0x1391, 0x2000) to IdealTec #271

FireGrace · 2016-04-01T19:35:33Z

I got some *nix on my Ix104c3 tablet and tried to work around the touchscreen.

And it works perfect =)
It will be awesome to see out-the box support for these tablets-because they run old WIndows XP.

I got some *nix on my Ix104c3 tablet and tried to work around the touchscreen. And it works perfect =)

@offset

Driver code did not remove event from the list of pending events before destroy. As a result drm core later tried to inspect invalid memory location. The patch replaces removal code with call to core helper. The bug was detected using KASAN: [ 10.107249] ================================================================== [ 10.107518] BUG: KASAN: use-after-free in drm_release+0xe9c/0x1000 at addr ffffffc089154a18 [ 10.107784] Read of size 8 by task modetest/103 [ 10.107931] ============================================================================= [ 10.113191] BUG kmalloc-128 (Not tainted): kasan: bad access detected [ 10.119608] ----------------------------------------------------------------------------- [ 10.119608] [ 10.129243] Disabling lock debugging due to kernel taint [ 10.134551] INFO: Allocated in drm_mode_page_flip_ioctl+0x500/0xa98 age=4 cpu=0 pid=103 [ 10.142532] alloc_debug_processing+0x18c/0x198 [ 10.147043] ___slab_alloc.constprop.28+0x360/0x380 [ 10.151906] __slab_alloc.isra.25.constprop.27+0x54/0xa0 [ 10.157197] kmem_cache_alloc_trace+0x370/0x3b0 [ 10.161709] drm_mode_page_flip_ioctl+0x500/0xa98 [ 10.166400] drm_ioctl+0x4c4/0xb68 [ 10.169787] do_vfs_ioctl+0x16c/0xeb8 [ 10.173429] SyS_ioctl+0x8c/0xa0 [ 10.176642] el0_svc_naked+0x24/0x28 [ 10.180204] INFO: Freed in exynos_drm_crtc_cancel_page_flip+0xe0/0x160 age=0 cpu=0 pid=103 [ 10.188447] free_debug_processing+0x174/0x388 [ 10.192871] __slab_free+0x2e8/0x438 [ 10.196431] kfree+0x350/0x360 [ 10.199469] exynos_drm_crtc_cancel_page_flip+0xe0/0x160 [ 10.204762] exynos_drm_preclose+0x58/0xa0 [ 10.208844] drm_release+0x1f0/0x1000 [ 10.212491] __fput+0x1c4/0x5b8 [ 10.215613] ____fput+0xc/0x18 [ 10.218654] task_work_run+0x130/0x198 [ 10.222385] do_exit+0x700/0x2278 [ 10.225681] do_group_exit+0xe4/0x2c8 [ 10.229327] SyS_exit_group+0x1c/0x20 [ 10.232973] el0_svc_naked+0x24/0x28 [ 10.236532] INFO: Slab 0xffffffbdc2a45500 objects=32 used=10 fp=0xffffffc089154a00 flags=0x4080 [ 10.245210] INFO: Object 0xffffffc089154a00 @offset=2560 fp=0xffffffc089157600 [ 10.245210] ... [ 10.384532] CPU: 0 PID: 103 Comm: modetest Tainted: G B 4.5.0-rc3-00748-gd5e2881 torvalds#271 [ 10.398325] Call trace: [ 10.400764] [<ffffffc000091428>] dump_backtrace+0x0/0x328 [ 10.406141] [<ffffffc000091764>] show_stack+0x14/0x20 [ 10.411176] [<ffffffc00089c550>] dump_stack+0xb0/0xe8 [ 10.416210] [<ffffffc000395778>] print_trailer+0xf8/0x160 [ 10.421592] [<ffffffc00039b5cc>] object_err+0x3c/0x50 [ 10.426626] [<ffffffc00039d630>] kasan_report_error+0x248/0x550 [ 10.432527] [<ffffffc00039da50>] __asan_report_load8_noabort+0x40/0x48 [ 10.439039] [<ffffffc000b5b724>] drm_release+0xe9c/0x1000 [ 10.444419] [<ffffffc0003d340c>] __fput+0x1c4/0x5b8 [ 10.449280] [<ffffffc0003d3884>] ____fput+0xc/0x18 [ 10.454055] [<ffffffc000101aa8>] task_work_run+0x130/0x198 [ 10.459522] [<ffffffc0000bc058>] do_exit+0x700/0x2278 [ 10.464557] [<ffffffc0000bdcfc>] do_group_exit+0xe4/0x2c8 [ 10.469939] [<ffffffc0000bdefc>] SyS_exit_group+0x1c/0x20 [ 10.475320] [<ffffffc000087530>] el0_svc_naked+0x24/0x28 Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>

lkl: build tools/lkl at out-of tree directory

Andrey reported a warning triggered by the rcu code: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 5911 at lib/debugobjects.c:289 debug_print_object+0x175/0x210 ODEBUG: activate active (active state 1) object type: rcu_head hint: (null) Modules linked in: CPU: 1 PID: 5911 Comm: a.out Not tainted 4.11.0-rc8+ torvalds#271 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:16 dump_stack+0x192/0x22d lib/dump_stack.c:52 __warn+0x19f/0x1e0 kernel/panic.c:549 warn_slowpath_fmt+0xe0/0x120 kernel/panic.c:564 debug_print_object+0x175/0x210 lib/debugobjects.c:286 debug_object_activate+0x574/0x7e0 lib/debugobjects.c:442 debug_rcu_head_queue kernel/rcu/rcu.h:75 __call_rcu.constprop.76+0xff/0x9c0 kernel/rcu/tree.c:3229 call_rcu_sched+0x12/0x20 kernel/rcu/tree.c:3288 rt6_rcu_free net/ipv6/ip6_fib.c:158 rt6_release+0x1ea/0x290 net/ipv6/ip6_fib.c:188 fib6_del_route net/ipv6/ip6_fib.c:1461 fib6_del+0xa42/0xdc0 net/ipv6/ip6_fib.c:1500 __ip6_del_rt+0x100/0x160 net/ipv6/route.c:2174 ip6_del_rt+0x140/0x1b0 net/ipv6/route.c:2187 __ipv6_ifa_notify+0x269/0x780 net/ipv6/addrconf.c:5520 addrconf_ifdown+0xe60/0x1a20 net/ipv6/addrconf.c:3672 ... Andrey's reproducer program runs in a very tight loop, calling 'unshare -n' and then spawning 2 sets of 14 threads running random ioctl calls. The relevant networking sequence: 1. New network namespace created via unshare -n - ip6tnl0 device is created in down state 2. address added to ip6tnl0 - equivalent to ip -6 addr add dev ip6tnl0 fd00::bb/1 - DAD is started on the address and when it completes the host route is inserted into the FIB 3. ip6tnl0 is brought up - the new fixup_permanent_addr function restarts DAD on the address 4. exit namespace - teardown / cleanup sequence starts - once in a blue moon, lo teardown appears to happen BEFORE teardown of ip6tunl0 + down on 'lo' removes the host route from the FIB since the dst->dev for the route is loobback + host route added to rcu callback list * rcu callback has not run yet, so rt is NOT on the gc list so it has NOT been marked obsolete 5. in parallel to 4. worker_thread runs addrconf_dad_completed - DAD on the address on ip6tnl0 completes - calls ipv6_ifa_notify which inserts the host route All of that happens very quickly. The result is that a host route that has been deleted from the IPv6 FIB and added to the RCU list is re-inserted into the FIB. The exit namespace eventually gets to cleaning up ip6tnl0 which removes the host route from the FIB again, calls the rcu function for cleanup -- and triggers the double rcu trace. The root cause is duplicate DAD on the address -- steps 2 and 3. Arguably, DAD should not be started in step 2. The interface is in the down state, so it can not really send out requests for the address which makes starting DAD pointless. Since the second DAD was introduced by a recent change, seems appropriate to use it for the Fixes tag and have the fixup function only start DAD for addresses in the PREDAD state which occurs in addrconf_ifdown if the address is retained. Big thanks to Andrey for isolating a reliable reproducer for this problem. Fixes: f1705ec ("net: ipv6: Make address flushing on ifdown optional") Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: David Ahern <dsahern@gmail.com>

[ Upstream commit 6d71713 ] Andrey reported a warning triggered by the rcu code: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 5911 at lib/debugobjects.c:289 debug_print_object+0x175/0x210 ODEBUG: activate active (active state 1) object type: rcu_head hint: (null) Modules linked in: CPU: 1 PID: 5911 Comm: a.out Not tainted 4.11.0-rc8+ torvalds#271 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:16 dump_stack+0x192/0x22d lib/dump_stack.c:52 __warn+0x19f/0x1e0 kernel/panic.c:549 warn_slowpath_fmt+0xe0/0x120 kernel/panic.c:564 debug_print_object+0x175/0x210 lib/debugobjects.c:286 debug_object_activate+0x574/0x7e0 lib/debugobjects.c:442 debug_rcu_head_queue kernel/rcu/rcu.h:75 __call_rcu.constprop.76+0xff/0x9c0 kernel/rcu/tree.c:3229 call_rcu_sched+0x12/0x20 kernel/rcu/tree.c:3288 rt6_rcu_free net/ipv6/ip6_fib.c:158 rt6_release+0x1ea/0x290 net/ipv6/ip6_fib.c:188 fib6_del_route net/ipv6/ip6_fib.c:1461 fib6_del+0xa42/0xdc0 net/ipv6/ip6_fib.c:1500 __ip6_del_rt+0x100/0x160 net/ipv6/route.c:2174 ip6_del_rt+0x140/0x1b0 net/ipv6/route.c:2187 __ipv6_ifa_notify+0x269/0x780 net/ipv6/addrconf.c:5520 addrconf_ifdown+0xe60/0x1a20 net/ipv6/addrconf.c:3672 ... Andrey's reproducer program runs in a very tight loop, calling 'unshare -n' and then spawning 2 sets of 14 threads running random ioctl calls. The relevant networking sequence: 1. New network namespace created via unshare -n - ip6tnl0 device is created in down state 2. address added to ip6tnl0 - equivalent to ip -6 addr add dev ip6tnl0 fd00::bb/1 - DAD is started on the address and when it completes the host route is inserted into the FIB 3. ip6tnl0 is brought up - the new fixup_permanent_addr function restarts DAD on the address 4. exit namespace - teardown / cleanup sequence starts - once in a blue moon, lo teardown appears to happen BEFORE teardown of ip6tunl0 + down on 'lo' removes the host route from the FIB since the dst->dev for the route is loobback + host route added to rcu callback list * rcu callback has not run yet, so rt is NOT on the gc list so it has NOT been marked obsolete 5. in parallel to 4. worker_thread runs addrconf_dad_completed - DAD on the address on ip6tnl0 completes - calls ipv6_ifa_notify which inserts the host route All of that happens very quickly. The result is that a host route that has been deleted from the IPv6 FIB and added to the RCU list is re-inserted into the FIB. The exit namespace eventually gets to cleaning up ip6tnl0 which removes the host route from the FIB again, calls the rcu function for cleanup -- and triggers the double rcu trace. The root cause is duplicate DAD on the address -- steps 2 and 3. Arguably, DAD should not be started in step 2. The interface is in the down state, so it can not really send out requests for the address which makes starting DAD pointless. Since the second DAD was introduced by a recent change, seems appropriate to use it for the Fixes tag and have the fixup function only start DAD for addresses in the PREDAD state which occurs in addrconf_ifdown if the address is retained. Big thanks to Andrey for isolating a reliable reproducer for this problem. Fixes: f1705ec ("net: ipv6: Make address flushing on ifdown optional") Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: David Ahern <dsahern@gmail.com> Tested-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[ Upstream commit 6d71713 ] Andrey reported a warning triggered by the rcu code: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 5911 at lib/debugobjects.c:289 debug_print_object+0x175/0x210 ODEBUG: activate active (active state 1) object type: rcu_head hint: (null) Modules linked in: CPU: 1 PID: 5911 Comm: a.out Not tainted 4.11.0-rc8+ #271 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:16 dump_stack+0x192/0x22d lib/dump_stack.c:52 __warn+0x19f/0x1e0 kernel/panic.c:549 warn_slowpath_fmt+0xe0/0x120 kernel/panic.c:564 debug_print_object+0x175/0x210 lib/debugobjects.c:286 debug_object_activate+0x574/0x7e0 lib/debugobjects.c:442 debug_rcu_head_queue kernel/rcu/rcu.h:75 __call_rcu.constprop.76+0xff/0x9c0 kernel/rcu/tree.c:3229 call_rcu_sched+0x12/0x20 kernel/rcu/tree.c:3288 rt6_rcu_free net/ipv6/ip6_fib.c:158 rt6_release+0x1ea/0x290 net/ipv6/ip6_fib.c:188 fib6_del_route net/ipv6/ip6_fib.c:1461 fib6_del+0xa42/0xdc0 net/ipv6/ip6_fib.c:1500 __ip6_del_rt+0x100/0x160 net/ipv6/route.c:2174 ip6_del_rt+0x140/0x1b0 net/ipv6/route.c:2187 __ipv6_ifa_notify+0x269/0x780 net/ipv6/addrconf.c:5520 addrconf_ifdown+0xe60/0x1a20 net/ipv6/addrconf.c:3672 ... Andrey's reproducer program runs in a very tight loop, calling 'unshare -n' and then spawning 2 sets of 14 threads running random ioctl calls. The relevant networking sequence: 1. New network namespace created via unshare -n - ip6tnl0 device is created in down state 2. address added to ip6tnl0 - equivalent to ip -6 addr add dev ip6tnl0 fd00::bb/1 - DAD is started on the address and when it completes the host route is inserted into the FIB 3. ip6tnl0 is brought up - the new fixup_permanent_addr function restarts DAD on the address 4. exit namespace - teardown / cleanup sequence starts - once in a blue moon, lo teardown appears to happen BEFORE teardown of ip6tunl0 + down on 'lo' removes the host route from the FIB since the dst->dev for the route is loobback + host route added to rcu callback list * rcu callback has not run yet, so rt is NOT on the gc list so it has NOT been marked obsolete 5. in parallel to 4. worker_thread runs addrconf_dad_completed - DAD on the address on ip6tnl0 completes - calls ipv6_ifa_notify which inserts the host route All of that happens very quickly. The result is that a host route that has been deleted from the IPv6 FIB and added to the RCU list is re-inserted into the FIB. The exit namespace eventually gets to cleaning up ip6tnl0 which removes the host route from the FIB again, calls the rcu function for cleanup -- and triggers the double rcu trace. The root cause is duplicate DAD on the address -- steps 2 and 3. Arguably, DAD should not be started in step 2. The interface is in the down state, so it can not really send out requests for the address which makes starting DAD pointless. Since the second DAD was introduced by a recent change, seems appropriate to use it for the Fixes tag and have the fixup function only start DAD for addresses in the PREDAD state which occurs in addrconf_ifdown if the address is retained. Big thanks to Andrey for isolating a reliable reproducer for this problem. Fixes: f1705ec ("net: ipv6: Make address flushing on ifdown optional") Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: David Ahern <dsahern@gmail.com> Tested-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

split __bpf_prog_run() interpreter into stack allocation and execution parts. The code section shrinks which helps interpreter performance in some cases. text data bss dec hex filename 26350 10328 624 37302 91b6 kernel/bpf/core.o.before 25777 10328 624 36729 8f79 kernel/bpf/core.o.after Very short programs got slower (due to extra function call): Before: test_bpf: torvalds#89 ALU64_ADD_K: 1 + 2 = 3 jited:0 7 PASS test_bpf: torvalds#90 ALU64_ADD_K: 3 + 0 = 3 jited:0 8 PASS test_bpf: torvalds#91 ALU64_ADD_K: 1 + 2147483646 = 2147483647 jited:0 7 PASS test_bpf: torvalds#92 ALU64_ADD_K: 4294967294 + 2 = 4294967296 jited:0 11 PASS test_bpf: torvalds#93 ALU64_ADD_K: 2147483646 + -2147483647 = -1 jited:0 7 PASS After: test_bpf: torvalds#89 ALU64_ADD_K: 1 + 2 = 3 jited:0 11 PASS test_bpf: torvalds#90 ALU64_ADD_K: 3 + 0 = 3 jited:0 11 PASS test_bpf: torvalds#91 ALU64_ADD_K: 1 + 2147483646 = 2147483647 jited:0 11 PASS test_bpf: torvalds#92 ALU64_ADD_K: 4294967294 + 2 = 4294967296 jited:0 14 PASS test_bpf: torvalds#93 ALU64_ADD_K: 2147483646 + -2147483647 = -1 jited:0 10 PASS Longer programs got faster: Before: test_bpf: torvalds#266 BPF_MAXINSNS: Ctx heavy transformations jited:0 20286 20513 PASS test_bpf: torvalds#267 BPF_MAXINSNS: Call heavy transformations jited:0 31853 31768 PASS test_bpf: torvalds#268 BPF_MAXINSNS: Jump heavy test jited:0 9815 PASS test_bpf: torvalds#269 BPF_MAXINSNS: Very long jump backwards jited:0 6 PASS test_bpf: torvalds#270 BPF_MAXINSNS: Edge hopping nuthouse jited:0 13959 PASS test_bpf: torvalds#271 BPF_MAXINSNS: Jump, gap, jump, ... jited:0 210 PASS test_bpf: torvalds#272 BPF_MAXINSNS: ld_abs+get_processor_id jited:0 21724 PASS test_bpf: torvalds#273 BPF_MAXINSNS: ld_abs+vlan_push/pop jited:0 19118 PASS After: test_bpf: torvalds#266 BPF_MAXINSNS: Ctx heavy transformations jited:0 19008 18827 PASS test_bpf: torvalds#267 BPF_MAXINSNS: Call heavy transformations jited:0 29238 28450 PASS test_bpf: torvalds#268 BPF_MAXINSNS: Jump heavy test jited:0 9485 PASS test_bpf: torvalds#269 BPF_MAXINSNS: Very long jump backwards jited:0 12 PASS test_bpf: torvalds#270 BPF_MAXINSNS: Edge hopping nuthouse jited:0 13257 PASS test_bpf: torvalds#271 BPF_MAXINSNS: Jump, gap, jump, ... jited:0 213 PASS test_bpf: torvalds#272 BPF_MAXINSNS: ld_abs+get_processor_id jited:0 19389 PASS test_bpf: torvalds#273 BPF_MAXINSNS: ld_abs+vlan_push/pop jited:0 19583 PASS For real world production programs the difference is noise. This patch is first step towards reducing interpreter stack consumption. Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: David S. Miller <davem@davemloft.net>

BugLink: http://bugs.launchpad.net/bugs/1690814 [ Upstream commit 6d71713 ] Andrey reported a warning triggered by the rcu code: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 5911 at lib/debugobjects.c:289 debug_print_object+0x175/0x210 ODEBUG: activate active (active state 1) object type: rcu_head hint: (null) Modules linked in: CPU: 1 PID: 5911 Comm: a.out Not tainted 4.11.0-rc8+ torvalds#271 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:16 dump_stack+0x192/0x22d lib/dump_stack.c:52 __warn+0x19f/0x1e0 kernel/panic.c:549 warn_slowpath_fmt+0xe0/0x120 kernel/panic.c:564 debug_print_object+0x175/0x210 lib/debugobjects.c:286 debug_object_activate+0x574/0x7e0 lib/debugobjects.c:442 debug_rcu_head_queue kernel/rcu/rcu.h:75 __call_rcu.constprop.76+0xff/0x9c0 kernel/rcu/tree.c:3229 call_rcu_sched+0x12/0x20 kernel/rcu/tree.c:3288 rt6_rcu_free net/ipv6/ip6_fib.c:158 rt6_release+0x1ea/0x290 net/ipv6/ip6_fib.c:188 fib6_del_route net/ipv6/ip6_fib.c:1461 fib6_del+0xa42/0xdc0 net/ipv6/ip6_fib.c:1500 __ip6_del_rt+0x100/0x160 net/ipv6/route.c:2174 ip6_del_rt+0x140/0x1b0 net/ipv6/route.c:2187 __ipv6_ifa_notify+0x269/0x780 net/ipv6/addrconf.c:5520 addrconf_ifdown+0xe60/0x1a20 net/ipv6/addrconf.c:3672 ... Andrey's reproducer program runs in a very tight loop, calling 'unshare -n' and then spawning 2 sets of 14 threads running random ioctl calls. The relevant networking sequence: 1. New network namespace created via unshare -n - ip6tnl0 device is created in down state 2. address added to ip6tnl0 - equivalent to ip -6 addr add dev ip6tnl0 fd00::bb/1 - DAD is started on the address and when it completes the host route is inserted into the FIB 3. ip6tnl0 is brought up - the new fixup_permanent_addr function restarts DAD on the address 4. exit namespace - teardown / cleanup sequence starts - once in a blue moon, lo teardown appears to happen BEFORE teardown of ip6tunl0 + down on 'lo' removes the host route from the FIB since the dst->dev for the route is loobback + host route added to rcu callback list * rcu callback has not run yet, so rt is NOT on the gc list so it has NOT been marked obsolete 5. in parallel to 4. worker_thread runs addrconf_dad_completed - DAD on the address on ip6tnl0 completes - calls ipv6_ifa_notify which inserts the host route All of that happens very quickly. The result is that a host route that has been deleted from the IPv6 FIB and added to the RCU list is re-inserted into the FIB. The exit namespace eventually gets to cleaning up ip6tnl0 which removes the host route from the FIB again, calls the rcu function for cleanup -- and triggers the double rcu trace. The root cause is duplicate DAD on the address -- steps 2 and 3. Arguably, DAD should not be started in step 2. The interface is in the down state, so it can not really send out requests for the address which makes starting DAD pointless. Since the second DAD was introduced by a recent change, seems appropriate to use it for the Fixes tag and have the fixup function only start DAD for addresses in the PREDAD state which occurs in addrconf_ifdown if the address is retained. Big thanks to Andrey for isolating a reliable reproducer for this problem. Fixes: f1705ec ("net: ipv6: Make address flushing on ifdown optional") Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: David Ahern <dsahern@gmail.com> Tested-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1691369 [ Upstream commit 6d71713 ] Andrey reported a warning triggered by the rcu code: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 5911 at lib/debugobjects.c:289 debug_print_object+0x175/0x210 ODEBUG: activate active (active state 1) object type: rcu_head hint: (null) Modules linked in: CPU: 1 PID: 5911 Comm: a.out Not tainted 4.11.0-rc8+ torvalds#271 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:16 dump_stack+0x192/0x22d lib/dump_stack.c:52 __warn+0x19f/0x1e0 kernel/panic.c:549 warn_slowpath_fmt+0xe0/0x120 kernel/panic.c:564 debug_print_object+0x175/0x210 lib/debugobjects.c:286 debug_object_activate+0x574/0x7e0 lib/debugobjects.c:442 debug_rcu_head_queue kernel/rcu/rcu.h:75 __call_rcu.constprop.76+0xff/0x9c0 kernel/rcu/tree.c:3229 call_rcu_sched+0x12/0x20 kernel/rcu/tree.c:3288 rt6_rcu_free net/ipv6/ip6_fib.c:158 rt6_release+0x1ea/0x290 net/ipv6/ip6_fib.c:188 fib6_del_route net/ipv6/ip6_fib.c:1461 fib6_del+0xa42/0xdc0 net/ipv6/ip6_fib.c:1500 __ip6_del_rt+0x100/0x160 net/ipv6/route.c:2174 ip6_del_rt+0x140/0x1b0 net/ipv6/route.c:2187 __ipv6_ifa_notify+0x269/0x780 net/ipv6/addrconf.c:5520 addrconf_ifdown+0xe60/0x1a20 net/ipv6/addrconf.c:3672 ... Andrey's reproducer program runs in a very tight loop, calling 'unshare -n' and then spawning 2 sets of 14 threads running random ioctl calls. The relevant networking sequence: 1. New network namespace created via unshare -n - ip6tnl0 device is created in down state 2. address added to ip6tnl0 - equivalent to ip -6 addr add dev ip6tnl0 fd00::bb/1 - DAD is started on the address and when it completes the host route is inserted into the FIB 3. ip6tnl0 is brought up - the new fixup_permanent_addr function restarts DAD on the address 4. exit namespace - teardown / cleanup sequence starts - once in a blue moon, lo teardown appears to happen BEFORE teardown of ip6tunl0 + down on 'lo' removes the host route from the FIB since the dst->dev for the route is loobback + host route added to rcu callback list * rcu callback has not run yet, so rt is NOT on the gc list so it has NOT been marked obsolete 5. in parallel to 4. worker_thread runs addrconf_dad_completed - DAD on the address on ip6tnl0 completes - calls ipv6_ifa_notify which inserts the host route All of that happens very quickly. The result is that a host route that has been deleted from the IPv6 FIB and added to the RCU list is re-inserted into the FIB. The exit namespace eventually gets to cleaning up ip6tnl0 which removes the host route from the FIB again, calls the rcu function for cleanup -- and triggers the double rcu trace. The root cause is duplicate DAD on the address -- steps 2 and 3. Arguably, DAD should not be started in step 2. The interface is in the down state, so it can not really send out requests for the address which makes starting DAD pointless. Since the second DAD was introduced by a recent change, seems appropriate to use it for the Fixes tag and have the fixup function only start DAD for addresses in the PREDAD state which occurs in addrconf_ifdown if the address is retained. Big thanks to Andrey for isolating a reliable reproducer for this problem. Fixes: f1705ec ("net: ipv6: Make address flushing on ifdown optional") Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: David Ahern <dsahern@gmail.com> Tested-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

Commit f7f9910 ("mm: stop zeroing memory during allocation in vmemmap") broke Xen pv domains in some configurations, as the "Pinned" information in struct page of early page tables could get lost. This will lead to the kernel trying to write directly into the page tables instead of asking the hypervisor to do so. The result is a crash like the following: [ 0.004000] BUG: unable to handle kernel paging request at ffff8801ead19008 [ 0.004000] IP: xen_set_pud+0x4e/0xd0 [ 0.004000] PGD 1c0a067 P4D 1c0a067 PUD 23a0067 PMD 1e9de0067 PTE 80100001ead19065 [ 0.004000] Oops: 0003 [#1] PREEMPT SMP [ 0.004000] Modules linked in: [ 0.004000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-default+ torvalds#271 [ 0.004000] Hardware name: Dell Inc. Latitude E6440/0159N7, BIOS A07 06/26/2014 [ 0.004000] task: ffffffff81c10480 task.stack: ffffffff81c00000 [ 0.004000] RIP: e030:xen_set_pud+0x4e/0xd0 [ 0.004000] RSP: e02b:ffffffff81c03cd8 EFLAGS: 00010246 [ 0.004000] RAX: 002ffff800000800 RBX: ffff88020fd31000 RCX: 0000000000000000 [ 0.004000] RDX: ffffea0000000000 RSI: 00000001b8308067 RDI: ffff8801ead19008 [ 0.004000] RBP: ffff8801ead19008 R08: aaaaaaaaaaaaaaaa R09: 00000000063f4c80 [ 0.004000] R10: aaaaaaaaaaaaaaaa R11: 0720072007200720 R12: 00000001b8308067 [ 0.004000] R13: ffffffff81c8a9cc R14: ffff88018fd31000 R15: 000077ff80000000 [ 0.004000] FS: 0000000000000000(0000) GS:ffff88020f600000(0000) knlGS:0000000000000000 [ 0.004000] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.004000] CR2: ffff8801ead19008 CR3: 0000000001c09000 CR4: 0000000000042660 [ 0.004000] Call Trace: [ 0.004000] __pmd_alloc+0x128/0x140 [ 0.004000] ? acpi_os_map_iomem+0x175/0x1b0 [ 0.004000] ioremap_page_range+0x3f4/0x410 [ 0.004000] ? acpi_os_map_iomem+0x175/0x1b0 [ 0.004000] __ioremap_caller+0x1c3/0x2e0 [ 0.004000] acpi_os_map_iomem+0x175/0x1b0 [ 0.004000] acpi_tb_acquire_table+0x39/0x66 [ 0.004000] acpi_tb_validate_table+0x44/0x7c [ 0.004000] acpi_tb_verify_temp_table+0x45/0x304 [ 0.004000] ? acpi_ut_acquire_mutex+0x12a/0x1c2 [ 0.004000] acpi_reallocate_root_table+0x12d/0x141 [ 0.004000] acpi_early_init+0x4d/0x10a [ 0.004000] start_kernel+0x3eb/0x4a1 [ 0.004000] ? set_init_arg+0x55/0x55 [ 0.004000] xen_start_kernel+0x528/0x532 [ 0.004000] Code: 48 01 e8 48 0f 42 15 a2 fd be 00 48 01 d0 48 ba 00 00 00 00 00 ea ff ff 48 c1 e8 0c 48 c1 e0 06 48 01 d0 48 8b 00 f6 c4 02 75 5d <4c> 89 65 00 5b 5d 41 5c c3 65 8b 05 52 9f fe 7e 89 c0 48 0f a3 [ 0.004000] RIP: xen_set_pud+0x4e/0xd0 RSP: ffffffff81c03cd8 [ 0.004000] CR2: ffff8801ead19008 [ 0.004000] ---[ end trace 38eca2e56f1b642e ]--- Avoid this problem by not deferring struct page initialization when running as Xen pv guest. Cc: <stable@vger.kernel.org> #4.15 Fixes: f7f9910 ("mm: stop zeroing memory during allocation in vmemmap") Signed-off-by: Juergen Gross <jgross@suse.com>

Commit f7f9910 ("mm: stop zeroing memory during allocation in vmemmap") broke Xen pv domains in some configurations, as the "Pinned" information in struct page of early page tables could get lost. This will lead to the kernel trying to write directly into the page tables instead of asking the hypervisor to do so. The result is a crash like the following: [ 0.004000] BUG: unable to handle kernel paging request at ffff8801ead19008 [ 0.004000] IP: xen_set_pud+0x4e/0xd0 [ 0.004000] PGD 1c0a067 P4D 1c0a067 PUD 23a0067 PMD 1e9de0067 PTE 80100001ead19065 [ 0.004000] Oops: 0003 [#1] PREEMPT SMP [ 0.004000] Modules linked in: [ 0.004000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-default+ torvalds#271 [ 0.004000] Hardware name: Dell Inc. Latitude E6440/0159N7, BIOS A07 06/26/2014 [ 0.004000] task: ffffffff81c10480 task.stack: ffffffff81c00000 [ 0.004000] RIP: e030:xen_set_pud+0x4e/0xd0 [ 0.004000] RSP: e02b:ffffffff81c03cd8 EFLAGS: 00010246 [ 0.004000] RAX: 002ffff800000800 RBX: ffff88020fd31000 RCX: 0000000000000000 [ 0.004000] RDX: ffffea0000000000 RSI: 00000001b8308067 RDI: ffff8801ead19008 [ 0.004000] RBP: ffff8801ead19008 R08: aaaaaaaaaaaaaaaa R09: 00000000063f4c80 [ 0.004000] R10: aaaaaaaaaaaaaaaa R11: 0720072007200720 R12: 00000001b8308067 [ 0.004000] R13: ffffffff81c8a9cc R14: ffff88018fd31000 R15: 000077ff80000000 [ 0.004000] FS: 0000000000000000(0000) GS:ffff88020f600000(0000) knlGS:0000000000000000 [ 0.004000] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.004000] CR2: ffff8801ead19008 CR3: 0000000001c09000 CR4: 0000000000042660 [ 0.004000] Call Trace: [ 0.004000] __pmd_alloc+0x128/0x140 [ 0.004000] ? acpi_os_map_iomem+0x175/0x1b0 [ 0.004000] ioremap_page_range+0x3f4/0x410 [ 0.004000] ? acpi_os_map_iomem+0x175/0x1b0 [ 0.004000] __ioremap_caller+0x1c3/0x2e0 [ 0.004000] acpi_os_map_iomem+0x175/0x1b0 [ 0.004000] acpi_tb_acquire_table+0x39/0x66 [ 0.004000] acpi_tb_validate_table+0x44/0x7c [ 0.004000] acpi_tb_verify_temp_table+0x45/0x304 [ 0.004000] ? acpi_ut_acquire_mutex+0x12a/0x1c2 [ 0.004000] acpi_reallocate_root_table+0x12d/0x141 [ 0.004000] acpi_early_init+0x4d/0x10a [ 0.004000] start_kernel+0x3eb/0x4a1 [ 0.004000] ? set_init_arg+0x55/0x55 [ 0.004000] xen_start_kernel+0x528/0x532 [ 0.004000] Code: 48 01 e8 48 0f 42 15 a2 fd be 00 48 01 d0 48 ba 00 00 00 00 00 ea ff ff 48 c1 e8 0c 48 c1 e0 06 48 01 d0 48 8b 00 f6 c4 02 75 5d <4c> 89 65 00 5b 5d 41 5c c3 65 8b 05 52 9f fe 7e 89 c0 48 0f a3 [ 0.004000] RIP: xen_set_pud+0x4e/0xd0 RSP: ffffffff81c03cd8 [ 0.004000] CR2: ffff8801ead19008 [ 0.004000] ---[ end trace 38eca2e56f1b642e ]--- Avoid this problem by not deferring struct page initialization when running as Xen pv guest. Cc: <stable@vger.kernel.org> #4.15 Signed-off-by: Juergen Gross <jgross@suse.com>

f7f9910 ("mm: stop zeroing memory during allocation in vmemmap") broke Xen pv domains in some configurations, as the "Pinned" information in struct page of early page tables could get lost. This will lead to the kernel trying to write directly into the page tables instead of asking the hypervisor to do so. The result is a crash like the following: [ 0.004000] BUG: unable to handle kernel paging request at ffff8801ead19008 [ 0.004000] IP: xen_set_pud+0x4e/0xd0 [ 0.004000] PGD 1c0a067 P4D 1c0a067 PUD 23a0067 PMD 1e9de0067 PTE 80100001ead19065 [ 0.004000] Oops: 0003 [#1] PREEMPT SMP [ 0.004000] Modules linked in: [ 0.004000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-default+ torvalds#271 [ 0.004000] Hardware name: Dell Inc. Latitude E6440/0159N7, BIOS A07 06/26/2014 [ 0.004000] task: ffffffff81c10480 task.stack: ffffffff81c00000 [ 0.004000] RIP: e030:xen_set_pud+0x4e/0xd0 [ 0.004000] RSP: e02b:ffffffff81c03cd8 EFLAGS: 00010246 [ 0.004000] RAX: 002ffff800000800 RBX: ffff88020fd31000 RCX: 0000000000000000 [ 0.004000] RDX: ffffea0000000000 RSI: 00000001b8308067 RDI: ffff8801ead19008 [ 0.004000] RBP: ffff8801ead19008 R08: aaaaaaaaaaaaaaaa R09: 00000000063f4c80 [ 0.004000] R10: aaaaaaaaaaaaaaaa R11: 0720072007200720 R12: 00000001b8308067 [ 0.004000] R13: ffffffff81c8a9cc R14: ffff88018fd31000 R15: 000077ff80000000 [ 0.004000] FS: 0000000000000000(0000) GS:ffff88020f600000(0000) knlGS:0000000000000000 [ 0.004000] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.004000] CR2: ffff8801ead19008 CR3: 0000000001c09000 CR4: 0000000000042660 [ 0.004000] Call Trace: [ 0.004000] __pmd_alloc+0x128/0x140 [ 0.004000] ? acpi_os_map_iomem+0x175/0x1b0 [ 0.004000] ioremap_page_range+0x3f4/0x410 [ 0.004000] ? acpi_os_map_iomem+0x175/0x1b0 [ 0.004000] __ioremap_caller+0x1c3/0x2e0 [ 0.004000] acpi_os_map_iomem+0x175/0x1b0 [ 0.004000] acpi_tb_acquire_table+0x39/0x66 [ 0.004000] acpi_tb_validate_table+0x44/0x7c [ 0.004000] acpi_tb_verify_temp_table+0x45/0x304 [ 0.004000] ? acpi_ut_acquire_mutex+0x12a/0x1c2 [ 0.004000] acpi_reallocate_root_table+0x12d/0x141 [ 0.004000] acpi_early_init+0x4d/0x10a [ 0.004000] start_kernel+0x3eb/0x4a1 [ 0.004000] ? set_init_arg+0x55/0x55 [ 0.004000] xen_start_kernel+0x528/0x532 [ 0.004000] Code: 48 01 e8 48 0f 42 15 a2 fd be 00 48 01 d0 48 ba 00 00 00 00 00 ea ff ff 48 c1 e8 0c 48 c1 e0 06 48 01 d0 48 8b 00 f6 c4 02 75 5d <4c> 89 65 00 5b 5d 41 5c c3 65 8b 05 52 9f fe 7e 89 c0 48 0f a3 [ 0.004000] RIP: xen_set_pud+0x4e/0xd0 RSP: ffffffff81c03cd8 [ 0.004000] CR2: ffff8801ead19008 [ 0.004000] ---[ end trace 38eca2e56f1b642e ]--- Avoid this problem by not deferring struct page initialization when running as Xen pv guest. Pavel said: : This is unique for Xen, so this particular issue won't effect other : configurations. I am going to investigate if there is a way to : re-enable deferred page initialization on xen guests. [akpm@linux-foundation.org: explicitly include xen.h] Link: http://lkml.kernel.org/r/20180216154101.22865-1-jgross@suse.com Fixes: f7f9910 ("mm: stop zeroing memory during allocation in vmemmap") Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com> Cc: Steven Sistare <steven.sistare@oracle.com> Cc: Daniel Jordan <daniel.m.jordan@oracle.com> Cc: Bob Picco <bob.picco@oracle.com> Cc: <stable@vger.kernel.org> [4.15.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

f7f9910 ("mm: stop zeroing memory during allocation in vmemmap") broke Xen pv domains in some configurations, as the "Pinned" information in struct page of early page tables could get lost. This will lead to the kernel trying to write directly into the page tables instead of asking the hypervisor to do so. The result is a crash like the following: [ 0.004000] BUG: unable to handle kernel paging request at ffff8801ead19008 [ 0.004000] IP: xen_set_pud+0x4e/0xd0 [ 0.004000] PGD 1c0a067 P4D 1c0a067 PUD 23a0067 PMD 1e9de0067 PTE 80100001ead19065 [ 0.004000] Oops: 0003 [#1] PREEMPT SMP [ 0.004000] Modules linked in: [ 0.004000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-default+ torvalds#271 [ 0.004000] Hardware name: Dell Inc. Latitude E6440/0159N7, BIOS A07 06/26/2014 [ 0.004000] task: ffffffff81c10480 task.stack: ffffffff81c00000 [ 0.004000] RIP: e030:xen_set_pud+0x4e/0xd0 [ 0.004000] RSP: e02b:ffffffff81c03cd8 EFLAGS: 00010246 [ 0.004000] RAX: 002ffff800000800 RBX: ffff88020fd31000 RCX: 0000000000000000 [ 0.004000] RDX: ffffea0000000000 RSI: 00000001b8308067 RDI: ffff8801ead19008 [ 0.004000] RBP: ffff8801ead19008 R08: aaaaaaaaaaaaaaaa R09: 00000000063f4c80 [ 0.004000] R10: aaaaaaaaaaaaaaaa R11: 0720072007200720 R12: 00000001b8308067 [ 0.004000] R13: ffffffff81c8a9cc R14: ffff88018fd31000 R15: 000077ff80000000 [ 0.004000] FS: 0000000000000000(0000) GS:ffff88020f600000(0000) knlGS:0000000000000000 [ 0.004000] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.004000] CR2: ffff8801ead19008 CR3: 0000000001c09000 CR4: 0000000000042660 [ 0.004000] Call Trace: [ 0.004000] __pmd_alloc+0x128/0x140 [ 0.004000] ? acpi_os_map_iomem+0x175/0x1b0 [ 0.004000] ioremap_page_range+0x3f4/0x410 [ 0.004000] ? acpi_os_map_iomem+0x175/0x1b0 [ 0.004000] __ioremap_caller+0x1c3/0x2e0 [ 0.004000] acpi_os_map_iomem+0x175/0x1b0 [ 0.004000] acpi_tb_acquire_table+0x39/0x66 [ 0.004000] acpi_tb_validate_table+0x44/0x7c [ 0.004000] acpi_tb_verify_temp_table+0x45/0x304 [ 0.004000] ? acpi_ut_acquire_mutex+0x12a/0x1c2 [ 0.004000] acpi_reallocate_root_table+0x12d/0x141 [ 0.004000] acpi_early_init+0x4d/0x10a [ 0.004000] start_kernel+0x3eb/0x4a1 [ 0.004000] ? set_init_arg+0x55/0x55 [ 0.004000] xen_start_kernel+0x528/0x532 [ 0.004000] Code: 48 01 e8 48 0f 42 15 a2 fd be 00 48 01 d0 48 ba 00 00 00 00 00 ea ff ff 48 c1 e8 0c 48 c1 e0 06 48 01 d0 48 8b 00 f6 c4 02 75 5d <4c> 89 65 00 5b 5d 41 5c c3 65 8b 05 52 9f fe 7e 89 c0 48 0f a3 [ 0.004000] RIP: xen_set_pud+0x4e/0xd0 RSP: ffffffff81c03cd8 [ 0.004000] CR2: ffff8801ead19008 [ 0.004000] ---[ end trace 38eca2e56f1b642e ]--- Avoid this problem by not deferring struct page initialization when running as Xen pv guest. Pavel said: : This is unique for Xen, so this particular issue won't effect other : configurations. I am going to investigate if there is a way to : re-enable deferred page initialization on xen guests. [akpm@linux-foundation.org: explicitly include xen.h] Link: http://lkml.kernel.org/r/20180216154101.22865-1-jgross@suse.com Fixes: f7f9910 ("mm: stop zeroing memory during allocation in vmemmap") Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com> Cc: Steven Sistare <steven.sistare@oracle.com> Cc: Daniel Jordan <daniel.m.jordan@oracle.com> Cc: Bob Picco <bob.picco@oracle.com> Cc: <stable@vger.kernel.org> [4.15.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Commit f7f9910 ("mm: stop zeroing memory during allocation in vmemmap") broke Xen pv domains in some configurations, as the "Pinned" information in struct page of early page tables could get lost. This will lead to the kernel trying to write directly into the page tables instead of asking the hypervisor to do so. The result is a crash like the following: BUG: unable to handle kernel paging request at ffff8801ead19008 IP: xen_set_pud+0x4e/0xd0 PGD 1c0a067 P4D 1c0a067 PUD 23a0067 PMD 1e9de0067 PTE 80100001ead19065 Oops: 0003 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-default+ #271 Hardware name: Dell Inc. Latitude E6440/0159N7, BIOS A07 06/26/2014 task: ffffffff81c10480 task.stack: ffffffff81c00000 RIP: e030:xen_set_pud+0x4e/0xd0 Call Trace: __pmd_alloc+0x128/0x140 ioremap_page_range+0x3f4/0x410 __ioremap_caller+0x1c3/0x2e0 acpi_os_map_iomem+0x175/0x1b0 acpi_tb_acquire_table+0x39/0x66 acpi_tb_validate_table+0x44/0x7c acpi_tb_verify_temp_table+0x45/0x304 acpi_reallocate_root_table+0x12d/0x141 acpi_early_init+0x4d/0x10a start_kernel+0x3eb/0x4a1 xen_start_kernel+0x528/0x532 Code: 48 01 e8 48 0f 42 15 a2 fd be 00 48 01 d0 48 ba 00 00 00 00 00 ea ff ff 48 c1 e8 0c 48 c1 e0 06 48 01 d0 48 8b 00 f6 c4 02 75 5d <4c> 89 65 00 5b 5d 41 5c c3 65 8b 05 52 9f fe 7e 89 c0 48 0f a3 RIP: xen_set_pud+0x4e/0xd0 RSP: ffffffff81c03cd8 CR2: ffff8801ead19008 ---[ end trace 38eca2e56f1b642e ]--- Avoid this problem by not deferring struct page initialization when running as Xen pv guest. Pavel said: : This is unique for Xen, so this particular issue won't effect other : configurations. I am going to investigate if there is a way to : re-enable deferred page initialization on xen guests. [akpm@linux-foundation.org: explicitly include xen.h] Link: http://lkml.kernel.org/r/20180216154101.22865-1-jgross@suse.com Fixes: f7f9910 ("mm: stop zeroing memory during allocation in vmemmap") Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com> Cc: Steven Sistare <steven.sistare@oracle.com> Cc: Daniel Jordan <daniel.m.jordan@oracle.com> Cc: Bob Picco <bob.picco@oracle.com> Cc: <stable@vger.kernel.org> [4.15.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 895f7b8 upstream. Commit f7f9910 ("mm: stop zeroing memory during allocation in vmemmap") broke Xen pv domains in some configurations, as the "Pinned" information in struct page of early page tables could get lost. This will lead to the kernel trying to write directly into the page tables instead of asking the hypervisor to do so. The result is a crash like the following: BUG: unable to handle kernel paging request at ffff8801ead19008 IP: xen_set_pud+0x4e/0xd0 PGD 1c0a067 P4D 1c0a067 PUD 23a0067 PMD 1e9de0067 PTE 80100001ead19065 Oops: 0003 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-default+ #271 Hardware name: Dell Inc. Latitude E6440/0159N7, BIOS A07 06/26/2014 task: ffffffff81c10480 task.stack: ffffffff81c00000 RIP: e030:xen_set_pud+0x4e/0xd0 Call Trace: __pmd_alloc+0x128/0x140 ioremap_page_range+0x3f4/0x410 __ioremap_caller+0x1c3/0x2e0 acpi_os_map_iomem+0x175/0x1b0 acpi_tb_acquire_table+0x39/0x66 acpi_tb_validate_table+0x44/0x7c acpi_tb_verify_temp_table+0x45/0x304 acpi_reallocate_root_table+0x12d/0x141 acpi_early_init+0x4d/0x10a start_kernel+0x3eb/0x4a1 xen_start_kernel+0x528/0x532 Code: 48 01 e8 48 0f 42 15 a2 fd be 00 48 01 d0 48 ba 00 00 00 00 00 ea ff ff 48 c1 e8 0c 48 c1 e0 06 48 01 d0 48 8b 00 f6 c4 02 75 5d <4c> 89 65 00 5b 5d 41 5c c3 65 8b 05 52 9f fe 7e 89 c0 48 0f a3 RIP: xen_set_pud+0x4e/0xd0 RSP: ffffffff81c03cd8 CR2: ffff8801ead19008 ---[ end trace 38eca2e56f1b642e ]--- Avoid this problem by not deferring struct page initialization when running as Xen pv guest. Pavel said: : This is unique for Xen, so this particular issue won't effect other : configurations. I am going to investigate if there is a way to : re-enable deferred page initialization on xen guests. [akpm@linux-foundation.org: explicitly include xen.h] Link: http://lkml.kernel.org/r/20180216154101.22865-1-jgross@suse.com Fixes: f7f9910 ("mm: stop zeroing memory during allocation in vmemmap") Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com> Cc: Steven Sistare <steven.sistare@oracle.com> Cc: Daniel Jordan <daniel.m.jordan@oracle.com> Cc: Bob Picco <bob.picco@oracle.com> Cc: <stable@vger.kernel.org> [4.15.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spdxcheck.py complains: include/linux/platform_data/gpio/gpio-amd-fch.h: 1:28 Invalid License ID: GPL+ which is correct because GPL+ is not a valid identifier. Of course this could have been caught by checkpatch.pl _before_ submitting or merging the patch. WARNING: 'SPDX-License-Identifier: GPL+ */' is not supported in LICENSES/... torvalds#271: FILE: include/linux/platform_data/gpio/gpio-amd-fch.h:1: +/* SPDX-License-Identifier: GPL+ */ Fix it under the assumption that the author meant GPL-2.0+, which makes sense as the corresponding C file is using that identifier. Fixes: e09d168 ("gpio: AMD G-Series PCH gpio driver") Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

rdma_listen() checks if device already attached to rdma_id_priv, based on the response the its decide to what to listen, however this is different when the listeners are canceled. This leads to a mismatch between rdma_listen() and cma_cancel_operation(), and causes to bellow wild-memory-access. Fix it by aligning rdma_listen() according to the cma_cancel_operation(). Found by syzcaller: BUG: KASAN: wild-memory-access in __list_del include/linux/list.h:112 [inline] BUG: KASAN: wild-memory-access in __list_del_entry include/linux/list.h:135 [inline] BUG: KASAN: wild-memory-access in list_del include/linux/list.h:146 [inline] BUG: KASAN: wild-memory-access in cma_cancel_listens drivers/infiniband/core/cma.c:1767 [inline] BUG: KASAN: wild-memory-access in cma_cancel_operation drivers/infiniband/core/cma.c:1795 [inline] BUG: KASAN: wild-memory-access in cma_cancel_operation+0x1f4/0x4b0 drivers/infiniband/core/cma.c:1783 Write of size 8 at addr dead000000000108 by task syz-executor716/334 CPU: 0 PID: 334 Comm: syz-executor716 Not tainted 5.11.0+ torvalds#271 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0xbe/0xf9 lib/dump_stack.c:120 __kasan_report mm/kasan/report.c:400 [inline] kasan_report.cold+0x5f/0xd5 mm/kasan/report.c:413 __list_del include/linux/list.h:112 [inline] __list_del_entry include/linux/list.h:135 [inline] list_del include/linux/list.h:146 [inline] cma_cancel_listens drivers/infiniband/core/cma.c:1767 [inline] cma_cancel_operation drivers/infiniband/core/cma.c:1795 [inline] cma_cancel_operation+0x1f4/0x4b0 drivers/infiniband/core/cma.c:1783 _destroy_id+0x29/0x460 drivers/infiniband/core/cma.c:1862 ucma_close_id+0x36/0x50 drivers/infiniband/core/ucma.c:185 ucma_destroy_private_ctx+0x58d/0x5b0 drivers/infiniband/core/ucma.c:576 ucma_close+0x91/0xd0 drivers/infiniband/core/ucma.c:1797 __fput+0x169/0x540 fs/file_table.c:280 task_work_run+0xb7/0x100 kernel/task_work.c:140 exit_task_work include/linux/task_work.h:30 [inline] do_exit+0x7da/0x17f0 kernel/exit.c:825 do_group_exit+0x9e/0x190 kernel/exit.c:922 __do_sys_exit_group kernel/exit.c:933 [inline] __se_sys_exit_group kernel/exit.c:931 [inline] __x64_sys_exit_group+0x2d/0x30 kernel/exit.c:931 do_syscall_64+0x2d/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x44a326 Code: Unable to access opcode bytes at RIP 0x44a2fc. RSP: 002b:00007ffd14306748 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00000000006c4490 RCX: 000000000044a326 RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001 RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0 R10: bb1414ac000000c2 R11: 0000000000000246 R12: 00000000006c4490 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 ================================================================== Fixes: 255d0c1 ("RDMA/cma: rdma_bind_addr() leaks a cma_dev reference count") Signed-off-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>

The idea that restrack needs asymmetrical delete routine was proven as wrong. It caused to try and access ib_device after it was already disconnected from the cma_dev. As a solution, move rdma_restrack_del() to be before id_priv destruction. Found by syzcaller: BUG: KASAN: wild-memory-access in __list_del include/linux/list.h:112 [inline] BUG: KASAN: wild-memory-access in __list_del_entry include/linux/list.h:135 [inline] BUG: KASAN: wild-memory-access in list_del include/linux/list.h:146 [inline] BUG: KASAN: wild-memory-access in cma_cancel_listens drivers/infiniband/core/cma.c:1767 [inline] BUG: KASAN: wild-memory-access in cma_cancel_operation drivers/infiniband/core/cma.c:1795 [inline] BUG: KASAN: wild-memory-access in cma_cancel_operation+0x1f4/0x4b0 drivers/infiniband/core/cma.c:1783 Write of size 8 at addr dead000000000108 by task syz-executor716/334 CPU: 0 PID: 334 Comm: syz-executor716 Not tainted 5.11.0+ torvalds#271 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0xbe/0xf9 lib/dump_stack.c:120 __kasan_report mm/kasan/report.c:400 [inline] kasan_report.cold+0x5f/0xd5 mm/kasan/report.c:413 __list_del include/linux/list.h:112 [inline] __list_del_entry include/linux/list.h:135 [inline] list_del include/linux/list.h:146 [inline] cma_cancel_listens drivers/infiniband/core/cma.c:1767 [inline] cma_cancel_operation drivers/infiniband/core/cma.c:1795 [inline] cma_cancel_operation+0x1f4/0x4b0 drivers/infiniband/core/cma.c:1783 _destroy_id+0x29/0x460 drivers/infiniband/core/cma.c:1862 ucma_close_id+0x36/0x50 drivers/infiniband/core/ucma.c:185 ucma_destroy_private_ctx+0x58d/0x5b0 drivers/infiniband/core/ucma.c:576 ucma_close+0x91/0xd0 drivers/infiniband/core/ucma.c:1797 __fput+0x169/0x540 fs/file_table.c:280 task_work_run+0xb7/0x100 kernel/task_work.c:140 exit_task_work include/linux/task_work.h:30 [inline] do_exit+0x7da/0x17f0 kernel/exit.c:825 do_group_exit+0x9e/0x190 kernel/exit.c:922 __do_sys_exit_group kernel/exit.c:933 [inline] __se_sys_exit_group kernel/exit.c:931 [inline] __x64_sys_exit_group+0x2d/0x30 kernel/exit.c:931 do_syscall_64+0x2d/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x44a326 Code: Unable to access opcode bytes at RIP 0x44a2fc. RSP: 002b:00007ffd14306748 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00000000006c4490 RCX: 000000000044a326 RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001 RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0 R10: bb1414ac000000c2 R11: 0000000000000246 R12: 00000000006c4490 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 ================================================================== Fixes: 255d0c1 ("RDMA/cma: rdma_bind_addr() leaks a cma_dev reference count") Signed-off-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>

restrack should only be attached to a cm_id while the ID has a valid device pointer. It is set up when the device is first loaded, but not cleared when the device is removed. There is also two copies of the device pointer, one private and one in the public API, and these were left out of sync. Make everything go to NULL together and manipulate restrack right around the device assignments. Found by syzcaller: BUG: KASAN: wild-memory-access in __list_del include/linux/list.h:112 [inline] BUG: KASAN: wild-memory-access in __list_del_entry include/linux/list.h:135 [inline] BUG: KASAN: wild-memory-access in list_del include/linux/list.h:146 [inline] BUG: KASAN: wild-memory-access in cma_cancel_listens drivers/infiniband/core/cma.c:1767 [inline] BUG: KASAN: wild-memory-access in cma_cancel_operation drivers/infiniband/core/cma.c:1795 [inline] BUG: KASAN: wild-memory-access in cma_cancel_operation+0x1f4/0x4b0 drivers/infiniband/core/cma.c:1783 Write of size 8 at addr dead000000000108 by task syz-executor716/334 CPU: 0 PID: 334 Comm: syz-executor716 Not tainted 5.11.0+ torvalds#271 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0xbe/0xf9 lib/dump_stack.c:120 __kasan_report mm/kasan/report.c:400 [inline] kasan_report.cold+0x5f/0xd5 mm/kasan/report.c:413 __list_del include/linux/list.h:112 [inline] __list_del_entry include/linux/list.h:135 [inline] list_del include/linux/list.h:146 [inline] cma_cancel_listens drivers/infiniband/core/cma.c:1767 [inline] cma_cancel_operation drivers/infiniband/core/cma.c:1795 [inline] cma_cancel_operation+0x1f4/0x4b0 drivers/infiniband/core/cma.c:1783 _destroy_id+0x29/0x460 drivers/infiniband/core/cma.c:1862 ucma_close_id+0x36/0x50 drivers/infiniband/core/ucma.c:185 ucma_destroy_private_ctx+0x58d/0x5b0 drivers/infiniband/core/ucma.c:576 ucma_close+0x91/0xd0 drivers/infiniband/core/ucma.c:1797 __fput+0x169/0x540 fs/file_table.c:280 task_work_run+0xb7/0x100 kernel/task_work.c:140 exit_task_work include/linux/task_work.h:30 [inline] do_exit+0x7da/0x17f0 kernel/exit.c:825 do_group_exit+0x9e/0x190 kernel/exit.c:922 __do_sys_exit_group kernel/exit.c:933 [inline] __se_sys_exit_group kernel/exit.c:931 [inline] __x64_sys_exit_group+0x2d/0x30 kernel/exit.c:931 do_syscall_64+0x2d/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 255d0c1 ("RDMA/cma: rdma_bind_addr() leaks a cma_dev reference count") Link: https://lore.kernel.org/r/3352ee288fe34f2b44220457a29bfc0548686363.1620711734.git.leonro@nvidia.com Signed-off-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>

[ Upstream commit 889d916 ] restrack should only be attached to a cm_id while the ID has a valid device pointer. It is set up when the device is first loaded, but not cleared when the device is removed. There is also two copies of the device pointer, one private and one in the public API, and these were left out of sync. Make everything go to NULL together and manipulate restrack right around the device assignments. Found by syzcaller: BUG: KASAN: wild-memory-access in __list_del include/linux/list.h:112 [inline] BUG: KASAN: wild-memory-access in __list_del_entry include/linux/list.h:135 [inline] BUG: KASAN: wild-memory-access in list_del include/linux/list.h:146 [inline] BUG: KASAN: wild-memory-access in cma_cancel_listens drivers/infiniband/core/cma.c:1767 [inline] BUG: KASAN: wild-memory-access in cma_cancel_operation drivers/infiniband/core/cma.c:1795 [inline] BUG: KASAN: wild-memory-access in cma_cancel_operation+0x1f4/0x4b0 drivers/infiniband/core/cma.c:1783 Write of size 8 at addr dead000000000108 by task syz-executor716/334 CPU: 0 PID: 334 Comm: syz-executor716 Not tainted 5.11.0+ torvalds#271 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0xbe/0xf9 lib/dump_stack.c:120 __kasan_report mm/kasan/report.c:400 [inline] kasan_report.cold+0x5f/0xd5 mm/kasan/report.c:413 __list_del include/linux/list.h:112 [inline] __list_del_entry include/linux/list.h:135 [inline] list_del include/linux/list.h:146 [inline] cma_cancel_listens drivers/infiniband/core/cma.c:1767 [inline] cma_cancel_operation drivers/infiniband/core/cma.c:1795 [inline] cma_cancel_operation+0x1f4/0x4b0 drivers/infiniband/core/cma.c:1783 _destroy_id+0x29/0x460 drivers/infiniband/core/cma.c:1862 ucma_close_id+0x36/0x50 drivers/infiniband/core/ucma.c:185 ucma_destroy_private_ctx+0x58d/0x5b0 drivers/infiniband/core/ucma.c:576 ucma_close+0x91/0xd0 drivers/infiniband/core/ucma.c:1797 __fput+0x169/0x540 fs/file_table.c:280 task_work_run+0xb7/0x100 kernel/task_work.c:140 exit_task_work include/linux/task_work.h:30 [inline] do_exit+0x7da/0x17f0 kernel/exit.c:825 do_group_exit+0x9e/0x190 kernel/exit.c:922 __do_sys_exit_group kernel/exit.c:933 [inline] __se_sys_exit_group kernel/exit.c:931 [inline] __x64_sys_exit_group+0x2d/0x30 kernel/exit.c:931 do_syscall_64+0x2d/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 255d0c1 ("RDMA/cma: rdma_bind_addr() leaks a cma_dev reference count") Link: https://lore.kernel.org/r/3352ee288fe34f2b44220457a29bfc0548686363.1620711734.git.leonro@nvidia.com Signed-off-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>

…CKOPT Add verifier ctx test to call bpf_get_netns_cookie from cgroup/setsockopt. torvalds#269/p pass ctx or null check, 1: ctx Did not run the program (not supported) OK torvalds#270/p pass ctx or null check, 2: null Did not run the program (not supported) OK torvalds#271/p pass ctx or null check, 3: 1 OK torvalds#272/p pass ctx or null check, 4: ctx - const OK torvalds#273/p pass ctx or null check, 5: null (connect) Did not run the program (not supported) OK torvalds#274/p pass ctx or null check, 6: null (bind) Did not run the program (not supported) OK torvalds#275/p pass ctx or null check, 7: ctx (bind) Did not run the program (not supported) OK torvalds#276/p pass ctx or null check, 8: null (bind) OK torvalds#277/p pass ctx or null check, 9: ctx (cgroup/setsockopt) Did not run the program (not supported) OK torvalds#278/p pass ctx or null check, 10: null (cgroup/setsockopt) Did not run the program (not supported) OK Signed-off-by: Stanislav Fomichev <sdf@google.com>

WARNING: please, no spaces at the start of a line torvalds#249: FILE: mm/page-writeback.c:2089: + {$ ERROR: code indent should use tabs where possible torvalds#250: FILE: mm/page-writeback.c:2090: + .procname = "dirty_background_ratio",$ WARNING: please, no spaces at the start of a line torvalds#250: FILE: mm/page-writeback.c:2090: + .procname = "dirty_background_ratio",$ ERROR: code indent should use tabs where possible torvalds#251: FILE: mm/page-writeback.c:2091: + .data = &dirty_background_ratio,$ WARNING: please, no spaces at the start of a line torvalds#251: FILE: mm/page-writeback.c:2091: + .data = &dirty_background_ratio,$ ERROR: code indent should use tabs where possible torvalds#252: FILE: mm/page-writeback.c:2092: + .maxlen = sizeof(dirty_background_ratio),$ WARNING: please, no spaces at the start of a line torvalds#252: FILE: mm/page-writeback.c:2092: + .maxlen = sizeof(dirty_background_ratio),$ ERROR: code indent should use tabs where possible torvalds#253: FILE: mm/page-writeback.c:2093: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#253: FILE: mm/page-writeback.c:2093: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#254: FILE: mm/page-writeback.c:2094: + .proc_handler = dirty_background_ratio_handler,$ WARNING: please, no spaces at the start of a line torvalds#254: FILE: mm/page-writeback.c:2094: + .proc_handler = dirty_background_ratio_handler,$ ERROR: code indent should use tabs where possible torvalds#255: FILE: mm/page-writeback.c:2095: + .extra1 = SYSCTL_ZERO,$ WARNING: please, no spaces at the start of a line torvalds#255: FILE: mm/page-writeback.c:2095: + .extra1 = SYSCTL_ZERO,$ ERROR: code indent should use tabs where possible torvalds#256: FILE: mm/page-writeback.c:2096: + .extra2 = SYSCTL_ONE_HUNDRED,$ WARNING: please, no spaces at the start of a line torvalds#256: FILE: mm/page-writeback.c:2096: + .extra2 = SYSCTL_ONE_HUNDRED,$ WARNING: please, no spaces at the start of a line torvalds#257: FILE: mm/page-writeback.c:2097: + },$ WARNING: please, no spaces at the start of a line torvalds#258: FILE: mm/page-writeback.c:2098: + {$ ERROR: code indent should use tabs where possible torvalds#259: FILE: mm/page-writeback.c:2099: + .procname = "dirty_background_bytes",$ WARNING: please, no spaces at the start of a line torvalds#259: FILE: mm/page-writeback.c:2099: + .procname = "dirty_background_bytes",$ ERROR: code indent should use tabs where possible torvalds#260: FILE: mm/page-writeback.c:2100: + .data = &dirty_background_bytes,$ WARNING: please, no spaces at the start of a line torvalds#260: FILE: mm/page-writeback.c:2100: + .data = &dirty_background_bytes,$ ERROR: code indent should use tabs where possible torvalds#261: FILE: mm/page-writeback.c:2101: + .maxlen = sizeof(dirty_background_bytes),$ WARNING: please, no spaces at the start of a line torvalds#261: FILE: mm/page-writeback.c:2101: + .maxlen = sizeof(dirty_background_bytes),$ ERROR: code indent should use tabs where possible torvalds#262: FILE: mm/page-writeback.c:2102: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#262: FILE: mm/page-writeback.c:2102: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#263: FILE: mm/page-writeback.c:2103: + .proc_handler = dirty_background_bytes_handler,$ WARNING: please, no spaces at the start of a line torvalds#263: FILE: mm/page-writeback.c:2103: + .proc_handler = dirty_background_bytes_handler,$ ERROR: code indent should use tabs where possible torvalds#264: FILE: mm/page-writeback.c:2104: + .extra1 = SYSCTL_LONG_ONE,$ WARNING: please, no spaces at the start of a line torvalds#264: FILE: mm/page-writeback.c:2104: + .extra1 = SYSCTL_LONG_ONE,$ WARNING: please, no spaces at the start of a line torvalds#265: FILE: mm/page-writeback.c:2105: + },$ WARNING: please, no spaces at the start of a line torvalds#266: FILE: mm/page-writeback.c:2106: + {$ ERROR: code indent should use tabs where possible torvalds#267: FILE: mm/page-writeback.c:2107: + .procname = "dirty_ratio",$ WARNING: please, no spaces at the start of a line torvalds#267: FILE: mm/page-writeback.c:2107: + .procname = "dirty_ratio",$ ERROR: code indent should use tabs where possible torvalds#268: FILE: mm/page-writeback.c:2108: + .data = &vm_dirty_ratio,$ WARNING: please, no spaces at the start of a line torvalds#268: FILE: mm/page-writeback.c:2108: + .data = &vm_dirty_ratio,$ ERROR: code indent should use tabs where possible torvalds#269: FILE: mm/page-writeback.c:2109: + .maxlen = sizeof(vm_dirty_ratio),$ WARNING: please, no spaces at the start of a line torvalds#269: FILE: mm/page-writeback.c:2109: + .maxlen = sizeof(vm_dirty_ratio),$ ERROR: code indent should use tabs where possible torvalds#270: FILE: mm/page-writeback.c:2110: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#270: FILE: mm/page-writeback.c:2110: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#271: FILE: mm/page-writeback.c:2111: + .proc_handler = dirty_ratio_handler,$ WARNING: please, no spaces at the start of a line torvalds#271: FILE: mm/page-writeback.c:2111: + .proc_handler = dirty_ratio_handler,$ ERROR: code indent should use tabs where possible torvalds#272: FILE: mm/page-writeback.c:2112: + .extra1 = SYSCTL_ZERO,$ WARNING: please, no spaces at the start of a line torvalds#272: FILE: mm/page-writeback.c:2112: + .extra1 = SYSCTL_ZERO,$ ERROR: code indent should use tabs where possible torvalds#273: FILE: mm/page-writeback.c:2113: + .extra2 = SYSCTL_ONE_HUNDRED,$ WARNING: please, no spaces at the start of a line torvalds#273: FILE: mm/page-writeback.c:2113: + .extra2 = SYSCTL_ONE_HUNDRED,$ WARNING: please, no spaces at the start of a line torvalds#274: FILE: mm/page-writeback.c:2114: + },$ WARNING: please, no spaces at the start of a line torvalds#275: FILE: mm/page-writeback.c:2115: + {$ ERROR: code indent should use tabs where possible torvalds#276: FILE: mm/page-writeback.c:2116: + .procname = "dirty_bytes",$ WARNING: please, no spaces at the start of a line torvalds#276: FILE: mm/page-writeback.c:2116: + .procname = "dirty_bytes",$ ERROR: code indent should use tabs where possible torvalds#277: FILE: mm/page-writeback.c:2117: + .data = &vm_dirty_bytes,$ WARNING: please, no spaces at the start of a line torvalds#277: FILE: mm/page-writeback.c:2117: + .data = &vm_dirty_bytes,$ ERROR: code indent should use tabs where possible torvalds#278: FILE: mm/page-writeback.c:2118: + .maxlen = sizeof(vm_dirty_bytes),$ WARNING: please, no spaces at the start of a line torvalds#278: FILE: mm/page-writeback.c:2118: + .maxlen = sizeof(vm_dirty_bytes),$ ERROR: code indent should use tabs where possible torvalds#279: FILE: mm/page-writeback.c:2119: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#279: FILE: mm/page-writeback.c:2119: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#280: FILE: mm/page-writeback.c:2120: + .proc_handler = dirty_bytes_handler,$ WARNING: please, no spaces at the start of a line torvalds#280: FILE: mm/page-writeback.c:2120: + .proc_handler = dirty_bytes_handler,$ ERROR: code indent should use tabs where possible torvalds#281: FILE: mm/page-writeback.c:2121: + .extra1 = (void *)&dirty_bytes_min,$ WARNING: please, no spaces at the start of a line torvalds#281: FILE: mm/page-writeback.c:2121: + .extra1 = (void *)&dirty_bytes_min,$ WARNING: please, no spaces at the start of a line torvalds#282: FILE: mm/page-writeback.c:2122: + },$ WARNING: please, no spaces at the start of a line torvalds#283: FILE: mm/page-writeback.c:2123: + {$ ERROR: code indent should use tabs where possible torvalds#284: FILE: mm/page-writeback.c:2124: + .procname = "dirty_writeback_centisecs",$ WARNING: please, no spaces at the start of a line torvalds#284: FILE: mm/page-writeback.c:2124: + .procname = "dirty_writeback_centisecs",$ ERROR: code indent should use tabs where possible torvalds#285: FILE: mm/page-writeback.c:2125: + .data = &dirty_writeback_interval,$ WARNING: please, no spaces at the start of a line torvalds#285: FILE: mm/page-writeback.c:2125: + .data = &dirty_writeback_interval,$ ERROR: code indent should use tabs where possible torvalds#286: FILE: mm/page-writeback.c:2126: + .maxlen = sizeof(dirty_writeback_interval),$ WARNING: please, no spaces at the start of a line torvalds#286: FILE: mm/page-writeback.c:2126: + .maxlen = sizeof(dirty_writeback_interval),$ ERROR: code indent should use tabs where possible torvalds#287: FILE: mm/page-writeback.c:2127: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#287: FILE: mm/page-writeback.c:2127: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#288: FILE: mm/page-writeback.c:2128: + .proc_handler = dirty_writeback_centisecs_handler,$ WARNING: please, no spaces at the start of a line torvalds#288: FILE: mm/page-writeback.c:2128: + .proc_handler = dirty_writeback_centisecs_handler,$ WARNING: please, no spaces at the start of a line torvalds#289: FILE: mm/page-writeback.c:2129: + },$ WARNING: please, no spaces at the start of a line torvalds#290: FILE: mm/page-writeback.c:2130: + {$ ERROR: code indent should use tabs where possible torvalds#291: FILE: mm/page-writeback.c:2131: + .procname = "dirty_expire_centisecs",$ WARNING: please, no spaces at the start of a line torvalds#291: FILE: mm/page-writeback.c:2131: + .procname = "dirty_expire_centisecs",$ ERROR: code indent should use tabs where possible torvalds#292: FILE: mm/page-writeback.c:2132: + .data = &dirty_expire_interval,$ WARNING: please, no spaces at the start of a line torvalds#292: FILE: mm/page-writeback.c:2132: + .data = &dirty_expire_interval,$ ERROR: code indent should use tabs where possible torvalds#293: FILE: mm/page-writeback.c:2133: + .maxlen = sizeof(dirty_expire_interval),$ WARNING: please, no spaces at the start of a line torvalds#293: FILE: mm/page-writeback.c:2133: + .maxlen = sizeof(dirty_expire_interval),$ ERROR: code indent should use tabs where possible torvalds#294: FILE: mm/page-writeback.c:2134: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#294: FILE: mm/page-writeback.c:2134: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#295: FILE: mm/page-writeback.c:2135: + .proc_handler = proc_dointvec_minmax,$ WARNING: please, no spaces at the start of a line torvalds#295: FILE: mm/page-writeback.c:2135: + .proc_handler = proc_dointvec_minmax,$ ERROR: code indent should use tabs where possible torvalds#296: FILE: mm/page-writeback.c:2136: + .extra1 = SYSCTL_ZERO,$ WARNING: please, no spaces at the start of a line torvalds#296: FILE: mm/page-writeback.c:2136: + .extra1 = SYSCTL_ZERO,$ WARNING: please, no spaces at the start of a line torvalds#297: FILE: mm/page-writeback.c:2137: + },$ total: 37 errors, 49 warnings, 287 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. NOTE: Whitespace errors detected. You may wish to use scripts/cleanpatch or scripts/cleanfile ./patches/mm-move-page-writeback-sysctls-to-is-own-file.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Iurii Zaikin <yzaikin@google.com> Cc: Kees Cook <keescook@chromium.org> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: zhanglianjie <zhanglianjie@uniontech.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

WARNING: please, no spaces at the start of a line torvalds#249: FILE: mm/page-writeback.c:2089: + {$ ERROR: code indent should use tabs where possible torvalds#250: FILE: mm/page-writeback.c:2090: + .procname = "dirty_background_ratio",$ WARNING: please, no spaces at the start of a line torvalds#250: FILE: mm/page-writeback.c:2090: + .procname = "dirty_background_ratio",$ ERROR: code indent should use tabs where possible torvalds#251: FILE: mm/page-writeback.c:2091: + .data = &dirty_background_ratio,$ WARNING: please, no spaces at the start of a line torvalds#251: FILE: mm/page-writeback.c:2091: + .data = &dirty_background_ratio,$ ERROR: code indent should use tabs where possible torvalds#252: FILE: mm/page-writeback.c:2092: + .maxlen = sizeof(dirty_background_ratio),$ WARNING: please, no spaces at the start of a line torvalds#252: FILE: mm/page-writeback.c:2092: + .maxlen = sizeof(dirty_background_ratio),$ ERROR: code indent should use tabs where possible torvalds#253: FILE: mm/page-writeback.c:2093: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#253: FILE: mm/page-writeback.c:2093: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#254: FILE: mm/page-writeback.c:2094: + .proc_handler = dirty_background_ratio_handler,$ WARNING: please, no spaces at the start of a line torvalds#254: FILE: mm/page-writeback.c:2094: + .proc_handler = dirty_background_ratio_handler,$ ERROR: code indent should use tabs where possible torvalds#255: FILE: mm/page-writeback.c:2095: + .extra1 = SYSCTL_ZERO,$ WARNING: please, no spaces at the start of a line torvalds#255: FILE: mm/page-writeback.c:2095: + .extra1 = SYSCTL_ZERO,$ ERROR: code indent should use tabs where possible torvalds#256: FILE: mm/page-writeback.c:2096: + .extra2 = SYSCTL_ONE_HUNDRED,$ WARNING: please, no spaces at the start of a line torvalds#256: FILE: mm/page-writeback.c:2096: + .extra2 = SYSCTL_ONE_HUNDRED,$ WARNING: please, no spaces at the start of a line torvalds#257: FILE: mm/page-writeback.c:2097: + },$ WARNING: please, no spaces at the start of a line torvalds#258: FILE: mm/page-writeback.c:2098: + {$ ERROR: code indent should use tabs where possible torvalds#259: FILE: mm/page-writeback.c:2099: + .procname = "dirty_background_bytes",$ WARNING: please, no spaces at the start of a line torvalds#259: FILE: mm/page-writeback.c:2099: + .procname = "dirty_background_bytes",$ ERROR: code indent should use tabs where possible torvalds#260: FILE: mm/page-writeback.c:2100: + .data = &dirty_background_bytes,$ WARNING: please, no spaces at the start of a line torvalds#260: FILE: mm/page-writeback.c:2100: + .data = &dirty_background_bytes,$ ERROR: code indent should use tabs where possible torvalds#261: FILE: mm/page-writeback.c:2101: + .maxlen = sizeof(dirty_background_bytes),$ WARNING: please, no spaces at the start of a line torvalds#261: FILE: mm/page-writeback.c:2101: + .maxlen = sizeof(dirty_background_bytes),$ ERROR: code indent should use tabs where possible torvalds#262: FILE: mm/page-writeback.c:2102: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#262: FILE: mm/page-writeback.c:2102: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#263: FILE: mm/page-writeback.c:2103: + .proc_handler = dirty_background_bytes_handler,$ WARNING: please, no spaces at the start of a line torvalds#263: FILE: mm/page-writeback.c:2103: + .proc_handler = dirty_background_bytes_handler,$ ERROR: code indent should use tabs where possible torvalds#264: FILE: mm/page-writeback.c:2104: + .extra1 = SYSCTL_LONG_ONE,$ WARNING: please, no spaces at the start of a line torvalds#264: FILE: mm/page-writeback.c:2104: + .extra1 = SYSCTL_LONG_ONE,$ WARNING: please, no spaces at the start of a line torvalds#265: FILE: mm/page-writeback.c:2105: + },$ WARNING: please, no spaces at the start of a line torvalds#266: FILE: mm/page-writeback.c:2106: + {$ ERROR: code indent should use tabs where possible torvalds#267: FILE: mm/page-writeback.c:2107: + .procname = "dirty_ratio",$ WARNING: please, no spaces at the start of a line torvalds#267: FILE: mm/page-writeback.c:2107: + .procname = "dirty_ratio",$ ERROR: code indent should use tabs where possible torvalds#268: FILE: mm/page-writeback.c:2108: + .data = &vm_dirty_ratio,$ WARNING: please, no spaces at the start of a line torvalds#268: FILE: mm/page-writeback.c:2108: + .data = &vm_dirty_ratio,$ ERROR: code indent should use tabs where possible torvalds#269: FILE: mm/page-writeback.c:2109: + .maxlen = sizeof(vm_dirty_ratio),$ WARNING: please, no spaces at the start of a line torvalds#269: FILE: mm/page-writeback.c:2109: + .maxlen = sizeof(vm_dirty_ratio),$ ERROR: code indent should use tabs where possible torvalds#270: FILE: mm/page-writeback.c:2110: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#270: FILE: mm/page-writeback.c:2110: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#271: FILE: mm/page-writeback.c:2111: + .proc_handler = dirty_ratio_handler,$ WARNING: please, no spaces at the start of a line torvalds#271: FILE: mm/page-writeback.c:2111: + .proc_handler = dirty_ratio_handler,$ ERROR: code indent should use tabs where possible torvalds#272: FILE: mm/page-writeback.c:2112: + .extra1 = SYSCTL_ZERO,$ WARNING: please, no spaces at the start of a line torvalds#272: FILE: mm/page-writeback.c:2112: + .extra1 = SYSCTL_ZERO,$ ERROR: code indent should use tabs where possible torvalds#273: FILE: mm/page-writeback.c:2113: + .extra2 = SYSCTL_ONE_HUNDRED,$ WARNING: please, no spaces at the start of a line torvalds#273: FILE: mm/page-writeback.c:2113: + .extra2 = SYSCTL_ONE_HUNDRED,$ WARNING: please, no spaces at the start of a line torvalds#274: FILE: mm/page-writeback.c:2114: + },$ WARNING: please, no spaces at the start of a line torvalds#275: FILE: mm/page-writeback.c:2115: + {$ ERROR: code indent should use tabs where possible torvalds#276: FILE: mm/page-writeback.c:2116: + .procname = "dirty_bytes",$ WARNING: please, no spaces at the start of a line torvalds#276: FILE: mm/page-writeback.c:2116: + .procname = "dirty_bytes",$ ERROR: code indent should use tabs where possible torvalds#277: FILE: mm/page-writeback.c:2117: + .data = &vm_dirty_bytes,$ WARNING: please, no spaces at the start of a line torvalds#277: FILE: mm/page-writeback.c:2117: + .data = &vm_dirty_bytes,$ ERROR: code indent should use tabs where possible torvalds#278: FILE: mm/page-writeback.c:2118: + .maxlen = sizeof(vm_dirty_bytes),$ WARNING: please, no spaces at the start of a line torvalds#278: FILE: mm/page-writeback.c:2118: + .maxlen = sizeof(vm_dirty_bytes),$ ERROR: code indent should use tabs where possible torvalds#279: FILE: mm/page-writeback.c:2119: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#279: FILE: mm/page-writeback.c:2119: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#280: FILE: mm/page-writeback.c:2120: + .proc_handler = dirty_bytes_handler,$ WARNING: please, no spaces at the start of a line torvalds#280: FILE: mm/page-writeback.c:2120: + .proc_handler = dirty_bytes_handler,$ ERROR: code indent should use tabs where possible torvalds#281: FILE: mm/page-writeback.c:2121: + .extra1 = (void *)&dirty_bytes_min,$ WARNING: please, no spaces at the start of a line torvalds#281: FILE: mm/page-writeback.c:2121: + .extra1 = (void *)&dirty_bytes_min,$ WARNING: please, no spaces at the start of a line torvalds#282: FILE: mm/page-writeback.c:2122: + },$ WARNING: please, no spaces at the start of a line torvalds#283: FILE: mm/page-writeback.c:2123: + {$ ERROR: code indent should use tabs where possible torvalds#284: FILE: mm/page-writeback.c:2124: + .procname = "dirty_writeback_centisecs",$ WARNING: please, no spaces at the start of a line torvalds#284: FILE: mm/page-writeback.c:2124: + .procname = "dirty_writeback_centisecs",$ ERROR: code indent should use tabs where possible torvalds#285: FILE: mm/page-writeback.c:2125: + .data = &dirty_writeback_interval,$ WARNING: please, no spaces at the start of a line torvalds#285: FILE: mm/page-writeback.c:2125: + .data = &dirty_writeback_interval,$ ERROR: code indent should use tabs where possible torvalds#286: FILE: mm/page-writeback.c:2126: + .maxlen = sizeof(dirty_writeback_interval),$ WARNING: please, no spaces at the start of a line torvalds#286: FILE: mm/page-writeback.c:2126: + .maxlen = sizeof(dirty_writeback_interval),$ ERROR: code indent should use tabs where possible torvalds#287: FILE: mm/page-writeback.c:2127: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#287: FILE: mm/page-writeback.c:2127: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#288: FILE: mm/page-writeback.c:2128: + .proc_handler = dirty_writeback_centisecs_handler,$ WARNING: please, no spaces at the start of a line torvalds#288: FILE: mm/page-writeback.c:2128: + .proc_handler = dirty_writeback_centisecs_handler,$ WARNING: please, no spaces at the start of a line torvalds#289: FILE: mm/page-writeback.c:2129: + },$ WARNING: please, no spaces at the start of a line torvalds#290: FILE: mm/page-writeback.c:2130: + {$ ERROR: code indent should use tabs where possible torvalds#291: FILE: mm/page-writeback.c:2131: + .procname = "dirty_expire_centisecs",$ WARNING: please, no spaces at the start of a line torvalds#291: FILE: mm/page-writeback.c:2131: + .procname = "dirty_expire_centisecs",$ ERROR: code indent should use tabs where possible torvalds#292: FILE: mm/page-writeback.c:2132: + .data = &dirty_expire_interval,$ WARNING: please, no spaces at the start of a line torvalds#292: FILE: mm/page-writeback.c:2132: + .data = &dirty_expire_interval,$ ERROR: code indent should use tabs where possible torvalds#293: FILE: mm/page-writeback.c:2133: + .maxlen = sizeof(dirty_expire_interval),$ WARNING: please, no spaces at the start of a line torvalds#293: FILE: mm/page-writeback.c:2133: + .maxlen = sizeof(dirty_expire_interval),$ ERROR: code indent should use tabs where possible torvalds#294: FILE: mm/page-writeback.c:2134: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#294: FILE: mm/page-writeback.c:2134: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#295: FILE: mm/page-writeback.c:2135: + .proc_handler = proc_dointvec_minmax,$ WARNING: please, no spaces at the start of a line torvalds#295: FILE: mm/page-writeback.c:2135: + .proc_handler = proc_dointvec_minmax,$ ERROR: code indent should use tabs where possible torvalds#296: FILE: mm/page-writeback.c:2136: + .extra1 = SYSCTL_ZERO,$ WARNING: please, no spaces at the start of a line torvalds#296: FILE: mm/page-writeback.c:2136: + .extra1 = SYSCTL_ZERO,$ WARNING: please, no spaces at the start of a line torvalds#297: FILE: mm/page-writeback.c:2137: + },$ total: 37 errors, 49 warnings, 287 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. NOTE: Whitespace errors detected. You may wish to use scripts/cleanpatch or scripts/cleanfile ./patches/mm-move-page-writeback-sysctls-to-is-own-file.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Iurii Zaikin <yzaikin@google.com> Cc: Kees Cook <keescook@chromium.org> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: zhanglianjie <zhanglianjie@uniontech.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Mark Brown <broonie@kernel.org>

ANBZ: torvalds#271 As group identity modified some logics of the mainline, the performence will degrade if the task is not in mixed deployment scenario. In order to avoid unnecessary overhead, group identity will be disabled by default. Signed-off-by: Cruz Zhao <CruzZhao@linux.alibaba.com> Reviewed-by: Shile Zhang <shile.zhang@linux.alibaba.com> Acked-by: Michael Wang <yun.wang@linux.alibaba.com>

./test_progs -t tc_opts [ 1.406778] tsc: Refined TSC clocksource calibration: 3407.990 MHz [ 1.408863] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x311fcaf6eb0, max_idle_ns: 440795321766 ns [ 1.412419] clocksource: Switched to clocksource tsc [ 1.428671] bpf_testmod: loading out-of-tree module taints kernel. [ 1.430260] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel torvalds#252 tc_opts_after:OK torvalds#253 tc_opts_append:OK torvalds#254 tc_opts_basic:OK torvalds#255 tc_opts_before:OK torvalds#256 tc_opts_chain_classic:OK torvalds#257 tc_opts_chain_mixed:OK torvalds#258 tc_opts_delete_empty:OK torvalds#259 tc_opts_demixed:OK torvalds#260 tc_opts_detach:OK torvalds#261 tc_opts_detach_after:OK torvalds#262 tc_opts_detach_before:OK torvalds#263 tc_opts_dev_cleanup:OK torvalds#264 tc_opts_invalid:OK torvalds#265 tc_opts_max:OK torvalds#266 tc_opts_mixed:OK torvalds#267 tc_opts_prepend:OK torvalds#268 tc_opts_query:OK torvalds#269 tc_opts_query_attach:OK torvalds#270 tc_opts_replace:OK torvalds#271 tc_opts_revision:OK Summary: 20/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

./test_progs -t tc_opts [ 1.406778] tsc: Refined TSC clocksource calibration: 3407.990 MHz [ 1.408863] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x311fcaf6eb0, max_idle_ns: 440795321766 ns [ 1.412419] clocksource: Switched to clocksource tsc [ 1.428671] bpf_testmod: loading out-of-tree module taints kernel. [ 1.430260] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel torvalds#252 tc_opts_after:OK torvalds#253 tc_opts_append:OK torvalds#254 tc_opts_basic:OK torvalds#255 tc_opts_before:OK torvalds#256 tc_opts_chain_classic:OK torvalds#257 tc_opts_chain_mixed:OK torvalds#258 tc_opts_delete_empty:OK torvalds#259 tc_opts_demixed:OK torvalds#260 tc_opts_detach:OK torvalds#261 tc_opts_detach_after:OK torvalds#262 tc_opts_detach_before:OK torvalds#263 tc_opts_dev_cleanup:OK torvalds#264 tc_opts_invalid:OK torvalds#265 tc_opts_max:OK torvalds#266 tc_opts_mixed:OK torvalds#267 tc_opts_prepend:OK torvalds#268 tc_opts_query:OK torvalds#269 tc_opts_query_attach:OK <--- (new test) torvalds#270 tc_opts_replace:OK torvalds#271 tc_opts_revision:OK Summary: 20/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

Add a new test case to query on an empty bpf_mprog and pass the revision directly into exprected_revision for attachment to assert that this does succeed. ./test_progs -t tc_opts [ 1.406778] tsc: Refined TSC clocksource calibration: 3407.990 MHz [ 1.408863] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x311fcaf6eb0, max_idle_ns: 440795321766 ns [ 1.412419] clocksource: Switched to clocksource tsc [ 1.428671] bpf_testmod: loading out-of-tree module taints kernel. [ 1.430260] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel torvalds#252 tc_opts_after:OK torvalds#253 tc_opts_append:OK torvalds#254 tc_opts_basic:OK torvalds#255 tc_opts_before:OK torvalds#256 tc_opts_chain_classic:OK torvalds#257 tc_opts_chain_mixed:OK torvalds#258 tc_opts_delete_empty:OK torvalds#259 tc_opts_demixed:OK torvalds#260 tc_opts_detach:OK torvalds#261 tc_opts_detach_after:OK torvalds#262 tc_opts_detach_before:OK torvalds#263 tc_opts_dev_cleanup:OK torvalds#264 tc_opts_invalid:OK torvalds#265 tc_opts_max:OK torvalds#266 tc_opts_mixed:OK torvalds#267 tc_opts_prepend:OK torvalds#268 tc_opts_query:OK torvalds#269 tc_opts_query_attach:OK <--- (new test) torvalds#270 tc_opts_replace:OK torvalds#271 tc_opts_revision:OK Summary: 20/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

Add a new test case to query on an empty bpf_mprog and pass the revision directly into expected_revision for attachment to assert that this does succeed. ./test_progs -t tc_opts [ 1.406778] tsc: Refined TSC clocksource calibration: 3407.990 MHz [ 1.408863] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x311fcaf6eb0, max_idle_ns: 440795321766 ns [ 1.412419] clocksource: Switched to clocksource tsc [ 1.428671] bpf_testmod: loading out-of-tree module taints kernel. [ 1.430260] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel torvalds#252 tc_opts_after:OK torvalds#253 tc_opts_append:OK torvalds#254 tc_opts_basic:OK torvalds#255 tc_opts_before:OK torvalds#256 tc_opts_chain_classic:OK torvalds#257 tc_opts_chain_mixed:OK torvalds#258 tc_opts_delete_empty:OK torvalds#259 tc_opts_demixed:OK torvalds#260 tc_opts_detach:OK torvalds#261 tc_opts_detach_after:OK torvalds#262 tc_opts_detach_before:OK torvalds#263 tc_opts_dev_cleanup:OK torvalds#264 tc_opts_invalid:OK torvalds#265 tc_opts_max:OK torvalds#266 tc_opts_mixed:OK torvalds#267 tc_opts_prepend:OK torvalds#268 tc_opts_query:OK torvalds#269 tc_opts_query_attach:OK <--- (new test) torvalds#270 tc_opts_replace:OK torvalds#271 tc_opts_revision:OK Summary: 20/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

Add a new test case to query on an empty bpf_mprog and pass the revision directly into expected_revision for attachment to assert that this does succeed. ./test_progs -t tc_opts [ 1.406778] tsc: Refined TSC clocksource calibration: 3407.990 MHz [ 1.408863] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x311fcaf6eb0, max_idle_ns: 440795321766 ns [ 1.412419] clocksource: Switched to clocksource tsc [ 1.428671] bpf_testmod: loading out-of-tree module taints kernel. [ 1.430260] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel torvalds#252 tc_opts_after:OK torvalds#253 tc_opts_append:OK torvalds#254 tc_opts_basic:OK torvalds#255 tc_opts_before:OK torvalds#256 tc_opts_chain_classic:OK torvalds#257 tc_opts_chain_mixed:OK torvalds#258 tc_opts_delete_empty:OK torvalds#259 tc_opts_demixed:OK torvalds#260 tc_opts_detach:OK torvalds#261 tc_opts_detach_after:OK torvalds#262 tc_opts_detach_before:OK torvalds#263 tc_opts_dev_cleanup:OK torvalds#264 tc_opts_invalid:OK torvalds#265 tc_opts_max:OK torvalds#266 tc_opts_mixed:OK torvalds#267 tc_opts_prepend:OK torvalds#268 tc_opts_query:OK torvalds#269 tc_opts_query_attach:OK <--- (new test) torvalds#270 tc_opts_replace:OK torvalds#271 tc_opts_revision:OK Summary: 20/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/r/20231006220655.1653-6-daniel@iogearbox.net Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>

Add several new test cases which assert corner cases on the mprog query mechanism, for example, around passing in a too small or a larger array than the current count. ./test_progs -t tc_opts torvalds#252 tc_opts_after:OK torvalds#253 tc_opts_append:OK torvalds#254 tc_opts_basic:OK torvalds#255 tc_opts_before:OK torvalds#256 tc_opts_chain_classic:OK torvalds#257 tc_opts_chain_mixed:OK torvalds#258 tc_opts_delete_empty:OK torvalds#259 tc_opts_demixed:OK torvalds#260 tc_opts_detach:OK torvalds#261 tc_opts_detach_after:OK torvalds#262 tc_opts_detach_before:OK torvalds#263 tc_opts_dev_cleanup:OK torvalds#264 tc_opts_invalid:OK torvalds#265 tc_opts_max:OK torvalds#266 tc_opts_mixed:OK torvalds#267 tc_opts_prepend:OK torvalds#268 tc_opts_query:OK torvalds#269 tc_opts_query_attach:OK torvalds#270 tc_opts_replace:OK torvalds#271 tc_opts_revision:OK Summary: 20/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

Add a new test case to query on an empty bpf_mprog and pass the revision directly into expected_revision for attachment to assert that this does succeed. ./test_progs -t tc_opts [ 1.406778] tsc: Refined TSC clocksource calibration: 3407.990 MHz [ 1.408863] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x311fcaf6eb0, max_idle_ns: 440795321766 ns [ 1.412419] clocksource: Switched to clocksource tsc [ 1.428671] bpf_testmod: loading out-of-tree module taints kernel. [ 1.430260] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel torvalds#252 tc_opts_after:OK torvalds#253 tc_opts_append:OK torvalds#254 tc_opts_basic:OK torvalds#255 tc_opts_before:OK torvalds#256 tc_opts_chain_classic:OK torvalds#257 tc_opts_chain_mixed:OK torvalds#258 tc_opts_delete_empty:OK torvalds#259 tc_opts_demixed:OK torvalds#260 tc_opts_detach:OK torvalds#261 tc_opts_detach_after:OK torvalds#262 tc_opts_detach_before:OK torvalds#263 tc_opts_dev_cleanup:OK torvalds#264 tc_opts_invalid:OK torvalds#265 tc_opts_max:OK torvalds#266 tc_opts_mixed:OK torvalds#267 tc_opts_prepend:OK torvalds#268 tc_opts_query:OK torvalds#269 tc_opts_query_attach:OK <--- (new test) torvalds#270 tc_opts_replace:OK torvalds#271 tc_opts_revision:OK Summary: 20/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/r/20231006220655.1653-6-daniel@iogearbox.net Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>

Add several new test cases which assert corner cases on the mprog query mechanism, for example, around passing in a too small or a larger array than the current count. ./test_progs -t tc_opts torvalds#252 tc_opts_after:OK torvalds#253 tc_opts_append:OK torvalds#254 tc_opts_basic:OK torvalds#255 tc_opts_before:OK torvalds#256 tc_opts_chain_classic:OK torvalds#257 tc_opts_chain_mixed:OK torvalds#258 tc_opts_delete_empty:OK torvalds#259 tc_opts_demixed:OK torvalds#260 tc_opts_detach:OK torvalds#261 tc_opts_detach_after:OK torvalds#262 tc_opts_detach_before:OK torvalds#263 tc_opts_dev_cleanup:OK torvalds#264 tc_opts_invalid:OK torvalds#265 tc_opts_max:OK torvalds#266 tc_opts_mixed:OK torvalds#267 tc_opts_prepend:OK torvalds#268 tc_opts_query:OK torvalds#269 tc_opts_query_attach:OK torvalds#270 tc_opts_replace:OK torvalds#271 tc_opts_revision:OK Summary: 20/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

Add several new test cases which assert corner cases on the mprog query mechanism, for example, around passing in a too small or a larger array than the current count. ./test_progs -t tc_opts torvalds#252 tc_opts_after:OK torvalds#253 tc_opts_append:OK torvalds#254 tc_opts_basic:OK torvalds#255 tc_opts_before:OK torvalds#256 tc_opts_chain_classic:OK torvalds#257 tc_opts_chain_mixed:OK torvalds#258 tc_opts_delete_empty:OK torvalds#259 tc_opts_demixed:OK torvalds#260 tc_opts_detach:OK torvalds#261 tc_opts_detach_after:OK torvalds#262 tc_opts_detach_before:OK torvalds#263 tc_opts_dev_cleanup:OK torvalds#264 tc_opts_invalid:OK torvalds#265 tc_opts_max:OK torvalds#266 tc_opts_mixed:OK torvalds#267 tc_opts_prepend:OK torvalds#268 tc_opts_query:OK torvalds#269 tc_opts_query_attach:OK torvalds#270 tc_opts_replace:OK torvalds#271 tc_opts_revision:OK Summary: 20/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Alan Maguire <alan.maguire@oracle.com> Link: https://lore.kernel.org/bpf/20231017081728.24769-1-daniel@iogearbox.net

…kr4.1 (torvalds#271) Signed-off-by: Stephen Chen <stephen@radxa.com>

Added (0x1391, 0x2000) to IdealTec

a77ad3d

I got some *nix on my Ix104c3 tablet and tried to work around the touchscreen. And it works perfect =)

FireGrace closed this Apr 1, 2016

FireGrace deleted the patch-1 branch April 1, 2016 20:06

laijs pushed a commit to laijs/linux that referenced this pull request Feb 13, 2017

Merge pull request torvalds#271 from libos-nuse/fix-outtree-build

cd6db0d

lkl: build tools/lkl at out-of tree directory

plbossart mentioned this pull request Nov 9, 2018

Update kernel ABI to latest FW version thesofproject/linux#260

Merged

RadxaStephen added a commit to RadxaStephen/linux that referenced this pull request Mar 6, 2024

Merge branch 'vamrs-feng-linux-5.10-gen-rkr4.1' into linux-5.10-gen-r…

850ebe4

…kr4.1 (torvalds#271) Signed-off-by: Stephen Chen <stephen@radxa.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Added (0x1391, 0x2000) to IdealTec #271

Added (0x1391, 0x2000) to IdealTec #271

FireGrace commented Apr 1, 2016

Added (0x1391, 0x2000) to IdealTec #271

Added (0x1391, 0x2000) to IdealTec #271

Conversation

FireGrace commented Apr 1, 2016