Yang Yang 420837d08c 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 09:00:26 +02:00
..
2024-01-19 11:59:11 -08:00
2024-02-01 13:06:40 +01:00
2023-11-03 07:08:36 -10: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
2024-04-25 21:07:06 -07:00
2023-02-02 22:50:01 -08:00
2023-02-02 22:50:01 -08:00
2021-01-03 20:05:18 -05:00
2024-05-21 15:29:01 -07: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
2024-03-11 09:38:17 -07:00
2021-08-19 09:02:55 +09:00
2024-04-25 21:07:05 -07:00
2024-05-22 11:53:02 -07:00
2023-08-21 13:46:25 -07:00
2023-04-17 18:01:23 +02:00
2021-07-08 11:48:20 -07:00
2023-10-16 12:44:06 -04:00
2023-08-24 16:20:18 -07:00
2023-10-16 12:44:06 -04:00
2022-10-03 17:34:32 -07:00
2021-07-08 11:48:20 -07:00
2024-02-15 12:17:28 -05:00
2022-06-03 10:34:34 -07:00
2024-02-20 20:47:32 -08:00
2021-06-18 11:43:09 +02:00
2024-05-21 15:29:01 -07:00
2024-04-16 17:22:18 +02:00
2022-01-20 08:52:54 +02:00
2024-05-19 16:12:38 -07:00
2024-05-02 17:48:09 -04:00