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: <20200730205705.ityqlyeswzo5dkow@ca-dmjordan1.us.oracle.com>
Date:   Thu, 30 Jul 2020 16:57:05 -0400
From:   Daniel Jordan <daniel.m.jordan@...cle.com>
To:     Hugh Dickins <hughd@...gle.com>
Cc:     Pengfei Li <fly@...nel.page>, akpm@...ux-foundation.org,
        bmt@...ich.ibm.com, dledford@...hat.com, willy@...radead.org,
        vbabka@...e.cz, kirill.shutemov@...ux.intel.com, jgg@...pe.ca,
        alex.williamson@...hat.com, cohuck@...hat.com,
        daniel.m.jordan@...cle.com, dbueso@...e.de, jglisse@...hat.com,
        jhubbard@...dia.com, ldufour@...ux.ibm.com,
        Liam.Howlett@...cle.com, peterz@...radead.org, cl@...ux.com,
        jack@...e.cz, rientjes@...gle.com, walken@...gle.com,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: [PATCH 2/2] mm, util: account_locked_vm() does not hold mmap_lock

On Wed, Jul 29, 2020 at 12:21:11PM -0700, Hugh Dickins wrote:
> On Sun, 26 Jul 2020, Pengfei Li wrote:
> 
> > Since mm->locked_vm is already an atomic counter, account_locked_vm()
> > does not need to hold mmap_lock.
> 
> I am worried that this patch, already added to mmotm, along with its
> 1/2 making locked_vm an atomic64, might be rushed into v5.9 with just
> that two-line commit description, and no discussion at all.
> 
> locked_vm belongs fundamentally to mm/mlock.c, and the lock to guard
> it is mmap_lock; and mlock() has some complicated stuff to do under
> that lock while it decides how to adjust locked_vm.
>
> It is very easy to convert an unsigned long to an atomic64_t, but
> "atomic read, check limit and do stuff, atomic add" does not give
> the same guarantee as holding the right lock around it all.

Yes, this is why I withdrew my attempt to do something similar last year, I
didn't want to make the accounting racy.  Stack and heap growing and mremap
would be affected in addition to mlock.

It'd help to hear more about the motivation for this.

Daniel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ