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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20180711115332.GM20050@dhcp22.suse.cz>
Date:   Wed, 11 Jul 2018 13:53:32 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     "Kirill A. Shutemov" <kirill@...temov.name>
Cc:     Yang Shi <yang.shi@...ux.alibaba.com>, willy@...radead.org,
        ldufour@...ux.vnet.ibm.com, akpm@...ux-foundation.org,
        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 14:13:12, Kirill A. Shutemov wrote:
> On Wed, Jul 11, 2018 at 12:33:12PM +0200, Michal Hocko wrote:
> > this is not a small change for something that could be achieved
> > from the userspace trivially (just call madvise before munmap - library
> > can hide this). Most workloads will even not care about races because
> > they simply do not play tricks with mmaps and userspace MM. So why do we
> > want to put the additional complexity into the kernel?
> 
> As I said before, kernel latency issues have to be addressed in kernel.
> We cannot rely on userspace being kind here.

Those who really care and create really large mappings will know how to
do this properly. Most others just do not care enough. So I am not
really sure this alone is a sufficient argument.

I personally like the in kernel auto tuning but as I've said the
changelog should be really clear why all the complications are
justified. This would be a lot easier to argue about if it was a simple
	if (len > THARSHOLD)
		do_madvise(DONTNEED)
	munmap().
approach. But if we really have to care about parallel faults and munmap
consitency this will always be tricky
-- 
Michal Hocko
SUSE Labs