-
Notifications
You must be signed in to change notification settings - Fork 54.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Artwork #154
Closed
Kernolia
wants to merge
11
commits into
torvalds:master
from
The-Feminist-Software-Foundation:master
Closed
Artwork #154
Kernolia
wants to merge
11
commits into
torvalds:master
from
The-Feminist-Software-Foundation:master
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gregkh
referenced
this pull request
in coreos/linux
Nov 20, 2015
[ Upstream commit 5933a7b ] If the vxlan interface is created without explicit group definition, there are corner cases which may cause kernel panic. For instance, in the following scenario: node A: $ ip link add dev vxlan42 address 2c:c2:60:00:10:20 type vxlan id 42 $ ip addr add dev vxlan42 10.0.0.1/24 $ ip link set up dev vxlan42 $ arp -i vxlan42 -s 10.0.0.2 2c:c2:60:00:01:02 $ bridge fdb add dev vxlan42 to 2c:c2:60:00:01:02 dst <IPv4 address> $ ping 10.0.0.2 node B: $ ip link add dev vxlan42 address 2c:c2:60:00:01:02 type vxlan id 42 $ ip addr add dev vxlan42 10.0.0.2/24 $ ip link set up dev vxlan42 $ arp -i vxlan42 -s 10.0.0.1 2c:c2:60:00:10:20 node B crashes: vxlan42: 2c:c2:60:00:10:20 migrated from 4011:eca4:c0a8:6466:c0a8:6415:8e09:2118 to (invalid address) vxlan42: 2c:c2:60:00:10:20 migrated from 4011:eca4:c0a8:6466:c0a8:6415:8e09:2118 to (invalid address) BUG: unable to handle kernel NULL pointer dereference at 0000000000000046 IP: [<ffffffff8143c459>] ip6_route_output+0x58/0x82 PGD 7bd89067 PUD 7bd4e067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.14.0-rc8-hvx-xen-00019-g97a5221-dirty #154 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 task: ffff88007c774f50 ti: ffff88007c79c000 task.ti: ffff88007c79c000 RIP: 0010:[<ffffffff8143c459>] [<ffffffff8143c459>] ip6_route_output+0x58/0x82 RSP: 0018:ffff88007fd03668 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffff8186a000 RCX: 0000000000000040 RDX: 0000000000000000 RSI: ffff88007b0e4a80 RDI: ffff88007fd03754 RBP: ffff88007fd03688 R08: ffff88007b0e4a80 R09: 0000000000000000 R10: 0200000a0100000a R11: 0001002200000000 R12: ffff88007fd03740 R13: ffff88007b0e4a80 R14: ffff88007b0e4a80 R15: ffff88007bba0c50 FS: 0000000000000000(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000046 CR3: 000000007bb60000 CR4: 00000000000006e0 Stack: 0000000000000000 ffff88007fd037a0 ffffffff8186a000 ffff88007fd03740 ffff88007fd036c8 ffffffff814320bb 0000000000006e49 ffff88007b8b7360 ffff88007bdbf200 ffff88007bcbc000 ffff88007b8b7000 ffff88007b8b7360 Call Trace: <IRQ> [<ffffffff814320bb>] ip6_dst_lookup_tail+0x2d/0xa4 [<ffffffff814322a5>] ip6_dst_lookup+0x10/0x12 [<ffffffff81323b4e>] vxlan_xmit_one+0x32a/0x68c [<ffffffff814a325a>] ? _raw_spin_unlock_irqrestore+0x12/0x14 [<ffffffff8104c551>] ? lock_timer_base.isra.23+0x26/0x4b [<ffffffff8132451a>] vxlan_xmit+0x66a/0x6a8 [<ffffffff8141a365>] ? ipt_do_table+0x35f/0x37e [<ffffffff81204ba2>] ? selinux_ip_postroute+0x41/0x26e [<ffffffff8139d0c1>] dev_hard_start_xmit+0x2ce/0x3ce [<ffffffff8139d491>] __dev_queue_xmit+0x2d0/0x392 [<ffffffff813b380f>] ? eth_header+0x28/0xb5 [<ffffffff8139d569>] dev_queue_xmit+0xb/0xd [<ffffffff813a5aa6>] neigh_resolve_output+0x134/0x152 [<ffffffff813db741>] ip_finish_output2+0x236/0x299 [<ffffffff813dc074>] ip_finish_output+0x98/0x9d [<ffffffff813dc749>] ip_output+0x62/0x67 [<ffffffff813da9f2>] dst_output+0xf/0x11 [<ffffffff813dc11c>] ip_local_out+0x1b/0x1f [<ffffffff813dcf1b>] ip_send_skb+0x11/0x37 [<ffffffff813dcf70>] ip_push_pending_frames+0x2f/0x33 [<ffffffff813ff732>] icmp_push_reply+0x106/0x115 [<ffffffff813ff9e4>] icmp_reply+0x142/0x164 [<ffffffff813ffb3b>] icmp_echo.part.16+0x46/0x48 [<ffffffff813c1d30>] ? nf_iterate+0x43/0x80 [<ffffffff813d8037>] ? xfrm4_policy_check.constprop.11+0x52/0x52 [<ffffffff813ffb62>] icmp_echo+0x25/0x27 [<ffffffff814005f7>] icmp_rcv+0x1d2/0x20a [<ffffffff813d8037>] ? xfrm4_policy_check.constprop.11+0x52/0x52 [<ffffffff813d810d>] ip_local_deliver_finish+0xd6/0x14f [<ffffffff813d8037>] ? xfrm4_policy_check.constprop.11+0x52/0x52 [<ffffffff813d7fde>] NF_HOOK.constprop.10+0x4c/0x53 [<ffffffff813d82bf>] ip_local_deliver+0x4a/0x4f [<ffffffff813d7f7b>] ip_rcv_finish+0x253/0x26a [<ffffffff813d7d28>] ? inet_add_protocol+0x3e/0x3e [<ffffffff813d7fde>] NF_HOOK.constprop.10+0x4c/0x53 [<ffffffff813d856a>] ip_rcv+0x2a6/0x2ec [<ffffffff8139a9a0>] __netif_receive_skb_core+0x43e/0x478 [<ffffffff812a346f>] ? virtqueue_poll+0x16/0x27 [<ffffffff8139aa2f>] __netif_receive_skb+0x55/0x5a [<ffffffff8139aaaa>] process_backlog+0x76/0x12f [<ffffffff8139add8>] net_rx_action+0xa2/0x1ab [<ffffffff81047847>] __do_softirq+0xca/0x1d1 [<ffffffff81047ace>] irq_exit+0x3e/0x85 [<ffffffff8100b98b>] do_IRQ+0xa9/0xc4 [<ffffffff814a37ad>] common_interrupt+0x6d/0x6d <EOI> [<ffffffff810378db>] ? native_safe_halt+0x6/0x8 [<ffffffff810110c7>] default_idle+0x9/0xd [<ffffffff81011694>] arch_cpu_idle+0x13/0x1c [<ffffffff8107480d>] cpu_startup_entry+0xbc/0x137 [<ffffffff8102e741>] start_secondary+0x1a0/0x1a5 Code: 24 14 e8 f1 e5 01 00 31 d2 a8 32 0f 95 c2 49 8b 44 24 2c 49 0b 44 24 24 74 05 83 ca 04 eb 1c 4d 85 ed 74 17 49 8b 85 a8 02 00 00 <66> 8b 40 46 66 c1 e8 07 83 e0 07 c1 e0 03 09 c2 4c 89 e6 48 89 RIP [<ffffffff8143c459>] ip6_route_output+0x58/0x82 RSP <ffff88007fd03668> CR2: 0000000000000046 ---[ end trace 4612329caab37efd ]--- When vxlan interface is created without explicit group definition, the default_dst protocol family is initialiazed to AF_UNSPEC and the driver assumes IPv4 configuration. On the other side, the default_dst protocol family is used to differentiate between IPv4 and IPv6 cases and, since, AF_UNSPEC != AF_INET, the processing takes the IPv6 path. Making the IPv4 assumption explicit by settting default_dst protocol family to AF_INET4 and preventing mixing of IPv4 and IPv6 addresses in snooped fdb entries fixes the corner case crashes. Signed-off-by: Mike Rapoport <mike.rapoport@ravellosystems.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
laijs
pushed a commit
to laijs/linux
that referenced
this pull request
Feb 13, 2017
lkl: properly free mutex and semaphore.
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 2, 2018
On Sun, 31 Dec 2017 20:58:01 +0100, syzbot wrote: > > Hello, > > syzkaller hit the following crash on > 71ee203 > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached. > C reproducer is attached > syzkaller reproducer is attached. See https://goo.gl/kgGztJ > for information about syzkaller reproducers > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+6f11c7e2a1b91d466432@syzkaller.appspotmail.com > It will help syzbot understand when the bug is fixed. See footer for > details. > If you forward the report, please keep this part and the footer. > > audit: type=1400 audit(1514740357.837:7): avc: denied { map } for > pid=3502 comm="syzkaller781065" path="/root/syzkaller781065961" > dev="sda1" ino=16481 > scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 > tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1 > WARNING: CPU: 0 PID: 3502 at sound/core/pcm_lib.c:1635 > snd_pcm_hw_param_first+0x289/0x690 sound/core/pcm_lib.c:1635 > Kernel panic - not syncing: panic_on_warn set ... > > CPU: 0 PID: 3502 Comm: syzkaller781065 Not tainted 4.15.0-rc5+ torvalds#154 > Hardware name: Google Google Compute Engine/Google Compute Engine, > BIOS Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:17 [inline] > dump_stack+0x194/0x257 lib/dump_stack.c:53 > panic+0x1e4/0x41c kernel/panic.c:183 > __warn+0x1dc/0x200 kernel/panic.c:547 > report_bug+0x211/0x2d0 lib/bug.c:184 > fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178 > fixup_bug arch/x86/kernel/traps.c:247 [inline] > do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296 > do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315 > invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1079 > RIP: 0010:snd_pcm_hw_param_first+0x289/0x690 sound/core/pcm_lib.c:1635 > RSP: 0018:ffff8801c013f1a0 EFLAGS: 00010293 > RAX: ffff8801c03bc3c0 RBX: ffff8801bff08dc0 RCX: ffffffff841bee19 > RDX: 0000000000000000 RSI: 00000000ffffffea RDI: ffffed0038027e28 > RBP: ffff8801c013f1f0 R08: ffffed0038027d63 R09: ffff8801c013eb10 > R10: 0000000000000001 R11: ffffed0038027d62 R12: 000000000000000d > R13: 00000000ffffffea R14: 0000000000000005 R15: 0000000000002000 > snd_pcm_hw_param_near.constprop.27+0x78d/0x9a0 sound/core/oss/pcm_oss.c:457 > snd_pcm_oss_change_params+0x17d3/0x3720 sound/core/oss/pcm_oss.c:969 > snd_pcm_oss_make_ready+0xaa/0x130 sound/core/oss/pcm_oss.c:1128 > snd_pcm_oss_sync+0x257/0x830 sound/core/oss/pcm_oss.c:1638 > snd_pcm_oss_release+0x20b/0x280 sound/core/oss/pcm_oss.c:2431 > __fput+0x327/0x7e0 fs/file_table.c:210 > ____fput+0x15/0x20 fs/file_table.c:244 > task_work_run+0x199/0x270 kernel/task_work.c:113 > exit_task_work include/linux/task_work.h:22 [inline] > do_exit+0x9bb/0x1ad0 kernel/exit.c:865 > do_group_exit+0x149/0x400 kernel/exit.c:968 > SYSC_exit_group kernel/exit.c:979 [inline] > SyS_exit_group+0x1d/0x20 kernel/exit.c:977 > do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline] > do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389 > entry_SYSENTER_compat+0x54/0x63 arch/x86/entry/entry_64_compat.S:129 > RIP: 0023:0xf7f4ec79 > RSP: 002b:00000000ffc2c18c EFLAGS: 00000292 ORIG_RAX: 00000000000000fc > RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000080f0298 > RDX: 0000000000000000 RSI: 00000000080d9b78 RDI: 00000000080f02a0 > RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > Dumping ftrace buffer: > (ftrace buffer empty) > Kernel Offset: disabled > Rebooting in 86400 seconds.. This must be a superfluous WARN_ON() call invoked by snd_BUG_ON() check that can be safely ignored. A quick fix patch is below. thanks, Takashi -- 8< -- From: Takashi Iwai <tiwai@suse.de> Subject: [PATCH] ALSA: pcm: Remove superfluous warning syzkaller triggered kernel warnings through PCM OSS emulation at closing a stream: WARNING: CPU: 0 PID: 3502 at sound/core/pcm_lib.c:1635 snd_pcm_hw_param_first+0x289/0x690 sound/core/pcm_lib.c:1635 Call Trace: .... snd_pcm_hw_param_near.constprop.27+0x78d/0x9a0 sound/core/oss/pcm_oss.c:457 snd_pcm_oss_change_params+0x17d3/0x3720 sound/core/oss/pcm_oss.c:969 snd_pcm_oss_make_ready+0xaa/0x130 sound/core/oss/pcm_oss.c:1128 snd_pcm_oss_sync+0x257/0x830 sound/core/oss/pcm_oss.c:1638 snd_pcm_oss_release+0x20b/0x280 sound/core/oss/pcm_oss.c:2431 __fput+0x327/0x7e0 fs/file_table.c:210 .... It's a spurious snd_BUG_ON() that invokes WARN_ON(). An error returned from snd_pcm_hw_refine() shouldn't be treated as an exception, but dealt as a normal error path. There are a couple of other places using snd_BUG_ON() unnecessarily, and this patch removes these spurious snd_BUG_ON() calls. Reported-by: syzbot+6f11c7e2a1b91d466432@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
idosch
pushed a commit
to idosch/linux
that referenced
this pull request
Mar 14, 2018
f7c83bc ("net: xfrm: use __this_cpu_read per-cpu helper") added a __this_cpu_read() call inside ipcomp_alloc_tfms(). At the time, __this_cpu_read() required the caller to either not care about races or to handle preemption/interrupt issues. 3.15 tightened the rules around some per-cpu operations, and now __this_cpu_read() should never be used in a preemptible context. On 3.15 and later, we need to use this_cpu_read() instead. syzkaller reported this leading to the following kernel BUG while fuzzing sendmsg: BUG: using __this_cpu_read() in preemptible [00000000] code: repro/3101 caller is ipcomp_init_state+0x185/0x990 CPU: 3 PID: 3101 Comm: repro Not tainted 4.16.0-rc4-00123-g86f84779d8e9 torvalds#154 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 Call Trace: dump_stack+0xb9/0x115 check_preemption_disabled+0x1cb/0x1f0 ipcomp_init_state+0x185/0x990 ? __xfrm_init_state+0x876/0xc20 ? lock_downgrade+0x5e0/0x5e0 ipcomp4_init_state+0xaa/0x7c0 __xfrm_init_state+0x3eb/0xc20 xfrm_init_state+0x19/0x60 pfkey_add+0x20df/0x36f0 ? pfkey_broadcast+0x3dd/0x600 ? pfkey_sock_destruct+0x340/0x340 ? pfkey_seq_stop+0x80/0x80 ? __skb_clone+0x236/0x750 ? kmem_cache_alloc+0x1f6/0x260 ? pfkey_sock_destruct+0x340/0x340 ? pfkey_process+0x62a/0x6f0 pfkey_process+0x62a/0x6f0 ? pfkey_send_new_mapping+0x11c0/0x11c0 ? mutex_lock_io_nested+0x1390/0x1390 pfkey_sendmsg+0x383/0x750 ? dump_sp+0x430/0x430 sock_sendmsg+0xc0/0x100 ___sys_sendmsg+0x6c8/0x8b0 ? copy_msghdr_from_user+0x3b0/0x3b0 ? pagevec_lru_move_fn+0x144/0x1f0 ? find_held_lock+0x32/0x1c0 ? do_huge_pmd_anonymous_page+0xc43/0x11e0 ? lock_downgrade+0x5e0/0x5e0 ? get_kernel_page+0xb0/0xb0 ? _raw_spin_unlock+0x29/0x40 ? do_huge_pmd_anonymous_page+0x400/0x11e0 ? __handle_mm_fault+0x553/0x2460 ? __fget_light+0x163/0x1f0 ? __sys_sendmsg+0xc7/0x170 __sys_sendmsg+0xc7/0x170 ? SyS_shutdown+0x1a0/0x1a0 ? __do_page_fault+0x5a0/0xca0 ? lock_downgrade+0x5e0/0x5e0 SyS_sendmsg+0x27/0x40 ? __sys_sendmsg+0x170/0x170 do_syscall_64+0x19f/0x640 entry_SYSCALL_64_after_hwframe+0x42/0xb7 RIP: 0033:0x7f0ee73dfb79 RSP: 002b:00007ffe14fc15a8 EFLAGS: 00000207 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0ee73dfb79 RDX: 0000000000000000 RSI: 00000000208befc8 RDI: 0000000000000004 RBP: 00007ffe14fc15b0 R08: 00007ffe14fc15c0 R09: 00007ffe14fc15c0 R10: 0000000000000000 R11: 0000000000000207 R12: 0000000000400440 R13: 00007ffe14fc16b0 R14: 0000000000000000 R15: 0000000000000000 Signed-off-by: Greg Hackmann <ghackmann@google.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Apr 8, 2018
commit 0dcd787 upstream. f7c83bc ("net: xfrm: use __this_cpu_read per-cpu helper") added a __this_cpu_read() call inside ipcomp_alloc_tfms(). At the time, __this_cpu_read() required the caller to either not care about races or to handle preemption/interrupt issues. 3.15 tightened the rules around some per-cpu operations, and now __this_cpu_read() should never be used in a preemptible context. On 3.15 and later, we need to use this_cpu_read() instead. syzkaller reported this leading to the following kernel BUG while fuzzing sendmsg: BUG: using __this_cpu_read() in preemptible [00000000] code: repro/3101 caller is ipcomp_init_state+0x185/0x990 CPU: 3 PID: 3101 Comm: repro Not tainted 4.16.0-rc4-00123-g86f84779d8e9 torvalds#154 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 Call Trace: dump_stack+0xb9/0x115 check_preemption_disabled+0x1cb/0x1f0 ipcomp_init_state+0x185/0x990 ? __xfrm_init_state+0x876/0xc20 ? lock_downgrade+0x5e0/0x5e0 ipcomp4_init_state+0xaa/0x7c0 __xfrm_init_state+0x3eb/0xc20 xfrm_init_state+0x19/0x60 pfkey_add+0x20df/0x36f0 ? pfkey_broadcast+0x3dd/0x600 ? pfkey_sock_destruct+0x340/0x340 ? pfkey_seq_stop+0x80/0x80 ? __skb_clone+0x236/0x750 ? kmem_cache_alloc+0x1f6/0x260 ? pfkey_sock_destruct+0x340/0x340 ? pfkey_process+0x62a/0x6f0 pfkey_process+0x62a/0x6f0 ? pfkey_send_new_mapping+0x11c0/0x11c0 ? mutex_lock_io_nested+0x1390/0x1390 pfkey_sendmsg+0x383/0x750 ? dump_sp+0x430/0x430 sock_sendmsg+0xc0/0x100 ___sys_sendmsg+0x6c8/0x8b0 ? copy_msghdr_from_user+0x3b0/0x3b0 ? pagevec_lru_move_fn+0x144/0x1f0 ? find_held_lock+0x32/0x1c0 ? do_huge_pmd_anonymous_page+0xc43/0x11e0 ? lock_downgrade+0x5e0/0x5e0 ? get_kernel_page+0xb0/0xb0 ? _raw_spin_unlock+0x29/0x40 ? do_huge_pmd_anonymous_page+0x400/0x11e0 ? __handle_mm_fault+0x553/0x2460 ? __fget_light+0x163/0x1f0 ? __sys_sendmsg+0xc7/0x170 __sys_sendmsg+0xc7/0x170 ? SyS_shutdown+0x1a0/0x1a0 ? __do_page_fault+0x5a0/0xca0 ? lock_downgrade+0x5e0/0x5e0 SyS_sendmsg+0x27/0x40 ? __sys_sendmsg+0x170/0x170 do_syscall_64+0x19f/0x640 entry_SYSCALL_64_after_hwframe+0x42/0xb7 RIP: 0033:0x7f0ee73dfb79 RSP: 002b:00007ffe14fc15a8 EFLAGS: 00000207 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0ee73dfb79 RDX: 0000000000000000 RSI: 00000000208befc8 RDI: 0000000000000004 RBP: 00007ffe14fc15b0 R08: 00007ffe14fc15c0 R09: 00007ffe14fc15c0 R10: 0000000000000000 R11: 0000000000000207 R12: 0000000000400440 R13: 00007ffe14fc16b0 R14: 0000000000000000 R15: 0000000000000000 Signed-off-by: Greg Hackmann <ghackmann@google.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Apr 8, 2018
commit 0dcd787 upstream. f7c83bc ("net: xfrm: use __this_cpu_read per-cpu helper") added a __this_cpu_read() call inside ipcomp_alloc_tfms(). At the time, __this_cpu_read() required the caller to either not care about races or to handle preemption/interrupt issues. 3.15 tightened the rules around some per-cpu operations, and now __this_cpu_read() should never be used in a preemptible context. On 3.15 and later, we need to use this_cpu_read() instead. syzkaller reported this leading to the following kernel BUG while fuzzing sendmsg: BUG: using __this_cpu_read() in preemptible [00000000] code: repro/3101 caller is ipcomp_init_state+0x185/0x990 CPU: 3 PID: 3101 Comm: repro Not tainted 4.16.0-rc4-00123-g86f84779d8e9 torvalds#154 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 Call Trace: dump_stack+0xb9/0x115 check_preemption_disabled+0x1cb/0x1f0 ipcomp_init_state+0x185/0x990 ? __xfrm_init_state+0x876/0xc20 ? lock_downgrade+0x5e0/0x5e0 ipcomp4_init_state+0xaa/0x7c0 __xfrm_init_state+0x3eb/0xc20 xfrm_init_state+0x19/0x60 pfkey_add+0x20df/0x36f0 ? pfkey_broadcast+0x3dd/0x600 ? pfkey_sock_destruct+0x340/0x340 ? pfkey_seq_stop+0x80/0x80 ? __skb_clone+0x236/0x750 ? kmem_cache_alloc+0x1f6/0x260 ? pfkey_sock_destruct+0x340/0x340 ? pfkey_process+0x62a/0x6f0 pfkey_process+0x62a/0x6f0 ? pfkey_send_new_mapping+0x11c0/0x11c0 ? mutex_lock_io_nested+0x1390/0x1390 pfkey_sendmsg+0x383/0x750 ? dump_sp+0x430/0x430 sock_sendmsg+0xc0/0x100 ___sys_sendmsg+0x6c8/0x8b0 ? copy_msghdr_from_user+0x3b0/0x3b0 ? pagevec_lru_move_fn+0x144/0x1f0 ? find_held_lock+0x32/0x1c0 ? do_huge_pmd_anonymous_page+0xc43/0x11e0 ? lock_downgrade+0x5e0/0x5e0 ? get_kernel_page+0xb0/0xb0 ? _raw_spin_unlock+0x29/0x40 ? do_huge_pmd_anonymous_page+0x400/0x11e0 ? __handle_mm_fault+0x553/0x2460 ? __fget_light+0x163/0x1f0 ? __sys_sendmsg+0xc7/0x170 __sys_sendmsg+0xc7/0x170 ? SyS_shutdown+0x1a0/0x1a0 ? __do_page_fault+0x5a0/0xca0 ? lock_downgrade+0x5e0/0x5e0 SyS_sendmsg+0x27/0x40 ? __sys_sendmsg+0x170/0x170 do_syscall_64+0x19f/0x640 entry_SYSCALL_64_after_hwframe+0x42/0xb7 RIP: 0033:0x7f0ee73dfb79 RSP: 002b:00007ffe14fc15a8 EFLAGS: 00000207 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0ee73dfb79 RDX: 0000000000000000 RSI: 00000000208befc8 RDI: 0000000000000004 RBP: 00007ffe14fc15b0 R08: 00007ffe14fc15c0 R09: 00007ffe14fc15c0 R10: 0000000000000000 R11: 0000000000000207 R12: 0000000000400440 R13: 00007ffe14fc16b0 R14: 0000000000000000 R15: 0000000000000000 Signed-off-by: Greg Hackmann <ghackmann@google.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
damentz
referenced
this pull request
in zen-kernel/zen-kernel
Apr 8, 2018
commit 0dcd787 upstream. f7c83bc ("net: xfrm: use __this_cpu_read per-cpu helper") added a __this_cpu_read() call inside ipcomp_alloc_tfms(). At the time, __this_cpu_read() required the caller to either not care about races or to handle preemption/interrupt issues. 3.15 tightened the rules around some per-cpu operations, and now __this_cpu_read() should never be used in a preemptible context. On 3.15 and later, we need to use this_cpu_read() instead. syzkaller reported this leading to the following kernel BUG while fuzzing sendmsg: BUG: using __this_cpu_read() in preemptible [00000000] code: repro/3101 caller is ipcomp_init_state+0x185/0x990 CPU: 3 PID: 3101 Comm: repro Not tainted 4.16.0-rc4-00123-g86f84779d8e9 #154 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 Call Trace: dump_stack+0xb9/0x115 check_preemption_disabled+0x1cb/0x1f0 ipcomp_init_state+0x185/0x990 ? __xfrm_init_state+0x876/0xc20 ? lock_downgrade+0x5e0/0x5e0 ipcomp4_init_state+0xaa/0x7c0 __xfrm_init_state+0x3eb/0xc20 xfrm_init_state+0x19/0x60 pfkey_add+0x20df/0x36f0 ? pfkey_broadcast+0x3dd/0x600 ? pfkey_sock_destruct+0x340/0x340 ? pfkey_seq_stop+0x80/0x80 ? __skb_clone+0x236/0x750 ? kmem_cache_alloc+0x1f6/0x260 ? pfkey_sock_destruct+0x340/0x340 ? pfkey_process+0x62a/0x6f0 pfkey_process+0x62a/0x6f0 ? pfkey_send_new_mapping+0x11c0/0x11c0 ? mutex_lock_io_nested+0x1390/0x1390 pfkey_sendmsg+0x383/0x750 ? dump_sp+0x430/0x430 sock_sendmsg+0xc0/0x100 ___sys_sendmsg+0x6c8/0x8b0 ? copy_msghdr_from_user+0x3b0/0x3b0 ? pagevec_lru_move_fn+0x144/0x1f0 ? find_held_lock+0x32/0x1c0 ? do_huge_pmd_anonymous_page+0xc43/0x11e0 ? lock_downgrade+0x5e0/0x5e0 ? get_kernel_page+0xb0/0xb0 ? _raw_spin_unlock+0x29/0x40 ? do_huge_pmd_anonymous_page+0x400/0x11e0 ? __handle_mm_fault+0x553/0x2460 ? __fget_light+0x163/0x1f0 ? __sys_sendmsg+0xc7/0x170 __sys_sendmsg+0xc7/0x170 ? SyS_shutdown+0x1a0/0x1a0 ? __do_page_fault+0x5a0/0xca0 ? lock_downgrade+0x5e0/0x5e0 SyS_sendmsg+0x27/0x40 ? __sys_sendmsg+0x170/0x170 do_syscall_64+0x19f/0x640 entry_SYSCALL_64_after_hwframe+0x42/0xb7 RIP: 0033:0x7f0ee73dfb79 RSP: 002b:00007ffe14fc15a8 EFLAGS: 00000207 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0ee73dfb79 RDX: 0000000000000000 RSI: 00000000208befc8 RDI: 0000000000000004 RBP: 00007ffe14fc15b0 R08: 00007ffe14fc15c0 R09: 00007ffe14fc15c0 R10: 0000000000000000 R11: 0000000000000207 R12: 0000000000400440 R13: 00007ffe14fc16b0 R14: 0000000000000000 R15: 0000000000000000 Signed-off-by: Greg Hackmann <ghackmann@google.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
May 29, 2018
[ Upstream commit 0dcd787 ] f7c83bc ("net: xfrm: use __this_cpu_read per-cpu helper") added a __this_cpu_read() call inside ipcomp_alloc_tfms(). At the time, __this_cpu_read() required the caller to either not care about races or to handle preemption/interrupt issues. 3.15 tightened the rules around some per-cpu operations, and now __this_cpu_read() should never be used in a preemptible context. On 3.15 and later, we need to use this_cpu_read() instead. syzkaller reported this leading to the following kernel BUG while fuzzing sendmsg: BUG: using __this_cpu_read() in preemptible [00000000] code: repro/3101 caller is ipcomp_init_state+0x185/0x990 CPU: 3 PID: 3101 Comm: repro Not tainted 4.16.0-rc4-00123-g86f84779d8e9 torvalds#154 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 Call Trace: dump_stack+0xb9/0x115 check_preemption_disabled+0x1cb/0x1f0 ipcomp_init_state+0x185/0x990 ? __xfrm_init_state+0x876/0xc20 ? lock_downgrade+0x5e0/0x5e0 ipcomp4_init_state+0xaa/0x7c0 __xfrm_init_state+0x3eb/0xc20 xfrm_init_state+0x19/0x60 pfkey_add+0x20df/0x36f0 ? pfkey_broadcast+0x3dd/0x600 ? pfkey_sock_destruct+0x340/0x340 ? pfkey_seq_stop+0x80/0x80 ? __skb_clone+0x236/0x750 ? kmem_cache_alloc+0x1f6/0x260 ? pfkey_sock_destruct+0x340/0x340 ? pfkey_process+0x62a/0x6f0 pfkey_process+0x62a/0x6f0 ? pfkey_send_new_mapping+0x11c0/0x11c0 ? mutex_lock_io_nested+0x1390/0x1390 pfkey_sendmsg+0x383/0x750 ? dump_sp+0x430/0x430 sock_sendmsg+0xc0/0x100 ___sys_sendmsg+0x6c8/0x8b0 ? copy_msghdr_from_user+0x3b0/0x3b0 ? pagevec_lru_move_fn+0x144/0x1f0 ? find_held_lock+0x32/0x1c0 ? do_huge_pmd_anonymous_page+0xc43/0x11e0 ? lock_downgrade+0x5e0/0x5e0 ? get_kernel_page+0xb0/0xb0 ? _raw_spin_unlock+0x29/0x40 ? do_huge_pmd_anonymous_page+0x400/0x11e0 ? __handle_mm_fault+0x553/0x2460 ? __fget_light+0x163/0x1f0 ? __sys_sendmsg+0xc7/0x170 __sys_sendmsg+0xc7/0x170 ? SyS_shutdown+0x1a0/0x1a0 ? __do_page_fault+0x5a0/0xca0 ? lock_downgrade+0x5e0/0x5e0 SyS_sendmsg+0x27/0x40 ? __sys_sendmsg+0x170/0x170 do_syscall_64+0x19f/0x640 entry_SYSCALL_64_after_hwframe+0x42/0xb7 RIP: 0033:0x7f0ee73dfb79 RSP: 002b:00007ffe14fc15a8 EFLAGS: 00000207 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0ee73dfb79 RDX: 0000000000000000 RSI: 00000000208befc8 RDI: 0000000000000004 RBP: 00007ffe14fc15b0 R08: 00007ffe14fc15c0 R09: 00007ffe14fc15c0 R10: 0000000000000000 R11: 0000000000000207 R12: 0000000000400440 R13: 00007ffe14fc16b0 R14: 0000000000000000 R15: 0000000000000000 Signed-off-by: Greg Hackmann <ghackmann@google.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
nemunaire
pushed a commit
to nemunaire/CI20_linux
that referenced
this pull request
Jun 6, 2018
commit 0dcd787 upstream. f7c83bc ("net: xfrm: use __this_cpu_read per-cpu helper") added a __this_cpu_read() call inside ipcomp_alloc_tfms(). At the time, __this_cpu_read() required the caller to either not care about races or to handle preemption/interrupt issues. 3.15 tightened the rules around some per-cpu operations, and now __this_cpu_read() should never be used in a preemptible context. On 3.15 and later, we need to use this_cpu_read() instead. syzkaller reported this leading to the following kernel BUG while fuzzing sendmsg: BUG: using __this_cpu_read() in preemptible [00000000] code: repro/3101 caller is ipcomp_init_state+0x185/0x990 CPU: 3 PID: 3101 Comm: repro Not tainted 4.16.0-rc4-00123-g86f84779d8e9 torvalds#154 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 Call Trace: dump_stack+0xb9/0x115 check_preemption_disabled+0x1cb/0x1f0 ipcomp_init_state+0x185/0x990 ? __xfrm_init_state+0x876/0xc20 ? lock_downgrade+0x5e0/0x5e0 ipcomp4_init_state+0xaa/0x7c0 __xfrm_init_state+0x3eb/0xc20 xfrm_init_state+0x19/0x60 pfkey_add+0x20df/0x36f0 ? pfkey_broadcast+0x3dd/0x600 ? pfkey_sock_destruct+0x340/0x340 ? pfkey_seq_stop+0x80/0x80 ? __skb_clone+0x236/0x750 ? kmem_cache_alloc+0x1f6/0x260 ? pfkey_sock_destruct+0x340/0x340 ? pfkey_process+0x62a/0x6f0 pfkey_process+0x62a/0x6f0 ? pfkey_send_new_mapping+0x11c0/0x11c0 ? mutex_lock_io_nested+0x1390/0x1390 pfkey_sendmsg+0x383/0x750 ? dump_sp+0x430/0x430 sock_sendmsg+0xc0/0x100 ___sys_sendmsg+0x6c8/0x8b0 ? copy_msghdr_from_user+0x3b0/0x3b0 ? pagevec_lru_move_fn+0x144/0x1f0 ? find_held_lock+0x32/0x1c0 ? do_huge_pmd_anonymous_page+0xc43/0x11e0 ? lock_downgrade+0x5e0/0x5e0 ? get_kernel_page+0xb0/0xb0 ? _raw_spin_unlock+0x29/0x40 ? do_huge_pmd_anonymous_page+0x400/0x11e0 ? __handle_mm_fault+0x553/0x2460 ? __fget_light+0x163/0x1f0 ? __sys_sendmsg+0xc7/0x170 __sys_sendmsg+0xc7/0x170 ? SyS_shutdown+0x1a0/0x1a0 ? __do_page_fault+0x5a0/0xca0 ? lock_downgrade+0x5e0/0x5e0 SyS_sendmsg+0x27/0x40 ? __sys_sendmsg+0x170/0x170 do_syscall_64+0x19f/0x640 entry_SYSCALL_64_after_hwframe+0x42/0xb7 RIP: 0033:0x7f0ee73dfb79 RSP: 002b:00007ffe14fc15a8 EFLAGS: 00000207 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0ee73dfb79 RDX: 0000000000000000 RSI: 00000000208befc8 RDI: 0000000000000004 RBP: 00007ffe14fc15b0 R08: 00007ffe14fc15c0 R09: 00007ffe14fc15c0 R10: 0000000000000000 R11: 0000000000000207 R12: 0000000000400440 R13: 00007ffe14fc16b0 R14: 0000000000000000 R15: 0000000000000000 Signed-off-by: Greg Hackmann <ghackmann@google.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Aug 27, 2018
While running regressions, observed below kernel panic when sdio disconnect called. This is because of, kthread_stop() is taking care of wait_for_completion() by default. When wait_for_completion triggered in kthread_stop and as it was done already, giving kernel panic. Hence, removing redundant wait_for_completion() from rsi_kill_thread(). ... skipping ... BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff810a63df>] exit_creds+0x1f/0x50 PGD 0 Oops: 0002 [#1] SMP CPU: 0 PID: 6502 Comm: rmmod Tainted: G OE 4.15.9-Generic torvalds#154-Ubuntu Hardware name: Dell Inc. Edge Gateway 3003/ , BIOS 01.00.00 04/17/2017 Stack: ffff88007392e600 ffff880075847dc0 ffffffff8108160a 0000000000000000 ffff88007392e600 ffff880075847de8 ffffffff810a484b ffff880076127000 ffff88003cd3a800 ffff880074f12a00 ffff880075847e28 ffffffffc09bed15 Call Trace: [<ffffffff8108160a>] __put_task_struct+0x5a/0x140 [<ffffffff810a484b>] kthread_stop+0x10b/0x110 [<ffffffffc09bed15>] rsi_disconnect+0x2f5/0x300 [ven_rsi_sdio] [<ffffffff81578bcb>] ? __pm_runtime_resume+0x5b/0x80 [<ffffffff816f0918>] sdio_bus_remove+0x38/0x100 [<ffffffff8156cc64>] __device_release_driver+0xa4/0x150 [<ffffffff8156d7a5>] driver_detach+0xb5/0xc0 [<ffffffff8156c6c5>] bus_remove_driver+0x55/0xd0 [<ffffffff8156dfbc>] driver_unregister+0x2c/0x50 [<ffffffff816f0b8a>] sdio_unregister_driver+0x1a/0x20 [<ffffffffc09bf0f5>] rsi_module_exit+0x15/0x30 [ven_rsi_sdio] [<ffffffff8110cad8>] SyS_delete_module+0x1b8/0x210 [<ffffffff81851dc8>] entry_SYSCALL_64_fastpath+0x1c/0xbb Signed-off-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Aug 31, 2018
While running regressions, observed below kernel panic when sdio disconnect called. This is because of, kthread_stop() is taking care of wait_for_completion() by default. When wait_for_completion triggered in kthread_stop and as it was done already, giving kernel panic. Hence, removing redundant wait_for_completion() from rsi_kill_thread(). ... skipping ... BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff810a63df>] exit_creds+0x1f/0x50 PGD 0 Oops: 0002 [#1] SMP CPU: 0 PID: 6502 Comm: rmmod Tainted: G OE 4.15.9-Generic torvalds#154-Ubuntu Hardware name: Dell Inc. Edge Gateway 3003/ , BIOS 01.00.00 04/17/2017 Stack: ffff88007392e600 ffff880075847dc0 ffffffff8108160a 0000000000000000 ffff88007392e600 ffff880075847de8 ffffffff810a484b ffff880076127000 ffff88003cd3a800 ffff880074f12a00 ffff880075847e28 ffffffffc09bed15 Call Trace: [<ffffffff8108160a>] __put_task_struct+0x5a/0x140 [<ffffffff810a484b>] kthread_stop+0x10b/0x110 [<ffffffffc09bed15>] rsi_disconnect+0x2f5/0x300 [ven_rsi_sdio] [<ffffffff81578bcb>] ? __pm_runtime_resume+0x5b/0x80 [<ffffffff816f0918>] sdio_bus_remove+0x38/0x100 [<ffffffff8156cc64>] __device_release_driver+0xa4/0x150 [<ffffffff8156d7a5>] driver_detach+0xb5/0xc0 [<ffffffff8156c6c5>] bus_remove_driver+0x55/0xd0 [<ffffffff8156dfbc>] driver_unregister+0x2c/0x50 [<ffffffff816f0b8a>] sdio_unregister_driver+0x1a/0x20 [<ffffffffc09bf0f5>] rsi_module_exit+0x15/0x30 [ven_rsi_sdio] [<ffffffff8110cad8>] SyS_delete_module+0x1b8/0x210 [<ffffffff81851dc8>] entry_SYSCALL_64_fastpath+0x1c/0xbb Signed-off-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Dec 30, 2018
The bpfilter.ko module can be removed while functions of the bpfilter.ko are executing. so panic can occurred. in order to protect that, locks can be used. a bpfilter_lock protects routines in the __bpfilter_process_sockopt() but it's not enough because __exit routine can be executed concurrently. Now, the bpfilter_umh can not run in parallel. So, the module do not removed while it's being used and it do not double-create UMH process. The members of the umh_info and the bpfilter_umh_ops are protected by the bpfilter_umh_ops.lock. test commands: while : do iptables -I FORWARD -m string --string ap --algo kmp & modprobe -rv bpfilter & done splat looks like: [ 298.623435] BUG: unable to handle kernel paging request at fffffbfff807440b [ 298.628512] #PF error: [normal kernel read fault] [ 298.633018] PGD 124327067 P4D 124327067 PUD 11c1a3067 PMD 119eb2067 PTE 0 [ 298.638859] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI [ 298.638859] CPU: 0 PID: 2997 Comm: iptables Not tainted 4.20.0+ torvalds#154 [ 298.638859] RIP: 0010:__mutex_lock+0x6b9/0x16a0 [ 298.638859] Code: c0 00 00 e8 89 82 ff ff 80 bd 8f fc ff ff 00 0f 85 d9 05 00 00 48 8b 85 80 fc ff ff 48 bf 00 00 00 00 00 fc ff df 48 c1 e8 03 <80> 3c 38 00 0f 85 1d 0e 00 00 48 8b 85 c8 fc ff ff 49 39 47 58 c6 [ 298.638859] RSP: 0018:ffff88810e7777a0 EFLAGS: 00010202 [ 298.638859] RAX: 1ffffffff807440b RBX: ffff888111bd4d80 RCX: 0000000000000000 [ 298.638859] RDX: 1ffff110235ff806 RSI: ffff888111bd5538 RDI: dffffc0000000000 [ 298.638859] RBP: ffff88810e777b30 R08: 0000000080000002 R09: 0000000000000000 [ 298.638859] R10: 0000000000000000 R11: 0000000000000000 R12: fffffbfff168a42c [ 298.638859] R13: ffff888111bd4d80 R14: ffff8881040e9a05 R15: ffffffffc03a2000 [ 298.638859] FS: 00007f39e3758700(0000) GS:ffff88811ae00000(0000) knlGS:0000000000000000 [ 298.638859] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 298.638859] CR2: fffffbfff807440b CR3: 000000011243e000 CR4: 00000000001006f0 [ 298.638859] Call Trace: [ 298.638859] ? mutex_lock_io_nested+0x1560/0x1560 [ 298.638859] ? kasan_kmalloc+0xa0/0xd0 [ 298.638859] ? kmem_cache_alloc+0x1c2/0x260 [ 298.638859] ? __alloc_file+0x92/0x3c0 [ 298.638859] ? alloc_empty_file+0x43/0x120 [ 298.638859] ? alloc_file_pseudo+0x220/0x330 [ 298.638859] ? sock_alloc_file+0x39/0x160 [ 298.638859] ? __sys_socket+0x113/0x1d0 [ 298.638859] ? __x64_sys_socket+0x6f/0xb0 [ 298.638859] ? do_syscall_64+0x138/0x560 [ 298.638859] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 298.638859] ? __alloc_file+0x92/0x3c0 [ 298.638859] ? init_object+0x6b/0x80 [ 298.638859] ? cyc2ns_read_end+0x10/0x10 [ 298.638859] ? cyc2ns_read_end+0x10/0x10 [ 298.638859] ? hlock_class+0x140/0x140 [ 298.638859] ? sched_clock_local+0xd4/0x140 [ 298.638859] ? sched_clock_local+0xd4/0x140 [ 298.638859] ? check_flags.part.37+0x440/0x440 [ 298.638859] ? __lock_acquire+0x4f90/0x4f90 [ 298.638859] ? set_rq_offline.part.89+0x140/0x140 [ ... ] Fixes: d2ba09c ("net: add skeleton of bpfilter kernel module") Signed-off-by: Taehee Yoo <ap420073@gmail.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 7, 2019
The bpfilter.ko module can be removed while functions of the bpfilter.ko are executing. so panic can occurred. in order to protect that, locks can be used. a bpfilter_lock protects routines in the __bpfilter_process_sockopt() but it's not enough because __exit routine can be executed concurrently. Now, the bpfilter_umh can not run in parallel. So, the module do not removed while it's being used and it do not double-create UMH process. The members of the umh_info and the bpfilter_umh_ops are protected by the bpfilter_umh_ops.lock. test commands: while : do iptables -I FORWARD -m string --string ap --algo kmp & modprobe -rv bpfilter & done splat looks like: [ 298.623435] BUG: unable to handle kernel paging request at fffffbfff807440b [ 298.628512] #PF error: [normal kernel read fault] [ 298.633018] PGD 124327067 P4D 124327067 PUD 11c1a3067 PMD 119eb2067 PTE 0 [ 298.638859] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI [ 298.638859] CPU: 0 PID: 2997 Comm: iptables Not tainted 4.20.0+ torvalds#154 [ 298.638859] RIP: 0010:__mutex_lock+0x6b9/0x16a0 [ 298.638859] Code: c0 00 00 e8 89 82 ff ff 80 bd 8f fc ff ff 00 0f 85 d9 05 00 00 48 8b 85 80 fc ff ff 48 bf 00 00 00 00 00 fc ff df 48 c1 e8 03 <80> 3c 38 00 0f 85 1d 0e 00 00 48 8b 85 c8 fc ff ff 49 39 47 58 c6 [ 298.638859] RSP: 0018:ffff88810e7777a0 EFLAGS: 00010202 [ 298.638859] RAX: 1ffffffff807440b RBX: ffff888111bd4d80 RCX: 0000000000000000 [ 298.638859] RDX: 1ffff110235ff806 RSI: ffff888111bd5538 RDI: dffffc0000000000 [ 298.638859] RBP: ffff88810e777b30 R08: 0000000080000002 R09: 0000000000000000 [ 298.638859] R10: 0000000000000000 R11: 0000000000000000 R12: fffffbfff168a42c [ 298.638859] R13: ffff888111bd4d80 R14: ffff8881040e9a05 R15: ffffffffc03a2000 [ 298.638859] FS: 00007f39e3758700(0000) GS:ffff88811ae00000(0000) knlGS:0000000000000000 [ 298.638859] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 298.638859] CR2: fffffbfff807440b CR3: 000000011243e000 CR4: 00000000001006f0 [ 298.638859] Call Trace: [ 298.638859] ? mutex_lock_io_nested+0x1560/0x1560 [ 298.638859] ? kasan_kmalloc+0xa0/0xd0 [ 298.638859] ? kmem_cache_alloc+0x1c2/0x260 [ 298.638859] ? __alloc_file+0x92/0x3c0 [ 298.638859] ? alloc_empty_file+0x43/0x120 [ 298.638859] ? alloc_file_pseudo+0x220/0x330 [ 298.638859] ? sock_alloc_file+0x39/0x160 [ 298.638859] ? __sys_socket+0x113/0x1d0 [ 298.638859] ? __x64_sys_socket+0x6f/0xb0 [ 298.638859] ? do_syscall_64+0x138/0x560 [ 298.638859] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 298.638859] ? __alloc_file+0x92/0x3c0 [ 298.638859] ? init_object+0x6b/0x80 [ 298.638859] ? cyc2ns_read_end+0x10/0x10 [ 298.638859] ? cyc2ns_read_end+0x10/0x10 [ 298.638859] ? hlock_class+0x140/0x140 [ 298.638859] ? sched_clock_local+0xd4/0x140 [ 298.638859] ? sched_clock_local+0xd4/0x140 [ 298.638859] ? check_flags.part.37+0x440/0x440 [ 298.638859] ? __lock_acquire+0x4f90/0x4f90 [ 298.638859] ? set_rq_offline.part.89+0x140/0x140 [ ... ] Fixes: d2ba09c ("net: add skeleton of bpfilter kernel module") Signed-off-by: Taehee Yoo <ap420073@gmail.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 14, 2019
The bpfilter.ko module can be removed while functions of the bpfilter.ko are executing. so panic can occurred. in order to protect that, locks can be used. a bpfilter_lock protects routines in the __bpfilter_process_sockopt() but it's not enough because __exit routine can be executed concurrently. Now, the bpfilter_umh can not run in parallel. So, the module do not removed while it's being used and it do not double-create UMH process. The members of the umh_info and the bpfilter_umh_ops are protected by the bpfilter_umh_ops.lock. test commands: while : do iptables -I FORWARD -m string --string ap --algo kmp & modprobe -rv bpfilter & done splat looks like: [ 298.623435] BUG: unable to handle kernel paging request at fffffbfff807440b [ 298.628512] #PF error: [normal kernel read fault] [ 298.633018] PGD 124327067 P4D 124327067 PUD 11c1a3067 PMD 119eb2067 PTE 0 [ 298.638859] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI [ 298.638859] CPU: 0 PID: 2997 Comm: iptables Not tainted 4.20.0+ torvalds#154 [ 298.638859] RIP: 0010:__mutex_lock+0x6b9/0x16a0 [ 298.638859] Code: c0 00 00 e8 89 82 ff ff 80 bd 8f fc ff ff 00 0f 85 d9 05 00 00 48 8b 85 80 fc ff ff 48 bf 00 00 00 00 00 fc ff df 48 c1 e8 03 <80> 3c 38 00 0f 85 1d 0e 00 00 48 8b 85 c8 fc ff ff 49 39 47 58 c6 [ 298.638859] RSP: 0018:ffff88810e7777a0 EFLAGS: 00010202 [ 298.638859] RAX: 1ffffffff807440b RBX: ffff888111bd4d80 RCX: 0000000000000000 [ 298.638859] RDX: 1ffff110235ff806 RSI: ffff888111bd5538 RDI: dffffc0000000000 [ 298.638859] RBP: ffff88810e777b30 R08: 0000000080000002 R09: 0000000000000000 [ 298.638859] R10: 0000000000000000 R11: 0000000000000000 R12: fffffbfff168a42c [ 298.638859] R13: ffff888111bd4d80 R14: ffff8881040e9a05 R15: ffffffffc03a2000 [ 298.638859] FS: 00007f39e3758700(0000) GS:ffff88811ae00000(0000) knlGS:0000000000000000 [ 298.638859] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 298.638859] CR2: fffffbfff807440b CR3: 000000011243e000 CR4: 00000000001006f0 [ 298.638859] Call Trace: [ 298.638859] ? mutex_lock_io_nested+0x1560/0x1560 [ 298.638859] ? kasan_kmalloc+0xa0/0xd0 [ 298.638859] ? kmem_cache_alloc+0x1c2/0x260 [ 298.638859] ? __alloc_file+0x92/0x3c0 [ 298.638859] ? alloc_empty_file+0x43/0x120 [ 298.638859] ? alloc_file_pseudo+0x220/0x330 [ 298.638859] ? sock_alloc_file+0x39/0x160 [ 298.638859] ? __sys_socket+0x113/0x1d0 [ 298.638859] ? __x64_sys_socket+0x6f/0xb0 [ 298.638859] ? do_syscall_64+0x138/0x560 [ 298.638859] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 298.638859] ? __alloc_file+0x92/0x3c0 [ 298.638859] ? init_object+0x6b/0x80 [ 298.638859] ? cyc2ns_read_end+0x10/0x10 [ 298.638859] ? cyc2ns_read_end+0x10/0x10 [ 298.638859] ? hlock_class+0x140/0x140 [ 298.638859] ? sched_clock_local+0xd4/0x140 [ 298.638859] ? sched_clock_local+0xd4/0x140 [ 298.638859] ? check_flags.part.37+0x440/0x440 [ 298.638859] ? __lock_acquire+0x4f90/0x4f90 [ 298.638859] ? set_rq_offline.part.89+0x140/0x140 [ ... ] Fixes: d2ba09c ("net: add skeleton of bpfilter kernel module") Signed-off-by: Taehee Yoo <ap420073@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
ndreys
pushed a commit
to ndreys/linux
that referenced
this pull request
Mar 12, 2019
The bpfilter.ko module can be removed while functions of the bpfilter.ko are executing. so panic can occurred. in order to protect that, locks can be used. a bpfilter_lock protects routines in the __bpfilter_process_sockopt() but it's not enough because __exit routine can be executed concurrently. Now, the bpfilter_umh can not run in parallel. So, the module do not removed while it's being used and it do not double-create UMH process. The members of the umh_info and the bpfilter_umh_ops are protected by the bpfilter_umh_ops.lock. test commands: while : do iptables -I FORWARD -m string --string ap --algo kmp & modprobe -rv bpfilter & done splat looks like: [ 298.623435] BUG: unable to handle kernel paging request at fffffbfff807440b [ 298.628512] #PF error: [normal kernel read fault] [ 298.633018] PGD 124327067 P4D 124327067 PUD 11c1a3067 PMD 119eb2067 PTE 0 [ 298.638859] Oops: 0000 [lunn#1] SMP DEBUG_PAGEALLOC KASAN PTI [ 298.638859] CPU: 0 PID: 2997 Comm: iptables Not tainted 4.20.0+ torvalds#154 [ 298.638859] RIP: 0010:__mutex_lock+0x6b9/0x16a0 [ 298.638859] Code: c0 00 00 e8 89 82 ff ff 80 bd 8f fc ff ff 00 0f 85 d9 05 00 00 48 8b 85 80 fc ff ff 48 bf 00 00 00 00 00 fc ff df 48 c1 e8 03 <80> 3c 38 00 0f 85 1d 0e 00 00 48 8b 85 c8 fc ff ff 49 39 47 58 c6 [ 298.638859] RSP: 0018:ffff88810e7777a0 EFLAGS: 00010202 [ 298.638859] RAX: 1ffffffff807440b RBX: ffff888111bd4d80 RCX: 0000000000000000 [ 298.638859] RDX: 1ffff110235ff806 RSI: ffff888111bd5538 RDI: dffffc0000000000 [ 298.638859] RBP: ffff88810e777b30 R08: 0000000080000002 R09: 0000000000000000 [ 298.638859] R10: 0000000000000000 R11: 0000000000000000 R12: fffffbfff168a42c [ 298.638859] R13: ffff888111bd4d80 R14: ffff8881040e9a05 R15: ffffffffc03a2000 [ 298.638859] FS: 00007f39e3758700(0000) GS:ffff88811ae00000(0000) knlGS:0000000000000000 [ 298.638859] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 298.638859] CR2: fffffbfff807440b CR3: 000000011243e000 CR4: 00000000001006f0 [ 298.638859] Call Trace: [ 298.638859] ? mutex_lock_io_nested+0x1560/0x1560 [ 298.638859] ? kasan_kmalloc+0xa0/0xd0 [ 298.638859] ? kmem_cache_alloc+0x1c2/0x260 [ 298.638859] ? __alloc_file+0x92/0x3c0 [ 298.638859] ? alloc_empty_file+0x43/0x120 [ 298.638859] ? alloc_file_pseudo+0x220/0x330 [ 298.638859] ? sock_alloc_file+0x39/0x160 [ 298.638859] ? __sys_socket+0x113/0x1d0 [ 298.638859] ? __x64_sys_socket+0x6f/0xb0 [ 298.638859] ? do_syscall_64+0x138/0x560 [ 298.638859] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 298.638859] ? __alloc_file+0x92/0x3c0 [ 298.638859] ? init_object+0x6b/0x80 [ 298.638859] ? cyc2ns_read_end+0x10/0x10 [ 298.638859] ? cyc2ns_read_end+0x10/0x10 [ 298.638859] ? hlock_class+0x140/0x140 [ 298.638859] ? sched_clock_local+0xd4/0x140 [ 298.638859] ? sched_clock_local+0xd4/0x140 [ 298.638859] ? check_flags.part.37+0x440/0x440 [ 298.638859] ? __lock_acquire+0x4f90/0x4f90 [ 298.638859] ? set_rq_offline.part.89+0x140/0x140 [ ... ] Fixes: d2ba09c ("net: add skeleton of bpfilter kernel module") Signed-off-by: Taehee Yoo <ap420073@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Apr 20, 2019
[ Upstream commit 4c62764 ] While running regressions, observed below kernel panic when sdio disconnect called. This is because of, kthread_stop() is taking care of wait_for_completion() by default. When wait_for_completion triggered in kthread_stop and as it was done already, giving kernel panic. Hence, removing redundant wait_for_completion() from rsi_kill_thread(). ... skipping ... BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff810a63df>] exit_creds+0x1f/0x50 PGD 0 Oops: 0002 [#1] SMP CPU: 0 PID: 6502 Comm: rmmod Tainted: G OE 4.15.9-Generic torvalds#154-Ubuntu Hardware name: Dell Inc. Edge Gateway 3003/ , BIOS 01.00.00 04/17/2017 Stack: ffff88007392e600 ffff880075847dc0 ffffffff8108160a 0000000000000000 ffff88007392e600 ffff880075847de8 ffffffff810a484b ffff880076127000 ffff88003cd3a800 ffff880074f12a00 ffff880075847e28 ffffffffc09bed15 Call Trace: [<ffffffff8108160a>] __put_task_struct+0x5a/0x140 [<ffffffff810a484b>] kthread_stop+0x10b/0x110 [<ffffffffc09bed15>] rsi_disconnect+0x2f5/0x300 [ven_rsi_sdio] [<ffffffff81578bcb>] ? __pm_runtime_resume+0x5b/0x80 [<ffffffff816f0918>] sdio_bus_remove+0x38/0x100 [<ffffffff8156cc64>] __device_release_driver+0xa4/0x150 [<ffffffff8156d7a5>] driver_detach+0xb5/0xc0 [<ffffffff8156c6c5>] bus_remove_driver+0x55/0xd0 [<ffffffff8156dfbc>] driver_unregister+0x2c/0x50 [<ffffffff816f0b8a>] sdio_unregister_driver+0x1a/0x20 [<ffffffffc09bf0f5>] rsi_module_exit+0x15/0x30 [ven_rsi_sdio] [<ffffffff8110cad8>] SyS_delete_module+0x1b8/0x210 [<ffffffff81851dc8>] entry_SYSCALL_64_fastpath+0x1c/0xbb Signed-off-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
rkojedzinszky
pushed a commit
to rkojedzinszky/linux-kernel
that referenced
this pull request
Apr 20, 2019
[ Upstream commit 4c62764 ] While running regressions, observed below kernel panic when sdio disconnect called. This is because of, kthread_stop() is taking care of wait_for_completion() by default. When wait_for_completion triggered in kthread_stop and as it was done already, giving kernel panic. Hence, removing redundant wait_for_completion() from rsi_kill_thread(). ... skipping ... BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff810a63df>] exit_creds+0x1f/0x50 PGD 0 Oops: 0002 [#1] SMP CPU: 0 PID: 6502 Comm: rmmod Tainted: G OE 4.15.9-Generic torvalds#154-Ubuntu Hardware name: Dell Inc. Edge Gateway 3003/ , BIOS 01.00.00 04/17/2017 Stack: ffff88007392e600 ffff880075847dc0 ffffffff8108160a 0000000000000000 ffff88007392e600 ffff880075847de8 ffffffff810a484b ffff880076127000 ffff88003cd3a800 ffff880074f12a00 ffff880075847e28 ffffffffc09bed15 Call Trace: [<ffffffff8108160a>] __put_task_struct+0x5a/0x140 [<ffffffff810a484b>] kthread_stop+0x10b/0x110 [<ffffffffc09bed15>] rsi_disconnect+0x2f5/0x300 [ven_rsi_sdio] [<ffffffff81578bcb>] ? __pm_runtime_resume+0x5b/0x80 [<ffffffff816f0918>] sdio_bus_remove+0x38/0x100 [<ffffffff8156cc64>] __device_release_driver+0xa4/0x150 [<ffffffff8156d7a5>] driver_detach+0xb5/0xc0 [<ffffffff8156c6c5>] bus_remove_driver+0x55/0xd0 [<ffffffff8156dfbc>] driver_unregister+0x2c/0x50 [<ffffffff816f0b8a>] sdio_unregister_driver+0x1a/0x20 [<ffffffffc09bf0f5>] rsi_module_exit+0x15/0x30 [ven_rsi_sdio] [<ffffffff8110cad8>] SyS_delete_module+0x1b8/0x210 [<ffffffff81851dc8>] entry_SYSCALL_64_fastpath+0x1c/0xbb Signed-off-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
mrchapp
pushed a commit
to mrchapp/linux
that referenced
this pull request
Apr 22, 2019
[ Upstream commit 4c62764 ] While running regressions, observed below kernel panic when sdio disconnect called. This is because of, kthread_stop() is taking care of wait_for_completion() by default. When wait_for_completion triggered in kthread_stop and as it was done already, giving kernel panic. Hence, removing redundant wait_for_completion() from rsi_kill_thread(). ... skipping ... BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff810a63df>] exit_creds+0x1f/0x50 PGD 0 Oops: 0002 [#1] SMP CPU: 0 PID: 6502 Comm: rmmod Tainted: G OE 4.15.9-Generic torvalds#154-Ubuntu Hardware name: Dell Inc. Edge Gateway 3003/ , BIOS 01.00.00 04/17/2017 Stack: ffff88007392e600 ffff880075847dc0 ffffffff8108160a 0000000000000000 ffff88007392e600 ffff880075847de8 ffffffff810a484b ffff880076127000 ffff88003cd3a800 ffff880074f12a00 ffff880075847e28 ffffffffc09bed15 Call Trace: [<ffffffff8108160a>] __put_task_struct+0x5a/0x140 [<ffffffff810a484b>] kthread_stop+0x10b/0x110 [<ffffffffc09bed15>] rsi_disconnect+0x2f5/0x300 [ven_rsi_sdio] [<ffffffff81578bcb>] ? __pm_runtime_resume+0x5b/0x80 [<ffffffff816f0918>] sdio_bus_remove+0x38/0x100 [<ffffffff8156cc64>] __device_release_driver+0xa4/0x150 [<ffffffff8156d7a5>] driver_detach+0xb5/0xc0 [<ffffffff8156c6c5>] bus_remove_driver+0x55/0xd0 [<ffffffff8156dfbc>] driver_unregister+0x2c/0x50 [<ffffffff816f0b8a>] sdio_unregister_driver+0x1a/0x20 [<ffffffffc09bf0f5>] rsi_module_exit+0x15/0x30 [ven_rsi_sdio] [<ffffffff8110cad8>] SyS_delete_module+0x1b8/0x210 [<ffffffff81851dc8>] entry_SYSCALL_64_fastpath+0x1c/0xbb Signed-off-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
mrchapp
pushed a commit
to mrchapp/linux
that referenced
this pull request
Apr 25, 2019
[ Upstream commit 4c62764 ] While running regressions, observed below kernel panic when sdio disconnect called. This is because of, kthread_stop() is taking care of wait_for_completion() by default. When wait_for_completion triggered in kthread_stop and as it was done already, giving kernel panic. Hence, removing redundant wait_for_completion() from rsi_kill_thread(). ... skipping ... BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff810a63df>] exit_creds+0x1f/0x50 PGD 0 Oops: 0002 [#1] SMP CPU: 0 PID: 6502 Comm: rmmod Tainted: G OE 4.15.9-Generic torvalds#154-Ubuntu Hardware name: Dell Inc. Edge Gateway 3003/ , BIOS 01.00.00 04/17/2017 Stack: ffff88007392e600 ffff880075847dc0 ffffffff8108160a 0000000000000000 ffff88007392e600 ffff880075847de8 ffffffff810a484b ffff880076127000 ffff88003cd3a800 ffff880074f12a00 ffff880075847e28 ffffffffc09bed15 Call Trace: [<ffffffff8108160a>] __put_task_struct+0x5a/0x140 [<ffffffff810a484b>] kthread_stop+0x10b/0x110 [<ffffffffc09bed15>] rsi_disconnect+0x2f5/0x300 [ven_rsi_sdio] [<ffffffff81578bcb>] ? __pm_runtime_resume+0x5b/0x80 [<ffffffff816f0918>] sdio_bus_remove+0x38/0x100 [<ffffffff8156cc64>] __device_release_driver+0xa4/0x150 [<ffffffff8156d7a5>] driver_detach+0xb5/0xc0 [<ffffffff8156c6c5>] bus_remove_driver+0x55/0xd0 [<ffffffff8156dfbc>] driver_unregister+0x2c/0x50 [<ffffffff816f0b8a>] sdio_unregister_driver+0x1a/0x20 [<ffffffffc09bf0f5>] rsi_module_exit+0x15/0x30 [ven_rsi_sdio] [<ffffffff8110cad8>] SyS_delete_module+0x1b8/0x210 [<ffffffff81851dc8>] entry_SYSCALL_64_fastpath+0x1c/0xbb Signed-off-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Apr 27, 2019
[ Upstream commit 4c62764 ] While running regressions, observed below kernel panic when sdio disconnect called. This is because of, kthread_stop() is taking care of wait_for_completion() by default. When wait_for_completion triggered in kthread_stop and as it was done already, giving kernel panic. Hence, removing redundant wait_for_completion() from rsi_kill_thread(). ... skipping ... BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff810a63df>] exit_creds+0x1f/0x50 PGD 0 Oops: 0002 [#1] SMP CPU: 0 PID: 6502 Comm: rmmod Tainted: G OE 4.15.9-Generic torvalds#154-Ubuntu Hardware name: Dell Inc. Edge Gateway 3003/ , BIOS 01.00.00 04/17/2017 Stack: ffff88007392e600 ffff880075847dc0 ffffffff8108160a 0000000000000000 ffff88007392e600 ffff880075847de8 ffffffff810a484b ffff880076127000 ffff88003cd3a800 ffff880074f12a00 ffff880075847e28 ffffffffc09bed15 Call Trace: [<ffffffff8108160a>] __put_task_struct+0x5a/0x140 [<ffffffff810a484b>] kthread_stop+0x10b/0x110 [<ffffffffc09bed15>] rsi_disconnect+0x2f5/0x300 [ven_rsi_sdio] [<ffffffff81578bcb>] ? __pm_runtime_resume+0x5b/0x80 [<ffffffff816f0918>] sdio_bus_remove+0x38/0x100 [<ffffffff8156cc64>] __device_release_driver+0xa4/0x150 [<ffffffff8156d7a5>] driver_detach+0xb5/0xc0 [<ffffffff8156c6c5>] bus_remove_driver+0x55/0xd0 [<ffffffff8156dfbc>] driver_unregister+0x2c/0x50 [<ffffffff816f0b8a>] sdio_unregister_driver+0x1a/0x20 [<ffffffffc09bf0f5>] rsi_module_exit+0x15/0x30 [ven_rsi_sdio] [<ffffffff8110cad8>] SyS_delete_module+0x1b8/0x210 [<ffffffff81851dc8>] entry_SYSCALL_64_fastpath+0x1c/0xbb Signed-off-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
nemunaire
pushed a commit
to nemunaire/CI20_linux
that referenced
this pull request
Jun 16, 2019
[ Upstream commit 4c62764 ] While running regressions, observed below kernel panic when sdio disconnect called. This is because of, kthread_stop() is taking care of wait_for_completion() by default. When wait_for_completion triggered in kthread_stop and as it was done already, giving kernel panic. Hence, removing redundant wait_for_completion() from rsi_kill_thread(). ... skipping ... BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff810a63df>] exit_creds+0x1f/0x50 PGD 0 Oops: 0002 [MIPS#1] SMP CPU: 0 PID: 6502 Comm: rmmod Tainted: G OE 4.15.9-Generic torvalds#154-Ubuntu Hardware name: Dell Inc. Edge Gateway 3003/ , BIOS 01.00.00 04/17/2017 Stack: ffff88007392e600 ffff880075847dc0 ffffffff8108160a 0000000000000000 ffff88007392e600 ffff880075847de8 ffffffff810a484b ffff880076127000 ffff88003cd3a800 ffff880074f12a00 ffff880075847e28 ffffffffc09bed15 Call Trace: [<ffffffff8108160a>] __put_task_struct+0x5a/0x140 [<ffffffff810a484b>] kthread_stop+0x10b/0x110 [<ffffffffc09bed15>] rsi_disconnect+0x2f5/0x300 [ven_rsi_sdio] [<ffffffff81578bcb>] ? __pm_runtime_resume+0x5b/0x80 [<ffffffff816f0918>] sdio_bus_remove+0x38/0x100 [<ffffffff8156cc64>] __device_release_driver+0xa4/0x150 [<ffffffff8156d7a5>] driver_detach+0xb5/0xc0 [<ffffffff8156c6c5>] bus_remove_driver+0x55/0xd0 [<ffffffff8156dfbc>] driver_unregister+0x2c/0x50 [<ffffffff816f0b8a>] sdio_unregister_driver+0x1a/0x20 [<ffffffffc09bf0f5>] rsi_module_exit+0x15/0x30 [ven_rsi_sdio] [<ffffffff8110cad8>] SyS_delete_module+0x1b8/0x210 [<ffffffff81851dc8>] entry_SYSCALL_64_fastpath+0x1c/0xbb Signed-off-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
pedwo
pushed a commit
to pedwo/linux
that referenced
this pull request
Dec 17, 2019
While running regressions, observed below kernel panic when sdio disconnect called. This is because of, kthread_stop() is taking care of wait_for_completion() by default. When wait_for_completion triggered in kthread_stop and as it was done already, giving kernel panic. Hence, removing redundant wait_for_completion() from rsi_kill_thread(). ... skipping ... BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff810a63df>] exit_creds+0x1f/0x50 PGD 0 Oops: 0002 [#1] SMP CPU: 0 PID: 6502 Comm: rmmod Tainted: G OE 4.15.9-Generic torvalds#154-Ubuntu Hardware name: Dell Inc. Edge Gateway 3003/ , BIOS 01.00.00 04/17/2017 Stack: ffff88007392e600 ffff880075847dc0 ffffffff8108160a 0000000000000000 ffff88007392e600 ffff880075847de8 ffffffff810a484b ffff880076127000 ffff88003cd3a800 ffff880074f12a00 ffff880075847e28 ffffffffc09bed15 Call Trace: [<ffffffff8108160a>] __put_task_struct+0x5a/0x140 [<ffffffff810a484b>] kthread_stop+0x10b/0x110 [<ffffffffc09bed15>] rsi_disconnect+0x2f5/0x300 [ven_rsi_sdio] [<ffffffff81578bcb>] ? __pm_runtime_resume+0x5b/0x80 [<ffffffff816f0918>] sdio_bus_remove+0x38/0x100 [<ffffffff8156cc64>] __device_release_driver+0xa4/0x150 [<ffffffff8156d7a5>] driver_detach+0xb5/0xc0 [<ffffffff8156c6c5>] bus_remove_driver+0x55/0xd0 [<ffffffff8156dfbc>] driver_unregister+0x2c/0x50 [<ffffffff816f0b8a>] sdio_unregister_driver+0x1a/0x20 [<ffffffffc09bf0f5>] rsi_module_exit+0x15/0x30 [ven_rsi_sdio] [<ffffffff8110cad8>] SyS_delete_module+0x1b8/0x210 [<ffffffff81851dc8>] entry_SYSCALL_64_fastpath+0x1c/0xbb Signed-off-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
gabrielesvelto
pushed a commit
to gabrielesvelto/CI20_linux
that referenced
this pull request
Jan 17, 2020
[ Upstream commit 4c62764 ] While running regressions, observed below kernel panic when sdio disconnect called. This is because of, kthread_stop() is taking care of wait_for_completion() by default. When wait_for_completion triggered in kthread_stop and as it was done already, giving kernel panic. Hence, removing redundant wait_for_completion() from rsi_kill_thread(). ... skipping ... BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff810a63df>] exit_creds+0x1f/0x50 PGD 0 Oops: 0002 [MIPS#1] SMP CPU: 0 PID: 6502 Comm: rmmod Tainted: G OE 4.15.9-Generic torvalds#154-Ubuntu Hardware name: Dell Inc. Edge Gateway 3003/ , BIOS 01.00.00 04/17/2017 Stack: ffff88007392e600 ffff880075847dc0 ffffffff8108160a 0000000000000000 ffff88007392e600 ffff880075847de8 ffffffff810a484b ffff880076127000 ffff88003cd3a800 ffff880074f12a00 ffff880075847e28 ffffffffc09bed15 Call Trace: [<ffffffff8108160a>] __put_task_struct+0x5a/0x140 [<ffffffff810a484b>] kthread_stop+0x10b/0x110 [<ffffffffc09bed15>] rsi_disconnect+0x2f5/0x300 [ven_rsi_sdio] [<ffffffff81578bcb>] ? __pm_runtime_resume+0x5b/0x80 [<ffffffff816f0918>] sdio_bus_remove+0x38/0x100 [<ffffffff8156cc64>] __device_release_driver+0xa4/0x150 [<ffffffff8156d7a5>] driver_detach+0xb5/0xc0 [<ffffffff8156c6c5>] bus_remove_driver+0x55/0xd0 [<ffffffff8156dfbc>] driver_unregister+0x2c/0x50 [<ffffffff816f0b8a>] sdio_unregister_driver+0x1a/0x20 [<ffffffffc09bf0f5>] rsi_module_exit+0x15/0x30 [ven_rsi_sdio] [<ffffffff8110cad8>] SyS_delete_module+0x1b8/0x210 [<ffffffff81851dc8>] entry_SYSCALL_64_fastpath+0x1c/0xbb Signed-off-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
torvalds
added a commit
that referenced
this pull request
Aug 6, 2020
This reverts commit 8bb9bf2. It seems the vmalloc page tables aren't always preallocated in all situations, because Jason Donenfeld reports an oops with this commit: BUG: unable to handle page fault for address: ffffe8ffffd00608 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 2 PID: 22 Comm: kworker/2:0 Not tainted 5.8.0+ #154 RIP: process_one_work+0x2c/0x2d0 Code: 41 56 41 55 41 54 55 48 89 f5 53 48 89 fb 48 83 ec 08 48 8b 06 4c 8b 67 40 49 89 c6 45 30 f6 a8 04 b8 00 00 00 00 4c 0f 44 f0 <49> 8b 46 08 44 8b a8 00 01 05 Call Trace: worker_thread+0x4b/0x3b0 ? rescuer_thread+0x360/0x360 kthread+0x116/0x140 ? __kthread_create_worker+0x110/0x110 ret_from_fork+0x1f/0x30 CR2: ffffe8ffffd00608 and that page fault address is right in that vmalloc space, and we clearly don't have a PGD/P4D entry for it. Looking at the "Code:" line, the actual fault seems to come from the 'pwq->wq' dereference at the top of the process_one_work() function: struct pool_workqueue *pwq = get_work_pwq(work); struct worker_pool *pool = worker->pool; bool cpu_intensive = pwq->wq->flags & WQ_CPU_INTENSIVE; so 'struct pool_workqueue *pwq' is the allocation that hasn't been synchronized across CPUs. Just revert for now, while Joerg figures out the cause. Reported-and-bisected-by: Jason A. Donenfeld <Jason@zx2c4.com> Acked-by: Ingo Molnar <mingo@kernel.org> Acked-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
igoropaniuk
pushed a commit
to igoropaniuk/linux
that referenced
this pull request
Nov 18, 2020
Update 5.4-2.1.x-imx to v5.4.72 from stable
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 15, 2021
This commit fixes the following checkpatch.pl errors: ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#12: FILE: ./hal/HalBtc8723b1Ant.c:12: +static struct COEX_DM_8723B_1ANT * pCoexDm = &GLCoexDm8723b1Ant; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#14: FILE: ./hal/HalBtc8723b1Ant.c:14: +static struct COEX_STA_8723B_1ANT * pCoexSta = &GLCoexSta8723b1Ant; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#154: FILE: ./hal/HalBtc8723b1Ant.c:154: + struct BTC_COEXIST * pBtCoexist, bool bForceExec, u32 disRateMask ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#169: FILE: ./hal/HalBtc8723b1Ant.c:169: + struct BTC_COEXIST * pBtCoexist, bool bForceExec, u8 type ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#207: FILE: ./hal/HalBtc8723b1Ant.c:207: + struct BTC_COEXIST * pBtCoexist, bool bForceExec, u8 type ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#234: FILE: ./hal/HalBtc8723b1Ant.c:234: + struct BTC_COEXIST * pBtCoexist, bool bForceExec, u8 type ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#260: FILE: ./hal/HalBtc8723b1Ant.c:260: + struct BTC_COEXIST * pBtCoexist, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#288: FILE: ./hal/HalBtc8723b1Ant.c:288: + struct BTC_COEXIST * pBtCoexist, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#317: FILE: ./hal/HalBtc8723b1Ant.c:317: +static void halbtc8723b1ant_QueryBtInfo(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#334: FILE: ./hal/HalBtc8723b1Ant.c:334: +static void halbtc8723b1ant_MonitorBtCtr(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#395: FILE: ./hal/HalBtc8723b1Ant.c:395: +static void halbtc8723b1ant_MonitorWiFiCtr(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#481: FILE: ./hal/HalBtc8723b1Ant.c:481: +static bool halbtc8723b1ant_IsWifiStatusChanged(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#516: FILE: ./hal/HalBtc8723b1Ant.c:516: +static void halbtc8723b1ant_UpdateBtLinkInfo(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#518: FILE: ./hal/HalBtc8723b1Ant.c:518: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#580: FILE: ./hal/HalBtc8723b1Ant.c:580: +static u8 halbtc8723b1ant_ActionAlgorithm(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#582: FILE: ./hal/HalBtc8723b1Ant.c:582: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#808: FILE: ./hal/HalBtc8723b1Ant.c:808: + struct BTC_COEXIST * pBtCoexist, bool bLowPenaltyRa ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#836: FILE: ./hal/HalBtc8723b1Ant.c:836: + struct BTC_COEXIST * pBtCoexist, bool bForceExec, bool bLowPenaltyRa ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#853: FILE: ./hal/HalBtc8723b1Ant.c:853: + struct BTC_COEXIST * pBtCoexist, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#890: FILE: ./hal/HalBtc8723b1Ant.c:890: + struct BTC_COEXIST * pBtCoexist, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#933: FILE: ./hal/HalBtc8723b1Ant.c:933: + struct BTC_COEXIST * pBtCoexist, bool bForceExec, u8 type ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#991: FILE: ./hal/HalBtc8723b1Ant.c:991: + struct BTC_COEXIST * pBtCoexist, bool bEnable ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1012: FILE: ./hal/HalBtc8723b1Ant.c:1012: + struct BTC_COEXIST * pBtCoexist, bool bForceExec, bool bEnable ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1046: FILE: ./hal/HalBtc8723b1Ant.c:1046: + struct BTC_COEXIST * pBtCoexist, u8 lpsVal, u8 rpwmVal ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1057: FILE: ./hal/HalBtc8723b1Ant.c:1057: + struct BTC_COEXIST * pBtCoexist, bool bForceExec, u8 lpsVal, u8 rpwmVal ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1108: FILE: ./hal/HalBtc8723b1Ant.c:1108: + struct BTC_COEXIST * pBtCoexist, bool bLowPenaltyRA ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1121: FILE: ./hal/HalBtc8723b1Ant.c:1121: + struct BTC_COEXIST * pBtCoexist, u8 antPosType, bool bInitHwCfg, bool bWifiOff ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1124: FILE: ./hal/HalBtc8723b1Ant.c:1124: + struct BTC_BOARD_INFO * pBoardInfo = &pBtCoexist->boardInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1310: FILE: ./hal/HalBtc8723b1Ant.c:1310: + struct BTC_COEXIST * pBtCoexist, u8 byte1, u8 byte2, u8 byte3, u8 byte4, u8 byte5 ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1364: FILE: ./hal/HalBtc8723b1Ant.c:1364: + struct BTC_COEXIST * pBtCoexist, bool bForceExec, bool bTurnOn, u8 type ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1367: FILE: ./hal/HalBtc8723b1Ant.c:1367: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1664: FILE: ./hal/HalBtc8723b1Ant.c:1664: +static bool halbtc8723b1ant_IsCommonAction(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1755: FILE: ./hal/HalBtc8723b1Ant.c:1755: + struct BTC_COEXIST * pBtCoexist, u8 wifiStatus ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1944: FILE: ./hal/HalBtc8723b1Ant.c:1944: + struct BTC_COEXIST * pBtCoexist, bool bNewPsState ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1966: FILE: ./hal/HalBtc8723b1Ant.c:1966: + struct BTC_COEXIST * pBtCoexist, u8 psType, u8 lpsVal, u8 rpwmVal ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2014: FILE: ./hal/HalBtc8723b1Ant.c:2014: +static void halbtc8723b1ant_ActionWifiMultiPort(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2022: FILE: ./hal/HalBtc8723b1Ant.c:2022: +static void halbtc8723b1ant_ActionHs(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2028: FILE: ./hal/HalBtc8723b1Ant.c:2028: +static void halbtc8723b1ant_ActionBtInquiry(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2030: FILE: ./hal/HalBtc8723b1Ant.c:2030: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2070: FILE: ./hal/HalBtc8723b1Ant.c:2070: + struct BTC_COEXIST * pBtCoexist, u8 wifiStatus ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2073: FILE: ./hal/HalBtc8723b1Ant.c:2073: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2090: FILE: ./hal/HalBtc8723b1Ant.c:2090: + struct BTC_COEXIST * pBtCoexist, u8 wifiStatus ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2095: FILE: ./hal/HalBtc8723b1Ant.c:2095: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2144: FILE: ./hal/HalBtc8723b1Ant.c:2144: +static void halbtc8723b1ant_ActionWifiNotConnected(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2155: FILE: ./hal/HalBtc8723b1Ant.c:2155: + struct BTC_COEXIST * pBtCoexist ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2158: FILE: ./hal/HalBtc8723b1Ant.c:2158: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2189: FILE: ./hal/HalBtc8723b1Ant.c:2189: + struct BTC_COEXIST * pBtCoexist ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2192: FILE: ./hal/HalBtc8723b1Ant.c:2192: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2213: FILE: ./hal/HalBtc8723b1Ant.c:2213: +static void halbtc8723b1ant_ActionWifiConnectedScan(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2215: FILE: ./hal/HalBtc8723b1Ant.c:2215: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2246: FILE: ./hal/HalBtc8723b1Ant.c:2246: + struct BTC_COEXIST * pBtCoexist ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2249: FILE: ./hal/HalBtc8723b1Ant.c:2249: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2270: FILE: ./hal/HalBtc8723b1Ant.c:2270: +static void halbtc8723b1ant_ActionWifiConnected(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2390: FILE: ./hal/HalBtc8723b1Ant.c:2390: +static void halbtc8723b1ant_RunSwCoexistMechanism(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2449: FILE: ./hal/HalBtc8723b1Ant.c:2449: +static void halbtc8723b1ant_RunCoexistMechanism(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2451: FILE: ./hal/HalBtc8723b1Ant.c:2451: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2582: FILE: ./hal/HalBtc8723b1Ant.c:2582: +static void halbtc8723b1ant_InitCoexDm(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2596: FILE: ./hal/HalBtc8723b1Ant.c:2596: + struct BTC_COEXIST * pBtCoexist, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2651: FILE: ./hal/HalBtc8723b1Ant.c:2651: +void EXhalbtc8723b1ant_PowerOnSetting(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2653: FILE: ./hal/HalBtc8723b1Ant.c:2653: + struct BTC_BOARD_INFO * pBoardInfo = &pBtCoexist->boardInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2703: FILE: ./hal/HalBtc8723b1Ant.c:2703: +void EXhalbtc8723b1ant_InitHwConfig(struct BTC_COEXIST * pBtCoexist, bool bWifiOnly) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2708: FILE: ./hal/HalBtc8723b1Ant.c:2708: +void EXhalbtc8723b1ant_InitCoexDm(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2723: FILE: ./hal/HalBtc8723b1Ant.c:2723: +void EXhalbtc8723b1ant_DisplayCoexInfo(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2725: FILE: ./hal/HalBtc8723b1Ant.c:2725: + struct BTC_BOARD_INFO * pBoardInfo = &pBtCoexist->boardInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2726: FILE: ./hal/HalBtc8723b1Ant.c:2726: + struct BTC_STACK_INFO * pStackInfo = &pBtCoexist->stackInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2727: FILE: ./hal/HalBtc8723b1Ant.c:2727: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #3186: FILE: ./hal/HalBtc8723b1Ant.c:3186: +void EXhalbtc8723b1ant_IpsNotify(struct BTC_COEXIST * pBtCoexist, u8 type) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #3212: FILE: ./hal/HalBtc8723b1Ant.c:3212: +void EXhalbtc8723b1ant_LpsNotify(struct BTC_COEXIST * pBtCoexist, u8 type) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #3230: FILE: ./hal/HalBtc8723b1Ant.c:3230: +void EXhalbtc8723b1ant_ScanNotify(struct BTC_COEXIST * pBtCoexist, u8 type) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #3320: FILE: ./hal/HalBtc8723b1Ant.c:3320: +void EXhalbtc8723b1ant_ConnectNotify(struct BTC_COEXIST * pBtCoexist, u8 type) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #3377: FILE: ./hal/HalBtc8723b1Ant.c:3377: +void EXhalbtc8723b1ant_MediaStatusNotify(struct BTC_COEXIST * pBtCoexist, u8 type) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #3447: FILE: ./hal/HalBtc8723b1Ant.c:3447: +void EXhalbtc8723b1ant_SpecialPacketNotify(struct BTC_COEXIST * pBtCoexist, u8 type) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #3536: FILE: ./hal/HalBtc8723b1Ant.c:3536: + struct BTC_COEXIST * pBtCoexist, u8 *tmpBuf, u8 length ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #3701: FILE: ./hal/HalBtc8723b1Ant.c:3701: +void EXhalbtc8723b1ant_HaltNotify(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #3716: FILE: ./hal/HalBtc8723b1Ant.c:3716: +void EXhalbtc8723b1ant_PnpNotify(struct BTC_COEXIST * pBtCoexist, u8 pnpState) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #3738: FILE: ./hal/HalBtc8723b1Ant.c:3738: +void EXhalbtc8723b1ant_Periodical(struct BTC_COEXIST * pBtCoexist) Signed-off-by: Marco Cesati <marcocesati@gmail.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 16, 2021
This commit fixes the following checkpatch.pl errors: ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#12: FILE: ./hal/HalBtc8723b1Ant.c:12: +static struct COEX_DM_8723B_1ANT * pCoexDm = &GLCoexDm8723b1Ant; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#14: FILE: ./hal/HalBtc8723b1Ant.c:14: +static struct COEX_STA_8723B_1ANT * pCoexSta = &GLCoexSta8723b1Ant; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#154: FILE: ./hal/HalBtc8723b1Ant.c:154: + struct BTC_COEXIST * pBtCoexist, bool bForceExec, u32 disRateMask ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#169: FILE: ./hal/HalBtc8723b1Ant.c:169: + struct BTC_COEXIST * pBtCoexist, bool bForceExec, u8 type ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#207: FILE: ./hal/HalBtc8723b1Ant.c:207: + struct BTC_COEXIST * pBtCoexist, bool bForceExec, u8 type ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#234: FILE: ./hal/HalBtc8723b1Ant.c:234: + struct BTC_COEXIST * pBtCoexist, bool bForceExec, u8 type ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#260: FILE: ./hal/HalBtc8723b1Ant.c:260: + struct BTC_COEXIST * pBtCoexist, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#288: FILE: ./hal/HalBtc8723b1Ant.c:288: + struct BTC_COEXIST * pBtCoexist, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#317: FILE: ./hal/HalBtc8723b1Ant.c:317: +static void halbtc8723b1ant_QueryBtInfo(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#334: FILE: ./hal/HalBtc8723b1Ant.c:334: +static void halbtc8723b1ant_MonitorBtCtr(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#395: FILE: ./hal/HalBtc8723b1Ant.c:395: +static void halbtc8723b1ant_MonitorWiFiCtr(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#481: FILE: ./hal/HalBtc8723b1Ant.c:481: +static bool halbtc8723b1ant_IsWifiStatusChanged(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#516: FILE: ./hal/HalBtc8723b1Ant.c:516: +static void halbtc8723b1ant_UpdateBtLinkInfo(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#518: FILE: ./hal/HalBtc8723b1Ant.c:518: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#580: FILE: ./hal/HalBtc8723b1Ant.c:580: +static u8 halbtc8723b1ant_ActionAlgorithm(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#582: FILE: ./hal/HalBtc8723b1Ant.c:582: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#808: FILE: ./hal/HalBtc8723b1Ant.c:808: + struct BTC_COEXIST * pBtCoexist, bool bLowPenaltyRa ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#836: FILE: ./hal/HalBtc8723b1Ant.c:836: + struct BTC_COEXIST * pBtCoexist, bool bForceExec, bool bLowPenaltyRa ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#853: FILE: ./hal/HalBtc8723b1Ant.c:853: + struct BTC_COEXIST * pBtCoexist, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#890: FILE: ./hal/HalBtc8723b1Ant.c:890: + struct BTC_COEXIST * pBtCoexist, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#933: FILE: ./hal/HalBtc8723b1Ant.c:933: + struct BTC_COEXIST * pBtCoexist, bool bForceExec, u8 type ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#991: FILE: ./hal/HalBtc8723b1Ant.c:991: + struct BTC_COEXIST * pBtCoexist, bool bEnable ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1012: FILE: ./hal/HalBtc8723b1Ant.c:1012: + struct BTC_COEXIST * pBtCoexist, bool bForceExec, bool bEnable ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1046: FILE: ./hal/HalBtc8723b1Ant.c:1046: + struct BTC_COEXIST * pBtCoexist, u8 lpsVal, u8 rpwmVal ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1057: FILE: ./hal/HalBtc8723b1Ant.c:1057: + struct BTC_COEXIST * pBtCoexist, bool bForceExec, u8 lpsVal, u8 rpwmVal ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1108: FILE: ./hal/HalBtc8723b1Ant.c:1108: + struct BTC_COEXIST * pBtCoexist, bool bLowPenaltyRA ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1121: FILE: ./hal/HalBtc8723b1Ant.c:1121: + struct BTC_COEXIST * pBtCoexist, u8 antPosType, bool bInitHwCfg, bool bWifiOff ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1124: FILE: ./hal/HalBtc8723b1Ant.c:1124: + struct BTC_BOARD_INFO * pBoardInfo = &pBtCoexist->boardInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1310: FILE: ./hal/HalBtc8723b1Ant.c:1310: + struct BTC_COEXIST * pBtCoexist, u8 byte1, u8 byte2, u8 byte3, u8 byte4, u8 byte5 ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1364: FILE: ./hal/HalBtc8723b1Ant.c:1364: + struct BTC_COEXIST * pBtCoexist, bool bForceExec, bool bTurnOn, u8 type ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1367: FILE: ./hal/HalBtc8723b1Ant.c:1367: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1664: FILE: ./hal/HalBtc8723b1Ant.c:1664: +static bool halbtc8723b1ant_IsCommonAction(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1755: FILE: ./hal/HalBtc8723b1Ant.c:1755: + struct BTC_COEXIST * pBtCoexist, u8 wifiStatus ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1944: FILE: ./hal/HalBtc8723b1Ant.c:1944: + struct BTC_COEXIST * pBtCoexist, bool bNewPsState ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1966: FILE: ./hal/HalBtc8723b1Ant.c:1966: + struct BTC_COEXIST * pBtCoexist, u8 psType, u8 lpsVal, u8 rpwmVal ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2014: FILE: ./hal/HalBtc8723b1Ant.c:2014: +static void halbtc8723b1ant_ActionWifiMultiPort(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2022: FILE: ./hal/HalBtc8723b1Ant.c:2022: +static void halbtc8723b1ant_ActionHs(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2028: FILE: ./hal/HalBtc8723b1Ant.c:2028: +static void halbtc8723b1ant_ActionBtInquiry(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2030: FILE: ./hal/HalBtc8723b1Ant.c:2030: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2070: FILE: ./hal/HalBtc8723b1Ant.c:2070: + struct BTC_COEXIST * pBtCoexist, u8 wifiStatus ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2073: FILE: ./hal/HalBtc8723b1Ant.c:2073: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2090: FILE: ./hal/HalBtc8723b1Ant.c:2090: + struct BTC_COEXIST * pBtCoexist, u8 wifiStatus ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2095: FILE: ./hal/HalBtc8723b1Ant.c:2095: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2144: FILE: ./hal/HalBtc8723b1Ant.c:2144: +static void halbtc8723b1ant_ActionWifiNotConnected(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2155: FILE: ./hal/HalBtc8723b1Ant.c:2155: + struct BTC_COEXIST * pBtCoexist ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2158: FILE: ./hal/HalBtc8723b1Ant.c:2158: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2189: FILE: ./hal/HalBtc8723b1Ant.c:2189: + struct BTC_COEXIST * pBtCoexist ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2192: FILE: ./hal/HalBtc8723b1Ant.c:2192: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2213: FILE: ./hal/HalBtc8723b1Ant.c:2213: +static void halbtc8723b1ant_ActionWifiConnectedScan(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2215: FILE: ./hal/HalBtc8723b1Ant.c:2215: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2246: FILE: ./hal/HalBtc8723b1Ant.c:2246: + struct BTC_COEXIST * pBtCoexist ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2249: FILE: ./hal/HalBtc8723b1Ant.c:2249: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2270: FILE: ./hal/HalBtc8723b1Ant.c:2270: +static void halbtc8723b1ant_ActionWifiConnected(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2390: FILE: ./hal/HalBtc8723b1Ant.c:2390: +static void halbtc8723b1ant_RunSwCoexistMechanism(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2449: FILE: ./hal/HalBtc8723b1Ant.c:2449: +static void halbtc8723b1ant_RunCoexistMechanism(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2451: FILE: ./hal/HalBtc8723b1Ant.c:2451: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2582: FILE: ./hal/HalBtc8723b1Ant.c:2582: +static void halbtc8723b1ant_InitCoexDm(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2596: FILE: ./hal/HalBtc8723b1Ant.c:2596: + struct BTC_COEXIST * pBtCoexist, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2651: FILE: ./hal/HalBtc8723b1Ant.c:2651: +void EXhalbtc8723b1ant_PowerOnSetting(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2653: FILE: ./hal/HalBtc8723b1Ant.c:2653: + struct BTC_BOARD_INFO * pBoardInfo = &pBtCoexist->boardInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2703: FILE: ./hal/HalBtc8723b1Ant.c:2703: +void EXhalbtc8723b1ant_InitHwConfig(struct BTC_COEXIST * pBtCoexist, bool bWifiOnly) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2708: FILE: ./hal/HalBtc8723b1Ant.c:2708: +void EXhalbtc8723b1ant_InitCoexDm(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2723: FILE: ./hal/HalBtc8723b1Ant.c:2723: +void EXhalbtc8723b1ant_DisplayCoexInfo(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2725: FILE: ./hal/HalBtc8723b1Ant.c:2725: + struct BTC_BOARD_INFO * pBoardInfo = &pBtCoexist->boardInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2726: FILE: ./hal/HalBtc8723b1Ant.c:2726: + struct BTC_STACK_INFO * pStackInfo = &pBtCoexist->stackInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2727: FILE: ./hal/HalBtc8723b1Ant.c:2727: + struct BTC_BT_LINK_INFO * pBtLinkInfo = &pBtCoexist->btLinkInfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #3186: FILE: ./hal/HalBtc8723b1Ant.c:3186: +void EXhalbtc8723b1ant_IpsNotify(struct BTC_COEXIST * pBtCoexist, u8 type) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #3212: FILE: ./hal/HalBtc8723b1Ant.c:3212: +void EXhalbtc8723b1ant_LpsNotify(struct BTC_COEXIST * pBtCoexist, u8 type) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #3230: FILE: ./hal/HalBtc8723b1Ant.c:3230: +void EXhalbtc8723b1ant_ScanNotify(struct BTC_COEXIST * pBtCoexist, u8 type) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #3320: FILE: ./hal/HalBtc8723b1Ant.c:3320: +void EXhalbtc8723b1ant_ConnectNotify(struct BTC_COEXIST * pBtCoexist, u8 type) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #3377: FILE: ./hal/HalBtc8723b1Ant.c:3377: +void EXhalbtc8723b1ant_MediaStatusNotify(struct BTC_COEXIST * pBtCoexist, u8 type) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #3447: FILE: ./hal/HalBtc8723b1Ant.c:3447: +void EXhalbtc8723b1ant_SpecialPacketNotify(struct BTC_COEXIST * pBtCoexist, u8 type) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #3536: FILE: ./hal/HalBtc8723b1Ant.c:3536: + struct BTC_COEXIST * pBtCoexist, u8 *tmpBuf, u8 length ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #3701: FILE: ./hal/HalBtc8723b1Ant.c:3701: +void EXhalbtc8723b1ant_HaltNotify(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #3716: FILE: ./hal/HalBtc8723b1Ant.c:3716: +void EXhalbtc8723b1ant_PnpNotify(struct BTC_COEXIST * pBtCoexist, u8 pnpState) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #3738: FILE: ./hal/HalBtc8723b1Ant.c:3738: +void EXhalbtc8723b1ant_Periodical(struct BTC_COEXIST * pBtCoexist) Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Marco Cesati <marcocesati@gmail.com> Link: https://lore.kernel.org/r/20210315170618.2566-3-marcocesati@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jun 3, 2021
In prf_open() the required buffer size can be so large that vzalloc() may sleep thus triggering bug: ====== BUG: sleeping function called from invalid context at include/linux/sched/mm.h:201 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 337, name: cat CPU: 1 PID: 337 Comm: cat Not tainted 5.13.0-rc2-24-hack+ torvalds#154 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack+0xc7/0x134 ___might_sleep+0x177/0x190 __might_sleep+0x5a/0x90 kmem_cache_alloc_node_trace+0x6b/0x3a0 ? __get_vm_area_node+0xcd/0x1b0 ? dput+0x283/0x300 __get_vm_area_node+0xcd/0x1b0 __vmalloc_node_range+0x7b/0x420 ? prf_open+0x1da/0x580 ? prf_open+0x32/0x580 ? __llvm_profile_instrument_memop+0x36/0x50 vzalloc+0x54/0x60 ? prf_open+0x1da/0x580 prf_open+0x1da/0x580 full_proxy_open+0x211/0x370 .... ====== Since we can't vzalloc while holding pgo_lock, split the code into steps: * First get buffer size via prf_buffer_size() and release the lock. * Round up to the page size and allocate the buffer. * Finally re-acquire the pgo_lock and call prf_serialize(). prf_serialize() will now check if the buffer is large enough and returns -EAGAIN if it is not. New in this v2 patch: The -EAGAIN case was determined to be such rare event that running following in a loop: $cat /sys/kernel/debug/pgo/vmlinux.profraw > vmlinux.profdata; Didn't trigger it, and I don't know if it ever may occur at all. Signed-off-by: Jarmo Tiitto <jarmo.tiitto@gmail.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jun 5, 2021
In prf_open() the required buffer size can be so large that vzalloc() may sleep thus triggering bug: ====== BUG: sleeping function called from invalid context at include/linux/sched/mm.h:201 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 337, name: cat CPU: 1 PID: 337 Comm: cat Not tainted 5.13.0-rc2-24-hack+ torvalds#154 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack+0xc7/0x134 ___might_sleep+0x177/0x190 __might_sleep+0x5a/0x90 kmem_cache_alloc_node_trace+0x6b/0x3a0 ? __get_vm_area_node+0xcd/0x1b0 ? dput+0x283/0x300 __get_vm_area_node+0xcd/0x1b0 __vmalloc_node_range+0x7b/0x420 ? prf_open+0x1da/0x580 ? prf_open+0x32/0x580 ? __llvm_profile_instrument_memop+0x36/0x50 vzalloc+0x54/0x60 ? prf_open+0x1da/0x580 prf_open+0x1da/0x580 full_proxy_open+0x211/0x370 .... ====== Since we can't vzalloc while holding pgo_lock, split the code into steps: * First get initial buffer size via prf_buffer_size() and release the lock. * Round up to the page size and allocate the buffer. * Finally re-acquire the pgo_lock and call prf_serialize(). prf_serialize() will now check if the buffer is large enough and returns -EAGAIN if it is not. Note that prf_buffer_size() walks linked lists that are modified by __llvm_profile_instrument_target(), so we have to "guess" the buffer size ahead of time. prf_serialize() will then return the actual data length. Signed-off-by: Jarmo Tiitto <jarmo.tiitto@gmail.com>
roxell
pushed a commit
to roxell/linux
that referenced
this pull request
Jun 9, 2021
In prf_open() the required buffer size can be so large that vzalloc() may sleep thus triggering bug: ====== BUG: sleeping function called from invalid context at include/linux/sched/mm.h:201 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 337, name: cat CPU: 1 PID: 337 Comm: cat Not tainted 5.13.0-rc2-24-hack+ torvalds#154 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack+0xc7/0x134 ___might_sleep+0x177/0x190 __might_sleep+0x5a/0x90 kmem_cache_alloc_node_trace+0x6b/0x3a0 ? __get_vm_area_node+0xcd/0x1b0 ? dput+0x283/0x300 __get_vm_area_node+0xcd/0x1b0 __vmalloc_node_range+0x7b/0x420 ? prf_open+0x1da/0x580 ? prf_open+0x32/0x580 ? __llvm_profile_instrument_memop+0x36/0x50 vzalloc+0x54/0x60 ? prf_open+0x1da/0x580 prf_open+0x1da/0x580 full_proxy_open+0x211/0x370 .... ====== Since we can't vzalloc while holding pgo_lock, split the code into steps: * First get initial buffer size via prf_buffer_size() and release the lock. * Round up to the page size and allocate the buffer. * Finally re-acquire the pgo_lock and call prf_serialize(). prf_serialize() will now check if the buffer is large enough and returns -EAGAIN if it is not. Note that prf_buffer_size() walks linked lists that are modified by __llvm_profile_instrument_target(), so we have to "guess" the buffer size ahead of time. prf_serialize() will then return the actual data length. Signed-off-by: Jarmo Tiitto <jarmo.tiitto@gmail.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210605183128.129614-1-jarmo.tiitto@gmail.com
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jun 25, 2021
In prf_open() the required buffer size can be so large that vzalloc() may sleep thus triggering bug: ====== BUG: sleeping function called from invalid context at include/linux/sched/mm.h:201 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 337, name: cat CPU: 1 PID: 337 Comm: cat Not tainted 5.13.0-rc2-24-hack+ torvalds#154 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack+0xc7/0x134 ___might_sleep+0x177/0x190 __might_sleep+0x5a/0x90 kmem_cache_alloc_node_trace+0x6b/0x3a0 ? __get_vm_area_node+0xcd/0x1b0 ? dput+0x283/0x300 __get_vm_area_node+0xcd/0x1b0 __vmalloc_node_range+0x7b/0x420 ? prf_open+0x1da/0x580 ? prf_open+0x32/0x580 ? __llvm_profile_instrument_memop+0x36/0x50 vzalloc+0x54/0x60 ? prf_open+0x1da/0x580 prf_open+0x1da/0x580 full_proxy_open+0x211/0x370 .... ====== Since we can't vzalloc while holding pgo_lock, split the code into steps: * First get initial buffer size via prf_buffer_size() and release the lock. * Round up to the page size and allocate the buffer. * Finally re-acquire the pgo_lock and call prf_serialize(). prf_serialize() will now check if the buffer is large enough and returns -EAGAIN if it is not. Note that prf_buffer_size() walks linked lists that are modified by __llvm_profile_instrument_target(), so we have to "guess" the buffer size ahead of time. prf_serialize() will then return the actual data length. Signed-off-by: Jarmo Tiitto <jarmo.tiitto@gmail.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210605183128.129614-1-jarmo.tiitto@gmail.com
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Nov 8, 2021
In prf_open() the required buffer size can be so large that vzalloc() may sleep thus triggering bug: ====== BUG: sleeping function called from invalid context at include/linux/sched/mm.h:201 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 337, name: cat CPU: 1 PID: 337 Comm: cat Not tainted 5.13.0-rc2-24-hack+ torvalds#154 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack+0xc7/0x134 ___might_sleep+0x177/0x190 __might_sleep+0x5a/0x90 kmem_cache_alloc_node_trace+0x6b/0x3a0 ? __get_vm_area_node+0xcd/0x1b0 ? dput+0x283/0x300 __get_vm_area_node+0xcd/0x1b0 __vmalloc_node_range+0x7b/0x420 ? prf_open+0x1da/0x580 ? prf_open+0x32/0x580 ? __llvm_profile_instrument_memop+0x36/0x50 vzalloc+0x54/0x60 ? prf_open+0x1da/0x580 prf_open+0x1da/0x580 full_proxy_open+0x211/0x370 .... ====== Since we can't vzalloc while holding pgo_lock, split the code into steps: * First get initial buffer size via prf_buffer_size() and release the lock. * Round up to the page size and allocate the buffer. * Finally re-acquire the pgo_lock and call prf_serialize(). prf_serialize() will now check if the buffer is large enough and returns -EAGAIN if it is not. Note that prf_buffer_size() walks linked lists that are modified by __llvm_profile_instrument_target(), so we have to "guess" the buffer size ahead of time. prf_serialize() will then return the actual data length. Signed-off-by: Jarmo Tiitto <jarmo.tiitto@gmail.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210605183128.129614-1-jarmo.tiitto@gmail.com
JATothrim
added a commit
to JATothrim/linux
that referenced
this pull request
Nov 23, 2021
In prf_open() the required buffer size can be so large that vzalloc() may sleep thus triggering bug: ====== BUG: sleeping function called from invalid context at include/linux/sched/mm.h:201 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 337, name: cat CPU: 1 PID: 337 Comm: cat Not tainted 5.13.0-rc2-24-hack+ torvalds#154 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack+0xc7/0x134 ___might_sleep+0x177/0x190 __might_sleep+0x5a/0x90 kmem_cache_alloc_node_trace+0x6b/0x3a0 ? __get_vm_area_node+0xcd/0x1b0 ? dput+0x283/0x300 __get_vm_area_node+0xcd/0x1b0 __vmalloc_node_range+0x7b/0x420 ? prf_open+0x1da/0x580 ? prf_open+0x32/0x580 ? __llvm_profile_instrument_memop+0x36/0x50 vzalloc+0x54/0x60 ? prf_open+0x1da/0x580 prf_open+0x1da/0x580 full_proxy_open+0x211/0x370 .... ====== Since we can't vzalloc while holding pgo_lock, split the code into steps: * First get initial buffer size via prf_buffer_size() and release the lock. * Round up to the page size and allocate the buffer. * Finally re-acquire the pgo_lock and call prf_serialize(). prf_serialize() will now check if the buffer is large enough and returns -EAGAIN if it is not. Note that prf_buffer_size() walks linked lists that are modified by __llvm_profile_instrument_target(), so we have to "guess" the buffer size ahead of time. prf_serialize() will then return the actual data length. Signed-off-by: Jarmo Tiitto <jarmo.tiitto@gmail.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210605183128.129614-1-jarmo.tiitto@gmail.com
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Jun 20, 2023
The following warning was reported when doing fsync on a pmem device: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 384 at block/blk-core.c:751 submit_bio_noacct+0x340/0x520 Modules linked in: CPU: 2 PID: 384 Comm: mkfs.xfs Not tainted 6.4.0-rc7+ torvalds#154 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:submit_bio_noacct+0x340/0x520 ...... Call Trace: <TASK> ? asm_exc_invalid_op+0x1b/0x20 ? submit_bio_noacct+0x340/0x520 ? submit_bio_noacct+0xd5/0x520 submit_bio+0x37/0x60 async_pmem_flush+0x79/0xa0 nvdimm_flush+0x17/0x40 pmem_submit_bio+0x370/0x390 __submit_bio+0xbc/0x190 submit_bio_noacct_nocheck+0x14d/0x370 submit_bio_noacct+0x1ef/0x520 submit_bio+0x55/0x60 submit_bio_wait+0x5a/0xc0 blkdev_issue_flush+0x44/0x60 The root cause is that submit_bio_noacct() needs bio_op() is either WRITE or ZONE_APPEND for flush bio and async_pmem_flush() doesn't assign REQ_OP_WRITE when allocating flush bio. The reason for allocating a new flush bio is to execute the flush command asynchrously and doesn't want to block the original submit_bio() invocation. However the original submit_bio() will be blocked anyway, because the nested submit_bio() for the flush bio just places the flush bio in current->bio_list and the original submit_bio() only returns after submitting all bio in bio_list. So just removing the allocation of new flush bio and do synchronous flush directly. Fixes: b4a6bb3 ("block: add a sanity check for non-write flush/fua bios") Signed-off-by: Hou Tao <houtao1@huawei.com>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Jun 21, 2023
The following warning was reported when doing fsync on a pmem device: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 384 at block/blk-core.c:751 submit_bio_noacct+0x340/0x520 Modules linked in: CPU: 2 PID: 384 Comm: mkfs.xfs Not tainted 6.4.0-rc7+ torvalds#154 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:submit_bio_noacct+0x340/0x520 ...... Call Trace: <TASK> ? asm_exc_invalid_op+0x1b/0x20 ? submit_bio_noacct+0x340/0x520 ? submit_bio_noacct+0xd5/0x520 submit_bio+0x37/0x60 async_pmem_flush+0x79/0xa0 nvdimm_flush+0x17/0x40 pmem_submit_bio+0x370/0x390 __submit_bio+0xbc/0x190 submit_bio_noacct_nocheck+0x14d/0x370 submit_bio_noacct+0x1ef/0x520 submit_bio+0x55/0x60 submit_bio_wait+0x5a/0xc0 blkdev_issue_flush+0x44/0x60 The root cause is that submit_bio_noacct() needs bio_op() is either WRITE or ZONE_APPEND for flush bio and async_pmem_flush() doesn't assign REQ_OP_WRITE when allocating flush bio, so submit_bio_noacct just fail the flush bio. Simply fix it by adding the missing REQ_OP_WRITE for flush bio. And we could fix the flush order issue and do flush optimization later. Fixes: b4a6bb3 ("block: add a sanity check for non-write flush/fua bios") Signed-off-by: Hou Tao <houtao1@huawei.com>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Jun 25, 2023
When doing mkfs.xfs on a pmem device, the following warning was reported and : ------------[ cut here ]------------ WARNING: CPU: 2 PID: 384 at block/blk-core.c:751 submit_bio_noacct Modules linked in: CPU: 2 PID: 384 Comm: mkfs.xfs Not tainted 6.4.0-rc7+ torvalds#154 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:submit_bio_noacct+0x340/0x520 ...... Call Trace: <TASK> ? asm_exc_invalid_op+0x1b/0x20 ? submit_bio_noacct+0x340/0x520 ? submit_bio_noacct+0xd5/0x520 submit_bio+0x37/0x60 async_pmem_flush+0x79/0xa0 nvdimm_flush+0x17/0x40 pmem_submit_bio+0x370/0x390 __submit_bio+0xbc/0x190 submit_bio_noacct_nocheck+0x14d/0x370 submit_bio_noacct+0x1ef/0x520 submit_bio+0x55/0x60 submit_bio_wait+0x5a/0xc0 blkdev_issue_flush+0x44/0x60 The root cause is that submit_bio_noacct() needs bio_op() is either WRITE or ZONE_APPEND for flush bio and async_pmem_flush() doesn't assign REQ_OP_WRITE when allocating flush bio, so submit_bio_noacct just fail the flush bio. Simply fix it by adding the missing REQ_OP_WRITE for flush bio. And we could fix the flush order issue and do flush optimization later. Fixes: b4a6bb3 ("block: add a sanity check for non-write flush/fua bios") Signed-off-by: Hou Tao <houtao1@huawei.com>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Jul 20, 2023
When doing mkfs.xfs on a pmem device, the following warning was reported: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 384 at block/blk-core.c:751 submit_bio_noacct Modules linked in: CPU: 2 PID: 384 Comm: mkfs.xfs Not tainted 6.4.0-rc7+ torvalds#154 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:submit_bio_noacct+0x340/0x520 ...... Call Trace: <TASK> ? submit_bio_noacct+0xd5/0x520 submit_bio+0x37/0x60 async_pmem_flush+0x79/0xa0 nvdimm_flush+0x17/0x40 pmem_submit_bio+0x370/0x390 __submit_bio+0xbc/0x190 submit_bio_noacct_nocheck+0x14d/0x370 submit_bio_noacct+0x1ef/0x520 submit_bio+0x55/0x60 submit_bio_wait+0x5a/0xc0 blkdev_issue_flush+0x44/0x60 The root cause is that submit_bio_noacct() needs bio_op() is either WRITE or ZONE_APPEND for flush bio and async_pmem_flush() doesn't assign REQ_OP_WRITE when allocating flush bio, so submit_bio_noacct just fail the flush bio. Simply fix it by adding the missing REQ_OP_WRITE for flush bio. And we could fix the flush order issue and do flush optimization later. Cc: stable@vger.kernel.org # 6.3+ Fixes: b4a6bb3 ("block: add a sanity check for non-write flush/fua bios") Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com> Tested-by: Pankaj Gupta <pankaj.gupta@amd.com> Signed-off-by: Hou Tao <houtao1@huawei.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Jul 30, 2023
Radxa CM3S IO has one HDMI port supporting CEC and HDMI 2.0 with resolutions up to 1080P@60fps. Signed-off-by: Stephen Chen <stephen@radxa.com>
Kaz205
pushed a commit
to Kaz205/linux
that referenced
this pull request
Sep 11, 2023
commit c1dbd8a upstream. When doing mkfs.xfs on a pmem device, the following warning was reported: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 384 at block/blk-core.c:751 submit_bio_noacct Modules linked in: CPU: 2 PID: 384 Comm: mkfs.xfs Not tainted 6.4.0-rc7+ torvalds#154 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:submit_bio_noacct+0x340/0x520 ...... Call Trace: <TASK> ? submit_bio_noacct+0xd5/0x520 submit_bio+0x37/0x60 async_pmem_flush+0x79/0xa0 nvdimm_flush+0x17/0x40 pmem_submit_bio+0x370/0x390 __submit_bio+0xbc/0x190 submit_bio_noacct_nocheck+0x14d/0x370 submit_bio_noacct+0x1ef/0x520 submit_bio+0x55/0x60 submit_bio_wait+0x5a/0xc0 blkdev_issue_flush+0x44/0x60 The root cause is that submit_bio_noacct() needs bio_op() is either WRITE or ZONE_APPEND for flush bio and async_pmem_flush() doesn't assign REQ_OP_WRITE when allocating flush bio, so submit_bio_noacct just fail the flush bio. Simply fix it by adding the missing REQ_OP_WRITE for flush bio. And we could fix the flush order issue and do flush optimization later. Cc: stable@vger.kernel.org # 6.3+ Fixes: b4a6bb3 ("block: add a sanity check for non-write flush/fua bios") Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com> Tested-by: Pankaj Gupta <pankaj.gupta@amd.com> Signed-off-by: Hou Tao <houtao1@huawei.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Sep 11, 2023
commit c1dbd8a upstream. When doing mkfs.xfs on a pmem device, the following warning was reported: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 384 at block/blk-core.c:751 submit_bio_noacct Modules linked in: CPU: 2 PID: 384 Comm: mkfs.xfs Not tainted 6.4.0-rc7+ torvalds#154 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:submit_bio_noacct+0x340/0x520 ...... Call Trace: <TASK> ? submit_bio_noacct+0xd5/0x520 submit_bio+0x37/0x60 async_pmem_flush+0x79/0xa0 nvdimm_flush+0x17/0x40 pmem_submit_bio+0x370/0x390 __submit_bio+0xbc/0x190 submit_bio_noacct_nocheck+0x14d/0x370 submit_bio_noacct+0x1ef/0x520 submit_bio+0x55/0x60 submit_bio_wait+0x5a/0xc0 blkdev_issue_flush+0x44/0x60 The root cause is that submit_bio_noacct() needs bio_op() is either WRITE or ZONE_APPEND for flush bio and async_pmem_flush() doesn't assign REQ_OP_WRITE when allocating flush bio, so submit_bio_noacct just fail the flush bio. Simply fix it by adding the missing REQ_OP_WRITE for flush bio. And we could fix the flush order issue and do flush optimization later. Cc: stable@vger.kernel.org # 6.3+ Fixes: b4a6bb3 ("block: add a sanity check for non-write flush/fua bios") Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com> Tested-by: Pankaj Gupta <pankaj.gupta@amd.com> Signed-off-by: Hou Tao <houtao1@huawei.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
intersectRaven
pushed a commit
to intersectRaven/linux
that referenced
this pull request
Sep 13, 2023
commit c1dbd8a upstream. When doing mkfs.xfs on a pmem device, the following warning was reported: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 384 at block/blk-core.c:751 submit_bio_noacct Modules linked in: CPU: 2 PID: 384 Comm: mkfs.xfs Not tainted 6.4.0-rc7+ torvalds#154 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:submit_bio_noacct+0x340/0x520 ...... Call Trace: <TASK> ? submit_bio_noacct+0xd5/0x520 submit_bio+0x37/0x60 async_pmem_flush+0x79/0xa0 nvdimm_flush+0x17/0x40 pmem_submit_bio+0x370/0x390 __submit_bio+0xbc/0x190 submit_bio_noacct_nocheck+0x14d/0x370 submit_bio_noacct+0x1ef/0x520 submit_bio+0x55/0x60 submit_bio_wait+0x5a/0xc0 blkdev_issue_flush+0x44/0x60 The root cause is that submit_bio_noacct() needs bio_op() is either WRITE or ZONE_APPEND for flush bio and async_pmem_flush() doesn't assign REQ_OP_WRITE when allocating flush bio, so submit_bio_noacct just fail the flush bio. Simply fix it by adding the missing REQ_OP_WRITE for flush bio. And we could fix the flush order issue and do flush optimization later. Cc: stable@vger.kernel.org # 6.3+ Fixes: b4a6bb3 ("block: add a sanity check for non-write flush/fua bios") Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com> Tested-by: Pankaj Gupta <pankaj.gupta@amd.com> Signed-off-by: Hou Tao <houtao1@huawei.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1054009064
pushed a commit
to 1054009064/linux
that referenced
this pull request
Sep 13, 2023
commit c1dbd8a upstream. When doing mkfs.xfs on a pmem device, the following warning was reported: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 384 at block/blk-core.c:751 submit_bio_noacct Modules linked in: CPU: 2 PID: 384 Comm: mkfs.xfs Not tainted 6.4.0-rc7+ torvalds#154 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:submit_bio_noacct+0x340/0x520 ...... Call Trace: <TASK> ? submit_bio_noacct+0xd5/0x520 submit_bio+0x37/0x60 async_pmem_flush+0x79/0xa0 nvdimm_flush+0x17/0x40 pmem_submit_bio+0x370/0x390 __submit_bio+0xbc/0x190 submit_bio_noacct_nocheck+0x14d/0x370 submit_bio_noacct+0x1ef/0x520 submit_bio+0x55/0x60 submit_bio_wait+0x5a/0xc0 blkdev_issue_flush+0x44/0x60 The root cause is that submit_bio_noacct() needs bio_op() is either WRITE or ZONE_APPEND for flush bio and async_pmem_flush() doesn't assign REQ_OP_WRITE when allocating flush bio, so submit_bio_noacct just fail the flush bio. Simply fix it by adding the missing REQ_OP_WRITE for flush bio. And we could fix the flush order issue and do flush optimization later. Cc: stable@vger.kernel.org # 6.3+ Fixes: b4a6bb3 ("block: add a sanity check for non-write flush/fua bios") Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com> Tested-by: Pankaj Gupta <pankaj.gupta@amd.com> Signed-off-by: Hou Tao <houtao1@huawei.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joshua-Riek
pushed a commit
to Joshua-Riek/linux
that referenced
this pull request
Oct 24, 2023
BugLink: https://bugs.launchpad.net/bugs/2035588 commit c1dbd8a upstream. When doing mkfs.xfs on a pmem device, the following warning was reported: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 384 at block/blk-core.c:751 submit_bio_noacct Modules linked in: CPU: 2 PID: 384 Comm: mkfs.xfs Not tainted 6.4.0-rc7+ torvalds#154 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:submit_bio_noacct+0x340/0x520 ...... Call Trace: <TASK> ? submit_bio_noacct+0xd5/0x520 submit_bio+0x37/0x60 async_pmem_flush+0x79/0xa0 nvdimm_flush+0x17/0x40 pmem_submit_bio+0x370/0x390 __submit_bio+0xbc/0x190 submit_bio_noacct_nocheck+0x14d/0x370 submit_bio_noacct+0x1ef/0x520 submit_bio+0x55/0x60 submit_bio_wait+0x5a/0xc0 blkdev_issue_flush+0x44/0x60 The root cause is that submit_bio_noacct() needs bio_op() is either WRITE or ZONE_APPEND for flush bio and async_pmem_flush() doesn't assign REQ_OP_WRITE when allocating flush bio, so submit_bio_noacct just fail the flush bio. Simply fix it by adding the missing REQ_OP_WRITE for flush bio. And we could fix the flush order issue and do flush optimization later. Cc: stable@vger.kernel.org # 6.3+ Fixes: b4a6bb3 ("block: add a sanity check for non-write flush/fua bios") Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com> Tested-by: Pankaj Gupta <pankaj.gupta@amd.com> Signed-off-by: Hou Tao <houtao1@huawei.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There should be no seperation between userspace and kernel space. The code itself can decide where it wants to operate.