1. 09 Feb, 2023 2 commits
  2. 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
  3. 07 Feb, 2023 5 commits
  4. 06 Feb, 2023 17 commits
  5. 03 Feb, 2023 13 commits