From patchwork Wed Oct 19 08:30:04 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 4856 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp223870wrs; Wed, 19 Oct 2022 02:38:44 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5YdmeQRVmlmubbMy074iu2ZUG8MULPa6R5oDPQfVDjQ77RCf77kYJN0uwBloWHpCz679Ws X-Received: by 2002:a63:20f:0:b0:43c:1ef6:ebd6 with SMTP id 15-20020a63020f000000b0043c1ef6ebd6mr6496438pgc.217.1666172324375; Wed, 19 Oct 2022 02:38:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666172324; cv=none; d=google.com; s=arc-20160816; b=VcLRGViXVYAwRFDoKCmrp74e8Z0ikZ0sCj118hF7YSPI6iGVE7K92VUejTDUC9wtUk V2YziPaL1zTCvB9vRTYTH/FtgaOuLvfT0PMhi2/jHnlJB//rqJqPqrKf0+nGogybzD1A WGs0aLZGWD4DQmo/dQxCUzVuh7urS0Uxh5OvPsNhrAixbEi/WAroiOwYuVScFtae8kjp itH7Iy2fP58+VBycVV5d5bmnRCzaEMwy4FowSc7s/KssMTEcjihyyPDZpMbCweQzKofG 7cZoWpv1KzIA3YbPsGvw6aFgfzf6dkeyOUquKVg6EZSizo1F0+7hgxfkcjc2rdY/PYc9 Amxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=3/tkMaLVrbczAouB+ClEvDpEmv4k3PVBx9LcN3Uog5s=; b=XY+jjhzumtPN0Js+aPKqXSW7g6k3rXAQE3ycBEt+r+/3PXdtwZYorecuQQX5ex1Qzw CUwWuOXbeGoVTG/HqymMQuRpE6TORp0yXwLYk4wttNqHbBELxM/k87QlBql0xYbalRzs XbqrqHptHkFkl8h5bdi727nFpWBi8/Kgs29cjdFCavTTRwonr0VegTVOfOzyH+GCevwV qFplTbojhYREescCC1rT9qMej7b4xFoCOHpUIeR9WwsBx+/Id9Qh6AckwQSt5ViRr5Nl gl7LqdAAUOqEZQA8UnJXB4jT96nPXNhlARU8UVri/RT/1mHrvcRWOaP+DVC1RLTLL8+x z3PQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Do2Yej9G; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h185-20020a6383c2000000b00461515e9706si16509065pge.654.2022.10.19.02.38.31; Wed, 19 Oct 2022 02:38:44 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Do2Yej9G; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233442AbiJSJVk (ORCPT + 99 others); Wed, 19 Oct 2022 05:21:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59148 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233715AbiJSJT6 (ORCPT ); Wed, 19 Oct 2022 05:19:58 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 22A70CFB; Wed, 19 Oct 2022 02:09:22 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 948F6617DE; Wed, 19 Oct 2022 09:01:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A69ACC433D6; Wed, 19 Oct 2022 09:01:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666170078; bh=Gor8ma1Y1JlT4Q8d2TK31fIyEysqMQqMhBeWnc8gzp8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Do2Yej9Go8Yb9vetJKhI6o078LI6hq+OcMKip6+CSeJqMJRc5MR0nIVPT66hfBHP3 eDw6Hs3JuSgavQ0UzMZpbpMHIwuxzypg4JDjO0iWbqc8P0TvQUOmYm/QfL/N6zDoWk 1uz50f6FIjynpxK9y7DtA740vqRFDpU2A/yEv5gg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Keith Busch , Jan Kara , Jens Axboe , Sasha Levin Subject: [PATCH 6.0 517/862] sbitmap: Avoid leaving waitqueue in invalid state in __sbq_wake_up() Date: Wed, 19 Oct 2022 10:30:04 +0200 Message-Id: <20221019083312.840347737@linuxfoundation.org> X-Mailer: git-send-email 2.38.0 In-Reply-To: <20221019083249.951566199@linuxfoundation.org> References: <20221019083249.951566199@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747108311414504656?= X-GMAIL-MSGID: =?utf-8?q?1747108311414504656?= From: Jan Kara [ Upstream commit 48c033314f372478548203c583529f53080fd078 ] When __sbq_wake_up() decrements wait_cnt to 0 but races with someone else waking the waiter on the waitqueue (so the waitqueue becomes empty), it exits without reseting wait_cnt to wake_batch number. Once wait_cnt is 0, nobody will ever reset the wait_cnt or wake the new waiters resulting in possible deadlocks or busyloops. Fix the problem by making sure we reset wait_cnt even if we didn't wake up anybody in the end. Fixes: 040b83fcecfb ("sbitmap: fix possible io hung due to lost wakeup") Reported-by: Keith Busch Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20220908130937.2795-1-jack@suse.cz Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin --- lib/sbitmap.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/lib/sbitmap.c b/lib/sbitmap.c index 1f31147872e6..bb1970ad4875 100644 --- a/lib/sbitmap.c +++ b/lib/sbitmap.c @@ -605,6 +605,7 @@ static bool __sbq_wake_up(struct sbitmap_queue *sbq) struct sbq_wait_state *ws; unsigned int wake_batch; int wait_cnt; + bool ret; ws = sbq_wake_ptr(sbq); if (!ws) @@ -615,12 +616,23 @@ static bool __sbq_wake_up(struct sbitmap_queue *sbq) * For concurrent callers of this, callers should call this function * again to wakeup a new batch on a different 'ws'. */ - if (wait_cnt < 0 || !waitqueue_active(&ws->wait)) + if (wait_cnt < 0) return true; + /* + * If we decremented queue without waiters, retry to avoid lost + * wakeups. + */ if (wait_cnt > 0) - return false; + return !waitqueue_active(&ws->wait); + /* + * 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. + */ + ret = !waitqueue_active(&ws->wait); wake_batch = READ_ONCE(sbq->wake_batch); /* @@ -649,7 +661,7 @@ static bool __sbq_wake_up(struct sbitmap_queue *sbq) sbq_index_atomic_inc(&sbq->wake_index); atomic_set(&ws->wait_cnt, wake_batch); - return false; + return ret; } void sbitmap_queue_wake_up(struct sbitmap_queue *sbq)