1. 24 Feb, 2023 2 commits
    • Jens Axboe's avatar
      block: be a bit more careful in checking for NULL bdev while polling · 310726c3
      Jens Axboe authored
      Wei reports a crash with an application using polled IO:
      
      PGD 14265e067 P4D 14265e067 PUD 47ec50067 PMD 0
      Oops: 0000 [#1] SMP
      CPU: 0 PID: 21915 Comm: iocore_0 Kdump: loaded Tainted: G S                5.12.0-0_fbk12_clang_7346_g1bb6f2e7058f #1
      Hardware name: Wiwynn Delta Lake MP T8/Delta Lake-Class2, BIOS Y3DLM08 04/10/2022
      RIP: 0010:bio_poll+0x25/0x200
      Code: 0f 1f 44 00 00 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 28 65 48 8b 04 25 28 00 00 00 48 89 44 24 20 48 8b 47 08 <48> 8b 80 70 02 00 00 4c 8b 70 50 8b 6f 34 31 db 83 fd ff 75 25 65
      RSP: 0018:ffffc90005fafdf8 EFLAGS: 00010292
      RAX: 0000000000000000 RBX: 0000000000000000 RCX: 74b43cd65dd66600
      RDX: 0000000000000003 RSI: ffffc90005fafe78 RDI: ffff8884b614e140
      RBP: ffff88849964df78 R08: 0000000000000000 R09: 0000000000000008
      R10: 0000000000000000 R11: 0000000000000000 R12: ffff88849964df00
      R13: ffffc90005fafe78 R14: ffff888137d3c378 R15: 0000000000000001
      FS:  00007fd195000640(0000) GS:ffff88903f400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000270 CR3: 0000000466121001 CR4: 00000000007706f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      PKRU: 55555554
      Call Trace:
       iocb_bio_iopoll+0x1d/0x30
       io_do_iopoll+0xac/0x250
       __se_sys_io_uring_enter+0x3c5/0x5a0
       ? __x64_sys_write+0x89/0xd0
       do_syscall_64+0x2d/0x40
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      RIP: 0033:0x94f225d
      Code: 24 cc 00 00 00 41 8b 84 24 d0 00 00 00 c1 e0 04 83 e0 10 41 09 c2 8b 33 8b 53 04 4c 8b 43 18 4c 63 4b 0c b8 aa 01 00 00 0f 05 <85> c0 0f 88 85 00 00 00 29 03 45 84 f6 0f 84 88 00 00 00 41 f6 c7
      RSP: 002b:00007fd194ffcd88 EFLAGS: 00000202 ORIG_RAX: 00000000000001aa
      RAX: ffffffffffffffda RBX: 00007fd194ffcdc0 RCX: 00000000094f225d
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000007
      RBP: 00007fd194ffcdb0 R08: 0000000000000000 R09: 0000000000000008
      R10: 0000000000000001 R11: 0000000000000202 R12: 00007fd269d68030
      R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000000
      
      which is due to bio->bi_bdev being NULL. This can happen if we have two
      tasks doing polled IO, and task B ends up completing IO from task A if
      they are sharing a poll queue. If task B completes the IO and puts the
      bio into our cache, then it can allocate that bio again before task A
      is done polling for it. As that would necessitate a preempt between the
      two tasks, it's enough to just be a bit more careful in checking for
      whether or not bio->bi_bdev is NULL.
      Reported-and-tested-by: default avatarWei Zhang <wzhang@meta.com>
      Cc: stable@vger.kernel.org
      Fixes: be4d234d ("bio: add allocation cache abstraction")
      Reviewed-by: default avatarKeith Busch <kbusch@kernel.org>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      310726c3
    • Jens Axboe's avatar
      block: clear bio->bi_bdev when putting a bio back in the cache · 11eb695f
      Jens Axboe authored
      This isn't strictly needed in terms of correctness, but it does allow
      polling to know if the bio has been put already by a different task
      and hence avoid polling something that we don't need to.
      
      Cc: stable@vger.kernel.org
      Fixes: be4d234d ("bio: add allocation cache abstraction")
      Reviewed-by: default avatarKeith Busch <kbusch@kernel.org>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      11eb695f
  2. 23 Feb, 2023 1 commit
  3. 21 Feb, 2023 2 commits
  4. 17 Feb, 2023 6 commits
  5. 16 Feb, 2023 6 commits
  6. 15 Feb, 2023 1 commit
  7. 14 Feb, 2023 7 commits
  8. 13 Feb, 2023 1 commit
  9. 10 Feb, 2023 3 commits
  10. 09 Feb, 2023 4 commits
  11. 08 Feb, 2023 3 commits
    • Jens Axboe's avatar
      Merge branch 'md-next' of... · a872818f
      Jens Axboe authored
      Merge branch 'md-next' of https://git.kernel.org/pub/scm/linux/kernel/git/song/md into for-6.3/block
      
      Pull MD fix from Song:
      
      "This commit fixes a rare crash during the takeover process."
      
      * 'md-next' of https://git.kernel.org/pub/scm/linux/kernel/git/song/md:
        md: account io_acct_set usage with active_io
      a872818f
    • Xiao Ni's avatar
      md: account io_acct_set usage with active_io · 76fed014
      Xiao Ni authored
      io_acct_set was enabled for raid0/raid5 io accounting. bios that contain
      md_io_acct are allocated in the i/o path. There isn't a good method to
      monitor if these bios are all finished and freed. In the takeover process,
      io_acct_set (which is used for bios with md_io_acct) need to be freed.
      However, if some bios finish after io_acct_set is freed, it may trigger
      the following panic:
      
      [ 6973.767999] RIP: 0010:mempool_free+0x52/0x80
      [ 6973.786098] Call Trace:
      [ 6973.786549]  md_end_io_acct+0x31/0x40
      [ 6973.787227]  blk_update_request+0x224/0x380
      [ 6973.787994]  blk_mq_end_request+0x1a/0x130
      [ 6973.788739]  blk_complete_reqs+0x35/0x50
      [ 6973.789456]  __do_softirq+0xd7/0x2c8
      [ 6973.790114]  ? sort_range+0x20/0x20
      [ 6973.790763]  run_ksoftirqd+0x2a/0x40
      [ 6973.791400]  smpboot_thread_fn+0xb5/0x150
      [ 6973.792114]  kthread+0x10b/0x130
      [ 6973.792724]  ? set_kthread_struct+0x50/0x50
      [ 6973.793491]  ret_from_fork+0x1f/0x40
      
      Fix this by increasing and decreasing active_io for each bio with
      md_io_acct so that mddev_suspend() will wait until all bios from
      io_acct_set finish before freeing io_acct_set.
      Reported-by: default avatarFine Fan <ffan@redhat.com>
      Signed-off-by: default avatarXiao Ni <xni@redhat.com>
      Signed-off-by: default avatarSong Liu <song@kernel.org>
      76fed014
    • Ming Lei's avatar
      block: ublk: improve handling device deletion · 0abe39de
      Ming Lei authored
      Inside ublk_ctrl_del_dev(), when the device is removed, we wait
      until the device number is freed with holding global lock of
      ublk_ctl_mutex, this way isn't friendly from user viewpoint:
      
      1) if device is in-use, the current delete command hangs in
      ublk_ctrl_del_dev(), and user can't break from the handling
      because wait_event() is used
      
      2) global lock is held, so any new device can't be added and
      other old devices can't be removed.
      
      Improve the deleting handling by the following way, suggested by
      Nadav:
      
      1) wait without holding the global lock
      
      2) replace wait_event() with wait_event_interruptible()
      Reported-by: default avatarNadav Amit <nadav.amit@gmail.com>
      Suggested-by: default avatarNadav Amit <nadav.amit@gmail.com>
      Signed-off-by: default avatarMing Lei <ming.lei@redhat.com>
      Link: https://lore.kernel.org/r/20230207150700.545530-1-ming.lei@redhat.comSigned-off-by: default avatarJens Axboe <axboe@kernel.dk>
      0abe39de
  12. 07 Feb, 2023 4 commits