1. 17 Feb, 2023 2 commits
    • Pankaj Raghav's avatar
      brd: use radix_tree_maybe_preload instead of radix_tree_preload · 0aa2988e
      Pankaj Raghav authored
      Unconditionally calling radix_tree_preload_end() results in a OOPS
      message as the preload is only conditionally called for
      gfpflags_allow_blocking().
      
      [   20.267323] BUG: using smp_processor_id() in preemptible [00000000] code: fio/416
      [   20.267837] caller is brd_insert_page.part.0+0xbe/0x190 [brd]
      [   20.269436] Call Trace:
      [   20.269598]  <TASK>
      [   20.269742]  dump_stack_lvl+0x32/0x50
      [   20.269982]  check_preemption_disabled+0xd1/0xe0
      [   20.270289]  brd_insert_page.part.0+0xbe/0x190 [brd]
      [   20.270664]  brd_submit_bio+0x33f/0xf40 [brd]
      
      Use radix_tree_maybe_preload() which does preload only if
      gfpflags_allow_blocking() is true but also takes the lock. Therefore,
      unconditionally calling radix_tree_preload_end() should not create any
      issues and the message disappears.
      
      Fixes: 6ded703c ("brd: check for REQ_NOWAIT and set correct page allocation mask")
      Signed-off-by: default avatarPankaj Raghav <p.raghav@samsung.com>
      Link: https://lore.kernel.org/r/20230217121442.33914-1-p.raghav@samsung.comSigned-off-by: default avatarJens Axboe <axboe@kernel.dk>
      0aa2988e
    • Jens Axboe's avatar
      block: use proper return value from bio_failfast() · f3ca7386
      Jens Axboe authored
      kernel test robot complains about a type mismatch:
      
         block/blk-merge.c:984:42: sparse:     expected restricted blk_opf_t const [usertype] ff
         block/blk-merge.c:984:42: sparse:     got unsigned int
         block/blk-merge.c:1010:42: sparse: sparse: incorrect type in initializer (different base types) @@     expected restricted blk_opf_t const [usertype] ff @@     got unsigned int @@
         block/blk-merge.c:1010:42: sparse:     expected restricted blk_opf_t const [usertype] ff
         block/blk-merge.c:1010:42: sparse:     got unsigned int
      
      because bio_failfast() is return an unsigned int rather than the
      appropriate blk_opt_f type. Fix it up.
      
      Fixes: 3ce6a115 ("block: sync mixed merged request's failfast with 1st bio's")
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Link: https://lore.kernel.org/oe-kbuild-all/202302170743.GXypM9Rt-lkp@intel.com/Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      f3ca7386
  2. 16 Feb, 2023 6 commits
  3. 15 Feb, 2023 1 commit
  4. 14 Feb, 2023 7 commits
  5. 13 Feb, 2023 1 commit
  6. 10 Feb, 2023 3 commits
  7. 09 Feb, 2023 4 commits
  8. 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
  9. 07 Feb, 2023 5 commits
  10. 06 Feb, 2023 8 commits