Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <e6a984e9-f597-d987-2eef-9c3dd8ae7f0e@kernel.dk>
Date:   Thu, 1 Dec 2022 17:58:47 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.0
Subject: Re: [PATCH 1/5] sbitmap: don't consume nr for inactive waitqueue to
 avoid lost wakeups
Content-Language: en-US
To:     Kemeng Shi <shikemeng@huaweicloud.com>,
        Kemeng Shi <shikemeng@huawei.com>
Cc:     linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
        linfeilong@huawei.com, liuzhiqiang@huawei.com
References: <20221201045408.21908-1-shikemeng@huawei.com>
 <20221201045408.21908-2-shikemeng@huawei.com>
 <81e3f861-f163-c17c-49d4-2408f16c3350@huaweicloud.com>
From:   Jens Axboe <axboe@kernel.dk>
In-Reply-To: <81e3f861-f163-c17c-49d4-2408f16c3350@huaweicloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 12/1/22 12:21?AM, Kemeng Shi wrote:
> 
> 
> on 12/1/2022 12:54 PM, Kemeng Shi wrote:
>> If we decremented queue without waiters, we should not decremente freed
>> bits number "nr", or all "nr" could be consumed in a empty queue and no
>> wakeup will be called.
>> Currently, for case "wait_cnt > 0", "nr" will not be decremented if we
>> decremented queue without watiers and retry is returned to avoid lost
>> wakeups. However for case "wait_cnt == 0", "nr" will be decremented
>> unconditionally and maybe decremented to zero. Although retry is
>> returned by active state of queue, it's not actually executed for "nr"
>> is zero.
>>
>> Fix this by only decrementing "nr" for active queue when "wait_cnt ==
>> 0". After this fix, "nr" will always be non-zero when we decremented
>> inactive queue for case "wait_cnt == 0", so the need to retry could
>> be returned by "nr" and active state of waitqueue returned for the same
>> purpose is not needed.
>>
>> Signed-off-by: Kemeng Shi <shikemeng@huawei.com>
>> ---
>>  lib/sbitmap.c | 13 ++++++-------
>>  1 file changed, 6 insertions(+), 7 deletions(-)
>>
>> diff --git a/lib/sbitmap.c b/lib/sbitmap.c
>> index 7280ae8ca88c..e40759bcf821 100644
>> --- a/lib/sbitmap.c
>> +++ b/lib/sbitmap.c
>> @@ -604,7 +604,6 @@ static bool __sbq_wake_up(struct sbitmap_queue *sbq, int *nr)
>>  	struct sbq_wait_state *ws;
>>  	unsigned int wake_batch;
>>  	int wait_cnt, cur, sub;
>> -	bool ret;
>>  
>>  	if (*nr <= 0)
>>  		return false;
>> @@ -632,15 +631,15 @@ static bool __sbq_wake_up(struct sbitmap_queue *sbq, int *nr)
>>  	if (wait_cnt > 0)
>>  		return !waitqueue_active(&ws->wait);
>>  
>> -	*nr -= sub;
>> -
>>  	/*
>>  	 * When wait_cnt == 0, we have to be particularly careful as we are
>>  	 * responsible to reset wait_cnt regardless whether we've actually
>> -	 * woken up anybody. But in case we didn't wakeup anybody, we still
>> -	 * need to retry.
>> +	 * woken up anybody. But in case we didn't wakeup anybody, we should
>> +	 * not consume nr and need to retry to avoid lost wakeups.
>>  	 */
>> -	ret = !waitqueue_active(&ws->wait);
> There is a warnning reported by checkpatch.pl which is
> "WARNING:waitqueue_active without comment" but I don't know why.

Most likely because waitqueue_active() could be racy, so a comment is
warranted on why it's safe rather than using wq_has_sleeper().

-- 
Jens Axboe