linux-kernel - Re: [RFC 4/4] Change 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: <8737d2d52e.fsf@firstfloor.org>
Date:   Thu, 20 Apr 2017 16:36:57 -0700
From:   Andi Kleen <andi@...stfloor.org>
To:     Laurent Dufour <ldufour@...ux.vnet.ibm.com>
Cc:     linux-mm@...ck.org, Davidlohr Bueso <dave@...olabs.net>,
        akpm@...ux-foundation.org, Jan Kara <jack@...e.cz>,
        "Kirill A . Shutemov" <kirill@...temov.name>,
        Michal Hocko <mhocko@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Mel Gorman <mgorman@...hsingularity.net>,
        haren@...ux.vnet.ibm.com, aneesh.kumar@...ux.vnet.ibm.com,
        khandual@...ux.vnet.ibm.com, Paul.McKenney@...ibm.com,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC 4/4] Change mmap_sem to range lock

Laurent Dufour <ldufour@...ux.vnet.ibm.com> writes:

> [resent this patch which seems to have not reached the mailing lists]
>
> Change the mmap_sem to a range lock to allow finer grain locking on
> the memory layout of a task.
>
> This patch rename mmap_sem into mmap_rw_tree to avoid confusion and
> replace any locking (read or write) by complete range locking.  So
> there is no functional change except in the way the underlying locking
> is achieved.
>
> Currently, this patch only supports x86 and PowerPc architectures,
> furthermore it should break the build of any others.

Thanks for working on this.

However as commented before I think the first step to make progress here
is a description of everything mmap_sem protects.

Surely the init full case could be done shorter with some wrapper
that combines the init_full and lock operation?

Then it would be likely a simple search'n'replace to move the
whole tree in one atomic step to the new wrappers.
Initially they could be just defined to use rwsems too to
not change anything at all.

It would be a good idea to merge such a patch as quickly
as possible beause it will be a nightmare to maintain
longer term.

Then you could add a config to use a range lock through
the wrappers.

Then after that you could add real ranges step by step,
after doing the proper analysis.

-Andi