Skip to content
  1. Feb 09, 2024
    • Tejun Heo's avatar
      blk-iocost: Fix an UBSAN shift-out-of-bounds warning · 2a427b49
      Tejun Heo authored
      
      
      When iocg_kick_delay() is called from a CPU different than the one which set
      the delay, @now may be in the past of @iocg->delay_at leading to the
      following warning:
      
        UBSAN: shift-out-of-bounds in block/blk-iocost.c:1359:23
        shift exponent 18446744073709 is too large for 64-bit type 'u64' (aka 'unsigned long long')
        ...
        Call Trace:
         <TASK>
         dump_stack_lvl+0x79/0xc0
         __ubsan_handle_shift_out_of_bounds+0x2ab/0x300
         iocg_kick_delay+0x222/0x230
         ioc_rqos_merge+0x1d7/0x2c0
         __rq_qos_merge+0x2c/0x80
         bio_attempt_back_merge+0x83/0x190
         blk_attempt_plug_merge+0x101/0x150
         blk_mq_submit_bio+0x2b1/0x720
         submit_bio_noacct_nocheck+0x320/0x3e0
         __swap_writepage+0x2ab/0x9d0
      
      The underflow itself doesn't really affect the behavior in any meaningful
      way; however, the past timestamp may exaggerate the delay amount calculated
      later in the code, which shouldn't be a material problem given the nature of
      the delay mechanism.
      
      If @now is in the past, this CPU is racing another CPU which recently set up
      the delay and there's nothing this CPU can contribute w.r.t. the delay.
      Let's bail early from iocg_kick_delay() in such cases.
      
      Reported-by: default avatarBreno Leitão <leitao@debian.org>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Fixes: 5160a5a5 ("blk-iocost: implement delay adjustment hysteresis")
      Link: https://lore.kernel.org/r/ZVvc9L_CYk5LO1fT@slm.duckdns.org
      
      
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      2a427b49
  2. Feb 07, 2024
    • Jan Kara's avatar
      blk-wbt: Fix detection of dirty-throttled tasks · f814bdda
      Jan Kara authored
      The detection of dirty-throttled tasks in blk-wbt has been subtly broken
      since its beginning in 2016. Namely if we are doing cgroup writeback and
      the throttled task is not in the root cgroup, balance_dirty_pages() will
      set dirty_sleep for the non-root bdi_writeback structure. However
      blk-wbt checks dirty_sleep only in the root cgroup bdi_writeback
      structure. Thus detection of recently throttled tasks is not working in
      this case (we noticed this when we switched to cgroup v2 and suddently
      writeback was slow).
      
      Since blk-wbt has no easy way to get to proper bdi_writeback and
      furthermore its intention has always been to work on the whole device
      rather than on individual cgroups, just move the dirty_sleep timestamp
      from bdi_writeback to backing_dev_info. That fixes the checking for
      recently throttled task and saves memory for everybody as a bonus.
      
      CC: stable@vger.kernel.org
      Fixes: b57d74af
      
       ("writeback: track if we're sleeping on progress in balance_dirty_pages()")
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20240123175826.21452-1-jack@suse.cz
      
      
      [axboe: fixup indentation errors]
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      f814bdda
  3. Feb 02, 2024
    • Hongyu Jin's avatar
      block: Fix where bio IO priority gets set · f3c89983
      Hongyu Jin authored
      Commit 82b74cac ("blk-ioprio: Convert from rqos policy to direct
      call") pushed setting bio I/O priority down into blk_mq_submit_bio()
      -- which is too low within block core's submit_bio() because it
      skips setting I/O priority for block drivers that implement
      fops->submit_bio() (e.g. DM, MD, etc).
      
      Fix this by moving bio_set_ioprio() up from blk-mq.c to blk-core.c and
      call it from submit_bio().  This ensures all block drivers call
      bio_set_ioprio() during initial bio submission.
      
      Fixes: a78418e6
      
       ("block: Always initialize bio IO priority on submit")
      Co-developed-by: default avatarYibin Ding <yibin.ding@unisoc.com>
      Signed-off-by: default avatarYibin Ding <yibin.ding@unisoc.com>
      Signed-off-by: default avatarHongyu Jin <hongyu.jin@unisoc.com>
      Reviewed-by: default avatarEric Biggers <ebiggers@google.com>
      Reviewed-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      [snitzer: revised commit header]
      Signed-off-by: default avatarMike Snitzer <snitzer@kernel.org>
      Reviewed-by: default avatarMing Lei <ming.lei@redhat.com>
      Link: https://lore.kernel.org/r/20240130202638.62600-2-snitzer@kernel.org
      
      
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      f3c89983
    • Jens Axboe's avatar
      Merge tag 'nvme-6.8-2024-02-01' of git://git.infradead.org/nvme into block-6.8 · 37358164
      Jens Axboe authored
      Pull NVMe fixes from Keith:
      
      "nvme fixes for Linux 6.8
      
       - Remove duplicated enums (Guixen)
       - Use appropriate controller state accessors (Keith)
       - Retryable authentication (Hannes)
       - Add missing module descriptions (Chaitanya)
       - Fibre-channel fixes for blktests (Daniel)
       - Various type correctness updates (Caleb)
       - Improve fabrics connection debugging prints (Nitin)
       - Passthrough command verbose error logging (Adam)"
      
      * tag 'nvme-6.8-2024-02-01' of git://git.infradead.org/nvme: (31 commits)
        nvme: allow passthru cmd error logging
        nvme-fc: show hostnqn when connecting to fc target
        nvme-rdma: show hostnqn when connecting to rdma target
        nvme-tcp: show hostnqn when connecting to tcp target
        nvmet-fc: use RCU list iterator for assoc_list
        nvmet-fc: take ref count on tgtport before delete assoc
        nvmet-fc: avoid deadlock on delete association path
        nvmet-fc: abort command when there is no binding
        nvmet-fc: do not tack refs on tgtports from assoc
        nvmet-fc: remove null hostport pointer check
        nvmet-fc: hold reference on hostport match
        nvmet-fc: free queue and assoc directly
        nvmet-fc: defer cleanup using RCU properly
        nvmet-fc: release reference on target port
        nvmet-fcloop: swap the list_add_tail arguments
        nvme-fc: do not wait in vain when unloading module
        nvme-fc: log human-readable opcode on timeout
        nvme: split out fabrics version of nvme_opcode_str()
        nvme: take const cmd pointer in read-only helpers
        nvme: remove redundant status mask
        ...
      37358164
  4. Feb 01, 2024
  5. Jan 29, 2024
  6. Jan 27, 2024
  7. Jan 26, 2024
  8. Jan 25, 2024
    • Mikulas Patocka's avatar
      md: fix a suspicious RCU usage warning · 9f3fe29d
      Mikulas Patocka authored
      RCU protection was removed in the commit 2d32777d
      
       ("raid1: remove rcu
      protection to access rdev from conf").
      
      However, the code in fix_read_error does rcu_dereference outside
      rcu_read_lock - this triggers the following warning. The warning is
      triggered by a LVM2 test shell/integrity-caching.sh.
      
      This commit removes rcu_dereference.
      
      =============================
      WARNING: suspicious RCU usage
      6.7.0 #2 Not tainted
      -----------------------------
      drivers/md/raid1.c:2265 suspicious rcu_dereference_check() usage!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 2, debug_locks = 1
      no locks held by mdX_raid1/1859.
      
      stack backtrace:
      CPU: 2 PID: 1859 Comm: mdX_raid1 Not tainted 6.7.0 #2
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
      Call Trace:
       <TASK>
       dump_stack_lvl+0x60/0x70
       lockdep_rcu_suspicious+0x153/0x1b0
       raid1d+0x1732/0x1750 [raid1]
       ? lock_acquire+0x9f/0x270
       ? finish_wait+0x3d/0x80
       ? md_thread+0xf7/0x130 [md_mod]
       ? lock_release+0xaa/0x230
       ? md_register_thread+0xd0/0xd0 [md_mod]
       md_thread+0xa0/0x130 [md_mod]
       ? housekeeping_test_cpu+0x30/0x30
       kthread+0xdc/0x110
       ? kthread_complete_and_exit+0x20/0x20
       ret_from_fork+0x28/0x40
       ? kthread_complete_and_exit+0x20/0x20
       ret_from_fork_asm+0x11/0x20
       </TASK>
      
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Fixes: ca294b34
      
       ("md/raid1: support read error check")
      Reviewed-by: default avatarYu Kuai <yukuai3@huawei.com>
      Signed-off-by: default avatarSong Liu <song@kernel.org>
      Link: https://lore.kernel.org/r/51539879-e1ca-fde3-b8b4-8934ddedcbc@redhat.com
      9f3fe29d
  9. Jan 24, 2024
  10. Jan 23, 2024