1. 16 Mar, 2023 1 commit
  2. 09 Mar, 2023 1 commit
    • Mike Snitzer's avatar
      dm crypt: avoid accessing uninitialized tasklet · d9a02e01
      Mike Snitzer authored
      When neither "no_read_workqueue" nor "no_write_workqueue" are enabled,
      tasklet_trylock() in crypt_dec_pending() may still return false due to
      an uninitialized state, and dm-crypt will unnecessarily do io completion
      in io_queue workqueue instead of current context.
      
      Fix this by adding an 'in_tasklet' flag to dm_crypt_io struct and
      initialize it to false in crypt_io_init(). Set this flag to true in
      kcryptd_queue_crypt() before calling tasklet_schedule(). If set
      crypt_dec_pending() will punt io completion to a workqueue.
      
      This also nicely avoids the tasklet_trylock/unlock hack when tasklets
      aren't in use.
      
      Fixes: 8e14f610 ("dm crypt: do not call bio_endio() from the dm-crypt tasklet")
      Cc: stable@vger.kernel.org
      Reported-by: default avatarHou Tao <houtao1@huawei.com>
      Suggested-by: default avatarIgnat Korchagin <ignat@cloudflare.com>
      Reviewed-by: default avatarIgnat Korchagin <ignat@cloudflare.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@kernel.org>
      d9a02e01
  3. 06 Mar, 2023 2 commits
    • Mikulas Patocka's avatar
      dm crypt: add cond_resched() to dmcrypt_write() · fb294b1c
      Mikulas Patocka authored
      The loop in dmcrypt_write may be running for unbounded amount of time,
      thus we need cond_resched() in it.
      
      This commit fixes the following warning:
      
      [ 3391.153255][   C12] watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [dmcrypt_write/2:2897]
      ...
      [ 3391.387210][   C12] Call trace:
      [ 3391.390338][   C12]  blk_attempt_bio_merge.part.6+0x38/0x158
      [ 3391.395970][   C12]  blk_attempt_plug_merge+0xc0/0x1b0
      [ 3391.401085][   C12]  blk_mq_submit_bio+0x398/0x550
      [ 3391.405856][   C12]  submit_bio_noacct+0x308/0x380
      [ 3391.410630][   C12]  dmcrypt_write+0x1e4/0x208 [dm_crypt]
      [ 3391.416005][   C12]  kthread+0x130/0x138
      [ 3391.419911][   C12]  ret_from_fork+0x10/0x18
      Reported-by: default avataryangerkun <yangerkun@huawei.com>
      Fixes: dc267621 ("dm crypt: offload writes to thread")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@kernel.org>
      fb294b1c
    • Coly Li's avatar
      dm thin: fix deadlock when swapping to thin device · 9bbf5fee
      Coly Li authored
      This is an already known issue that dm-thin volume cannot be used as
      swap, otherwise a deadlock may happen when dm-thin internal memory
      demand triggers swap I/O on the dm-thin volume itself.
      
      But thanks to commit a666e5c0 ("dm: fix deadlock when swapping to
      encrypted device"), the limit_swap_bios target flag can also be used
      for dm-thin to avoid the recursive I/O when it is used as swap.
      
      Fix is to simply set ti->limit_swap_bios to true in both pool_ctr()
      and thin_ctr().
      
      In my test, I create a dm-thin volume /dev/vg/swap and use it as swap
      device. Then I run fio on another dm-thin volume /dev/vg/main and use
      large --blocksize to trigger swap I/O onto /dev/vg/swap.
      
      The following fio command line is used in my test,
        fio --name recursive-swap-io --lockmem 1 --iodepth 128 \
           --ioengine libaio --filename /dev/vg/main --rw randrw \
          --blocksize 1M --numjobs 32 --time_based --runtime=12h
      
      Without this fix, the whole system can be locked up within 15 seconds.
      
      With this fix, there is no any deadlock or hung task observed after
      2 hours of running fio.
      
      Furthermore, if blocksize is changed from 1M to 128M, after around 30
      seconds fio has no visible I/O, and the out-of-memory killer message
      shows up in kernel message. After around 20 minutes all fio processes
      are killed and the whole system is back to being alive.
      
      This is exactly what is expected when recursive I/O happens on dm-thin
      volume when it is used as swap.
      
      Depends-on: a666e5c0 ("dm: fix deadlock when swapping to encrypted device")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarColy Li <colyli@suse.de>
      Acked-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@kernel.org>
      9bbf5fee
  4. 20 Feb, 2023 1 commit
  5. 17 Feb, 2023 4 commits
  6. 16 Feb, 2023 2 commits
  7. 14 Feb, 2023 29 commits