From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Pedro Falcato <pfalcato@suse.de>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>,
"David Hildenbrand (Arm)" <david@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, "Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Jann Horn <jannh@google.com>, Zi Yan <ziy@nvidia.com>
Subject: Re: [PATCH mm-new v3] mm: mincore: use per-vma lock during page table walk
Date: Wed, 16 Sep 2026 13:40:04 +0100 [thread overview]
Message-ID: <aqqNBHYvB5gsrjBw@gremlin> (raw)
In-Reply-To: <aqqK378rhs5g7Wua@pedro-suse.tail5790ac.ts.net>
On Wed, Sep 16, 2026 at 01:30:53PM +0100, Pedro Falcato wrote:
> On Wed, Sep 16, 2026 at 12:19:50PM +0100, Lorenzo Stoakes (ARM) wrote:
> > <snip>
> > It'd be pretty broken if the VMA lock provided less guarantees than the
> > mmap read lock in VMA-specific operations.
>
> Well, there is one big case where that doesn't happen: cross-VMA operations.
> For which ATM there is no locking scheme for "lock two or more VMAs" so any
> operation loses atomicity.
Right yeah :)
I meant at a VMA granularity.
The /proc/$pid/maps stuff that Suren is doing speaks to the difficulties you
encounter when acquiring a VMA lock over a range of VMAs.
>
> Which isn't a problem here, because mincore() seems to have been written in
> a silly way.
I saw that it was explicitly limited to a single VMA so I wasn't worried about
it ;)
>
> --
> Pedro
--
Cheers, Lorenzo
prev parent reply other threads:[~2026-09-16 12:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 4:31 [PATCH mm-new v3] mm: mincore: use per-vma lock during page table walk Kefeng Wang
2026-09-16 6:33 ` David Hildenbrand (Arm)
2026-09-16 6:50 ` Kefeng Wang
2026-09-16 11:19 ` Lorenzo Stoakes (ARM)
2026-09-16 12:30 ` Pedro Falcato
2026-09-16 12:40 ` Lorenzo Stoakes (ARM) [this message]
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=aqqNBHYvB5gsrjBw@gremlin \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=jannh@google.com \
--cc=liam@infradead.org \
--cc=linux-mm@kvack.org \
--cc=pfalcato@suse.de \
--cc=vbabka@kernel.org \
--cc=wangkefeng.wang@huawei.com \
--cc=ziy@nvidia.com \
/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