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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.