Message ID | 20230201150815.409582-8-urezki@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp334720wrn; Wed, 1 Feb 2023 07:15:00 -0800 (PST) X-Google-Smtp-Source: AK7set9DMIa4JwF5cyaQjXcuTShM521Y3QpAgpumddSB88kpVne1iJ1z60Bz7NrsQiCbmtQPPlTR X-Received: by 2002:a17:90b:3e82:b0:229:4731:994d with SMTP id rj2-20020a17090b3e8200b002294731994dmr2678544pjb.4.1675264500143; Wed, 01 Feb 2023 07:15:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675264500; cv=none; d=google.com; s=arc-20160816; b=S3jwOhtsMxNpQr4dhM8Ne2EXFGpUs/1Svya4kN2QDqjVV9htQDmNmh/6Uft96T+9Yn wHlgOZlxntMdf46uNWVmP3Ru9XSRkNnVFnJtTERjVhCrRNi0HxQkIJr1nFHAP24X5iWF dPhVhVRnc6UPM2Hyd5VRsRx05c0hHMC1rL/qrBXzZrW4BFCixx9FIFv72fWYcZ/B7z0S ILyPoysONUSDYTWTz6kkSlIpCgKrBSAz7LS2ekRcPzoCVGBT08O9+Gf/lIwO1wZpOJey j1ugkfUSt+W5TYMR4eRWmN0sZ/cQ0Gl0vApSgS7jHIocBWt6vP4P2zoeDGZ864GyoD6L Fj6g== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=JmKlyMMJ/xEGlFGd5Gxv5AeF+U+6+mZ4G3QkqKY1mdM=; b=A9R3w3YQQlYrhEXL8BIxnR+F7/wo5Niq+RrL/dSGywsOVsmRCPy0bYXCSc5ooLy0HJ 8kE7AkRtBXu3mpgFSwXN8W6T14ahtgfgCMaGrZXcjSOjlbYPH9c3ldK0y7XXBULE0tSI 9JXrcH5plzYorqXzVztcG4vcOrHg6Hvmefc/V7iXTmmelyejS7NpqMNa8zqjBI44EVVQ qLYd189Vg/Ggnf9znx2waEGv1OJMPT1y6N/K//eD9B6nhvZacvt0frlRKWIo0E5BInmF W/zISIKpIF2NFG4BsCB3yzWsT+WNvBMgYoTH+XI9bmj31Q9Hk+H35pM4Q55cdsF6Unez vSfw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=c6azTpWk; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p18-20020a63b812000000b004ce7eecf595si17850325pge.281.2023.02.01.07.14.47; Wed, 01 Feb 2023 07:15:00 -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=@gmail.com header.s=20210112 header.b=c6azTpWk; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232040AbjBAPKt (ORCPT <rfc822;duw91626@gmail.com> + 99 others); Wed, 1 Feb 2023 10:10:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43378 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232922AbjBAPJo (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 1 Feb 2023 10:09:44 -0500 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2018969532; Wed, 1 Feb 2023 07:08:26 -0800 (PST) Received: by mail-ej1-x62f.google.com with SMTP id hx15so32760401ejc.11; Wed, 01 Feb 2023 07:08:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=JmKlyMMJ/xEGlFGd5Gxv5AeF+U+6+mZ4G3QkqKY1mdM=; b=c6azTpWkKQffBEe2MAEiXW7H64r7G8RxpP6AOHcPVZdNMYkjx+JYt3ZJrwoey7Bhi4 3U5CZt8416awlbOmwyyXDpO4v9virbiJVJJ6QAT0nXMsCHWYFUBDwFiZipY6eNuE4zWB ZRQrhMcnthZ5uwrMZCRpHftZzckhjKVjf1N1UrgJcg4ZitsN+YtuToG35yrOwioAWtNw EPhjUTGd2kUwpjHBOlh5TAL1SbRX6ezF05RUFgd0l9zrrRWxU1sJvo7LM9lQTOWCljrx LnLmy+g4GWsbSBU9Ph/CEfX9TR82hOo4TOwOX4YqqT39urmQ0JKYNLdFMEdiCthvc3O3 oSKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JmKlyMMJ/xEGlFGd5Gxv5AeF+U+6+mZ4G3QkqKY1mdM=; b=bvSnPIkDHLQVHQCV7IgZAS5qdkO4qWHmUMU/EF5PJXOFvjJ037CUodOFfhWf+XFNjp bpEloCSGfIXal9sNlTIEAJoI2w12J7OkTMv9u1dJcNwblTgEnGpH2kPleu2D7CM2khLc S49nIM/P6tJnDGQcpQ7s4uwk3lDllV0TioUpb2rR5EZK9lPhONssPbUzv+glbIhr6u1V GBkeqkZSQpAOdBwgL3jowiG4RVrG/Et84313cqXIvCivQ3ERfpvDzlEngp0tSzgKP/5o CguCdV+RYRLdgijNc0uvpbO03gCQ74/+Ee7h7o5RUv2LpRAMP+NILHAIWMRbY1GAqoVz ItnA== X-Gm-Message-State: AO0yUKXITv0377hAamF7toC9r3bGX3VVPUZxUh8hbb0AeBT132tfSFDv y7wLON/TPLZqhMzAmU84i17uDa9XmUKZEw== X-Received: by 2002:a17:906:fc13:b0:87f:d08:1064 with SMTP id ov19-20020a170906fc1300b0087f0d081064mr6012611ejb.6.1675264104460; Wed, 01 Feb 2023 07:08:24 -0800 (PST) Received: from pc638.lan ([155.137.26.201]) by smtp.gmail.com with ESMTPSA id qc26-20020a170906d8ba00b008787e94c5ccsm9585774ejb.184.2023.02.01.07.08.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Feb 2023 07:08:24 -0800 (PST) From: "Uladzislau Rezki (Sony)" <urezki@gmail.com> To: LKML <linux-kernel@vger.kernel.org>, RCU <rcu@vger.kernel.org>, "Paul E . McKenney" <paulmck@kernel.org> Cc: Uladzislau Rezki <urezki@gmail.com>, Oleksiy Avramchenko <oleksiy.avramchenko@sony.com>, Jens Axboe <axboe@kernel.dk>, Philipp Reisner <philipp.reisner@linbit.com>, Bryan Tan <bryantan@vmware.com>, Steven Rostedt <rostedt@goodmis.org>, Eric Dumazet <edumazet@google.com>, Bob Pearson <rpearsonhpe@gmail.com>, Ariel Levkovich <lariel@nvidia.com>, Theodore Ts'o <tytso@mit.edu>, Julian Anastasov <ja@ssi.bg>, Jason Gunthorpe <jgg@nvidia.com> Subject: [PATCH 07/13] RDMA/rxe: Rename kfree_rcu() to kfree_rcu_mightsleep() Date: Wed, 1 Feb 2023 16:08:13 +0100 Message-Id: <20230201150815.409582-8-urezki@gmail.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20230201150815.409582-1-urezki@gmail.com> References: <20230201150815.409582-1-urezki@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756642148439332957?= X-GMAIL-MSGID: =?utf-8?q?1756642148439332957?= |
Series |
Rename k[v]free_rcu() single argument to k[v]free_rcu_mightsleep()
|
|
Commit Message
Uladzislau Rezki
Feb. 1, 2023, 3:08 p.m. UTC
The kfree_rcu()'s single argument name is deprecated therefore
rename it to kfree_rcu_mightsleep() variant. The goal is explicitly
underline that it is for sleepable contexts.
Please check the RXE driver in a way that a single argument can
be used. Briefly looking at it and rcu_head should be embed to
free an obj over RCU-core. The context might be atomic.
Cc: Bob Pearson <rpearsonhpe@gmail.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
---
drivers/infiniband/sw/rxe/rxe_pool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Wed, Feb 01, 2023 at 04:08:13PM +0100, Uladzislau Rezki (Sony) wrote: > The kfree_rcu()'s single argument name is deprecated therefore > rename it to kfree_rcu_mightsleep() variant. The goal is explicitly > underline that it is for sleepable contexts. > > Please check the RXE driver in a way that a single argument can > be used. Briefly looking at it and rcu_head should be embed to > free an obj over RCU-core. The context might be atomic. > > Cc: Bob Pearson <rpearsonhpe@gmail.com> > Cc: Jason Gunthorpe <jgg@nvidia.com> > Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com> > --- > drivers/infiniband/sw/rxe/rxe_pool.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Could you please add you reviwed-by or Acked-by tags so we can bring our series with renaming for the next merge window? Thanks! -- Uladzislau Rezki
> On Wed, Feb 01, 2023 at 04:08:13PM +0100, Uladzislau Rezki (Sony) wrote: > > The kfree_rcu()'s single argument name is deprecated therefore > > rename it to kfree_rcu_mightsleep() variant. The goal is explicitly > > underline that it is for sleepable contexts. > > > > Please check the RXE driver in a way that a single argument can > > be used. Briefly looking at it and rcu_head should be embed to > > free an obj over RCU-core. The context might be atomic. > > > > Cc: Bob Pearson <rpearsonhpe@gmail.com> > > Cc: Jason Gunthorpe <jgg@nvidia.com> > > Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com> > > --- > > drivers/infiniband/sw/rxe/rxe_pool.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > Could you please add you reviwed-by or Acked-by tags so we can bring > our series with renaming for the next merge window? > > Thanks! > __rxe_cleanup() can be called in two contexts, sleepable and not. Therefore usage of a single argument of the kvfree_rcu() is not correct here. Could you please fix and check your driver? If my above statement is not correct, please provide Acked-by or Reviwed-by tags to the path that is in question. Otherwise please add an rcu_head in your data to free objects over kvfree_rcu() using double argument API. Could you please support? -- Uladzislau Rezki
On Thu, Mar 09, 2023 at 03:13:08PM +0100, Uladzislau Rezki wrote: > > On Wed, Feb 01, 2023 at 04:08:13PM +0100, Uladzislau Rezki (Sony) wrote: > > > The kfree_rcu()'s single argument name is deprecated therefore > > > rename it to kfree_rcu_mightsleep() variant. The goal is explicitly > > > underline that it is for sleepable contexts. > > > > > > Please check the RXE driver in a way that a single argument can > > > be used. Briefly looking at it and rcu_head should be embed to > > > free an obj over RCU-core. The context might be atomic. > > > > > > Cc: Bob Pearson <rpearsonhpe@gmail.com> > > > Cc: Jason Gunthorpe <jgg@nvidia.com> > > > Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com> > > > --- > > > drivers/infiniband/sw/rxe/rxe_pool.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > Could you please add you reviwed-by or Acked-by tags so we can bring > > our series with renaming for the next merge window? > > > > Thanks! > > > __rxe_cleanup() can be called in two contexts, sleepable and not. > Therefore usage of a single argument of the kvfree_rcu() is not correct > here. > > Could you please fix and check your driver? If my above statement > is not correct, please provide Acked-by or Reviwed-by tags to the > path that is in question. > > Otherwise please add an rcu_head in your data to free objects over > kvfree_rcu() using double argument API. > > Could you please support? Also this one needs renaming? It came in because of the commit in 6.3-rc1: 72a03627443d ("RDMA/rxe: Remove rxe_alloc()") It could be squashed into this patch itself since it is infiniband related. Paul noticed that this breaks dropping the old API on -next, so it is blocking the renaming. ---8<----------------------- diff --git a/drivers/infiniband/sw/rxe/rxe_mr.c b/drivers/infiniband/sw/rxe/rxe_mr.c index b10aa1580a64..ae3a100e18fb 100644 --- a/drivers/infiniband/sw/rxe/rxe_mr.c +++ b/drivers/infiniband/sw/rxe/rxe_mr.c @@ -731,7 +731,7 @@ int rxe_dereg_mr(struct ib_mr *ibmr, struct ib_udata *udata) return -EINVAL; rxe_cleanup(mr); - kfree_rcu(mr); + kfree_rcu_mightsleep(mr); return 0; }
On 3/9/23 18:55, Joel Fernandes wrote: > On Thu, Mar 09, 2023 at 03:13:08PM +0100, Uladzislau Rezki wrote: >>> On Wed, Feb 01, 2023 at 04:08:13PM +0100, Uladzislau Rezki (Sony) wrote: >>>> The kfree_rcu()'s single argument name is deprecated therefore >>>> rename it to kfree_rcu_mightsleep() variant. The goal is explicitly >>>> underline that it is for sleepable contexts. >>>> >>>> Please check the RXE driver in a way that a single argument can >>>> be used. Briefly looking at it and rcu_head should be embed to >>>> free an obj over RCU-core. The context might be atomic. >>>> >>>> Cc: Bob Pearson <rpearsonhpe@gmail.com> >>>> Cc: Jason Gunthorpe <jgg@nvidia.com> >>>> Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com> >>>> --- >>>> drivers/infiniband/sw/rxe/rxe_pool.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>> Could you please add you reviwed-by or Acked-by tags so we can bring >>> our series with renaming for the next merge window? >>> >>> Thanks! >>> >> __rxe_cleanup() can be called in two contexts, sleepable and not. >> Therefore usage of a single argument of the kvfree_rcu() is not correct >> here. >> >> Could you please fix and check your driver? If my above statement >> is not correct, please provide Acked-by or Reviwed-by tags to the >> path that is in question. >> >> Otherwise please add an rcu_head in your data to free objects over >> kvfree_rcu() using double argument API. >> >> Could you please support? > > Also this one needs renaming? It came in because of the commit in 6.3-rc1: > 72a03627443d ("RDMA/rxe: Remove rxe_alloc()") > > It could be squashed into this patch itself since it is infiniband related. > > Paul noticed that this breaks dropping the old API on -next, so it is > blocking the renaming. > > ---8<----------------------- > > diff --git a/drivers/infiniband/sw/rxe/rxe_mr.c b/drivers/infiniband/sw/rxe/rxe_mr.c > index b10aa1580a64..ae3a100e18fb 100644 > --- a/drivers/infiniband/sw/rxe/rxe_mr.c > +++ b/drivers/infiniband/sw/rxe/rxe_mr.c > @@ -731,7 +731,7 @@ int rxe_dereg_mr(struct ib_mr *ibmr, struct ib_udata *udata) > return -EINVAL; > > rxe_cleanup(mr); > - kfree_rcu(mr); > + kfree_rcu_mightsleep(mr); > return 0; > } > I just got back from a 1 week vacation and missed all this. The "RDMA/rxe: Remove rxe_alloc()" patch just moved the memory allocation for MR (verbs) objects outside of the rxe_pool code since it only applied to MRs and not the other verbs objects (AH, QP, CQ, ...). That code has to handle a unique situation for AH objects which can be created or destroyed by connection manager code in atomic context while all the other ones including MRs are always created/destroyed in process context. All objects other than MR's are created/destroyed in the rdma-core code (drivers/infiniband/core). The rxe driver keeps xarray's of pointers to the various objects which are protected by rcu locking and so it made sense to use kfree_rcu to delete the object with a delay. In the MR case ..._mightsleep seems harmless and should not be an issue. However on reflection, all the references to the MR objects are ref counted and they have been dropped before reaching the kfree and so there really never was a good reason to use kfree_rcu in the first place. So a better solution would be to replace kfree_rcu with kfree. There is a timeout in completion_done() that triggers a WARN_ON() and this is only seen if the driver is broken for some reason but that is equivalent to getting a seg fault so no reason to further delay the kfree. Reviewed-by: Bob Pearson <rpearsonhpe@gmail.com>
On Thu, Mar 9, 2023 at 10:13 PM Uladzislau Rezki <urezki@gmail.com> wrote: > > > On Wed, Feb 01, 2023 at 04:08:13PM +0100, Uladzislau Rezki (Sony) wrote: > > > The kfree_rcu()'s single argument name is deprecated therefore > > > rename it to kfree_rcu_mightsleep() variant. The goal is explicitly > > > underline that it is for sleepable contexts. > > > > > > Please check the RXE driver in a way that a single argument can > > > be used. Briefly looking at it and rcu_head should be embed to > > > free an obj over RCU-core. The context might be atomic. > > > > > > Cc: Bob Pearson <rpearsonhpe@gmail.com> > > > Cc: Jason Gunthorpe <jgg@nvidia.com> > > > Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com> Thanks. Acked-by: Zhu Yanjun <zyjzyj2000@gmail.com> Zhu Yanjun > > > --- > > > drivers/infiniband/sw/rxe/rxe_pool.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > Could you please add you reviwed-by or Acked-by tags so we can bring > > our series with renaming for the next merge window? > > > > Thanks! > > > __rxe_cleanup() can be called in two contexts, sleepable and not. > Therefore usage of a single argument of the kvfree_rcu() is not correct > here. > > Could you please fix and check your driver? If my above statement > is not correct, please provide Acked-by or Reviwed-by tags to the > path that is in question. > > Otherwise please add an rcu_head in your data to free objects over > kvfree_rcu() using double argument API. > > Could you please support? > > -- > Uladzislau Rezki
On Mon, Mar 13, 2023 at 02:43:43PM -0500, Bob Pearson wrote: > On 3/9/23 18:55, Joel Fernandes wrote: > > On Thu, Mar 09, 2023 at 03:13:08PM +0100, Uladzislau Rezki wrote: > >>> On Wed, Feb 01, 2023 at 04:08:13PM +0100, Uladzislau Rezki (Sony) wrote: > >>>> The kfree_rcu()'s single argument name is deprecated therefore > >>>> rename it to kfree_rcu_mightsleep() variant. The goal is explicitly > >>>> underline that it is for sleepable contexts. > >>>> > >>>> Please check the RXE driver in a way that a single argument can > >>>> be used. Briefly looking at it and rcu_head should be embed to > >>>> free an obj over RCU-core. The context might be atomic. > >>>> > >>>> Cc: Bob Pearson <rpearsonhpe@gmail.com> > >>>> Cc: Jason Gunthorpe <jgg@nvidia.com> > >>>> Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com> > >>>> --- > >>>> drivers/infiniband/sw/rxe/rxe_pool.c | 2 +- > >>>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>>> > >>> Could you please add you reviwed-by or Acked-by tags so we can bring > >>> our series with renaming for the next merge window? > >>> > >>> Thanks! > >>> > >> __rxe_cleanup() can be called in two contexts, sleepable and not. > >> Therefore usage of a single argument of the kvfree_rcu() is not correct > >> here. > >> > >> Could you please fix and check your driver? If my above statement > >> is not correct, please provide Acked-by or Reviwed-by tags to the > >> path that is in question. > >> > >> Otherwise please add an rcu_head in your data to free objects over > >> kvfree_rcu() using double argument API. > >> > >> Could you please support? > > > > Also this one needs renaming? It came in because of the commit in 6.3-rc1: > > 72a03627443d ("RDMA/rxe: Remove rxe_alloc()") > > > > It could be squashed into this patch itself since it is infiniband related. > > > > Paul noticed that this breaks dropping the old API on -next, so it is > > blocking the renaming. > > > > ---8<----------------------- > > > > diff --git a/drivers/infiniband/sw/rxe/rxe_mr.c b/drivers/infiniband/sw/rxe/rxe_mr.c > > index b10aa1580a64..ae3a100e18fb 100644 > > --- a/drivers/infiniband/sw/rxe/rxe_mr.c > > +++ b/drivers/infiniband/sw/rxe/rxe_mr.c > > @@ -731,7 +731,7 @@ int rxe_dereg_mr(struct ib_mr *ibmr, struct ib_udata *udata) > > return -EINVAL; > > > > rxe_cleanup(mr); > > - kfree_rcu(mr); > > + kfree_rcu_mightsleep(mr); > > return 0; > > } > > > I just got back from a 1 week vacation and missed all this. > > The "RDMA/rxe: Remove rxe_alloc()" patch just moved the memory allocation > for MR (verbs) objects outside of the rxe_pool code since it only applied > to MRs and not the other verbs objects (AH, QP, CQ, ...). That code has to > handle a unique situation for AH objects which can be created or destroyed > by connection manager code in atomic context while all the other ones > including MRs are always created/destroyed in process context. All objects > other than MR's are created/destroyed in the rdma-core code > (drivers/infiniband/core). > > The rxe driver keeps xarray's of pointers to the various objects which are > protected by rcu locking and so it made sense to use kfree_rcu to delete > the object with a delay. In the MR case ..._mightsleep seems harmless and > should not be an issue. > > However on reflection, all the references to the MR objects are ref counted > and they have been dropped before reaching the kfree and so there really > never was a good reason to use kfree_rcu in the first place. So a better > solution would be to replace kfree_rcu with kfree. There is a timeout in > completion_done() that triggers a WARN_ON() and this is only seen if the > driver is broken for some reason but that is equivalent to getting a seg > fault so no reason to further delay the kfree. > > Reviewed-by: Bob Pearson <rpearsonhpe@gmail.com> Thanks, I am planning to send the following patch for 6.4 consideration, please let me know if you disagree. Still testing it. ----8<--- From: Joel Fernandes (Google) <joel@joelfernandes.org> Subject: [PATCH] RDMA/rxe: Rename kfree_rcu() to kvfree_rcu_mightsleep() The k[v]free_rcu() macro's single-argument form is deprecated. Therefore switch to the new k[v]free_rcu_mightsleep() variant. The goal is to avoid accidental use of the single-argument forms, which can introduce functionality bugs in atomic contexts and latency bugs in non-atomic contexts. There is no functionality change with this patch. Link: https://lore.kernel.org/rcu/20230201150815.409582-1-urezki@gmail.com Acked-by: Zhu Yanjun <zyjzyj2000@gmail.com> Reviewed-by: Bob Pearson <rpearsonhpe@gmail.com> Reviewed-by: Paul E. McKenney <paulmck@kernel.org> Fixes: 72a03627443d ("RDMA/rxe: Remove rxe_alloc()") Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> --- drivers/infiniband/sw/rxe/rxe_mr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/sw/rxe/rxe_mr.c b/drivers/infiniband/sw/rxe/rxe_mr.c index b10aa1580a64..ae3a100e18fb 100644 --- a/drivers/infiniband/sw/rxe/rxe_mr.c +++ b/drivers/infiniband/sw/rxe/rxe_mr.c @@ -731,7 +731,7 @@ int rxe_dereg_mr(struct ib_mr *ibmr, struct ib_udata *udata) return -EINVAL; rxe_cleanup(mr); - kfree_rcu(mr); + kfree_rcu_mightsleep(mr); return 0; }
On 3/15/23 06:50, Joel Fernandes wrote: > On Mon, Mar 13, 2023 at 02:43:43PM -0500, Bob Pearson wrote: >> On 3/9/23 18:55, Joel Fernandes wrote: >>> On Thu, Mar 09, 2023 at 03:13:08PM +0100, Uladzislau Rezki wrote: >>>>> On Wed, Feb 01, 2023 at 04:08:13PM +0100, Uladzislau Rezki (Sony) wrote: >>>>>> The kfree_rcu()'s single argument name is deprecated therefore >>>>>> rename it to kfree_rcu_mightsleep() variant. The goal is explicitly >>>>>> underline that it is for sleepable contexts. >>>>>> >>>>>> Please check the RXE driver in a way that a single argument can >>>>>> be used. Briefly looking at it and rcu_head should be embed to >>>>>> free an obj over RCU-core. The context might be atomic. >>>>>> >>>>>> Cc: Bob Pearson <rpearsonhpe@gmail.com> >>>>>> Cc: Jason Gunthorpe <jgg@nvidia.com> >>>>>> Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com> >>>>>> --- >>>>>> drivers/infiniband/sw/rxe/rxe_pool.c | 2 +- >>>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>>> >>>>> Could you please add you reviwed-by or Acked-by tags so we can bring >>>>> our series with renaming for the next merge window? >>>>> >>>>> Thanks! >>>>> >>>> __rxe_cleanup() can be called in two contexts, sleepable and not. >>>> Therefore usage of a single argument of the kvfree_rcu() is not correct >>>> here. >>>> >>>> Could you please fix and check your driver? If my above statement >>>> is not correct, please provide Acked-by or Reviwed-by tags to the >>>> path that is in question. >>>> >>>> Otherwise please add an rcu_head in your data to free objects over >>>> kvfree_rcu() using double argument API. >>>> >>>> Could you please support? >>> >>> Also this one needs renaming? It came in because of the commit in 6.3-rc1: >>> 72a03627443d ("RDMA/rxe: Remove rxe_alloc()") >>> >>> It could be squashed into this patch itself since it is infiniband related. >>> >>> Paul noticed that this breaks dropping the old API on -next, so it is >>> blocking the renaming. >>> >>> ---8<----------------------- >>> >>> diff --git a/drivers/infiniband/sw/rxe/rxe_mr.c b/drivers/infiniband/sw/rxe/rxe_mr.c >>> index b10aa1580a64..ae3a100e18fb 100644 >>> --- a/drivers/infiniband/sw/rxe/rxe_mr.c >>> +++ b/drivers/infiniband/sw/rxe/rxe_mr.c >>> @@ -731,7 +731,7 @@ int rxe_dereg_mr(struct ib_mr *ibmr, struct ib_udata *udata) >>> return -EINVAL; >>> >>> rxe_cleanup(mr); >>> - kfree_rcu(mr); >>> + kfree_rcu_mightsleep(mr); >>> return 0; >>> } >>> >> I just got back from a 1 week vacation and missed all this. >> >> The "RDMA/rxe: Remove rxe_alloc()" patch just moved the memory allocation >> for MR (verbs) objects outside of the rxe_pool code since it only applied >> to MRs and not the other verbs objects (AH, QP, CQ, ...). That code has to >> handle a unique situation for AH objects which can be created or destroyed >> by connection manager code in atomic context while all the other ones >> including MRs are always created/destroyed in process context. All objects >> other than MR's are created/destroyed in the rdma-core code >> (drivers/infiniband/core). >> >> The rxe driver keeps xarray's of pointers to the various objects which are >> protected by rcu locking and so it made sense to use kfree_rcu to delete >> the object with a delay. In the MR case ..._mightsleep seems harmless and >> should not be an issue. >> >> However on reflection, all the references to the MR objects are ref counted >> and they have been dropped before reaching the kfree and so there really >> never was a good reason to use kfree_rcu in the first place. So a better >> solution would be to replace kfree_rcu with kfree. There is a timeout in >> completion_done() that triggers a WARN_ON() and this is only seen if the >> driver is broken for some reason but that is equivalent to getting a seg >> fault so no reason to further delay the kfree. >> >> Reviewed-by: Bob Pearson <rpearsonhpe@gmail.com> > > Thanks, I am planning to send the following patch for 6.4 consideration, > please let me know if you disagree. Still testing it. > > ----8<--- > > From: Joel Fernandes (Google) <joel@joelfernandes.org> > Subject: [PATCH] RDMA/rxe: Rename kfree_rcu() to kvfree_rcu_mightsleep() > > The k[v]free_rcu() macro's single-argument form is deprecated. > Therefore switch to the new k[v]free_rcu_mightsleep() variant. The goal > is to avoid accidental use of the single-argument forms, which can > introduce functionality bugs in atomic contexts and latency bugs in > non-atomic contexts. > > There is no functionality change with this patch. > > Link: https://lore.kernel.org/rcu/20230201150815.409582-1-urezki@gmail.com > Acked-by: Zhu Yanjun <zyjzyj2000@gmail.com> > Reviewed-by: Bob Pearson <rpearsonhpe@gmail.com> > Reviewed-by: Paul E. McKenney <paulmck@kernel.org> > Fixes: 72a03627443d ("RDMA/rxe: Remove rxe_alloc()") > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> > --- > drivers/infiniband/sw/rxe/rxe_mr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/infiniband/sw/rxe/rxe_mr.c b/drivers/infiniband/sw/rxe/rxe_mr.c > index b10aa1580a64..ae3a100e18fb 100644 > --- a/drivers/infiniband/sw/rxe/rxe_mr.c > +++ b/drivers/infiniband/sw/rxe/rxe_mr.c > @@ -731,7 +731,7 @@ int rxe_dereg_mr(struct ib_mr *ibmr, struct ib_udata *udata) > return -EINVAL; > > rxe_cleanup(mr); > - kfree_rcu(mr); > + kfree_rcu_mightsleep(mr); > return 0; > } > I would prefer just - kfree_rcu(mr); + kfree(mr); but either one will work. Bob
diff --git a/drivers/infiniband/sw/rxe/rxe_pool.c b/drivers/infiniband/sw/rxe/rxe_pool.c index f50620f5a0a1..e2fa061f19b3 100644 --- a/drivers/infiniband/sw/rxe/rxe_pool.c +++ b/drivers/infiniband/sw/rxe/rxe_pool.c @@ -276,7 +276,7 @@ int __rxe_cleanup(struct rxe_pool_elem *elem, bool sleepable) pool->cleanup(elem); if (pool->type == RXE_TYPE_MR) - kfree_rcu(elem->obj); + kfree_rcu_mightsleep(elem->obj); atomic_dec(&pool->num_elem);