Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp1512542pxp; Sun, 6 Mar 2022 17:43:45 -0800 (PST) X-Google-Smtp-Source: ABdhPJxN/vV72JJFZ3MO1vgpGnYrXYqsGFXD4yxO0COkqZtwYRTJYg3cYxSKx5I8pgaILoZ0uCky X-Received: by 2002:a17:902:ef52:b0:151:84fe:bccb with SMTP id e18-20020a170902ef5200b0015184febccbmr10002369plx.9.1646617424871; Sun, 06 Mar 2022 17:43:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646617424; cv=none; d=google.com; s=arc-20160816; b=YVE4Duez4uUB3mFUxeGn0KFzjNIVPrqg8QhRpmXp2K2gmDEkVda0WFmFuolcqlmCRL ybJXlcFK8Ls4FPShvgReEAmkqrYqqjRr4UQ463B4t5yzDkm9Bzou4U8KxxL7uk7jM6n7 /GwjNlPor1QNWKX/tBzZMyI9Iflh6mIN4ec/+QS5rOqrS+Xne4rd6vuysqM3XoEhuoLX 5mYFOFwXPIrXLGEHAqkIFyNuPSZjDe82UwQiReSSnyRJOEOIrnuDYYE0pBlFAbwkWo0A bc6m/lcmPEhuxV+gnBDmNfNmJSs0MQKGOL13X6UNnqeEiJaRI5JFgDhaecgdvQAESnl+ BG3A== 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=IPvCOS7rbM/k3GMDuBmZSR7OsiZQNy4JAGERYirLU0YTQFQAXjFuYUUtOVqpsOu60a 1l+Pbn5UbCSjQTRGWb+AuXPl8v1hWXPVpkP4JZmyW7R1a29UUvzCikj0FbeGaorzpG1g 5Fjm/T3Ol5fFerUJNw4guhXfWjwlThvPRGsI3SEQOhgL8F0p34C1bSRCLkKsm9d4N0MP OYYg/YPqcqZvCUvCXChancmNNbTb6TrrvwZillSqg8um2RYp/VU/+aiZskCnUTtSH+jo Nr26LxXk7v6S+uN60k7ad4d/KXl7Rv8idfhrw+h6vxtlyghoVlPZ6FoN8MeeTI814PKR sPfA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=ULEa2lIn; dkim=neutral (no key) header.i=@suse.de; 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 mh13-20020a17090b4acd00b001bef92e59besi6701541pjb.40.2022.03.06.17.43.18; Sun, 06 Mar 2022 17:43:44 -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=ULEa2lIn; dkim=neutral (no key) header.i=@suse.de; 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 S234447AbiCFXna (ORCPT + 99 others); Sun, 6 Mar 2022 18:43:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41426 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234453AbiCFXn2 (ORCPT ); Sun, 6 Mar 2022 18:43:28 -0500 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B5A586264 for ; Sun, 6 Mar 2022 15:42:34 -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 081C2210FC; Sun, 6 Mar 2022 23:42:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1646610153; 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=ULEa2lInaiA8E6FHFh/s+puLhZZMrIN0tJERmyPKYTRET5YsY1xbbYrlmTMpfDFct0KKsq 5Zehag3CjmDpbXiFpTU+5YpusfDqLy9x0Lwewx6EKT/uMuOtAeoo3eG+2/TdXTn8vkucvf c9xtpcNEfUAH6Kb4Id169AIhWQhdF/s= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1646610153; 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=Lj/BMr3rs42wXMyn+3IzbHX6+uax6bjtoTq2FaCHoG2/1ER0JwI+cDNMKFK0U4pRSUtrVq /Cl6QP63jlWbuSCQ== 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 ECD9E134CD; Sun, 6 Mar 2022 23:42:31 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id DgN0KudGJWIQWAAAMHmgww (envelope-from ); Sun, 06 Mar 2022 23:42:31 +0000 Subject: [PATCH 02/11] SUNRPC/call_alloc: async tasks mustn't block waiting for memory From: NeilBrown To: Trond Myklebust , Anna Schumaker Cc: linux-nfs@vger.kernel.org Date: Mon, 07 Mar 2022 10:41:44 +1100 Message-ID: <164661010494.31054.3655053845587236983.stgit@noble.brown> In-Reply-To: <164660993703.31054.17075972410545449555.stgit@noble.brown> References: <164660993703.31054.17075972410545449555.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=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,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))