linux-kernel - Re: [PATCH 1/1] RFC: add pidfd_send_signal flag to reclaim mm while killing a process

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: <CAJuCfpGucpqxOzGhteFrtv-0HrSbAmZjLbA2=NCy-5UEx04mJw@mail.gmail.com>
Date:   Wed, 18 Nov 2020 11:51:29 -0800
From:   Suren Baghdasaryan <surenb@...gle.com>
To:     Michal Hocko <mhocko@...e.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        David Rientjes <rientjes@...gle.com>,
        Matthew Wilcox <willy@...radead.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Roman Gushchin <guro@...com>, Rik van Riel <riel@...riel.com>,
        Christian Brauner <christian@...uner.io>,
        Oleg Nesterov <oleg@...hat.com>,
        Tim Murray <timmurray@...gle.com>, linux-api@...r.kernel.org,
        linux-mm <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-team <kernel-team@...roid.com>,
        Minchan Kim <minchan@...nel.org>
Subject: Re: [PATCH 1/1] RFC: add pidfd_send_signal flag to reclaim mm while
 killing a process

On Wed, Nov 18, 2020 at 11:32 AM Michal Hocko <mhocko@...e.com> wrote:
>
> On Wed 18-11-20 11:22:21, Suren Baghdasaryan wrote:
> > On Wed, Nov 18, 2020 at 11:10 AM Michal Hocko <mhocko@...e.com> wrote:
> > >
> > > On Fri 13-11-20 18:16:32, Andrew Morton wrote:
> > > [...]
> > > > It's all sounding a bit painful (but not *too* painful).  But to
> > > > reiterate, I do think that adding the ability for a process to shoot
> > > > down a large amount of another process's memory is a lot more generally
> > > > useful than tying it to SIGKILL, agree?
> > >
> > > I am not sure TBH. Is there any reasonable usecase where uncoordinated
> > > memory tear down is OK and a target process which is able to see the
> > > unmapped memory?
> >
> > I think uncoordinated memory tear down is a special case which makes
> > sense only when the target process is being killed (and we can enforce
> > that by allowing MADV_DONTNEED to be used only if the target process
> > has pending SIGKILL).
>
> That would be safe but then I am wondering whether it makes sense to
> implement as a madvise call. It is quite strange to expect somebody call
> a syscall on a killed process. But this is more a detail. I am not a
> great fan of a more generic MADV_DONTNEED on a remote process. This is
> just too dangerous IMHO.

Agree 100%

>
> > However, the ability to apply other flavors of
> > process_madvise() to large memory areas spanning multiple VMAs can be
> > useful in more cases.
>
> Yes I do agree with that. The error reporting would be more tricky but
> I am not really sure that the exact reporting is really necessary for
> advice like interface.

Andrew's suggestion for this special mode to change return semantics
to the usual "0 or error code" seems to me like the most reasonable
way to deal with the return value limitation.

>
> > For example in Android we will use
> > process_madvise(MADV_PAGEOUT) to "shrink" an inactive background
> > process.
>
> That makes sense to me.
> --
> Michal Hocko
> SUSE Labs