linux-kernel - Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 7 Feb 2018 08:57:00 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:     Kirill Tkhai <ktkhai@...tuozzo.com>,
        Matthew Wilcox <willy@...radead.org>, josh@...htriplett.org,
        mathieu.desnoyers@...icios.com, jiangshanlai@...il.com,
        mingo@...hat.com, cl@...ux.com, penberg@...nel.org,
        rientjes@...gle.com, iamjoonsoo.kim@....com,
        akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, brouer@...hat.com, rao.shoaib@...cle.com
Subject: Re: [PATCH 0/2] rcu: Transform kfree_rcu() into kvfree_rcu()

On Wed, 7 Feb 2018 00:31:04 -0800
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> wrote:

> I see problems.  We would then have two different names for exactly the
> same thing.
> 
> Seems like it would be a lot easier to simply document the existing
> kfree_rcu() behavior, especially given that it apparently already works.
> The really doesn't seem to me to be worth a name change.

Honestly, I don't believe this is an RCU sub-system decision. This is a
memory management decision.

If we have kmalloc(), vmalloc(), kfree(), vfree() and kvfree(), and we
want kmalloc() to be freed with kfree(), and vmalloc() to be freed with
vfree(), and for strange reasons, we don't know how the data was
allocated we have kvfree(). That's an mm decision not an rcu one. We
should have kfree_rcu(), vfree_rcu() and kvfree_rcu(), and honestly,
they should not depend on kvfree() doing the same thing for everything.
Each should call the corresponding member that they represent. Which
would change this patch set.

Why? Too much coupling between RCU and MM. What if in the future
something changes and kvfree() goes away or changes drastically. We
would then have to go through all the users of RCU to change them too.

To me kvfree() is a special case and should not be used by RCU as a
generic function. That would make RCU and MM much more coupled than
necessary.

-- Steve