linux-kernel - Re: [PATCH 13/13] rcu/kvfree: Eliminate k[v]free

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230305180524.GL1301832@paulmck-ThinkPad-P17-Gen-1>
Date:   Sun, 5 Mar 2023 10:05:24 -0800
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Joel Fernandes <joel@...lfernandes.org>
Cc:     Uladzislau Rezki <urezki@...il.com>,
        LKML <linux-kernel@...r.kernel.org>, RCU <rcu@...r.kernel.org>,
        Oleksiy Avramchenko <oleksiy.avramchenko@...y.com>,
        Jens Axboe <axboe@...nel.dk>,
        Philipp Reisner <philipp.reisner@...bit.com>,
        Bryan Tan <bryantan@...are.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Bob Pearson <rpearsonhpe@...il.com>,
        Ariel Levkovich <lariel@...dia.com>,
        Theodore Ts'o <tytso@....edu>, Julian Anastasov <ja@....bg>
Subject: Re: [PATCH 13/13] rcu/kvfree: Eliminate k[v]free_rcu() single
 argument macro

On Sun, Mar 05, 2023 at 07:56:33AM -0500, Joel Fernandes wrote:
> 
> 
> > On Mar 5, 2023, at 6:41 AM, Uladzislau Rezki <urezki@...il.com> wrote:
> > 
> > 
> >> 
> >>>> On Mar 5, 2023, at 5:29 AM, Joel Fernandes <joel@...lfernandes.org> wrote:
> >>> 
> >>> Hi, All,
> >>> 
> >>>> On Wed, Feb 1, 2023 at 10:11 AM Uladzislau Rezki (Sony)
> >>>> <urezki@...il.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.

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.  ;-)

							Thanx, Paul

> Thanks,
> 
>  - Joel
> 
> 
> > 
> > @Paul what is your view?
> > 
> > Thanks!
> > 
> > --
> > Uladzislau Rezki