1. 06 Mar, 2023 1 commit
    • 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
  2. 20 Feb, 2023 1 commit
  3. 17 Feb, 2023 4 commits
  4. 16 Feb, 2023 2 commits
  5. 14 Feb, 2023 32 commits