linux-kernel - Re: [RFC v1 0/4] Two alternatives for mm async teardown

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, 12 Nov 2021 11:15:51 +0100
From:   Michal Hocko <mhocko@...e.com>
To:     Claudio Imbrenda <imbrenda@...ux.ibm.com>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org, thuth@...hat.com,
        frankja@...ux.ibm.com, borntraeger@...ibm.com,
        Ulrich.Weigand@...ibm.com, heiko.carstens@...ibm.com,
        david@...hat.com, ultrachin@....com, akpm@...ux-foundation.org,
        vbabka@...e.cz, brookxu.cn@...il.com, xiaoggchen@...cent.com,
        linuszeng@...cent.com, yihuilu@...cent.com,
        daniel.m.jordan@...cle.com, axboe@...nel.dk, legion@...nel.org,
        peterz@...radead.org, aarcange@...hat.com, christian@...uner.io,
        ebiederm@...ssion.com, tglx@...utronix.de
Subject: Re: [RFC v1 0/4] Two alternatives for mm async teardown

On Thu 11-11-21 10:50:03, Claudio Imbrenda wrote:
> This RFC series proposes two possible ways for enabling asynchronous mm
> teardown.

It would be great to describe an intended usecase here and also explain
why the existing features do not allow the required functionality.

Please also make sure to cc linux-api when adding a new user visible
interface or changing a visible behavior of existing one.

E.g. why cannot you simply create a process outside of the thread group
yet share the mm with your task. Once the other process exits which you
can detect then you just exit that process and do the finall clean up
from that context?

> The first approach, in patch 1, is simply to provide an arch hook in
> exit_mm. This has no functional change for archs that don't explicitly
> use the hook, and leaves the hard part to arch code (including
> accounting, if any).

This is just too vague but I have to say I am not really a fan of hooks
that considerably change the existing behavior.

> The second approach, in patches 2 to 4, adds a new syscall to allow an
> mm to be asynchronously torn down in the context of another process
> (similarly to how process_mrelease works). It also adds an OOM notifier
> to prevent the OOM killer from killing processes while the teardown is
> in progress.

I have to say I do not like oom notifier part at all. You can have
different sources of the OOM (memcg, cpusets or global oom). It is
impossible to tell those appart in the notifier. Not to mention that
memcg oom is explicitly avoiding notifiers altogether.

-- 
Michal Hocko
SUSE Labs