Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp905184pxb; Tue, 8 Feb 2022 05:16:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJy7VSoCFK+o+vfbgqX0jEK4eqJOhqNR1tN7uZYPmDckN8SjsguuhZu9CzG3v8ggWssamb80 X-Received: by 2002:a05:6a00:a87:: with SMTP id b7mr4446548pfl.51.1644326208909; Tue, 08 Feb 2022 05:16:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644326208; cv=none; d=google.com; s=arc-20160816; b=kCGsAOjwpbWnAr1aENEKCGJk+QVdx2C4OlUMiMJSCu93+bFrNIm2XwMfO3mAwnnEEC RlOm/+5akNaggkjpVt37hkCrQtU9g4u0h2HcEEBWCv+WeA/hRPphPxDQGWFlvAmWv08Q eXGizPUh9Iv3smojpo3umHPHtUEMcW/ttJoD5QT9TroeQc1DzGtsQXXSZuYmMlLEnNTY xaerRRsFV81fAKY9qzWMPI5E9dH0VFu9gFZiliz2k9kkYbMVekZzjfrZa3wVmXXatpMp 2ElE6poPz+zqtt1Fggpm1dV0zrQSNwc85v2hzPQy+1CoHQZFet6dngHJfC0NojG2YXmP WMjg== 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=a+dzRdJ1CEiYYNz26tJO1Hsz32DqZM0fgdDIWGvYfvU=; b=BZZkqFsCazWy2sLz1R5L4WbFWYFZ18/byNPYMidiCzFt4rs/5pb7keNBKZTisPDkAY dD+wGxqWYtL8PrqCmWCF89pLL4NoG2ewcGpmA77gkczi6MDmy9OIbELGUI6mqRD9A2hk lTiNCUqW7+Aob+fV+lhVLHWqglY5CR4aSxKF16zbROq7uVW17+VTB1h1WsBPfQgQb48c Jl6cW6CCIhKlg1SbwsxBKw1L1RmzEwKJoAVfhmfT95KmnoHaQmBjCMYGXdA9A2VsjqyY 1lfz+i4VTKyQcUCAVHKT3BEanGaEEXzpdu3KzD8xVOVWXxqvO/YR9+GiQolC2dfQWbhX 021g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b="lfv/cyb2"; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=sbcOPan0; 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=suse.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f71si13134663pgc.681.2022.02.08.05.16.34; Tue, 08 Feb 2022 05:16:48 -0800 (PST) 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=@suse.de header.s=susede2_rsa header.b="lfv/cyb2"; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=sbcOPan0; 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=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237345AbiBGFuI (ORCPT + 99 others); Mon, 7 Feb 2022 00:50:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50598 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352074AbiBGEs2 (ORCPT ); Sun, 6 Feb 2022 23:48:28 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7E389C043181; Sun, 6 Feb 2022 20:48:27 -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-out2.suse.de (Postfix) with ESMTPS id 353921F37E; Mon, 7 Feb 2022 04:48:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1644209306; 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=a+dzRdJ1CEiYYNz26tJO1Hsz32DqZM0fgdDIWGvYfvU=; b=lfv/cyb2G2DNPQTKbRop55g6PPjG1/708V4hQnTQAafD0bZ9UtKAxn2iYQoECGw8O1j85V PMIrabGZ3le/+8BBDqS1s3koU+vRWhWcFT3uueX8MIn2jnE5amCTbNjCpeGlSpnN03buIS CL0t0YYd98rDIgC4MeIwwFYNCzNrrt4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1644209306; 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=a+dzRdJ1CEiYYNz26tJO1Hsz32DqZM0fgdDIWGvYfvU=; b=sbcOPan0DVFL0E5MLU5X6ME2JEKy2viqKrzKBOOAt7EgYngT/daz1mGkkQLHl+tcBAOFff pE+zXdtPfmXl/6BA== 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 244891330E; Mon, 7 Feb 2022 04:48:22 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id sQAQNJakAGJ0NQAAMHmgww (envelope-from ); Mon, 07 Feb 2022 04:48:22 +0000 Subject: [PATCH 14/21] SUNRPC/xprt: 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: <164420916120.29374.8047763295599370687.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-kernel@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. xprt_dynamic_alloc_slot can block indefinitely. This can tie up all workqueue threads and NFS can deadlock. So when called from a workqueue, set __GFP_NORETRY. The rdma alloc_slot already does not block. However it sets the error to -EAGAIN suggesting this will trigger a sleep. It does not. As we can see in call_reserveresult(), only -ENOMEM causes a sleep. -EAGAIN causes immediate retry. Signed-off-by: NeilBrown --- net/sunrpc/xprt.c | 5 ++++- net/sunrpc/xprtrdma/transport.c | 2 +- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c index a02de2bddb28..47d207e416ab 100644 --- a/net/sunrpc/xprt.c +++ b/net/sunrpc/xprt.c @@ -1687,12 +1687,15 @@ static bool xprt_throttle_congested(struct rpc_xprt *xprt, struct rpc_task *task static struct rpc_rqst *xprt_dynamic_alloc_slot(struct rpc_xprt *xprt) { struct rpc_rqst *req = ERR_PTR(-EAGAIN); + gfp_t gfp_mask = GFP_NOFS; if (xprt->num_reqs >= xprt->max_reqs) goto out; ++xprt->num_reqs; spin_unlock(&xprt->reserve_lock); - req = kzalloc(sizeof(struct rpc_rqst), GFP_NOFS); + if (current->flags & PF_WQ_WORKER) + gfp_mask |= __GFP_NORETRY | __GFP_NOWARN; + req = kzalloc(sizeof(struct rpc_rqst), gfp_mask); spin_lock(&xprt->reserve_lock); if (req != NULL) goto out; diff --git a/net/sunrpc/xprtrdma/transport.c b/net/sunrpc/xprtrdma/transport.c index 5714bf880e95..923e4b512ee9 100644 --- a/net/sunrpc/xprtrdma/transport.c +++ b/net/sunrpc/xprtrdma/transport.c @@ -517,7 +517,7 @@ xprt_rdma_alloc_slot(struct rpc_xprt *xprt, struct rpc_task *task) return; out_sleep: - task->tk_status = -EAGAIN; + task->tk_status = -ENOMEM; xprt_add_backlog(xprt, task); }