1. 08 Feb, 2024 1 commit
    • 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.orgSigned-off-by: default avatarJens Axboe <axboe@kernel.dk>
      2a427b49
  2. 06 Feb, 2024 1 commit
    • 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. 01 Feb, 2024 24 commits
  4. 31 Jan, 2024 3 commits
  5. 29 Jan, 2024 1 commit
  6. 26 Jan, 2024 2 commits
  7. 25 Jan, 2024 1 commit
    • 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
  8. 24 Jan, 2024 4 commits
  9. 23 Jan, 2024 2 commits
  10. 22 Jan, 2024 1 commit