simplified getting previous and next node in red-black tree for vmalloc #302

SemanShen · 2016-07-10T13:31:51Z

In the red-black tree, when looking for the insertion point for a new node, we can get the previous and next nodes to the new one, before color adjustment(rb_insert_color ). No need to retraverse the red-black tree again.

lenovouser · 2016-07-10T14:27:37Z

@SemanShen

This repo is mirror-only - nothing will be accepted here for legitimate reasons. Please see:

#17 (comment)

I don't do github pull requests.

github throws away all the relevant information, like having even a
valid email address for the person asking me to pull. The diffstat is
also deficient and useless.

Git comes with a nice pull-request generation module, but github
instead decided to replace it with their own totally inferior version.
As a result, I consider github useless for these kinds of things. It's
fine for hosting, but the pull requests and the online commit
editing, are just pure garbage.

I've told github people about my concerns, they didn't think they
mattered, so I gave up. Feel free to make a bugreport to github.

Linus

If we don't need to split the extent, also don't need to re-get the path for a logical block

…p list Calling gpiod_get() from a module and then unloading the module leads to an oops due to acpi_can_fallback_to_crs() storing the pointer to the passed 'con_id' string onto acpi_crs_lookup_list. The next guy to come along will then try to access the string but the memory may now be gone with the module. Make a copy of the passed string instead, and store the copy on the list. BUG: unable to handle kernel paging request at ffffffffa03e7855 IP: [<ffffffff81338322>] strcmp+0x12/0x30 PGD 2a07067 PUD 2a08063 PMD 74720067 PTE 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: i915(+) drm_kms_helper drm intel_gtt snd_hda_codec snd_hda_core i2c_algo_bit syscopya rea sysfillrect sysimgblt fb_sys_fops agpgart snd_soc_sst_bytcr_rt5640 coretemp hwmon intel_rapl intel_soc_dts_thermal punit_atom_debug snd_soc_rt5640 snd_soc_rl6231 serio snd_intel_sst_acpi snd_intel_sst_core video snd_soc_sst_mfld_platf orm snd_soc_sst_match backlight int3402_thermal processor_thermal_device int3403_thermal int3400_thermal acpi_thermal_r el snd_soc_core intel_soc_dts_iosf int340x_thermal_zone snd_compress i2c_hid hid snd_pcm snd_timer snd soundcore evdev sch_fq_codel efivarfs ipv6 autofs4 [last unloaded: drm] CPU: 2 PID: 3064 Comm: modprobe Tainted: G U W 4.6.0-rc3-ffrd-ipvr+ torvalds#302 Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLAKFF81.X64.0088.R10.1403240443 FFD8 _X64_R_2014_13_1_00 03/24/2014 task: ffff8800701cd200 ti: ffff880070034000 task.ti: ffff880070034000 RIP: 0010:[<ffffffff81338322>] [<ffffffff81338322>] strcmp+0x12/0x30 RSP: 0000:ffff880070037748 EFLAGS: 00010286 RAX: 0000000080000000 RBX: ffff88007a342800 RCX: 0000000000000006 RDX: 0000000000000006 RSI: ffffffffa054f856 RDI: ffffffffa03e7856 RBP: ffff880070037748 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa054f855 R13: ffff88007281cae0 R14: 0000000000000010 R15: ffffffffffffffea FS: 00007faa51447700(0000) GS:ffff880079300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffa03e7855 CR3: 0000000041eba000 CR4: 00000000001006e0 Stack: ffff880070037770 ffffffff8136ad28 ffffffffa054f855 0000000000000000 ffff88007a0a2098 ffff8800700377e8 ffffffff8136852e ffff88007a342800 00000007700377a0 ffff8800700377a0 ffffffff81412442 70672d6c656e6170 Call Trace: [<ffffffff8136ad28>] acpi_can_fallback_to_crs+0x88/0x100 [<ffffffff8136852e>] gpiod_get_index+0x25e/0x310 [<ffffffff81412442>] ? mipi_dsi_attach+0x22/0x30 [<ffffffff813685f2>] gpiod_get+0x12/0x20 [<ffffffffa04fcf41>] intel_dsi_init+0x421/0x480 [i915] [<ffffffffa04d3783>] intel_modeset_init+0x853/0x16b0 [i915] [<ffffffffa0504864>] ? intel_setup_gmbus+0x214/0x260 [i915] [<ffffffffa0510158>] i915_driver_load+0xdc8/0x19b0 [i915] [<ffffffff8160fb53>] ? _raw_spin_unlock_irqrestore+0x43/0x70 [<ffffffffa026b13b>] drm_dev_register+0xab/0xc0 [drm] [<ffffffffa026d7b3>] drm_get_pci_dev+0x93/0x1f0 [drm] [<ffffffff8160fb53>] ? _raw_spin_unlock_irqrestore+0x43/0x70 [<ffffffffa043f1f4>] i915_pci_probe+0x34/0x50 [i915] [<ffffffff81379751>] pci_device_probe+0x91/0x100 [<ffffffff8141a75a>] driver_probe_device+0x20a/0x2d0 [<ffffffff8141a8be>] __driver_attach+0x9e/0xb0 [<ffffffff8141a820>] ? driver_probe_device+0x2d0/0x2d0 [<ffffffff81418439>] bus_for_each_dev+0x69/0xa0 [<ffffffff8141a04e>] driver_attach+0x1e/0x20 [<ffffffff81419c20>] bus_add_driver+0x1c0/0x240 [<ffffffff8141b6d0>] driver_register+0x60/0xe0 [<ffffffff81377d20>] __pci_register_driver+0x60/0x70 [<ffffffffa026d9f4>] drm_pci_init+0xe4/0x110 [drm] [<ffffffff810ce04e>] ? trace_hardirqs_on+0xe/0x10 [<ffffffffa02f1000>] ? 0xffffffffa02f1000 [<ffffffffa02f1094>] i915_init+0x94/0x9b [i915] [<ffffffff810003bb>] do_one_initcall+0x8b/0x1c0 [<ffffffff810eb616>] ? rcu_read_lock_sched_held+0x86/0x90 [<ffffffff811de6d6>] ? kmem_cache_alloc_trace+0x1f6/0x270 [<ffffffff81183826>] do_init_module+0x60/0x1dc [<ffffffff81115a8d>] load_module+0x1d0d/0x2390 [<ffffffff811120b0>] ? __symbol_put+0x70/0x70 [<ffffffff811f41b2>] ? kernel_read_file+0x92/0x120 [<ffffffff811162f4>] SYSC_finit_module+0xa4/0xb0 [<ffffffff8111631e>] SyS_finit_module+0xe/0x10 [<ffffffff81001ff3>] do_syscall_64+0x63/0x350 [<ffffffff816103da>] entry_SYSCALL64_slow_path+0x25/0x25 Code: f7 48 8d 76 01 48 8d 52 01 0f b6 4e ff 84 c9 88 4a ff 75 ed 5d c3 0f 1f 00 55 48 89 e5 eb 04 84 c0 74 18 48 8d 7f 01 48 8d 76 01 <0f> b6 47 ff 3a 46 ff 74 eb 19 c0 83 c8 01 5d c3 31 c0 5d c3 66 RIP [<ffffffff81338322>] strcmp+0x12/0x30 RSP <ffff880070037748> CR2: ffffffffa03e7855 v2: Make the copied con_id const Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: stable@vger.kernel.org Fixes: 10cf489 ("gpiolib: tighten up ACPI legacy gpio lookups") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Patch series "x86, kasan: add KASAN checks to atomic operations". KASAN uses compiler instrumentation to intercept all memory accesses. But it does not see memory accesses done in assembly code. One notable user of assembly code is atomic operations. Frequently, for example, an atomic reference decrement is the last access to an object and a good candidate for a racy use-after-free. Atomic operations are defined in arch files, but KASAN instrumentation is required for several archs that support KASAN. Later we will need similar hooks for KMSAN (uninit use detector) and KTSAN (data race detector). This change introduces wrappers around atomic operations that can be used to add KASAN/KMSAN/KTSAN instrumentation across several archs, and adds KASAN checks to them. This patch uses the wrappers only for x86 arch. Arm64 will be switched later. And we also plan to instrument bitops in a similar way. Within a day it has found its first bug: BUG: KASAN: use-after-free in atomic_dec_and_test arch/x86/include/asm/atomic.h:123 [inline] at addr ffff880079c30158 Write of size 4 by task syz-executor6/25698 CPU: 2 PID: 25698 Comm: syz-executor6 Not tainted 4.10.0+ torvalds#302 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: kasan_check_write+0x14/0x20 mm/kasan/kasan.c:344 atomic_dec_and_test arch/x86/include/asm/atomic.h:123 [inline] put_task_struct include/linux/sched/task.h:93 [inline] put_ctx+0xcf/0x110 kernel/events/core.c:1131 perf_event_release_kernel+0x3ad/0xc90 kernel/events/core.c:4322 perf_release+0x37/0x50 kernel/events/core.c:4338 __fput+0x332/0x800 fs/file_table.c:209 ____fput+0x15/0x20 fs/file_table.c:245 task_work_run+0x197/0x260 kernel/task_work.c:116 exit_task_work include/linux/task_work.h:21 [inline] do_exit+0xb38/0x29c0 kernel/exit.c:880 do_group_exit+0x149/0x420 kernel/exit.c:984 get_signal+0x7e0/0x1820 kernel/signal.c:2318 do_signal+0xd2/0x2190 arch/x86/kernel/signal.c:808 exit_to_usermode_loop+0x200/0x2a0 arch/x86/entry/common.c:157 syscall_return_slowpath arch/x86/entry/common.c:191 [inline] do_syscall_64+0x6fc/0x930 arch/x86/entry/common.c:286 entry_SYSCALL64_slow_path+0x25/0x25 RIP: 0033:0x4458d9 RSP: 002b:00007f3f07187cf8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca RAX: fffffffffffffe00 RBX: 00000000007080c8 RCX: 00000000004458d9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000007080c8 RBP: 00000000007080a8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f3f071889c0 R15: 00007f3f07188700 Object at ffff880079c30140, in cache task_struct size: 5376 Allocated: PID = 25681 kmem_cache_alloc_node+0x122/0x6f0 mm/slab.c:3662 alloc_task_struct_node kernel/fork.c:153 [inline] dup_task_struct kernel/fork.c:495 [inline] copy_process.part.38+0x19c8/0x4aa0 kernel/fork.c:1560 copy_process kernel/fork.c:1531 [inline] _do_fork+0x200/0x1010 kernel/fork.c:1994 SYSC_clone kernel/fork.c:2104 [inline] SyS_clone+0x37/0x50 kernel/fork.c:2098 do_syscall_64+0x2e8/0x930 arch/x86/entry/common.c:281 return_from_SYSCALL_64+0x0/0x7a Freed: PID = 25681 __cache_free mm/slab.c:3514 [inline] kmem_cache_free+0x71/0x240 mm/slab.c:3774 free_task_struct kernel/fork.c:158 [inline] free_task+0x151/0x1d0 kernel/fork.c:370 copy_process.part.38+0x18e5/0x4aa0 kernel/fork.c:1931 copy_process kernel/fork.c:1531 [inline] _do_fork+0x200/0x1010 kernel/fork.c:1994 SYSC_clone kernel/fork.c:2104 [inline] SyS_clone+0x37/0x50 kernel/fork.c:2098 do_syscall_64+0x2e8/0x930 arch/x86/entry/common.c:281 return_from_SYSCALL_64+0x0/0x7a This patch (of 3): Currently kasan_check_read/write() accept 'const void*', make them accept 'const volatile void*'. This is required for instrumentation of atomic operations and there is just no reason to not allow that. Link: http://lkml.kernel.org/r/b47f7c2e3445cf48493a1504247e6794232cc073.1489519233.git.dvyukov@google.com Signed-off-by: Dmitry Vyukov <dvyukov@google.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will.deacon@arm.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Ingo Molnar <mingo@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

The following false positive lockdep splat has been observed. ====================================================== WARNING: possible circular locking dependency detected 4.20.0+ torvalds#302 Not tainted ------------------------------------------------------ systemd-udevd/160 is trying to acquire lock: edea6080 (&chip->reg_lock){+.+.}, at: __setup_irq+0x640/0x704 but task is already holding lock: edff0340 (&desc->request_mutex){+.+.}, at: __setup_irq+0xa0/0x704 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&desc->request_mutex){+.+.}: mutex_lock_nested+0x1c/0x24 __setup_irq+0xa0/0x704 request_threaded_irq+0xd0/0x150 mv88e6xxx_probe+0x41c/0x694 [mv88e6xxx] mdio_probe+0x2c/0x54 really_probe+0x200/0x2c4 driver_probe_device+0x5c/0x174 __driver_attach+0xd8/0xdc bus_for_each_dev+0x58/0x7c bus_add_driver+0xe4/0x1f0 driver_register+0x7c/0x110 mdio_driver_register+0x24/0x58 do_one_initcall+0x74/0x2e8 do_init_module+0x60/0x1d0 load_module+0x1968/0x1ff4 sys_finit_module+0x8c/0x98 ret_fast_syscall+0x0/0x28 0xbedf2ae8 -> #0 (&chip->reg_lock){+.+.}: __mutex_lock+0x50/0x8b8 mutex_lock_nested+0x1c/0x24 __setup_irq+0x640/0x704 request_threaded_irq+0xd0/0x150 mv88e6xxx_g2_irq_setup+0xcc/0x1b4 [mv88e6xxx] mv88e6xxx_probe+0x44c/0x694 [mv88e6xxx] mdio_probe+0x2c/0x54 really_probe+0x200/0x2c4 driver_probe_device+0x5c/0x174 __driver_attach+0xd8/0xdc bus_for_each_dev+0x58/0x7c bus_add_driver+0xe4/0x1f0 driver_register+0x7c/0x110 mdio_driver_register+0x24/0x58 do_one_initcall+0x74/0x2e8 do_init_module+0x60/0x1d0 load_module+0x1968/0x1ff4 sys_finit_module+0x8c/0x98 ret_fast_syscall+0x0/0x28 0xbedf2ae8 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&desc->request_mutex); lock(&chip->reg_lock); lock(&desc->request_mutex); lock(&chip->reg_lock); &desc->request_mutex refer to two different mutex. #1 is the GPIO for the chip interrupt. #2 is the chained interrupt between global 1 and global 2. Add lockdep classes to the GPIO interrupt to avoid this. Reported-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Andrew Lunn <andrew@lunn.ch>

The following false positive lockdep splat has been observed. ====================================================== WARNING: possible circular locking dependency detected 4.20.0+ torvalds#302 Not tainted ------------------------------------------------------ systemd-udevd/160 is trying to acquire lock: edea6080 (&chip->reg_lock){+.+.}, at: __setup_irq+0x640/0x704 but task is already holding lock: edff0340 (&desc->request_mutex){+.+.}, at: __setup_irq+0xa0/0x704 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&desc->request_mutex){+.+.}: mutex_lock_nested+0x1c/0x24 __setup_irq+0xa0/0x704 request_threaded_irq+0xd0/0x150 mv88e6xxx_probe+0x41c/0x694 [mv88e6xxx] mdio_probe+0x2c/0x54 really_probe+0x200/0x2c4 driver_probe_device+0x5c/0x174 __driver_attach+0xd8/0xdc bus_for_each_dev+0x58/0x7c bus_add_driver+0xe4/0x1f0 driver_register+0x7c/0x110 mdio_driver_register+0x24/0x58 do_one_initcall+0x74/0x2e8 do_init_module+0x60/0x1d0 load_module+0x1968/0x1ff4 sys_finit_module+0x8c/0x98 ret_fast_syscall+0x0/0x28 0xbedf2ae8 -> #0 (&chip->reg_lock){+.+.}: __mutex_lock+0x50/0x8b8 mutex_lock_nested+0x1c/0x24 __setup_irq+0x640/0x704 request_threaded_irq+0xd0/0x150 mv88e6xxx_g2_irq_setup+0xcc/0x1b4 [mv88e6xxx] mv88e6xxx_probe+0x44c/0x694 [mv88e6xxx] mdio_probe+0x2c/0x54 really_probe+0x200/0x2c4 driver_probe_device+0x5c/0x174 __driver_attach+0xd8/0xdc bus_for_each_dev+0x58/0x7c bus_add_driver+0xe4/0x1f0 driver_register+0x7c/0x110 mdio_driver_register+0x24/0x58 do_one_initcall+0x74/0x2e8 do_init_module+0x60/0x1d0 load_module+0x1968/0x1ff4 sys_finit_module+0x8c/0x98 ret_fast_syscall+0x0/0x28 0xbedf2ae8 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&desc->request_mutex); lock(&chip->reg_lock); lock(&desc->request_mutex); lock(&chip->reg_lock); &desc->request_mutex refer to two different mutex. #1 is the GPIO for the chip interrupt. #2 is the chained interrupt between global 1 and global 2. Add lockdep classes to the GPIO interrupt to avoid this. Reported-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>

[ Upstream commit f6d9758 ] The following false positive lockdep splat has been observed. ====================================================== WARNING: possible circular locking dependency detected 4.20.0+ #302 Not tainted ------------------------------------------------------ systemd-udevd/160 is trying to acquire lock: edea6080 (&chip->reg_lock){+.+.}, at: __setup_irq+0x640/0x704 but task is already holding lock: edff0340 (&desc->request_mutex){+.+.}, at: __setup_irq+0xa0/0x704 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&desc->request_mutex){+.+.}: mutex_lock_nested+0x1c/0x24 __setup_irq+0xa0/0x704 request_threaded_irq+0xd0/0x150 mv88e6xxx_probe+0x41c/0x694 [mv88e6xxx] mdio_probe+0x2c/0x54 really_probe+0x200/0x2c4 driver_probe_device+0x5c/0x174 __driver_attach+0xd8/0xdc bus_for_each_dev+0x58/0x7c bus_add_driver+0xe4/0x1f0 driver_register+0x7c/0x110 mdio_driver_register+0x24/0x58 do_one_initcall+0x74/0x2e8 do_init_module+0x60/0x1d0 load_module+0x1968/0x1ff4 sys_finit_module+0x8c/0x98 ret_fast_syscall+0x0/0x28 0xbedf2ae8 -> #0 (&chip->reg_lock){+.+.}: __mutex_lock+0x50/0x8b8 mutex_lock_nested+0x1c/0x24 __setup_irq+0x640/0x704 request_threaded_irq+0xd0/0x150 mv88e6xxx_g2_irq_setup+0xcc/0x1b4 [mv88e6xxx] mv88e6xxx_probe+0x44c/0x694 [mv88e6xxx] mdio_probe+0x2c/0x54 really_probe+0x200/0x2c4 driver_probe_device+0x5c/0x174 __driver_attach+0xd8/0xdc bus_for_each_dev+0x58/0x7c bus_add_driver+0xe4/0x1f0 driver_register+0x7c/0x110 mdio_driver_register+0x24/0x58 do_one_initcall+0x74/0x2e8 do_init_module+0x60/0x1d0 load_module+0x1968/0x1ff4 sys_finit_module+0x8c/0x98 ret_fast_syscall+0x0/0x28 0xbedf2ae8 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&desc->request_mutex); lock(&chip->reg_lock); lock(&desc->request_mutex); lock(&chip->reg_lock); &desc->request_mutex refer to two different mutex. #1 is the GPIO for the chip interrupt. #2 is the chained interrupt between global 1 and global 2. Add lockdep classes to the GPIO interrupt to avoid this. Reported-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>

BugLink: https://bugs.launchpad.net/bugs/1828410 [ Upstream commit f6d9758 ] The following false positive lockdep splat has been observed. ====================================================== WARNING: possible circular locking dependency detected 4.20.0+ #302 Not tainted ------------------------------------------------------ systemd-udevd/160 is trying to acquire lock: edea6080 (&chip->reg_lock){+.+.}, at: __setup_irq+0x640/0x704 but task is already holding lock: edff0340 (&desc->request_mutex){+.+.}, at: __setup_irq+0xa0/0x704 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&desc->request_mutex){+.+.}: mutex_lock_nested+0x1c/0x24 __setup_irq+0xa0/0x704 request_threaded_irq+0xd0/0x150 mv88e6xxx_probe+0x41c/0x694 [mv88e6xxx] mdio_probe+0x2c/0x54 really_probe+0x200/0x2c4 driver_probe_device+0x5c/0x174 __driver_attach+0xd8/0xdc bus_for_each_dev+0x58/0x7c bus_add_driver+0xe4/0x1f0 driver_register+0x7c/0x110 mdio_driver_register+0x24/0x58 do_one_initcall+0x74/0x2e8 do_init_module+0x60/0x1d0 load_module+0x1968/0x1ff4 sys_finit_module+0x8c/0x98 ret_fast_syscall+0x0/0x28 0xbedf2ae8 -> #0 (&chip->reg_lock){+.+.}: __mutex_lock+0x50/0x8b8 mutex_lock_nested+0x1c/0x24 __setup_irq+0x640/0x704 request_threaded_irq+0xd0/0x150 mv88e6xxx_g2_irq_setup+0xcc/0x1b4 [mv88e6xxx] mv88e6xxx_probe+0x44c/0x694 [mv88e6xxx] mdio_probe+0x2c/0x54 really_probe+0x200/0x2c4 driver_probe_device+0x5c/0x174 __driver_attach+0xd8/0xdc bus_for_each_dev+0x58/0x7c bus_add_driver+0xe4/0x1f0 driver_register+0x7c/0x110 mdio_driver_register+0x24/0x58 do_one_initcall+0x74/0x2e8 do_init_module+0x60/0x1d0 load_module+0x1968/0x1ff4 sys_finit_module+0x8c/0x98 ret_fast_syscall+0x0/0x28 0xbedf2ae8 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&desc->request_mutex); lock(&chip->reg_lock); lock(&desc->request_mutex); lock(&chip->reg_lock); &desc->request_mutex refer to two different mutex. #1 is the GPIO for the chip interrupt. #2 is the chained interrupt between global 1 and global 2. Add lockdep classes to the GPIO interrupt to avoid this. Reported-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

The test is broken w.r.t page table update rules and results in kernel crash as below. Disable the support untill we get the tests updated. [ 21.083506] ------------[ cut here ]------------ [ 21.083519] kernel BUG at arch/powerpc/mm/pgtable.c:304! cpu 0x0: Vector: 700 (Program Check) at [c000000c6d1e76c0] pc: c00000000009a5ec: assert_pte_locked+0x14c/0x380 lr: c0000000005eeeec: pte_update+0x11c/0x190 sp: c000000c6d1e7950 msr: 8000000002029033 current = 0xc000000c6d172c80 paca = 0xc000000003ba0000 irqmask: 0x03 irq_happened: 0x01 pid = 1, comm = swapper/0 kernel BUG at arch/powerpc/mm/pgtable.c:304! Linux version 5.9.0-rc2-34902-g4da73871507c (kvaneesh@ltczz75-lp2) (gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) torvalds#301 SMP Tue Sep 1 02:28:29 CDT 2020 enter ? for help [link register ] c0000000005eeeec pte_update+0x11c/0x190 [c000000c6d1e7950] 0000000000000001 (unreliable) [c000000c6d1e79b0] c0000000005eee14 pte_update+0x44/0x190 [c000000c6d1e7a10] c000000001a2ca9c pte_advanced_tests+0x160/0x3d8 [c000000c6d1e7ab0] c000000001a2d4fc debug_vm_pgtable+0x7e8/0x1338 [c000000c6d1e7ba0] c0000000000116ec do_one_initcall+0xac/0x5f0 [c000000c6d1e7c80] c0000000019e4fac kernel_init_freeable+0x4dc/0x5a4 [c000000c6d1e7db0] c000000000012474 kernel_init+0x24/0x160 [c000000c6d1e7e20] c00000000000cbd0 ret_from_kernel_thread+0x5c/0x6c With DEBUG_VM disabled [ 20.530152] BUG: Kernel NULL pointer dereference on read at 0x00000000 [ 20.530183] Faulting instruction address: 0xc0000000000df330 cpu 0x33: Vector: 380 (Data SLB Access) at [c000000c6d19f700] pc: c0000000000df330: memset+0x68/0x104 lr: c00000000009f6d8: hash__pmdp_huge_get_and_clear+0xe8/0x1b0 sp: c000000c6d19f990 msr: 8000000002009033 dar: 0 current = 0xc000000c6d177480 paca = 0xc00000001ec4f400 irqmask: 0x03 irq_happened: 0x01 pid = 1, comm = swapper/0 Linux version 5.9.0-rc2-34902-g4da73871507c (kvaneesh@ltczz75-lp2) (gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) torvalds#302 SMP Tue Sep 1 02:56:02 CDT 2020 enter ? for help [link register ] c00000000009f6d8 hash__pmdp_huge_get_and_clear+0xe8/0x1b0 [c000000c6d19f990] c00000000009f748 hash__pmdp_huge_get_and_clear+0x158/0x1b0 (unreliable) [c000000c6d19fa10] c0000000019ebf30 pmd_advanced_tests+0x1f0/0x378 [c000000c6d19fab0] c0000000019ed088 debug_vm_pgtable+0x79c/0x1244 [c000000c6d19fba0] c0000000000116ec do_one_initcall+0xac/0x5f0 [c000000c6d19fc80] c0000000019a4fac kernel_init_freeable+0x4dc/0x5a4 [c000000c6d19fdb0] c000000000012474 kernel_init+0x24/0x160 [c000000c6d19fe20] c00000000000cbd0 ret_from_kernel_thread+0x5c/0x6c 33:mon> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>

This commit fixes the following checkpatch.pl errors: ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#12: FILE: ./hal/odm_CfoTracking.c:12: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#13: FILE: ./hal/odm_CfoTracking.c:13: + struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#42: FILE: ./hal/odm_CfoTracking.c:42: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #52: FILE: ./hal/odm_CfoTracking.c:52: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #53: FILE: ./hal/odm_CfoTracking.c:53: + struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #70: FILE: ./hal/odm_CfoTracking.c:70: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#82: FILE: ./hal/odm_CfoTracking.c:82: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#83: FILE: ./hal/odm_CfoTracking.c:83: + struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#94: FILE: ./hal/odm_CfoTracking.c:94: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#95: FILE: ./hal/odm_CfoTracking.c:95: + struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#121: FILE: ./hal/odm_CfoTracking.c:121: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#122: FILE: ./hal/odm_CfoTracking.c:122: + struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#300: FILE: ./hal/odm_CfoTracking.c:300: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#302: FILE: ./hal/odm_CfoTracking.c:302: + struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack; Signed-off-by: Marco Cesati <marcocesati@gmail.com>

This commit fixes the following checkpatch.pl errors: ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#12: FILE: ./hal/odm_CfoTracking.c:12: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#13: FILE: ./hal/odm_CfoTracking.c:13: + struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#42: FILE: ./hal/odm_CfoTracking.c:42: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #52: FILE: ./hal/odm_CfoTracking.c:52: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #53: FILE: ./hal/odm_CfoTracking.c:53: + struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #70: FILE: ./hal/odm_CfoTracking.c:70: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#82: FILE: ./hal/odm_CfoTracking.c:82: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#83: FILE: ./hal/odm_CfoTracking.c:83: + struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#94: FILE: ./hal/odm_CfoTracking.c:94: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#95: FILE: ./hal/odm_CfoTracking.c:95: + struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#121: FILE: ./hal/odm_CfoTracking.c:121: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#122: FILE: ./hal/odm_CfoTracking.c:122: + struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#300: FILE: ./hal/odm_CfoTracking.c:300: + struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#302: FILE: ./hal/odm_CfoTracking.c:302: + struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack; Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Marco Cesati <marcocesati@gmail.com> Link: https://lore.kernel.org/r/20210315170618.2566-23-marcocesati@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Enable CPU v4 instruction tests for arm64. Below are the test results from BPF test_progs selftests: # ./test_progs -t ldsx_insn,verifier_sdiv,verifier_movsx,verifier_ldsx,verifier_gotol,verifier_bswap torvalds#115/1 ldsx_insn/map_val and probed_memory:OK torvalds#115/2 ldsx_insn/ctx_member_sign_ext:OK torvalds#115/3 ldsx_insn/ctx_member_narrow_sign_ext:OK torvalds#115 ldsx_insn:OK torvalds#302/1 verifier_bswap/BSWAP, 16:OK torvalds#302/2 verifier_bswap/BSWAP, 16 @unpriv:OK torvalds#302/3 verifier_bswap/BSWAP, 32:OK torvalds#302/4 verifier_bswap/BSWAP, 32 @unpriv:OK torvalds#302/5 verifier_bswap/BSWAP, 64:OK torvalds#302/6 verifier_bswap/BSWAP, 64 @unpriv:OK torvalds#302 verifier_bswap:OK torvalds#316/1 verifier_gotol/gotol, small_imm:OK torvalds#316/2 verifier_gotol/gotol, small_imm @unpriv:OK torvalds#316 verifier_gotol:OK torvalds#324/1 verifier_ldsx/LDSX, S8:OK torvalds#324/2 verifier_ldsx/LDSX, S8 @unpriv:OK torvalds#324/3 verifier_ldsx/LDSX, S16:OK torvalds#324/4 verifier_ldsx/LDSX, S16 @unpriv:OK torvalds#324/5 verifier_ldsx/LDSX, S32:OK torvalds#324/6 verifier_ldsx/LDSX, S32 @unpriv:OK torvalds#324/7 verifier_ldsx/LDSX, S8 range checking, privileged:OK torvalds#324/8 verifier_ldsx/LDSX, S16 range checking:OK torvalds#324/9 verifier_ldsx/LDSX, S16 range checking @unpriv:OK torvalds#324/10 verifier_ldsx/LDSX, S32 range checking:OK torvalds#324/11 verifier_ldsx/LDSX, S32 range checking @unpriv:OK torvalds#324 verifier_ldsx:OK torvalds#335/1 verifier_movsx/MOV32SX, S8:OK torvalds#335/2 verifier_movsx/MOV32SX, S8 @unpriv:OK torvalds#335/3 verifier_movsx/MOV32SX, S16:OK torvalds#335/4 verifier_movsx/MOV32SX, S16 @unpriv:OK torvalds#335/5 verifier_movsx/MOV64SX, S8:OK torvalds#335/6 verifier_movsx/MOV64SX, S8 @unpriv:OK torvalds#335/7 verifier_movsx/MOV64SX, S16:OK torvalds#335/8 verifier_movsx/MOV64SX, S16 @unpriv:OK torvalds#335/9 verifier_movsx/MOV64SX, S32:OK torvalds#335/10 verifier_movsx/MOV64SX, S32 @unpriv:OK torvalds#335/11 verifier_movsx/MOV32SX, S8, range_check:OK torvalds#335/12 verifier_movsx/MOV32SX, S8, range_check @unpriv:OK torvalds#335/13 verifier_movsx/MOV32SX, S16, range_check:OK torvalds#335/14 verifier_movsx/MOV32SX, S16, range_check @unpriv:OK torvalds#335/15 verifier_movsx/MOV32SX, S16, range_check 2:OK torvalds#335/16 verifier_movsx/MOV32SX, S16, range_check 2 @unpriv:OK torvalds#335/17 verifier_movsx/MOV64SX, S8, range_check:OK torvalds#335/18 verifier_movsx/MOV64SX, S8, range_check @unpriv:OK torvalds#335/19 verifier_movsx/MOV64SX, S16, range_check:OK torvalds#335/20 verifier_movsx/MOV64SX, S16, range_check @unpriv:OK torvalds#335/21 verifier_movsx/MOV64SX, S32, range_check:OK torvalds#335/22 verifier_movsx/MOV64SX, S32, range_check @unpriv:OK torvalds#335/23 verifier_movsx/MOV64SX, S16, R10 Sign Extension:OK torvalds#335/24 verifier_movsx/MOV64SX, S16, R10 Sign Extension @unpriv:OK torvalds#335 verifier_movsx:OK torvalds#347/1 verifier_sdiv/SDIV32, non-zero imm divisor, check 1:OK torvalds#347/2 verifier_sdiv/SDIV32, non-zero imm divisor, check 1 @unpriv:OK torvalds#347/3 verifier_sdiv/SDIV32, non-zero imm divisor, check 2:OK torvalds#347/4 verifier_sdiv/SDIV32, non-zero imm divisor, check 2 @unpriv:OK torvalds#347/5 verifier_sdiv/SDIV32, non-zero imm divisor, check 3:OK torvalds#347/6 verifier_sdiv/SDIV32, non-zero imm divisor, check 3 @unpriv:OK torvalds#347/7 verifier_sdiv/SDIV32, non-zero imm divisor, check 4:OK torvalds#347/8 verifier_sdiv/SDIV32, non-zero imm divisor, check 4 @unpriv:OK torvalds#347/9 verifier_sdiv/SDIV32, non-zero imm divisor, check 5:OK torvalds#347/10 verifier_sdiv/SDIV32, non-zero imm divisor, check 5 @unpriv:OK torvalds#347/11 verifier_sdiv/SDIV32, non-zero imm divisor, check 6:OK torvalds#347/12 verifier_sdiv/SDIV32, non-zero imm divisor, check 6 @unpriv:OK torvalds#347/13 verifier_sdiv/SDIV32, non-zero imm divisor, check 7:OK torvalds#347/14 verifier_sdiv/SDIV32, non-zero imm divisor, check 7 @unpriv:OK torvalds#347/15 verifier_sdiv/SDIV32, non-zero imm divisor, check 8:OK torvalds#347/16 verifier_sdiv/SDIV32, non-zero imm divisor, check 8 @unpriv:OK torvalds#347/17 verifier_sdiv/SDIV32, non-zero reg divisor, check 1:OK torvalds#347/18 verifier_sdiv/SDIV32, non-zero reg divisor, check 1 @unpriv:OK torvalds#347/19 verifier_sdiv/SDIV32, non-zero reg divisor, check 2:OK torvalds#347/20 verifier_sdiv/SDIV32, non-zero reg divisor, check 2 @unpriv:OK torvalds#347/21 verifier_sdiv/SDIV32, non-zero reg divisor, check 3:OK torvalds#347/22 verifier_sdiv/SDIV32, non-zero reg divisor, check 3 @unpriv:OK torvalds#347/23 verifier_sdiv/SDIV32, non-zero reg divisor, check 4:OK torvalds#347/24 verifier_sdiv/SDIV32, non-zero reg divisor, check 4 @unpriv:OK torvalds#347/25 verifier_sdiv/SDIV32, non-zero reg divisor, check 5:OK torvalds#347/26 verifier_sdiv/SDIV32, non-zero reg divisor, check 5 @unpriv:OK torvalds#347/27 verifier_sdiv/SDIV32, non-zero reg divisor, check 6:OK torvalds#347/28 verifier_sdiv/SDIV32, non-zero reg divisor, check 6 @unpriv:OK torvalds#347/29 verifier_sdiv/SDIV32, non-zero reg divisor, check 7:OK torvalds#347/30 verifier_sdiv/SDIV32, non-zero reg divisor, check 7 @unpriv:OK torvalds#347/31 verifier_sdiv/SDIV32, non-zero reg divisor, check 8:OK torvalds#347/32 verifier_sdiv/SDIV32, non-zero reg divisor, check 8 @unpriv:OK torvalds#347/33 verifier_sdiv/SDIV64, non-zero imm divisor, check 1:OK torvalds#347/34 verifier_sdiv/SDIV64, non-zero imm divisor, check 1 @unpriv:OK torvalds#347/35 verifier_sdiv/SDIV64, non-zero imm divisor, check 2:OK torvalds#347/36 verifier_sdiv/SDIV64, non-zero imm divisor, check 2 @unpriv:OK torvalds#347/37 verifier_sdiv/SDIV64, non-zero imm divisor, check 3:OK torvalds#347/38 verifier_sdiv/SDIV64, non-zero imm divisor, check 3 @unpriv:OK torvalds#347/39 verifier_sdiv/SDIV64, non-zero imm divisor, check 4:OK torvalds#347/40 verifier_sdiv/SDIV64, non-zero imm divisor, check 4 @unpriv:OK torvalds#347/41 verifier_sdiv/SDIV64, non-zero imm divisor, check 5:OK torvalds#347/42 verifier_sdiv/SDIV64, non-zero imm divisor, check 5 @unpriv:OK torvalds#347/43 verifier_sdiv/SDIV64, non-zero imm divisor, check 6:OK torvalds#347/44 verifier_sdiv/SDIV64, non-zero imm divisor, check 6 @unpriv:OK torvalds#347/45 verifier_sdiv/SDIV64, non-zero reg divisor, check 1:OK torvalds#347/46 verifier_sdiv/SDIV64, non-zero reg divisor, check 1 @unpriv:OK torvalds#347/47 verifier_sdiv/SDIV64, non-zero reg divisor, check 2:OK torvalds#347/48 verifier_sdiv/SDIV64, non-zero reg divisor, check 2 @unpriv:OK torvalds#347/49 verifier_sdiv/SDIV64, non-zero reg divisor, check 3:OK torvalds#347/50 verifier_sdiv/SDIV64, non-zero reg divisor, check 3 @unpriv:OK torvalds#347/51 verifier_sdiv/SDIV64, non-zero reg divisor, check 4:OK torvalds#347/52 verifier_sdiv/SDIV64, non-zero reg divisor, check 4 @unpriv:OK torvalds#347/53 verifier_sdiv/SDIV64, non-zero reg divisor, check 5:OK torvalds#347/54 verifier_sdiv/SDIV64, non-zero reg divisor, check 5 @unpriv:OK torvalds#347/55 verifier_sdiv/SDIV64, non-zero reg divisor, check 6:OK torvalds#347/56 verifier_sdiv/SDIV64, non-zero reg divisor, check 6 @unpriv:OK torvalds#347/57 verifier_sdiv/SMOD32, non-zero imm divisor, check 1:OK torvalds#347/58 verifier_sdiv/SMOD32, non-zero imm divisor, check 1 @unpriv:OK torvalds#347/59 verifier_sdiv/SMOD32, non-zero imm divisor, check 2:OK torvalds#347/60 verifier_sdiv/SMOD32, non-zero imm divisor, check 2 @unpriv:OK torvalds#347/61 verifier_sdiv/SMOD32, non-zero imm divisor, check 3:OK torvalds#347/62 verifier_sdiv/SMOD32, non-zero imm divisor, check 3 @unpriv:OK torvalds#347/63 verifier_sdiv/SMOD32, non-zero imm divisor, check 4:OK torvalds#347/64 verifier_sdiv/SMOD32, non-zero imm divisor, check 4 @unpriv:OK torvalds#347/65 verifier_sdiv/SMOD32, non-zero imm divisor, check 5:OK torvalds#347/66 verifier_sdiv/SMOD32, non-zero imm divisor, check 5 @unpriv:OK torvalds#347/67 verifier_sdiv/SMOD32, non-zero imm divisor, check 6:OK torvalds#347/68 verifier_sdiv/SMOD32, non-zero imm divisor, check 6 @unpriv:OK torvalds#347/69 verifier_sdiv/SMOD32, non-zero reg divisor, check 1:OK torvalds#347/70 verifier_sdiv/SMOD32, non-zero reg divisor, check 1 @unpriv:OK torvalds#347/71 verifier_sdiv/SMOD32, non-zero reg divisor, check 2:OK torvalds#347/72 verifier_sdiv/SMOD32, non-zero reg divisor, check 2 @unpriv:OK torvalds#347/73 verifier_sdiv/SMOD32, non-zero reg divisor, check 3:OK torvalds#347/74 verifier_sdiv/SMOD32, non-zero reg divisor, check 3 @unpriv:OK torvalds#347/75 verifier_sdiv/SMOD32, non-zero reg divisor, check 4:OK torvalds#347/76 verifier_sdiv/SMOD32, non-zero reg divisor, check 4 @unpriv:OK torvalds#347/77 verifier_sdiv/SMOD32, non-zero reg divisor, check 5:OK torvalds#347/78 verifier_sdiv/SMOD32, non-zero reg divisor, check 5 @unpriv:OK torvalds#347/79 verifier_sdiv/SMOD32, non-zero reg divisor, check 6:OK torvalds#347/80 verifier_sdiv/SMOD32, non-zero reg divisor, check 6 @unpriv:OK torvalds#347/81 verifier_sdiv/SMOD64, non-zero imm divisor, check 1:OK torvalds#347/82 verifier_sdiv/SMOD64, non-zero imm divisor, check 1 @unpriv:OK torvalds#347/83 verifier_sdiv/SMOD64, non-zero imm divisor, check 2:OK torvalds#347/84 verifier_sdiv/SMOD64, non-zero imm divisor, check 2 @unpriv:OK torvalds#347/85 verifier_sdiv/SMOD64, non-zero imm divisor, check 3:OK torvalds#347/86 verifier_sdiv/SMOD64, non-zero imm divisor, check 3 @unpriv:OK torvalds#347/87 verifier_sdiv/SMOD64, non-zero imm divisor, check 4:OK torvalds#347/88 verifier_sdiv/SMOD64, non-zero imm divisor, check 4 @unpriv:OK torvalds#347/89 verifier_sdiv/SMOD64, non-zero imm divisor, check 5:OK torvalds#347/90 verifier_sdiv/SMOD64, non-zero imm divisor, check 5 @unpriv:OK torvalds#347/91 verifier_sdiv/SMOD64, non-zero imm divisor, check 6:OK torvalds#347/92 verifier_sdiv/SMOD64, non-zero imm divisor, check 6 @unpriv:OK torvalds#347/93 verifier_sdiv/SMOD64, non-zero imm divisor, check 7:OK torvalds#347/94 verifier_sdiv/SMOD64, non-zero imm divisor, check 7 @unpriv:OK torvalds#347/95 verifier_sdiv/SMOD64, non-zero imm divisor, check 8:OK torvalds#347/96 verifier_sdiv/SMOD64, non-zero imm divisor, check 8 @unpriv:OK torvalds#347/97 verifier_sdiv/SMOD64, non-zero reg divisor, check 1:OK torvalds#347/98 verifier_sdiv/SMOD64, non-zero reg divisor, check 1 @unpriv:OK torvalds#347/99 verifier_sdiv/SMOD64, non-zero reg divisor, check 2:OK torvalds#347/100 verifier_sdiv/SMOD64, non-zero reg divisor, check 2 @unpriv:OK torvalds#347/101 verifier_sdiv/SMOD64, non-zero reg divisor, check 3:OK torvalds#347/102 verifier_sdiv/SMOD64, non-zero reg divisor, check 3 @unpriv:OK torvalds#347/103 verifier_sdiv/SMOD64, non-zero reg divisor, check 4:OK torvalds#347/104 verifier_sdiv/SMOD64, non-zero reg divisor, check 4 @unpriv:OK torvalds#347/105 verifier_sdiv/SMOD64, non-zero reg divisor, check 5:OK torvalds#347/106 verifier_sdiv/SMOD64, non-zero reg divisor, check 5 @unpriv:OK torvalds#347/107 verifier_sdiv/SMOD64, non-zero reg divisor, check 6:OK torvalds#347/108 verifier_sdiv/SMOD64, non-zero reg divisor, check 6 @unpriv:OK torvalds#347/109 verifier_sdiv/SMOD64, non-zero reg divisor, check 7:OK torvalds#347/110 verifier_sdiv/SMOD64, non-zero reg divisor, check 7 @unpriv:OK torvalds#347/111 verifier_sdiv/SMOD64, non-zero reg divisor, check 8:OK torvalds#347/112 verifier_sdiv/SMOD64, non-zero reg divisor, check 8 @unpriv:OK torvalds#347/113 verifier_sdiv/SDIV32, zero divisor:OK torvalds#347/114 verifier_sdiv/SDIV32, zero divisor @unpriv:OK torvalds#347/115 verifier_sdiv/SDIV64, zero divisor:OK torvalds#347/116 verifier_sdiv/SDIV64, zero divisor @unpriv:OK torvalds#347/117 verifier_sdiv/SMOD32, zero divisor:OK torvalds#347/118 verifier_sdiv/SMOD32, zero divisor @unpriv:OK torvalds#347/119 verifier_sdiv/SMOD64, zero divisor:OK torvalds#347/120 verifier_sdiv/SMOD64, zero divisor @unpriv:OK torvalds#347 verifier_sdiv:OK Summary: 6/166 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Tested-by: Florent Revest <revest@chromium.org> Acked-by: Yonghong Song <yonghong.song@linux.dev> Acked-by: Florent Revest <revest@chromium.org> Link: https://lore.kernel.org/bpf/20230815154158.717901-8-xukuohai@huaweicloud.com

Extend snprintf negative tests to cover pointer specifiers to prevent possible invalid handling of %p% from happening again. ./test_progs -t snprintf torvalds#302/1 snprintf/snprintf_positive:OK torvalds#302/2 snprintf/snprintf_negative:OK torvalds#302 snprintf:OK torvalds#303 snprintf_btf:OK Summary: 2/2 PASSED, 0 SKIPPED, 0 FAILED Co-developed-by: Nikita Marushkin <hfggklm@gmail.com> Signed-off-by: Nikita Marushkin <hfggklm@gmail.com> Signed-off-by: Ilya Shchipletsov <rabbelkin@mail.ru>

Extend snprintf negative tests to cover pointer specifiers to prevent possible invalid handling of %p% from happening again. ./test_progs -t snprintf torvalds#302/1 snprintf/snprintf_positive:OK torvalds#302/2 snprintf/snprintf_negative:OK torvalds#302 snprintf:OK torvalds#303 snprintf_btf:OK Summary: 2/2 PASSED, 0 SKIPPED, 0 FAILED Co-developed-by: Nikita Marushkin <hfggklm@gmail.com> Signed-off-by: Nikita Marushkin <hfggklm@gmail.com> Signed-off-by: Ilya Shchipletsov <rabbelkin@mail.ru> Acked-by: Yonghong Song <yonghong.song@linux.dev> Acked-by: Florent Revest <revest@chromium.org>

no need to get path for a logical block

598ebd1

If we don't need to split the extent, also don't need to re-get the path for a logical block

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

simplified getting previous and next node in red-black tree for vmalloc #302

simplified getting previous and next node in red-black tree for vmalloc #302

SemanShen commented Jul 10, 2016

lenovouser commented Jul 10, 2016

simplified getting previous and next node in red-black tree for vmalloc #302

Are you sure you want to change the base?

simplified getting previous and next node in red-black tree for vmalloc #302

Conversation

SemanShen commented Jul 10, 2016

lenovouser commented Jul 10, 2016