linux-kernel - Re: [RFC v4 0/3] mm: zap pages with read mmap

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:   Thu, 12 Jul 2018 10:15:24 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Yang Shi <yang.shi@...ux.alibaba.com>, willy@...radead.org,
        ldufour@...ux.vnet.ibm.com, kirill@...temov.name,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC v4 0/3] mm: zap pages with read mmap_sem in munmap for
 large mapping

On Wed 11-07-18 15:49:54, Andrew Morton wrote:
> On Wed, 11 Jul 2018 12:33:12 +0200 Michal Hocko <mhocko@...nel.org> wrote:
> 
> > > Approach:
> > > Zapping pages is the most time consuming part, according to the suggestion from
> > > Michal Hocko [1], zapping pages can be done with holding read mmap_sem, like
> > > what MADV_DONTNEED does. Then re-acquire write mmap_sem to cleanup vmas.
> > > 
> > > But, we can't call MADV_DONTNEED directly, since there are two major drawbacks:
> > >   * The unexpected state from PF if it wins the race in the middle of munmap.
> > >     It may return zero page, instead of the content or SIGSEGV.
> > >   * Can’t handle VM_LOCKED | VM_HUGETLB | VM_PFNMAP and uprobe mappings, which
> > >     is a showstopper from akpm
> > 
> > I do not really understand why this is a showstopper. This is a mere
> > optimization. VM_LOCKED ranges are usually not that large. VM_HUGETLB
> > can be quite large alright but this should be doable on top. Is there
> > any reason to block any "cover most mappings first" patch?
> 
> Somebody somewhere is going to want to unmap vast mlocked regions and
> they're going to report softlockup warnings. So we shouldn't implement
> something which can't address these cases.  Maybe it doesn't do so in
> the first version, but we should at least have a plan to handle all
> cases.

Absolutely. I was just responding to the "showstopper" part. This is
improving some cases but it shouldn't make others worse so going
incremental should be perfectly reasonable.
-- 
Michal Hocko
SUSE Labs