Re: [PATCH v2 2/2] blk-mq: Fix a race condition in blk_mq_mark_tag_wait()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2018-01-11 at 08:39 +0100, Hannes Reinecke wrote:
> I'm actually not that convinced with this change; originally we had been
> checking if it's on the wait list, and only _then_ call bt_wait_ptr().
> Now we call bt_wait_ptr() always, meaning we run a chance of increasing
> the bitmap_tags wait pointer without actually using it.
> Looking at the code I'm not sure this is the correct way of using it ...

Hello Hannes,

Are you perhaps referring to sbq_index_atomic_inc()? I think it's fine to
call bt_wait_ptr() even if the corresponding waitqueue won't be used. My
understanding is that the purpose of having multiple waitqueues and of
using these in a round-robin fashion is to avoid that if less than or equal
to 8 (SBQ_WAIT_QUEUES) threads are waiting for a tag that these won't use
the same wait queue. So in the unlikely event of an early return the worst
that can happen is that there is more contention on one of the eight wait
queues. But since that is an unlikely scenario I don't think we have to
worry about this.

Bart.




[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux