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: <fe5a50a8-25b8-91b2-3a84-e68efa1905bb@kernel.dk>
Date:   Wed, 19 Oct 2022 10:37:33 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.3
Subject: Re: [PATCH 6.0 479/862] sbitmap: fix possible io hung due to lost
 wakeup
Content-Language: en-US
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Hugh Dickins <hughd@google.com>
Cc:     linux-kernel@vger.kernel.org, stable@vger.kernel.org,
        Yu Kuai <yukuai3@huawei.com>, Jan Kara <jack@suse.cz>,
        Sasha Levin <sashal@kernel.org>, linux-block@vger.kernel.org
References: <20221019083249.951566199@linuxfoundation.org>
 <20221019083311.114449669@linuxfoundation.org>
 <174a196-5473-4e93-a52a-5e26eb37949@google.com> <Y1AzCuwWxEPoYGRr@kroah.com>
From:   Jens Axboe <axboe@kernel.dk>
In-Reply-To: <Y1AzCuwWxEPoYGRr@kroah.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 10/19/22 10:25 AM, Greg Kroah-Hartman wrote:
> On Wed, Oct 19, 2022 at 08:06:26AM -0700, Hugh Dickins wrote:
>> On Wed, 19 Oct 2022, Greg Kroah-Hartman wrote:
>>
>>> From: Yu Kuai <yukuai3@huawei.com>
>>>
>>> [ Upstream commit 040b83fcecfb86f3225d3a5de7fd9b3fbccf83b4 ]
>>>
>>> There are two problems can lead to lost wakeup:
>>>
>>> 1) invalid wakeup on the wrong waitqueue:
>>>
>>> For example, 2 * wake_batch tags are put, while only wake_batch threads
>>> are woken:
>>>
>>> __sbq_wake_up
>>>  atomic_cmpxchg -> reset wait_cnt
>>> 			__sbq_wake_up -> decrease wait_cnt
>>> 			...
>>> 			__sbq_wake_up -> wait_cnt is decreased to 0 again
>>> 			 atomic_cmpxchg
>>> 			 sbq_index_atomic_inc -> increase wake_index
>>> 			 wake_up_nr -> wake up and waitqueue might be empty
>>>  sbq_index_atomic_inc -> increase again, one waitqueue is skipped
>>>  wake_up_nr -> invalid wake up because old wakequeue might be empty
>>>
>>> To fix the problem, increasing 'wake_index' before resetting 'wait_cnt'.
>>>
>>> 2) 'wait_cnt' can be decreased while waitqueue is empty
>>>
>>> As pointed out by Jan Kara, following race is possible:
>>>
>>> CPU1				CPU2
>>> __sbq_wake_up			 __sbq_wake_up
>>>  sbq_wake_ptr()			 sbq_wake_ptr() -> the same
>>>  wait_cnt = atomic_dec_return()
>>>  /* decreased to 0 */
>>>  sbq_index_atomic_inc()
>>>  /* move to next waitqueue */
>>>  atomic_set()
>>>  /* reset wait_cnt */
>>>  wake_up_nr()
>>>  /* wake up on the old waitqueue */
>>> 				 wait_cnt = atomic_dec_return()
>>> 				 /*
>>> 				  * decrease wait_cnt in the old
>>> 				  * waitqueue, while it can be
>>> 				  * empty.
>>> 				  */
>>>
>>> Fix the problem by waking up before updating 'wake_index' and
>>> 'wait_cnt'.
>>>
>>> With this patch, noted that 'wait_cnt' is still decreased in the old
>>> empty waitqueue, however, the wakeup is redirected to a active waitqueue,
>>> and the extra decrement on the old empty waitqueue is not handled.
>>>
>>> Fixes: 88459642cba4 ("blk-mq: abstract tag allocation out into sbitmap library")
>>> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
>>> Reviewed-by: Jan Kara <jack@suse.cz>
>>> Link: https://lore.kernel.org/r/20220803121504.212071-1-yukuai1@huaweicloud.com
>>> Signed-off-by: Jens Axboe <axboe@kernel.dk>
>>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>>
>> I have no authority on linux-block, but I'll say NAK to this one
>> (and 517/862), and let Jens and Jan overrule me if they disagree.
>>
>> This was the first of several 6.1-rc1 commits which had given me lost
>> wakeups never suffered before; was not tagged Cc stable; and (unless I've
>> missed it on lore) never had AUTOSEL posted to linux-block or linux-kernel.
> 
> Ok, thanks for the review.  I'll drop both of the sbitmap.c changes and
> if people report issues and want them back, I'll be glad to revisit them
> then.

Sorry for being late, did see Hugh respond to the original auto-select
as well, and was surprised to see it moving forward after that. Let's
please drop them for now.

-- 
Jens Axboe