From: Jason Gunthorpe <jgg@ziepe.ca>
To: David Hildenbrand <david@redhat.com>
Cc: Vlastimil Babka <vbabka@suse.cz>, Jens Axboe <axboe@kernel.dk>,
Andrew Dona-Couch <andrew@donacou.ch>,
Andrew Morton <akpm@linux-foundation.org>,
Drew DeVault <sir@cmpwn.com>,
Ammar Faizi <ammarfaizi2@gnuweeb.org>,
linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
io_uring Mailing List <io-uring@vger.kernel.org>,
Pavel Begunkov <asml.silence@gmail.com>,
linux-mm@kvack.org
Subject: Re: [PATCH] Increase default MLOCK_LIMIT to 8 MiB
Date: Wed, 24 Nov 2021 09:23:53 -0400 [thread overview]
Message-ID: <20211124132353.GG5112@ziepe.ca> (raw)
In-Reply-To: <2adca04f-92e1-5f99-6094-5fac66a22a77@redhat.com>
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
next prev parent reply other threads:[~2021-11-24 13:24 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20211028080813.15966-1-sir@cmpwn.com>
[not found] ` <CAFBCWQ+=2T4U7iNQz_vsBsGVQ72s+QiECndy_3AMFV98bMOLow@mail.gmail.com>
[not found] ` <CFII8LNSW5XH.3OTIVFYX8P65Y@taiga>
[not found] ` <593aea3b-e4a4-65ce-0eda-cb3885ff81cd@gnuweeb.org>
2021-11-16 4:35 ` Andrew Morton
2021-11-16 6:32 ` Drew DeVault
2021-11-16 19:47 ` Andrew Morton
2021-11-16 19:48 ` Drew DeVault
2021-11-16 21:37 ` Andrew Morton
2021-11-17 8:23 ` Drew DeVault
2021-11-22 17:11 ` David Hildenbrand
2021-11-22 17:55 ` Andrew Dona-Couch
2021-11-22 18:26 ` David Hildenbrand
2021-11-22 19:53 ` Jens Axboe
2021-11-22 20:03 ` Matthew Wilcox
2021-11-22 20:04 ` Jens Axboe
2021-11-22 20:08 ` David Hildenbrand
2021-11-22 20:44 ` Jens Axboe
2021-11-22 21:56 ` David Hildenbrand
2021-11-23 12:02 ` David Hildenbrand
2021-11-23 13:25 ` Jason Gunthorpe
2021-11-23 13:39 ` David Hildenbrand
2021-11-23 14:07 ` Jason Gunthorpe
2021-11-23 14:44 ` David Hildenbrand
2021-11-23 17:00 ` Jason Gunthorpe
2021-11-23 17:04 ` David Hildenbrand
2021-11-23 22:04 ` Vlastimil Babka
2021-11-23 23:59 ` Jason Gunthorpe
2021-11-24 8:57 ` David Hildenbrand
2021-11-24 13:23 ` Jason Gunthorpe [this message]
2021-11-24 13:25 ` David Hildenbrand
2021-11-24 13:28 ` Jason Gunthorpe
2021-11-24 13:29 ` David Hildenbrand
2021-11-24 13:48 ` Jason Gunthorpe
2021-11-24 14:14 ` David Hildenbrand
2021-11-24 15:34 ` Jason Gunthorpe
2021-11-24 16:43 ` David Hildenbrand
2021-11-24 18:35 ` Jason Gunthorpe
2021-11-24 19:09 ` David Hildenbrand
2021-11-24 23:11 ` Jason Gunthorpe
2021-11-30 15:52 ` David Hildenbrand
2021-11-24 18:37 ` David Hildenbrand
2021-11-24 14:37 ` Vlastimil Babka
2021-11-24 14:41 ` David Hildenbrand
2021-11-16 18:36 ` Matthew Wilcox
2021-11-16 18:44 ` Drew DeVault
2021-11-16 18:55 ` Jens Axboe
2021-11-16 19:21 ` Vito Caputo
2021-11-16 19:25 ` Drew DeVault
2021-11-16 19:46 ` Vito Caputo
2021-11-16 19:41 ` Jens Axboe
2021-11-17 22:26 ` Johannes Weiner
2021-11-17 23:17 ` Jens Axboe
2021-11-18 21:58 ` Andrew Morton
2021-11-19 7:41 ` Drew DeVault
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211124132353.GG5112@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=akpm@linux-foundation.org \
--cc=ammarfaizi2@gnuweeb.org \
--cc=andrew@donacou.ch \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=david@redhat.com \
--cc=io-uring@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sir@cmpwn.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox