Yang Yang 681583ad67 sbitmap: fix io hung due to race on sbitmap_word::cleared
[ Upstream commit 72d04bdcf3f7d7e07d82f9757946f68802a7270a ]

Configuration for sbq:
  depth=64, wake_batch=6, shift=6, map_nr=1

1. There are 64 requests in progress:
  map->word = 0xFFFFFFFFFFFFFFFF
2. After all the 64 requests complete, and no more requests come:
  map->word = 0xFFFFFFFFFFFFFFFF, map->cleared = 0xFFFFFFFFFFFFFFFF
3. Now two tasks try to allocate requests:
  T1:                                       T2:
  __blk_mq_get_tag                          .
  __sbitmap_queue_get                       .
  sbitmap_get                               .
  sbitmap_find_bit                          .
  sbitmap_find_bit_in_word                  .
  __sbitmap_get_word  -> nr=-1              __blk_mq_get_tag
  sbitmap_deferred_clear                    __sbitmap_queue_get
  /* map->cleared=0xFFFFFFFFFFFFFFFF */     sbitmap_find_bit
    if (!READ_ONCE(map->cleared))           sbitmap_find_bit_in_word
      return false;                         __sbitmap_get_word -> nr=-1
    mask = xchg(&map->cleared, 0)           sbitmap_deferred_clear
    atomic_long_andnot()                    /* map->cleared=0 */
                                              if (!(map->cleared))
                                                return false;
                                     /*
                                      * map->cleared is cleared by T1
                                      * T2 fail to acquire the tag
                                      */

4. T2 is the sole tag waiter. When T1 puts the tag, T2 cannot be woken
up due to the wake_batch being set at 6. If no more requests come, T1
will wait here indefinitely.

This patch achieves two purposes:
1. Check on ->cleared and update on both ->cleared and ->word need to
be done atomically, and using spinlock could be the simplest solution.
2. Add extra check in sbitmap_deferred_clear(), to identify whether
->word has free bits.

Fixes: ea86ea2cdced ("sbitmap: ammortize cost of clearing bits")
Signed-off-by: Yang Yang <yang.yang@vivo.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20240716082644.659566-1-yang.yang@vivo.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03 08:49:29 +02:00
..
2024-07-11 12:47:08 +02:00
2021-09-08 11:50:26 -07:00
2021-07-08 11:48:20 -07:00
2021-05-06 19:24:12 -07:00
2021-01-21 14:06:00 -07:00
2022-03-07 12:48:35 -07:00
2021-08-19 09:02:55 +09:00
2022-09-01 18:04:43 +02:00
2022-04-22 21:30:57 +02:00
2021-01-03 20:05:18 -05:00
2022-03-07 12:48:35 -07:00
2022-04-29 14:38:01 -07:00
2022-10-03 14:03:21 -07:00
2021-08-19 09:02:55 +09:00
2021-07-08 11:48:20 -07:00
2021-07-08 11:48:20 -07:00
2021-07-08 11:48:20 -07:00
2022-10-03 17:34:32 -07:00
2021-09-17 13:52:17 +01:00
2021-07-08 11:48:20 -07:00
2021-07-08 11:48:20 -07:00
2021-07-08 11:48:20 -07:00
2022-06-03 10:34:34 -07:00
2021-06-18 11:43:09 +02:00
2021-07-08 11:48:20 -07:00
2022-01-20 08:52:54 +02:00