linux-kernel - Re: [RFC-PATCH 2/4] mm: Add __rcu_alloc_page

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]

Date:   Fri, 25 Sep 2020 10:26:18 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     Uladzislau Rezki <urezki@...il.com>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Michal Hocko <mhocko@...e.com>,
        LKML <linux-kernel@...r.kernel.org>, RCU <rcu@...r.kernel.org>,
        linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Theodore Y . Ts'o" <tytso@....edu>,
        Joel Fernandes <joel@...lfernandes.org>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Oleksiy Avramchenko <oleksiy.avramchenko@...ymobile.com>,
        Mel Gorman <mgorman@...e.de>
Subject: Re: [RFC-PATCH 2/4] mm: Add __rcu_alloc_page_lockless() func.

On Thu, Sep 24, 2020 at 08:38:34AM -0700, Paul E. McKenney wrote:
> On Thu, Sep 24, 2020 at 01:19:07PM +0200, Peter Zijlstra wrote:
> > On Thu, Sep 24, 2020 at 10:16:14AM +0200, Uladzislau Rezki wrote:
> > > The key point is "enough". We need pages to make a) fast progress b) support
> > > single argument of kvfree_rcu(one_arg). Not vice versa. That "enough" depends
> > > on scheduler latency and vague pre-allocated number of pages, it might
> > > be not enough what would require to refill it more and more or we can overshoot
> > > that would lead to memory overhead. So we have here timing issues and
> > > not accurate model. IMHO.
> > 
> > I'm firmly opposed to the single argument kvfree_rcu() idea, that's
> > requiring memory to free memory.
> 
> Not quite.
> 
> First, there is a fallback when memory allocation fails.  Second,
> in heavy-use situations, there is only one allocation per about
> 500 kvfree_rcu() calls on 64-bit systems.  Third, there are other
> long-standing situations that require allocating memory in order to
> free memory.

Some of which are quite broken. And yes, I'm aware of all that, I'm the
one that started swap-over-NFS, which requires network traffic to free
memory, which is one insane step further.

But the way to make that 'work' is carefully account and pre-allocate
(or size the reserve) the required memory to make progress and to
strictly limit concurrency to ensure you stay in your bounds.

> So I agree that it is a good general rule of thumb to avoid allocating
> on free paths, but there are exceptions.  This is one of them.

The very first thing you need to do is proof your memory usage is
bounded, and then calculate your bound.

The problem is that with RCU you can't limit concurrency. call_rcu()
can't block, you can't wait for a grace period to end when you've ran
out of your reserve.

That is, you don't have a bound, so no reserve what so ever is going to
help.

You must have that callback_head fallback.