From: Joel Fernandes <joel@joelfernandes.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Uladzislau Rezki <urezki@gmail.com>,
LKML <linux-kernel@vger.kernel.org>, RCU <rcu@vger.kernel.org>,
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>
Subject: Re: [PATCH 13/13] rcu/kvfree: Eliminate k[v]free_rcu() single argument macro
Date: Mon, 6 Mar 2023 14:49:48 +0000 [thread overview]
Message-ID: <20230306144948.GA3280216@google.com> (raw)
In-Reply-To: <20230305180524.GL1301832@paulmck-ThinkPad-P17-Gen-1>
On Sun, Mar 05, 2023 at 10:05:24AM -0800, Paul E. McKenney wrote:
> On Sun, Mar 05, 2023 at 07:56:33AM -0500, Joel Fernandes wrote:
> >
> >
> > > On Mar 5, 2023, at 6:41 AM, Uladzislau Rezki <urezki@gmail.com> wrote:
> > >
> > >
> > >>
> > >>>> On Mar 5, 2023, at 5:29 AM, Joel Fernandes <joel@joelfernandes.org> wrote:
> > >>>
> > >>> Hi, All,
> > >>>
> > >>>> On Wed, Feb 1, 2023 at 10:11 AM Uladzislau Rezki (Sony)
> > >>>> <urezki@gmail.com> wrote:
> > >>>>
> > >>>> For a single argument invocations a new kfree_rcu_mightsleep()
> > >>>> and kvfree_rcu_mightsleep() macroses are used. This is done in
> > >>>> order to prevent users from calling a single argument from
> > >>>> atomic contexts as "_mightsleep" prefix signals that it can
> > >>>> schedule().
> > >>>>
> > >>>
> > >>> Since this commit in -dev branch [1] suggests more users still need
> > >>> conversion, let us drop this single patch for 6.4 and move the rest of
> > >>> the series forward? Let me know if you disagree.
> > >>> https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/commit/?h=dev&id=9bf5e3a2626ed474d080f695007541b6ecd6e60b
> > >>>
> > >>> All -- please supply Ack/Review tags for patches 1-12.
> > >>
> > >> Or put another way, what is the transition plan for these remaining users?
> > >>
> > >> I am getting on a plane right now but I can research which users are remaining later.
> > >>
> > > I am not sure. I think we can cover it on the meeting.
> >
> > Cool, thanks.
>
> My current plan is as follows:
>
> 1. Addition of kvfree_rcu_mightsleep() went into v6.3.
>
> 2. After creating branches, I send out the series, including 12/12.
> The -rcu tree's "dev" branch continues to have a revert to avoid
> breaking -next until we achieve clean -next and clean "dev"
> branch.
>
> 3. Any conversion patches that get maintainer acks go into v6.4.
> Along with a checkpatch error, as Joel notes below.
>
> 4. There are periodic checks for new code using the single-argument
> forms of kfree_rcu() and kvfree_rcu(). Patches are produced
> for them, or responses to the patches introducing them, as
> appropriate. A coccinelle script might be helpful, perhaps
> even as part of kernel test robot or similar.
>
> 5. The -rcu tree's "dev" branch will revert to unclean from time
> to time as maintainers choose to take conversion patches into
> their own trees.
>
> 6. Once mainline is clean, we push 12/12 into the next merge
> window.
Since in theory, mainline could also be after 6.4-rc1, I am assuming next merge
window could also mean 6.5 right? But yes, agreed.
> 7. We then evaluate whether further cleanups are needed.
>
> > > My feeling is
> > > that, we introduced "_mightsleep" macros first and after that try to
> > > convert users.
>
> > One stopgap could be to add a checkpatch error if anyone tries to use old API,
> > and then in the meanwhile convert all users.
> > Though, that requires people listening to checkpatch complaints.
>
> Every person who listens is that much less hassle. It doesn't have to
> be perfect. ;-)
The below checkpatch change can catch at least simple single-arg uses (i.e.
not having compound expressions inside of k[v]free_rcu() args). I will submit
a proper patch to it which we can include in this set.
Thoughts?
---
scripts/checkpatch.pl | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 78cc595b98ce..fc73786064b3 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -6362,6 +6362,15 @@ sub process {
}
}
+# check for soon-to-be-deprecated single-argument k[v]free_rcu() API
+ if ($line =~ /\bk[v]?free_rcu\s*\([^(]+\)/) {
+ if ($line =~ /\bk[v]?free_rcu\s*\([^,]+\)/) {
+ ERROR("DEPRECATED_API",
+ "Single-argument k[v]free_rcu() API is deprecated, please pass an rcu_head object." . $herecurr);
+ }
+ }
+
+
# check for unnecessary "Out of Memory" messages
if ($line =~ /^\+.*\b$logFunctions\s*\(/ &&
$prevline =~ /^[ \+]\s*if\s*\(\s*(\!\s*|NULL\s*==\s*)?($Lval)(\s*==\s*NULL\s*)?\s*\)/ &&
--
2.40.0.rc0.216.gc4246ad0f0-goog
next prev parent reply other threads:[~2023-03-06 14:50 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-01 15:09 [PATCH 10/13] ipvs: Rename kfree_rcu() to kfree_rcu_mightsleep() Uladzislau Rezki (Sony)
2023-02-01 15:09 ` [PATCH 11/13] rcuscale: " Uladzislau Rezki (Sony)
2023-02-01 15:09 ` [PATCH 12/13] doc: Update whatisRCU.rst Uladzislau Rezki (Sony)
2023-02-01 15:09 ` [PATCH 13/13] rcu/kvfree: Eliminate k[v]free_rcu() single argument macro Uladzislau Rezki (Sony)
2023-03-05 10:29 ` Joel Fernandes
2023-03-05 10:49 ` Joel Fernandes
2023-03-05 11:41 ` Uladzislau Rezki
2023-03-05 12:56 ` Joel Fernandes
2023-03-05 18:05 ` Paul E. McKenney
2023-03-06 14:49 ` Joel Fernandes [this message]
2023-03-06 15:01 ` Paul E. McKenney
2023-03-06 15:12 ` Joel Fernandes
2023-03-06 16:42 ` Uladzislau Rezki
2023-03-06 16:55 ` Paul E. McKenney
2023-03-06 17:10 ` Uladzislau Rezki
2023-03-06 19:54 ` Joel Fernandes
2023-02-01 15:53 ` [PATCH 10/13] ipvs: Rename kfree_rcu() to kfree_rcu_mightsleep() Pablo Neira Ayuso
2023-02-01 16:12 ` Julian Anastasov
2023-02-01 16:52 ` Uladzislau Rezki
2023-02-01 17:10 ` Pablo Neira Ayuso
2023-02-01 17:19 ` Uladzislau Rezki
2023-03-09 0:11 ` Joel Fernandes
2023-03-09 9:19 ` Pablo Neira Ayuso
2023-03-10 1:08 ` Joel Fernandes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230306144948.GA3280216@google.com \
--to=joel@joelfernandes.org \
--cc=axboe@kernel.dk \
--cc=bryantan@vmware.com \
--cc=edumazet@google.com \
--cc=ja@ssi.bg \
--cc=lariel@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleksiy.avramchenko@sony.com \
--cc=paulmck@kernel.org \
--cc=philipp.reisner@linbit.com \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=rpearsonhpe@gmail.com \
--cc=tytso@mit.edu \
--cc=urezki@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.