1. 16 Feb, 2023 1 commit
    • Ming Lei's avatar
      block: sync mixed merged request's failfast with 1st bio's · 3ce6a115
      Ming Lei authored
      We support mixed merge for requests/bios with different fastfail
      settings. When request fails, each time we only handle the portion
      with same failfast setting, then bios with failfast can be failed
      immediately, and bios without failfast can be retried.
      
      The idea is pretty good, but the current implementation has several
      defects:
      
      1) initially RA bio doesn't set failfast, however bio merge code
      doesn't consider this point, and just check its failfast setting for
      deciding if mixed merge is required. Fix this issue by adding helper
      of bio_failfast().
      
      2) when merging bio to request front, if this request is mixed
      merged, we have to sync request's faifast setting with 1st bio's
      failfast. Fix it by calling blk_update_mixed_merge().
      
      3) when merging bio to request back, if this request is mixed
      merged, we have to mark the bio as failfast, because blk_update_request
      simply updates request failfast with 1st bio's failfast. Fix
      it by calling blk_update_mixed_merge().
      
      Fixes one normal EXT4 READ IO failure issue, because it is observed
      that the normal READ IO is merged with RA IO, and the mixed merged
      request has different failfast setting with 1st bio's, so finally
      the normal READ IO doesn't get retried.
      
      Cc: Tejun Heo <tj@kernel.org>
      Fixes: 80a761fd ("block: implement mixed merge of different failfast requests")
      Signed-off-by: default avatarMing Lei <ming.lei@redhat.com>
      Link: https://lore.kernel.org/r/20230209125527.667004-1-ming.lei@redhat.comSigned-off-by: default avatarJens Axboe <axboe@kernel.dk>
      3ce6a115
  2. 15 Feb, 2023 1 commit
  3. 14 Feb, 2023 7 commits
  4. 13 Feb, 2023 1 commit
  5. 10 Feb, 2023 3 commits
  6. 09 Feb, 2023 4 commits
  7. 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
  8. 07 Feb, 2023 5 commits
  9. 06 Feb, 2023 15 commits