1. 11 7月, 2023 1 次提交
  2. 26 4月, 2023 2 次提交
  3. 28 2月, 2023 11 次提交
  4. 18 1月, 2023 2 次提交
  5. 11 1月, 2023 1 次提交
  6. 01 11月, 2022 1 次提交
  7. 26 10月, 2022 2 次提交
  8. 17 8月, 2022 1 次提交
  9. 09 8月, 2022 3 次提交
  10. 14 7月, 2022 1 次提交
  11. 05 7月, 2022 2 次提交
  12. 14 6月, 2022 3 次提交
  13. 28 5月, 2022 1 次提交
    • E
      io_uring: add a schedule point in io_add_buffers() · 2cd5934b
      Eric Dumazet 提交于
      stable inclusion
      from stable-v5.10.103
      commit 4a93c6594613c3429b6f30136fff115c7f803af4
      bugzilla: https://gitee.com/openeuler/kernel/issues/I56NE7
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4a93c6594613c3429b6f30136fff115c7f803af4
      
      --------------------------------
      
      commit f240762f upstream.
      
      Looping ~65535 times doing kmalloc() calls can trigger soft lockups,
      especially with DEBUG features (like KASAN).
      
      [  253.536212] watchdog: BUG: soft lockup - CPU#64 stuck for 26s! [b219417889:12575]
      [  253.544433] Modules linked in: vfat fat i2c_mux_pca954x i2c_mux spidev cdc_acm xhci_pci xhci_hcd sha3_generic gq(O)
      [  253.544451] CPU: 64 PID: 12575 Comm: b219417889 Tainted: G S         O      5.17.0-smp-DEV #801
      [  253.544457] RIP: 0010:kernel_text_address (./include/asm-generic/sections.h:192 ./include/linux/kallsyms.h:29 kernel/extable.c:67 kernel/extable.c:98)
      [  253.544464] Code: 0f 93 c0 48 c7 c1 e0 63 d7 a4 48 39 cb 0f 92 c1 20 c1 0f b6 c1 5b 5d c3 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 53 48 89 fb <48> c7 c0 00 00 80 a0 41 be 01 00 00 00 48 39 c7 72 0c 48 c7 c0 40
      [  253.544468] RSP: 0018:ffff8882d8baf4c0 EFLAGS: 00000246
      [  253.544471] RAX: 1ffff1105b175e00 RBX: ffffffffa13ef09a RCX: 00000000a13ef001
      [  253.544474] RDX: ffffffffa13ef09a RSI: ffff8882d8baf558 RDI: ffffffffa13ef09a
      [  253.544476] RBP: ffff8882d8baf4d8 R08: ffff8882d8baf5e0 R09: 0000000000000004
      [  253.544479] R10: ffff8882d8baf5e8 R11: ffffffffa0d59a50 R12: ffff8882eab20380
      [  253.544481] R13: ffffffffa0d59a50 R14: dffffc0000000000 R15: 1ffff1105b175eb0
      [  253.544483] FS:  00000000016d3380(0000) GS:ffff88af48c00000(0000) knlGS:0000000000000000
      [  253.544486] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  253.544488] CR2: 00000000004af0f0 CR3: 00000002eabfa004 CR4: 00000000003706e0
      [  253.544491] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  253.544492] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  253.544494] Call Trace:
      [  253.544496]  <TASK>
      [  253.544498] ? io_queue_sqe (fs/io_uring.c:7143)
      [  253.544505] __kernel_text_address (kernel/extable.c:78)
      [  253.544508] unwind_get_return_address (arch/x86/kernel/unwind_frame.c:19)
      [  253.544514] arch_stack_walk (arch/x86/kernel/stacktrace.c:27)
      [  253.544517] ? io_queue_sqe (fs/io_uring.c:7143)
      [  253.544521] stack_trace_save (kernel/stacktrace.c:123)
      [  253.544527] ____kasan_kmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515)
      [  253.544531] ? ____kasan_kmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515)
      [  253.544533] ? __kasan_kmalloc (mm/kasan/common.c:524)
      [  253.544535] ? kmem_cache_alloc_trace (./include/linux/kasan.h:270 mm/slab.c:3567)
      [  253.544541] ? io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)
      [  253.544544] ? __io_queue_sqe (fs/io_uring.c:?)
      [  253.544551] __kasan_kmalloc (mm/kasan/common.c:524)
      [  253.544553] kmem_cache_alloc_trace (./include/linux/kasan.h:270 mm/slab.c:3567)
      [  253.544556] ? io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)
      [  253.544560] io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)
      [  253.544564] ? __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)
      [  253.544567] ? __kasan_slab_alloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)
      [  253.544569] ? kmem_cache_alloc_bulk (mm/slab.h:732 mm/slab.c:3546)
      [  253.544573] ? __io_alloc_req_refill (fs/io_uring.c:2078)
      [  253.544578] ? io_submit_sqes (fs/io_uring.c:7441)
      [  253.544581] ? __se_sys_io_uring_enter (fs/io_uring.c:10154 fs/io_uring.c:10096)
      [  253.544584] ? __x64_sys_io_uring_enter (fs/io_uring.c:10096)
      [  253.544587] ? do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
      [  253.544590] ? entry_SYSCALL_64_after_hwframe (??:?)
      [  253.544596] __io_queue_sqe (fs/io_uring.c:?)
      [  253.544600] io_queue_sqe (fs/io_uring.c:7143)
      [  253.544603] io_submit_sqe (fs/io_uring.c:?)
      [  253.544608] io_submit_sqes (fs/io_uring.c:?)
      [  253.544612] __se_sys_io_uring_enter (fs/io_uring.c:10154 fs/io_uring.c:10096)
      [  253.544616] __x64_sys_io_uring_enter (fs/io_uring.c:10096)
      [  253.544619] do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
      [  253.544623] entry_SYSCALL_64_after_hwframe (??:?)
      
      Fixes: ddf0322d ("io_uring: add IORING_OP_PROVIDE_BUFFERS")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Pavel Begunkov <asml.silence@gmail.com>
      Cc: io-uring <io-uring@vger.kernel.org>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Link: https://lore.kernel.org/r/20220215041003.2394784-1-eric.dumazet@gmail.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYu Liao <liaoyu15@huawei.com>
      Reviewed-by: NWei Li <liwei391@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      2cd5934b
  14. 18 5月, 2022 1 次提交
  15. 19 4月, 2022 1 次提交
  16. 14 1月, 2022 3 次提交
    • Y
      io_uring: fix soft lockup when call __io_remove_buffers · 4222bec0
      Ye Bin 提交于
      mainline inclusion
      from mainline-v5.16-rc3
      commit 1d0254e6
      category: bugfix
      bugzilla: 185836 https://gitee.com/openeuler/kernel/issues/I4DDEL
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1d0254e6b47e73222fd3d6ae95cccbaafe5b3ecf
      
      -----------------------------------------------
      
      I got issue as follows:
      [ 567.094140] __io_remove_buffers: [1]start ctx=0xffff8881067bf000 bgid=65533 buf=0xffff8881fefe1680
      [  594.360799] watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [kworker/u32:5:108]
      [  594.364987] Modules linked in:
      [  594.365405] irq event stamp: 604180238
      [  594.365906] hardirqs last  enabled at (604180237): [<ffffffff93fec9bd>] _raw_spin_unlock_irqrestore+0x2d/0x50
      [  594.367181] hardirqs last disabled at (604180238): [<ffffffff93fbbadb>] sysvec_apic_timer_interrupt+0xb/0xc0
      [  594.368420] softirqs last  enabled at (569080666): [<ffffffff94200654>] __do_softirq+0x654/0xa9e
      [  594.369551] softirqs last disabled at (569080575): [<ffffffff913e1d6a>] irq_exit_rcu+0x1ca/0x250
      [  594.370692] CPU: 2 PID: 108 Comm: kworker/u32:5 Tainted: G            L    5.15.0-next-20211112+ #88
      [  594.371891] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
      [  594.373604] Workqueue: events_unbound io_ring_exit_work
      [  594.374303] RIP: 0010:_raw_spin_unlock_irqrestore+0x33/0x50
      [  594.375037] Code: 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 55 f5 55 fd 48 89 ef e8 ed a7 56 fd 80 e7 02 74 06 e8 43 13 7b fd fb bf 01 00 00 00 <e8> f8 78 474
      [  594.377433] RSP: 0018:ffff888101587a70 EFLAGS: 00000202
      [  594.378120] RAX: 0000000024030f0d RBX: 0000000000000246 RCX: 1ffffffff2f09106
      [  594.379053] RDX: 0000000000000000 RSI: ffffffff9449f0e0 RDI: 0000000000000001
      [  594.379991] RBP: ffffffff9586cdc0 R08: 0000000000000001 R09: fffffbfff2effcab
      [  594.380923] R10: ffffffff977fe557 R11: fffffbfff2effcaa R12: ffff8881b8f3def0
      [  594.381858] R13: 0000000000000246 R14: ffff888153a8b070 R15: 0000000000000000
      [  594.382787] FS:  0000000000000000(0000) GS:ffff888399c00000(0000) knlGS:0000000000000000
      [  594.383851] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  594.384602] CR2: 00007fcbe71d2000 CR3: 00000000b4216000 CR4: 00000000000006e0
      [  594.385540] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  594.386474] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  594.387403] Call Trace:
      [  594.387738]  <TASK>
      [  594.388042]  find_and_remove_object+0x118/0x160
      [  594.389321]  delete_object_full+0xc/0x20
      [  594.389852]  kfree+0x193/0x470
      [  594.390275]  __io_remove_buffers.part.0+0xed/0x147
      [  594.390931]  io_ring_ctx_free+0x342/0x6a2
      [  594.392159]  io_ring_exit_work+0x41e/0x486
      [  594.396419]  process_one_work+0x906/0x15a0
      [  594.399185]  worker_thread+0x8b/0xd80
      [  594.400259]  kthread+0x3bf/0x4a0
      [  594.401847]  ret_from_fork+0x22/0x30
      [  594.402343]  </TASK>
      
      Message from syslogd@localhost at Nov 13 09:09:54 ...
      kernel:watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [kworker/u32:5:108]
      [  596.793660] __io_remove_buffers: [2099199]start ctx=0xffff8881067bf000 bgid=65533 buf=0xffff8881fefe1680
      
      We can reproduce this issue by follow syzkaller log:
      r0 = syz_io_uring_setup(0x401, &(0x7f0000000300), &(0x7f0000003000/0x2000)=nil, &(0x7f0000ff8000/0x4000)=nil, &(0x7f0000000280)=<r1=>0x0, &(0x7f0000000380)=<r2=>0x0)
      sendmsg$ETHTOOL_MSG_FEATURES_SET(0xffffffffffffffff, &(0x7f0000003080)={0x0, 0x0, &(0x7f0000003040)={&(0x7f0000000040)=ANY=[], 0x18}}, 0x0)
      syz_io_uring_submit(r1, r2, &(0x7f0000000240)=@IORING_OP_PROVIDE_BUFFERS={0x1f, 0x5, 0x0, 0x401, 0x1, 0x0, 0x100, 0x0, 0x1, {0xfffd}}, 0x0)
      io_uring_enter(r0, 0x3a2d, 0x0, 0x0, 0x0, 0x0)
      
      The reason above issue  is 'buf->list' has 2,100,000 nodes, occupied cpu lead
      to soft lockup.
      To solve this issue, we need add schedule point when do while loop in
      '__io_remove_buffers'.
      After add  schedule point we do regression, get follow data.
      [  240.141864] __io_remove_buffers: [1]start ctx=0xffff888170603000 bgid=65533 buf=0xffff8881116fcb00
      [  268.408260] __io_remove_buffers: [1]start ctx=0xffff8881b92d2000 bgid=65533 buf=0xffff888130c83180
      [  275.899234] __io_remove_buffers: [2099199]start ctx=0xffff888170603000 bgid=65533 buf=0xffff8881116fcb00
      [  296.741404] __io_remove_buffers: [1]start ctx=0xffff8881b659c000 bgid=65533 buf=0xffff8881010fe380
      [  305.090059] __io_remove_buffers: [2099199]start ctx=0xffff8881b92d2000 bgid=65533 buf=0xffff888130c83180
      [  325.415746] __io_remove_buffers: [1]start ctx=0xffff8881b92d1000 bgid=65533 buf=0xffff8881a17d8f00
      [  333.160318] __io_remove_buffers: [2099199]start ctx=0xffff8881b659c000 bgid=65533 buf=0xffff8881010fe380
      ...
      
      Fixes:8bab4c09("io_uring: allow conditional reschedule for intensive iterators")
      Signed-off-by: NYe Bin <yebin10@huawei.com>
      Link: https://lore.kernel.org/r/20211122024737.2198530-1-yebin10@huawei.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
      
      conflicts:
      fs/io_uring.c
      Signed-off-by: NYe Bin <yebin10@huawei.com>
      Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
      Signed-off-by: NChen Jun <chenjun102@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      4222bec0
    • P
      io_uring: return back safer resurrect · 71e2bfbe
      Pavel Begunkov 提交于
      mainline inclusion
      from mainline-v5.13-rc1
      commit f70865db
      category: bugfix
      bugzilla: 185824 https://gitee.com/openeuler/kernel/issues/I4DDEL
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f70865db5ff35f5ed0c7e9ef63e7cca3d4947f04
      
      -----------------------------------------------
      
      Revert of revert of "io_uring: wait potential ->release() on resurrect",
      which adds a helper for resurrect not racing completion reinit, as was
      removed because of a strange bug with no clear root or link to the
      patch.
      
      Was improved, instead of rcu_synchronize(), just wait_for_completion()
      because we're at 0 refs and it will happen very shortly. Specifically
      use non-interruptible version to ignore all pending signals that may
      have ended prior interruptible wait.
      
      This reverts commit cb5e1b81.
      Signed-off-by: NPavel Begunkov <asml.silence@gmail.com>
      Link: https://lore.kernel.org/r/7a080c20f686d026efade810b116b72f88abaff9.1618101759.git.asml.silence@gmail.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
      
      conflicts:
      fs/io_uring.c
      Signed-off-by: NYe Bin <yebin10@huawei.com>
      Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
      Signed-off-by: NChen Jun <chenjun102@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      71e2bfbe
    • P
      io_uring: fix ltout double free on completion race · 8455c60c
      Pavel Begunkov 提交于
      mainline inclusion
      from mainline-v5.13-rc2
      commit 447c19f3
      category: bugfix
      bugzilla: 185823 https://gitee.com/openeuler/kernel/issues/I4DDEL
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=447c19f3b5074409c794b350b10306e1da1ef4ba
      
      -----------------------------------------------
      
      Always remove linked timeout on io_link_timeout_fn() from the master
      request link list, otherwise we may get use-after-free when first
      io_link_timeout_fn() puts linked timeout in the fail path, and then
      will be found and put on master's free.
      
      Cc: stable@vger.kernel.org # 5.10+
      Fixes: 90cd7e42 ("io_uring: track link timeout's master explicitly")
      Reported-and-tested-by: syzbot+5a864149dd970b546223@syzkaller.appspotmail.com
      Signed-off-by: NPavel Begunkov <asml.silence@gmail.com>
      Link: https://lore.kernel.org/r/69c46bf6ce37fec4fdcd98f0882e18eb07ce693a.1620990121.git.asml.silence@gmail.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
      
      conflicts:
      fs/io_uring.c
      Signed-off-by: NYe Bin <yebin10@huawei.com>
      Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
      Signed-off-by: NChen Jun <chenjun102@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      8455c60c
  17. 15 11月, 2021 4 次提交
    • L
      Revert "io_uring: reinforce cancel on flush during exit" · ebed39f3
      Lee Jones 提交于
      stable inclusion
      from stable-5.10.78
      commit 748786564a358945922aa43a5b90710c81ed133e
      bugzilla: 185700 https://gitee.com/openeuler/kernel/issues/I4IAU2
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=748786564a358945922aa43a5b90710c81ed133e
      
      --------------------------------
      
      This reverts commit 88dbd085a51ec78c83dde79ad63bca8aa4272a9d.
      
      Causes the following Syzkaller reported issue:
      
      BUG: kernel NULL pointer dereference, address: 0000000000000010
      PGD 0 P4D 0
      Oops: 0002 [#1] PREEMPT SMP KASAN
      CPU: 1 PID: 546 Comm: syz-executor631 Tainted: G    B             5.10.76-syzkaller-01178-g4944ec82ebb9 #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:arch_atomic_try_cmpxchg syzkaller/managers/android-5-10/kernel/./arch/x86/include/asm/atomic.h:202 [inline]
      RIP: 0010:atomic_try_cmpxchg_acquire syzkaller/managers/android-5-10/kernel/./include/asm-generic/atomic-instrumented.h:707 [inline]
      RIP: 0010:queued_spin_lock syzkaller/managers/android-5-10/kernel/./include/asm-generic/qspinlock.h:82 [inline]
      RIP: 0010:do_raw_spin_lock_flags syzkaller/managers/android-5-10/kernel/./include/linux/spinlock.h:195 [inline]
      RIP: 0010:__raw_spin_lock_irqsave syzkaller/managers/android-5-10/kernel/./include/linux/spinlock_api_smp.h:119 [inline]
      RIP: 0010:_raw_spin_lock_irqsave+0x10d/0x210 syzkaller/managers/android-5-10/kernel/kernel/locking/spinlock.c:159
      Code: 00 00 00 e8 d5 29 09 fd 4c 89 e7 be 04 00 00 00 e8 c8 29 09 fd 42 8a 04 3b 84 c0 0f 85 be 00 00 00 8b 44 24 40 b9 01 00 00 00 <f0> 41 0f b1 4d 00 75 45 48 c7 44 24 20 0e 36 e0 45 4b c7 04 37 00
      RSP: 0018:ffffc90000f174e0 EFLAGS: 00010097
      RAX: 0000000000000000 RBX: 1ffff920001e2ea4 RCX: 0000000000000001
      RDX: 0000000000000001 RSI: 0000000000000004 RDI: ffffc90000f17520
      RBP: ffffc90000f175b0 R08: dffffc0000000000 R09: 0000000000000003
      R10: fffff520001e2ea5 R11: 0000000000000004 R12: ffffc90000f17520
      R13: 0000000000000010 R14: 1ffff920001e2ea0 R15: dffffc0000000000
      FS:  0000000000000000(0000) GS:ffff8881f7100000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000010 CR3: 000000000640f000 CR4: 00000000003506a0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       prepare_to_wait+0x9c/0x290 syzkaller/managers/android-5-10/kernel/kernel/sched/wait.c:248
       io_uring_cancel_files syzkaller/managers/android-5-10/kernel/fs/io_uring.c:8690 [inline]
       io_uring_cancel_task_requests+0x16a9/0x1ed0 syzkaller/managers/android-5-10/kernel/fs/io_uring.c:8760
       io_uring_flush+0x170/0x6d0 syzkaller/managers/android-5-10/kernel/fs/io_uring.c:8923
       filp_close+0xb0/0x150 syzkaller/managers/android-5-10/kernel/fs/open.c:1319
       close_files syzkaller/managers/android-5-10/kernel/fs/file.c:401 [inline]
       put_files_struct+0x1d4/0x350 syzkaller/managers/android-5-10/kernel/fs/file.c:429
       exit_files+0x80/0xa0 syzkaller/managers/android-5-10/kernel/fs/file.c:458
       do_exit+0x6d9/0x23a0 syzkaller/managers/android-5-10/kernel/kernel/exit.c:808
       do_group_exit+0x16a/0x2d0 syzkaller/managers/android-5-10/kernel/kernel/exit.c:910
       get_signal+0x133e/0x1f80 syzkaller/managers/android-5-10/kernel/kernel/signal.c:2790
       arch_do_signal+0x8d/0x620 syzkaller/managers/android-5-10/kernel/arch/x86/kernel/signal.c:805
       exit_to_user_mode_loop syzkaller/managers/android-5-10/kernel/kernel/entry/common.c:161 [inline]
       exit_to_user_mode_prepare+0xaa/0xe0 syzkaller/managers/android-5-10/kernel/kernel/entry/common.c:191
       syscall_exit_to_user_mode+0x24/0x40 syzkaller/managers/android-5-10/kernel/kernel/entry/common.c:266
       do_syscall_64+0x3d/0x70 syzkaller/managers/android-5-10/kernel/arch/x86/entry/common.c:56
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x7fc6d1589a89
      Code: Unable to access opcode bytes at RIP 0x7fc6d1589a5f.
      RSP: 002b:00007ffd2b5da728 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
      RAX: fffffffffffffdfc RBX: 0000000000005193 RCX: 00007fc6d1589a89
      RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fc6d161142c
      RBP: 0000000000000032 R08: 00007ffd2b5eb0b8 R09: 0000000000000000
      R10: 00007ffd2b5da750 R11: 0000000000000246 R12: 00007fc6d161142c
      R13: 00007ffd2b5da750 R14: 00007ffd2b5da770 R15: 0000000000000000
      Modules linked in:
      CR2: 0000000000000010
      ---[ end trace fe8044f7dc4d8d65 ]---
      RIP: 0010:arch_atomic_try_cmpxchg syzkaller/managers/android-5-10/kernel/./arch/x86/include/asm/atomic.h:202 [inline]
      RIP: 0010:atomic_try_cmpxchg_acquire syzkaller/managers/android-5-10/kernel/./include/asm-generic/atomic-instrumented.h:707 [inline]
      RIP: 0010:queued_spin_lock syzkaller/managers/android-5-10/kernel/./include/asm-generic/qspinlock.h:82 [inline]
      RIP: 0010:do_raw_spin_lock_flags syzkaller/managers/android-5-10/kernel/./include/linux/spinlock.h:195 [inline]
      RIP: 0010:__raw_spin_lock_irqsave syzkaller/managers/android-5-10/kernel/./include/linux/spinlock_api_smp.h:119 [inline]
      RIP: 0010:_raw_spin_lock_irqsave+0x10d/0x210 syzkaller/managers/android-5-10/kernel/kernel/locking/spinlock.c:159
      Code: 00 00 00 e8 d5 29 09 fd 4c 89 e7 be 04 00 00 00 e8 c8 29 09 fd 42 8a 04 3b 84 c0 0f 85 be 00 00 00 8b 44 24 40 b9 01 00 00 00 <f0> 41 0f b1 4d 00 75 45 48 c7 44 24 20 0e 36 e0 45 4b c7 04 37 00
      RSP: 0018:ffffc90000f174e0 EFLAGS: 00010097
      RAX: 0000000000000000 RBX: 1ffff920001e2ea4 RCX: 0000000000000001
      RDX: 0000000000000001 RSI: 0000000000000004 RDI: ffffc90000f17520
      RBP: ffffc90000f175b0 R08: dffffc0000000000 R09: 0000000000000003
      R10: fffff520001e2ea5 R11: 0000000000000004 R12: ffffc90000f17520
      R13: 0000000000000010 R14: 1ffff920001e2ea0 R15: dffffc0000000000
      FS:  0000000000000000(0000) GS:ffff8881f7100000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000010 CR3: 000000000640f000 CR4: 00000000003506a0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      ----------------
      Code disassembly (best guess), 1 bytes skipped:
         0:	00 00                	add    %al,(%rax)
         2:	e8 d5 29 09 fd       	callq  0xfd0929dc
         7:	4c 89 e7             	mov    %r12,%rdi
         a:	be 04 00 00 00       	mov    $0x4,%esi
         f:	e8 c8 29 09 fd       	callq  0xfd0929dc
        14:	42 8a 04 3b          	mov    (%rbx,%r15,1),%al
        18:	84 c0                	test   %al,%al
        1a:	0f 85 be 00 00 00    	jne    0xde
        20:	8b 44 24 40          	mov    0x40(%rsp),%eax
        24:	b9 01 00 00 00       	mov    $0x1,%ecx
      * 29:	f0 41 0f b1 4d 00    	lock cmpxchg %ecx,0x0(%r13) <-- trapping instruction
        2f:	75 45                	jne    0x76
        31:	48 c7 44 24 20 0e 36 	movq   $0x45e0360e,0x20(%rsp)
        38:	e0 45
        3a:	4b                   	rex.WXB
        3b:	c7                   	.byte 0xc7
        3c:	04 37                	add    $0x37,%al
      
      Link: https://syzkaller.appspot.com/bug?extid=b0003676644cf0d6acc4
      Reported-by: syzbot+b0003676644cf0d6acc4@syzkaller.appspotmail.com
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NChen Jun <chenjun102@huawei.com>
      Acked-by: NWeilong Chen <chenweilong@huawei.com>
      Signed-off-by: NChen Jun <chenjun102@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      ebed39f3
    • P
      io_uring: don't take uring_lock during iowq cancel · c5562a26
      Pavel Begunkov 提交于
      mainline inclusion
      from mainline-5.12-rc1
      commit 792bb6eb
      category: bugfix
      bugzilla: 182869 https://gitee.com/openeuler/kernel/issues/I4DDEL
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=792bb6eb862333658bf1bd2260133f0507e2da8d
      
      ---------------------------
      
      [   97.866748] a.out/2890 is trying to acquire lock:
      [   97.867829] ffff8881046763e8 (&ctx->uring_lock){+.+.}-{3:3}, at:
      io_wq_submit_work+0x155/0x240
      [   97.869735]
      [   97.869735] but task is already holding lock:
      [   97.871033] ffff88810dfe0be8 (&ctx->uring_lock){+.+.}-{3:3}, at:
      __x64_sys_io_uring_enter+0x3f0/0x5b0
      [   97.873074]
      [   97.873074] other info that might help us debug this:
      [   97.874520]  Possible unsafe locking scenario:
      [   97.874520]
      [   97.875845]        CPU0
      [   97.876440]        ----
      [   97.877048]   lock(&ctx->uring_lock);
      [   97.877961]   lock(&ctx->uring_lock);
      [   97.878881]
      [   97.878881]  *** DEADLOCK ***
      [   97.878881]
      [   97.880341]  May be due to missing lock nesting notation
      [   97.880341]
      [   97.881952] 1 lock held by a.out/2890:
      [   97.882873]  #0: ffff88810dfe0be8 (&ctx->uring_lock){+.+.}-{3:3}, at:
      __x64_sys_io_uring_enter+0x3f0/0x5b0
      [   97.885108]
      [   97.885108] stack backtrace:
      [   97.890457] Call Trace:
      [   97.891121]  dump_stack+0xac/0xe3
      [   97.891972]  __lock_acquire+0xab6/0x13a0
      [   97.892940]  lock_acquire+0x2c3/0x390
      [   97.894894]  __mutex_lock+0xae/0x9f0
      [   97.901101]  io_wq_submit_work+0x155/0x240
      [   97.902112]  io_wq_cancel_cb+0x162/0x490
      [   97.904126]  io_async_find_and_cancel+0x3b/0x140
      [   97.905247]  io_issue_sqe+0x86d/0x13e0
      [   97.909122]  __io_queue_sqe+0x10b/0x550
      [   97.913971]  io_queue_sqe+0x235/0x470
      [   97.914894]  io_submit_sqes+0xcce/0xf10
      [   97.917872]  __x64_sys_io_uring_enter+0x3fb/0x5b0
      [   97.921424]  do_syscall_64+0x2d/0x40
      [   97.922329]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      While holding uring_lock, e.g. from inline execution, async cancel
      request may attempt cancellations through io_wq_submit_work, which may
      try to grab a lock. Delay it to task_work, so we do it from a clean
      context and don't have to worry about locking.
      
      Cc: <stable@vger.kernel.org> # 5.5+
      Fixes: c07e6719 ("io_uring: hold uring_lock while completing failed polled io in io_wq_submit_work()")
      Reported-by: NAbaci <abaci@linux.alibaba.com>
      Reported-by: NHao Xu <haoxu@linux.alibaba.com>
      Signed-off-by: NPavel Begunkov <asml.silence@gmail.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      
      Conflicts:
      	[ 5280f7e5("io_uring/io-wq: return 2-step work swap scheme") is
      	  not applied. ]
      Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com>
      Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
      Signed-off-by: NChen Jun <chenjun102@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      c5562a26
    • P
      io_uring: deduplicate failing task_work_add · 62ca1710
      Pavel Begunkov 提交于
      mainline inclusion
      from mainline-5.12-rc1
      commit eab30c4d
      category: bugfix
      bugzilla: 182869 https://gitee.com/openeuler/kernel/issues/I4DDEL
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eab30c4d20dc761d463445e5130421863ff81505
      
      ---------------------------
      
      When io_req_task_work_add() fails, the request will be cancelled by
      enqueueing via task_works of io-wq. Extract a function for that.
      Signed-off-by: NPavel Begunkov <asml.silence@gmail.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      
      Conflicts:
      	fs/io_uring.c
      	[ 355fb9e2("io_uring: remove 'twa_signal_ok' deadlock
      	  work-around") is not applied. ]
      Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com>
      Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
      Signed-off-by: NChen Jun <chenjun102@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      62ca1710
    • K
      io_uring: fix splice_fd_in checks backport typo · c9edfb29
      Kamal Mostafa 提交于
      stable inclusion
      from stable-5.10.76
      commit f59da9f7efa73a31b6287bd9b8f03a8d536e524f
      bugzilla: 182988 https://gitee.com/openeuler/kernel/issues/I4IAHF
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f59da9f7efa73a31b6287bd9b8f03a8d536e524f
      
      --------------------------------
      
      The linux-5.10.y backport of commit "io_uring: add ->splice_fd_in checks"
      includes a typo: "|" where "||" should be. (The original upstream commit
      is fine.)
      
      Fixes: 54eb6211b979 ("io_uring: add ->splice_fd_in checks")
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: stable@vger.kernel.org # v5.10
      Signed-off-by: NKamal Mostafa <kamal@canonical.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NChen Jun <chenjun102@huawei.com>
      Acked-by: NWeilong Chen <chenweilong@huawei.com>
      Signed-off-by: NChen Jun <chenjun102@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      c9edfb29