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]
Date:   Wed, 24 Nov 2021 09:23:53 -0400
From:   Jason Gunthorpe <jgg@...pe.ca>
To:     David Hildenbrand <david@...hat.com>
Cc:     Vlastimil Babka <vbabka@...e.cz>, Jens Axboe <axboe@...nel.dk>,
        Andrew Dona-Couch <andrew@...acou.ch>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Drew DeVault <sir@...wn.com>,
        Ammar Faizi <ammarfaizi2@...weeb.org>,
        linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
        io_uring Mailing List <io-uring@...r.kernel.org>,
        Pavel Begunkov <asml.silence@...il.com>, linux-mm@...ck.org
Subject: Re: [PATCH] Increase default MLOCK_LIMIT to 8 MiB

On Wed, Nov 24, 2021 at 09:57:32AM +0100, David Hildenbrand wrote:

> Unfortunately it will only be a band aid AFAIU. I can rewrite my
> reproducer fairly easily to pin the whole 2M range first, pin a second
> time only a single page, and then unpin the 2M range, resulting in the
> very same way to block THP. (I can block some THP less because I always
> need the possibility to memlock 2M first, though).

Oh!

The issue is GUP always pins an entire compound, no matter how little
the user requests.

However, when all the GUP callers do mlock accounting they have no
idea how much memory GUP actually pinned and only account mlock on 4K
chunks.

This is the bug your test is showing - using this accounting error the
user can significantly blow past their mlock limit by having GUP pin
2M chunks and then mlock accounting for only 4k chunks.

It is a super obnoxious bug to fix, but still just a bug and not some
inherent defect in FOLL_LONGTERM.

It also says the MLOCK_LIMIT really needs to always be > 1 THP
otherwise even a single 4K page may be unpinnable with correct
accounting.

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ