linux-kernel - Re: + include-linux-sched-mmh-uninline-mmdrop

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 PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

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

Date:   Mon, 18 Sep 2017 08:08:00 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-kernel@...r.kernel.org, mingo@...nel.org, oleg@...hat.com,
        peterz@...radead.org, mm-commits@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: + include-linux-sched-mmh-uninline-mmdrop_async-etc.patch added
 to -mm tree

On Fri 15-09-17 11:05:20, Andrew Morton wrote:
> On Fri, 15 Sep 2017 09:12:28 +0200 Michal Hocko <mhocko@...nel.org> wrote:
> 
> > On Fri 15-09-17 09:07:31, Michal Hocko wrote:
> > > On Thu 14-09-17 13:19:38, Andrew Morton wrote:
> > > > From: Andrew Morton <akpm@...ux-foundation.org>
> > > > Subject: include/linux/sched/mm.h: uninline mmdrop_async(), etc
> > > > 
> > > > mmdrop_async() is only used in fork.c.  Move that and its support
> > > > functions into fork.c, uninline it all.
> > > 
> > > Is this really an improvement? Why do we want to discourage more code
> > > paths to use mmdrop_async? It sounds like a useful api and it has been
> > > removed only because it lost its own user in oom code. Now that we have
> > > a user I would just keep it where it was before.
> > 
> > Dohh, I have mixed mmput_async with mmdrop_async. Anyway I still think
> > that this is universal enough to have it in a header rather than hiding
> > it in fork.c
> 
> Async free is a hack.  It consumes more resources (runtime and memory)
> than a synchronous free.  It introduces a risk of memory exhaustion
> when an unbounded number of async frees are pending, not yet serviced. 
> It introduces a risk of unbounded latency when an unbounded number of
> async frees are serviced by the kernel thread.

It is our standard technique of postponing an action to a more relaxed
context when we cannot afford an action from the current context.
 
> Synchronous frees are simply better, so we shouldn't encourage the use
> of async frees.

No questions about that. But we have a clear demand for the deferred
implementation as well. And we have learned that having our own
private, thing usually leads people to invent their own wheel.

-- 
Michal Hocko
SUSE Labs