Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp875610rwi; Wed, 19 Oct 2022 04:11:29 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6STwj1eFxrPGX6pFxkLJa4CcDJi1mp+qfUv9RylbwkGEb9gLQiVj5DxKh4sNehWiQGjzkw X-Received: by 2002:a17:907:628f:b0:72f:58fc:3815 with SMTP id nd15-20020a170907628f00b0072f58fc3815mr6354574ejc.719.1666177889541; Wed, 19 Oct 2022 04:11:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666177889; cv=none; d=google.com; s=arc-20160816; b=f58GYU53Dz0iK6Xp/nhXsORohrqXWvdhn239Wx2tNzNfgh8Ut1moGPOaOy2N9W1gtX ks89yt75bDppM9huFPkSk0SnXWSIBTCuXaFxsoCaA51rCXTZwFxzGBKCzSUlBibjNdN8 ilMLjXf4rrQU3sjXXKmXpR+xSCw/ZGfYT8dfNX/zeDT8wJ73enC8z19bHJ+udbBPLH7i NuUh3IcdPByVUlD9VjntSrROA4rfPkJPbYoqOAi612USWWOf0C5cDgkTyHnq3PeyHg40 NSdszCjjqvVZX8eI2uUTnCt4hm7AmPUNa1zjetJfYaP8mPEC1/9PtVK0Kb6FHxCSSiGL lPnA== 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=+Hh8j/ZjXiGwG1MV+LqN/xTN8LGsCyWrYfmIFEeenvw=; b=0egmeXDpqbHNvG3NT7cDtP1wylB8pGni+CyETIvBmkRQ/Ufks9O8lKrhzXXWXiQAbw tFS1gXfVWHUGM2TYQA7CB+DNovkoGqM/NBkBG8+pA0d1O1R0Ng+Zh2icccwfl9zusd1V naJ3vBA2XDsHMfQmOi5AsqkHpOpyPO8WVyK4nEH0V1RKbhHjAwE61uFyT+bFsXnyhRf3 wVpzRleKquyLW6SpfEBDtPeygBntqDlQg3U5Lky7q8eYL9eI/Q2hlSG9lKF6+YbCgiBH CJcS4cG3Zbe+Pa950PJxy8DL399MF7E6koNqwKo4lFHWuYKUPGoDUpqmyH7xN6PmtF4c bQHQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=mC6Frnnq; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j9-20020a05640211c900b0045db850a506si6259675edw.46.2022.10.19.04.10.58; Wed, 19 Oct 2022 04:11:29 -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=mC6Frnnq; 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 S234548AbiJSK6V (ORCPT + 99 others); Wed, 19 Oct 2022 06:58:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49802 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234687AbiJSK5I (ORCPT ); Wed, 19 Oct 2022 06:57:08 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C0629108DF7; Wed, 19 Oct 2022 03:27:43 -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 ams.source.kernel.org (Postfix) with ESMTPS id 1CB47B8249C; Wed, 19 Oct 2022 09:07:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6424EC433D6; Wed, 19 Oct 2022 09:07:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666170459; bh=LOQm+b4gdhndYidtU+rnK72Qvs2MOTXXFuDNLCJmht0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mC6FrnnqJZQbP8ggrxdb+cHvWHIpdq8HJTiRKQQUk4im/IoC8XWRWc+xr5jf2Vnht 8ca4zDtR9rsoYIx2Dj/obDDvf1L0NKMZHOrv7+//OemqcRI4Je+5thoZrn+mHfrLIX 2CoEv8oZHGFaZ5VmMyUVJq77OKRMxmQstalTvk6E= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Uladzislau Rezki (Sony)" , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Josh Triplett , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Joel Fernandes , Michal Hocko , Sasha Levin Subject: [PATCH 6.0 663/862] rcu: Back off upon fill_page_cache_func() allocation failure Date: Wed, 19 Oct 2022 10:32:30 +0200 Message-Id: <20221019083319.261237319@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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 From: Michal Hocko [ Upstream commit 093590c16b447f53e66771c8579ae66c96f6ef61 ] The fill_page_cache_func() function allocates couple of pages to store kvfree_rcu_bulk_data structures. This is a lightweight (GFP_NORETRY) allocation which can fail under memory pressure. The function will, however keep retrying even when the previous attempt has failed. This retrying is in theory correct, but in practice the allocation is invoked from workqueue context, which means that if the memory reclaim gets stuck, these retries can hog the worker for quite some time. Although the workqueues subsystem automatically adjusts concurrency, such adjustment is not guaranteed to happen until the worker context sleeps. And the fill_page_cache_func() function's retry loop is not guaranteed to sleep (see the should_reclaim_retry() function). And we have seen this function cause workqueue lockups: kernel: BUG: workqueue lockup - pool cpus=93 node=1 flags=0x1 nice=0 stuck for 32s! [...] kernel: pool 74: cpus=37 node=0 flags=0x1 nice=0 hung=32s workers=2 manager: 2146 kernel: pwq 498: cpus=249 node=1 flags=0x1 nice=0 active=4/256 refcnt=5 kernel: in-flight: 1917:fill_page_cache_func kernel: pending: dbs_work_handler, free_work, kfree_rcu_monitor Originally, we thought that the root cause of this lockup was several retries with direct reclaim, but this is not yet confirmed. Furthermore, we have seen similar lockups without any heavy memory pressure. This suggests that there are other factors contributing to these lockups. However, it is not really clear that endless retries are desireable. So let's make the fill_page_cache_func() function back off after allocation failure. Cc: Uladzislau Rezki (Sony) Cc: "Paul E. McKenney" Cc: Frederic Weisbecker Cc: Neeraj Upadhyay Cc: Josh Triplett Cc: Steven Rostedt Cc: Mathieu Desnoyers Cc: Lai Jiangshan Cc: Joel Fernandes Signed-off-by: Michal Hocko Reviewed-by: Uladzislau Rezki (Sony) Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin --- kernel/rcu/tree.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 79aea7df4345..eb435941e92f 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -3183,15 +3183,16 @@ static void fill_page_cache_func(struct work_struct *work) bnode = (struct kvfree_rcu_bulk_data *) __get_free_page(GFP_KERNEL | __GFP_NORETRY | __GFP_NOMEMALLOC | __GFP_NOWARN); - if (bnode) { - raw_spin_lock_irqsave(&krcp->lock, flags); - pushed = put_cached_bnode(krcp, bnode); - raw_spin_unlock_irqrestore(&krcp->lock, flags); + if (!bnode) + break; - if (!pushed) { - free_page((unsigned long) bnode); - break; - } + raw_spin_lock_irqsave(&krcp->lock, flags); + pushed = put_cached_bnode(krcp, bnode); + raw_spin_unlock_irqrestore(&krcp->lock, flags); + + if (!pushed) { + free_page((unsigned long) bnode); + break; } } -- 2.35.1