All of lore.kernel.org
 help / color / mirror / Atom feed
From: Usama Arif <usama.arif@linux.dev>
To: Rik van Riel <riel@surriel.com>
Cc: Usama Arif <usama.arif@linux.dev>,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	kernel-team@meta.com, David Hildenbrand <david@kernel.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	Vlastimil Babka <vbabka@kernel.org>,
	Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>,
	linux-mm@kvack.org, Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Usama Arif <usamaarif642@gmail.com>
Subject: Re: [PATCH RFC v3 1/6] x86/mm: add untagged_addr_remote_unlocked()
Date: Mon, 20 Jul 2026 04:12:37 -0700	[thread overview]
Message-ID: <20260720111238.3313021-1-usama.arif@linux.dev> (raw)
In-Reply-To: <20260717170036.743149-2-riel@surriel.com>

On Fri, 17 Jul 2026 13:00:31 -0400 Rik van Riel <riel@surriel.com> wrote:

> __access_remote_vm() reads another process's memory under the mmap lock. On
> large machines that lock is contended by tasks polling /proc/PID/cmdline,
> /proc/PID/environ, or calling process_vm_readv(), even though the memory
> they read is almost always resident and could be reached under the per-VMA
> lock instead.
> 
> Looking up the VMA first requires untagging the address.
> untagged_addr_remote() asserts the mmap lock only because it reads
> mm->context.untag_mask, which can race with the write in mm_enable_lam().
> 
> That mask is set once, when LAM is enabled, and never changes afterwards,
> so the read itself does not need the lock. It is already read without it,
> from the context switch path and /proc/PID/status.
> 
> Add untagged_addr_remote_unlocked() for callers that have not taken the
> mmap lock, and annotate access to mm->context.untag_mask with READ_ONCE()
> and WRITE_ONCE() so the existing lockless reads are explicit and
> KCSAN-clean. untagged_addr_remote() keeps its assertion and shares the same
> code.
> 
> Assisted-by: Claude:claude-opus-4.8
> Acked-by: Usama Arif <usamaarif642@gmail.com>

Hi Rik,

Would you mind changing this to

Acked-by: Usama Arif <usama.arif@linux.dev>

in the next revision

Thanks!
 


  reply	other threads:[~2026-07-20 11:12 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-17 17:00 [PATCH v3 0/6] mm: access remote process memory under the per-VMA lock Rik van Riel
2026-07-17 17:00 ` [PATCH RFC v3 1/6] x86/mm: add untagged_addr_remote_unlocked() Rik van Riel
2026-07-20 11:12   ` Usama Arif [this message]
2026-07-17 17:00 ` [PATCH RFC v3 2/6] riscv/mm: " Rik van Riel
2026-07-17 17:00   ` Rik van Riel
2026-07-20 11:57   ` Usama Arif
2026-07-20 11:57     ` Usama Arif
2026-07-20 15:08     ` Rik van Riel
2026-07-20 15:08       ` Rik van Riel
2026-07-20 16:46       ` Usama Arif
2026-07-20 16:46         ` Usama Arif
2026-07-20 17:34         ` Rik van Riel
2026-07-20 17:34           ` Rik van Riel
2026-07-20 18:46           ` Usama Arif
2026-07-20 18:46             ` Usama Arif
2026-07-20 19:21             ` Rik van Riel
2026-07-20 19:21               ` Rik van Riel
2026-07-20 19:39               ` Usama Arif
2026-07-20 19:39                 ` Usama Arif
2026-07-17 17:00 ` [PATCH RFC v3 3/6] mm: rename get_user_page_vma_remote() to get_user_page_lookup_vma() Rik van Riel
2026-07-20 12:00   ` Usama Arif
2026-07-17 17:00 ` [PATCH RFC v3 4/6] mm/gup: add get_user_page_vma() to fault in a page under a held lock Rik van Riel
2026-07-20 12:35   ` Usama Arif
2026-07-20 15:24     ` Rik van Riel
2026-07-17 17:00 ` [PATCH RFC v3 5/6] mm: use per-VMA lock in __access_remote_vm() for single-VMA accesses Rik van Riel
2026-07-17 17:00 ` [PATCH RFC v3 6/6] selftests/mm: cover /proc/pid/mem access to VM_PFNMAP memory Rik van Riel
2026-07-21 18:12 ` [PATCH v3 0/6] mm: access remote process memory under the per-VMA lock David Hildenbrand (Arm)

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=20260720111238.3313021-1-usama.arif@linux.dev \
    --to=usama.arif@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@kernel.org \
    --cc=hpa@zytor.com \
    --cc=kernel-team@meta.com \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=riel@surriel.com \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --cc=tglx@kernel.org \
    --cc=usamaarif642@gmail.com \
    --cc=vbabka@kernel.org \
    --cc=x86@kernel.org \
    /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.