Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp560282pxb; Mon, 7 Feb 2022 18:56:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJxdtwwTYhY42V035UyV0AfE5dx2tCe0jFYgh/Go5CX1ERRYbE2u+/G9NmjNqLk1cDoj3zby X-Received: by 2002:a17:90a:8a13:: with SMTP id w19mr2191955pjn.22.1644289008367; Mon, 07 Feb 2022 18:56:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644289008; cv=none; d=google.com; s=arc-20160816; b=GIAMgkO9jYnH9QO43/Wv3rdFtx5OSEAxK6Iepr3huZxDQkRqDVMgbS1+WOeQgD6SaH Nriat6Y9wJms6pjeCDfkhHwjiQFa+F/TxssN63g0dXCOAGOoJ2CxMuX97C+cyXD//JBe Uy0iEiscMN25kaF2AOlemq12iSPArLlUuejAEbzWr5DXRZVKhoYy7TDQG9waUi13k8lA LAtk98DQUXLyJ/9nKG6ge4QetVDDyfcIAHZ4nJHg/mHG9+9mvp5+UslVKZxkvM+OxHVl sgNXfQYdM0kazHYTrky3L/pdna5/FuMGejCzddoCmrO5jJy2yyFgkZmQzyDO/e5LlaNE msjg== 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:cc:to:from :subject:dkim-signature:dkim-signature; bh=ViWGm/depDGf235ykZcrvlwHPhzYZ1IOzNywgeuJlCs=; b=d0g4cBhGZC5xn6e+/cM1U23N1wzJc8q255bECi7hYeOAxIAu7mphZ7ShIb7l1b7e/Y nPjupFWkc2AyKRG1Uf11+YgPjt/NXfWk0Z9yzREnAaf+NH2Pp+n5e0c8RzPt2JTv+L9S XP24EyT/uR3HuSX+Eoo0jTyuGGJGyE168q69DDrt9b17MzHXGWp54shzGXbtI4/u95ms Jk+EnKzhhzT+ezRS26uR7qqnxdxJDybdSOdk1gIm1WeeqaaWwo9vO7P9kLMfQdUF9PbQ 5x5JEOuwNm84s0DEE4qgSxhlGLo1rfV0fyeGXD/cuMvRqreSC4QCtrfbkJzp4aVPxG6h wZ6Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b="dEj/ZECg"; dkim=neutral (no key) header.i=@suse.de header.b=LB4uxgey; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h36si11859561pgi.321.2022.02.07.18.56.20; Mon, 07 Feb 2022 18:56:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-nfs-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=@suse.de header.s=susede2_rsa header.b="dEj/ZECg"; dkim=neutral (no key) header.i=@suse.de header.b=LB4uxgey; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243896AbiBGGPn (ORCPT + 99 others); Mon, 7 Feb 2022 01:15:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50540 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352072AbiBGEsP (ORCPT ); Sun, 6 Feb 2022 23:48:15 -0500 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 22607C043181; Sun, 6 Feb 2022 20:48:14 -0800 (PST) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id D2BA6210E8; Mon, 7 Feb 2022 04:48:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1644209292; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ViWGm/depDGf235ykZcrvlwHPhzYZ1IOzNywgeuJlCs=; b=dEj/ZECgQzPmVNNwNtLhRwIK+t+7MZfIgofMU57KXuIxPsebs5TmJ+yBisbfSkJ1Lthv13 WGxGwr5R4TqIlYYAhIz1CsdYyp+aE9q3/2eQvTm0XbIF4xjDADjB0h2337rxl00eMcgeg/ EywU58RZdtc7KMmvbgUOuYuHFQJUK2Q= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1644209292; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ViWGm/depDGf235ykZcrvlwHPhzYZ1IOzNywgeuJlCs=; b=LB4uxgey7EDf4HC0h1f45bTAwNW+UouWDbatH0XJLCUd1qURVb63ibV21W/iR7wynleyiL nIOTeQVWLnjvIqCQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id F0D7B1330E; Mon, 7 Feb 2022 04:48:09 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id O2hbK4mkAGJiNQAAMHmgww (envelope-from ); Mon, 07 Feb 2022 04:48:09 +0000 Subject: [PATCH 12/21] SUNRPC/call_alloc: async tasks mustn't block waiting for memory From: NeilBrown To: Trond Myklebust , Anna Schumaker , Chuck Lever , Andrew Morton , Mark Hemment , Christoph Hellwig , David Howells Cc: linux-nfs@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Date: Mon, 07 Feb 2022 15:46:01 +1100 Message-ID: <164420916119.29374.4983888648335050333.stgit@noble.brown> In-Reply-To: <164420889455.29374.17958998143835612560.stgit@noble.brown> References: <164420889455.29374.17958998143835612560.stgit@noble.brown> User-Agent: StGit/0.23 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE 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-nfs@vger.kernel.org When memory is short, new worker threads cannot be created and we depend on the minimum one rpciod thread to be able to handle everything. So it must not block waiting for memory. mempools are particularly a problem as memory can only be released back to the mempool by an async rpc task running. If all available workqueue threads are waiting on the mempool, no thread is available to return anything. rpc_malloc() can block, and this might cause deadlocks. So check RPC_IS_ASYNC(), rather than RPC_IS_SWAPPER() to determine if blocking is acceptable. Signed-off-by: NeilBrown --- net/sunrpc/sched.c | 4 +++- net/sunrpc/xprtrdma/transport.c | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c index e2c835482791..d5b6e897f5a5 100644 --- a/net/sunrpc/sched.c +++ b/net/sunrpc/sched.c @@ -1023,8 +1023,10 @@ int rpc_malloc(struct rpc_task *task) struct rpc_buffer *buf; gfp_t gfp = GFP_NOFS; + if (RPC_IS_ASYNC(task)) + gfp = GFP_NOWAIT | __GFP_NOWARN; if (RPC_IS_SWAPPER(task)) - gfp = __GFP_MEMALLOC | GFP_NOWAIT | __GFP_NOWARN; + gfp |= __GFP_MEMALLOC; size += sizeof(struct rpc_buffer); if (size <= RPC_BUFFER_MAXSIZE) diff --git a/net/sunrpc/xprtrdma/transport.c b/net/sunrpc/xprtrdma/transport.c index 42e375dbdadb..5714bf880e95 100644 --- a/net/sunrpc/xprtrdma/transport.c +++ b/net/sunrpc/xprtrdma/transport.c @@ -570,8 +570,10 @@ xprt_rdma_allocate(struct rpc_task *task) gfp_t flags; flags = RPCRDMA_DEF_GFP; + if (RPC_IS_ASYNC(task)) + flags = GFP_NOWAIT | __GFP_NOWARN; if (RPC_IS_SWAPPER(task)) - flags = __GFP_MEMALLOC | GFP_NOWAIT | __GFP_NOWARN; + flags |= __GFP_MEMALLOC; if (!rpcrdma_check_regbuf(r_xprt, req->rl_sendbuf, rqst->rq_callsize, flags))