Skip to content
  1. Feb 09, 2023
    • Xiao Ni's avatar
      block: Merge bio before checking ->cached_rq · 23f3e327
      Xiao Ni authored
      
      
      It checks if plug->cached_rq is empty before merging bio. But the merge action
      doesn't have relationship with plug->cached_rq, it trys to merge bio with
      requests within plug->mq_list. Now it checks if ->cached_rq is empty before
      merging bio. If it's empty, it will miss the merge chances. So move the merge
      function before checking ->cached_rq.
      
      Signed-off-by: default avatarXiao Ni <xni@redhat.com>
      Reviewed-by: default avatarMing Lei <ming.lei@redhat.com>
      Link: https://lore.kernel.org/r/20230209031930.27354-1-xni@redhat.com
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      23f3e327
    • Christoph Hellwig's avatar
      Revert "blk-cgroup: simplify blkg freeing from initialization failure paths" · dcb52201
      Christoph Hellwig authored
      It turns out this was too soon.  blkg_conf_prep does to funky locking games
      with the queue lock for this to work properly.
      
      This reverts commit 27b642b0
      
      .
      
      Reported-by: default avatarDan Carpenter <error27@gmail.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Link: https://lore.kernel.org/r/20230209053523.437927-1-hch@lst.de
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      dcb52201
    • Christoph Hellwig's avatar
      blk-cgroup: delay calling blkcg_exit_disk until disk_release · c43332fe
      Christoph Hellwig authored
      While del_gendisk ensures there is no outstanding I/O on the queue,
      it can't prevent block layer users from building new I/O.
      
      This leads to a NULL ->root_blkg reference in bio_associate_blkg when
      allocating a new bio on a shut down file system.  Delay freeing the
      blk-cgroup subsystems from del_gendisk until disk_release to make
      sure the blkg and throttle information is still avaіlable for bio
      submitters, even if those bios will immediately fail.
      
      This now can cause a case where disk_release is called on a disk
      that hasn't been added.  That's mostly harmless, except for a case
      in blk_throttl_exit that now needs to check for a NULL ->td pointer.
      
      Fixes: 178fa7d4
      
       ("blk-cgroup: delay blk-cgroup initialization until add_disk")
      Reported-by: default avatarMing Lei <ming.lei@redhat.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarMing Lei <ming.lei@redhat.com>
      Link: https://lore.kernel.org/r/20230208063514.171485-1-hch@lst.de
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      c43332fe
    • 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
  2. Feb 08, 2023
    • 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.com
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      0abe39de
    • Yu Kuai's avatar
      block, bfq: cleanup 'bfqg->online' · f37bf75c
      Yu Kuai authored
      After commit dfd6200a
      
       ("blk-cgroup: support to track if policy is
      online"), there is no need to do this again in bfq.
      
      However, 'pd->online' is not protected by 'bfqd->lock', in order to make
      sure bfq won't see that 'pd->online' is still set after bfq_pd_offline(),
      clear it before bfq_pd_offline() is called. This is fine because other
      polices doesn't use 'pd->online' and bfq_pd_offline() will move active
      bfqq to root cgroup anyway.
      
      Signed-off-by: default avatarYu Kuai <yukuai3@huawei.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20230202134913.2364549-1-yukuai1@huaweicloud.com
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      f37bf75c
  3. Feb 07, 2023
  4. Feb 06, 2023
  5. Feb 04, 2023