Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp1659181pxp; Sun, 6 Mar 2022 22:31:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJyF532QB0uZExlv1gaw2fBK5vReCdM/JdLDtNe38K06aPZl86Ax7IVS6q9JgYXRbT6ZSDNw X-Received: by 2002:a17:906:3cf1:b0:6cf:86c6:8a12 with SMTP id d17-20020a1709063cf100b006cf86c68a12mr7896926ejh.202.1646634717014; Sun, 06 Mar 2022 22:31:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646634717; cv=none; d=google.com; s=arc-20160816; b=BkowwhcfsiA3ifBW5agbF9Es8FVPK083785wVV36F6DX2UpxfIurXHGK1Xvwlv0JVm 7nv8Nrz+hy+wHTINFD63ZuAXB4CodKvWMRnpCXJPNi2Xo3a2JDB+3y7E5NwwF1krhe34 No6VwB9kNlM1u+Qwbja0ox1m5i3lJUHmJYfA5ATuZUxyXxxx7ctwJnsuSenMKpU3quaH +OX0nk54+rrey5fMfHVHHgswBgbBUPhbbHS7xt/3apeJmeGSg5kqVE2QjCEvNx/o72Zc ahB2dUWHOhOW/FrIe9J3h5xi9NQLAHPZnuERi4gkd1i3nsJZityG/ijcTw59EAeu1xFc aBWA== 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=WEfcbq1/ee9eOf+W9MRAhDMLLa4E0bAnyxCt3gnhbfg=; b=J9/BONz5CeWYum+QiJFfymVjCUbEyioqWAuixuAOtCa3q6ppa8j8wWeYLbpzbfrFLq BlfvvzDBJR3JCQZ5So6dtzXKMy94v484YfGYpEc4YUQgqpWrZh0+zQP5vfGhuNJVCnd8 icd7bXwLqTgDLquxyW1elZJs7+U43it42bNfWe0khQX08nzMPomUNhwJeP5WMT490HCo MBBQpI+5WOuxsiKjY9KJgXTiRMcZy89VogOz4bDJeB8jDQYYZx3ISxMBMvvkU2stRmLV PB8CRsWhJ/M6hFaT3Qm+EIxKie4R95d38XUoGWuY7q6WFGm7nnF4wU6QpNuOtCatDbtu fmNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b="lnQ1/++X"; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519; 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 dt14-20020a170907728e00b006dabc09f08asi6647970ejc.52.2022.03.06.22.31.24; Sun, 06 Mar 2022 22:31:56 -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="lnQ1/++X"; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519; 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 S234456AbiCFXno (ORCPT + 99 others); Sun, 6 Mar 2022 18:43:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42226 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234455AbiCFXnn (ORCPT ); Sun, 6 Mar 2022 18:43:43 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 243E53C484 for ; Sun, 6 Mar 2022 15:42:50 -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 D7B761F38E; Sun, 6 Mar 2022 23:42:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1646610168; 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=WEfcbq1/ee9eOf+W9MRAhDMLLa4E0bAnyxCt3gnhbfg=; b=lnQ1/++XaR21/kGuzD76VNliRPQaTxjFYf/75Kx7IDdVlXAUEgC4a68wvnLxNyhZXdn+o+ mpyfLDU4ew0VMTKJoy2X6uZTsuopTZVyjI4B6ucHFoS2R+U4JhBWgeW4xy3SNoS+ZZmMut sJ1DsVnOp3FK5um1LuVb/oShsK1hJb4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1646610168; 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=WEfcbq1/ee9eOf+W9MRAhDMLLa4E0bAnyxCt3gnhbfg=; b=eZJCcONlhADOk+mgjSR2ycqQQ72QHL3h/muDiFqD+V2XiS0XM4O5ODXGmvCmwwURNuA5bO Exb1X2wFzRtQKpBA== 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 C8527134CD; Sun, 6 Mar 2022 23:42:47 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id gKCGIfdGJWIjWAAAMHmgww (envelope-from ); Sun, 06 Mar 2022 23:42:47 +0000 Subject: [PATCH 04/11] SUNRPC/xprt: 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: <164661010495.31054.15493859799937151207.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. 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..dbffb5147f16 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(*req), 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); }