public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>
Cc: "Liam.Howlett@oracle.com" <Liam.Howlett@oracle.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"ljs@kernel.org" <ljs@kernel.org>,
	"surenb@google.com" <surenb@google.com>,
	"vbabka@kernel.org" <vbabka@kernel.org>,
	"shakeel.butt@linux.dev" <shakeel.butt@linux.dev>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Subject: Re: [PATCH 6/6] x86/mm: Avoid mmap lock for shadow stack pop fast path
Date: Tue, 5 May 2026 09:39:09 -0700	[thread overview]
Message-ID: <7a82a652-f861-4d72-8bd7-4e082af482f2@intel.com> (raw)
In-Reply-To: <a46738ebd632ff046bc9b0d02a5382de5f2e9f2e.camel@intel.com>

On 5/4/26 16:15, Edgecombe, Rick P wrote:
> 
> I guess the problem is the lock ordering. Not sure if there is any slow path
> avoidance details that could make this splat a false positive. But how about
> this simpler munmap() case:
> 
> Shadow stack signal                          munmap()
> -------------------                          --------
> vma_start_read() (VM_SHADOW_STACK check)
>                                              mmap_write_lock()
> mmap_read_lock() (user fault) <- deadlock
>                                              vma_start_write() <-deadlock

It's a little more complicated than that in practice, but I think you're
right.

I'm not sure when this would happen in practice because the fault is
actually on the VMA that's being held for read. So I think another
writer would have had to sneak in there and zap the VMA.

The funny thing is that the fault handler is really just trying to find
the VMA. The thing causing the fault *has* the VMA. So it's as simple as
just passing the VMA down into the fault handler, right? How hard could
it be? ;)

There are still games to play, but they all involve dropping locks and
retrying, like:

retry:
	vma = lock_vma_under_rcu()
	// muck with VMA
	pagefault_disable() // avoid deadlock
	ret = copy_from_user()
	pagefault_enable()
	vma_end_read();

	if (!ret)
		return SUCCESS;

	mmap_read_lock()
	vma = vma_lookup()
	mmap_read_unlock() // avoid deadlock before touching userspace
	// check for valid VMA to avoid looping when there is no VMA
	if (!vma)
		return -ERRNO;

	// uh oh, slow path, something faulted
	get_user_pages()??
	//or
	copy_from_user() without the VMA??

	goto retry;


This also needs some very careful thought, but something like this
should work, where we avoid fault handling (and lock taking) in the
actual #PF and do it in a context where the VMA lock is held:

	vma = lock_vma_under_rcu();
	pagefault_disable() // avoid deadlock

	while (1) {
		ret = copy_from_user()
		if (!ret)
			break;
		handle_mm_fault(vma, address, FAULT_FLAG_VMA_LOCK...);
	};

	pagefault_enable()
	vma_end_read();

That's effectively just short-circuiting the #PF code which does the:

        vma = lock_vma_under_rcu(mm, address);
	...
        fault = handle_mm_fault(vma, address, ... FAULT_FLAG_VMA_LOCK)

sequence _itself_.

  reply	other threads:[~2026-05-05 16:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-29 18:19 [PATCH 0/6] mm: Make per-VMA locks available in all builds Dave Hansen
2026-04-29 18:19 ` [PATCH 1/6] mm: Make per-VMA locks available universally Dave Hansen
2026-04-29 18:19 ` [PATCH 2/6] binder: Make shrinker rely solely on per-VMA lock Dave Hansen
2026-04-29 18:19 ` [PATCH 3/6] mm: Add RCU-based VMA lookup that waits for writers Dave Hansen
2026-04-29 18:20 ` [PATCH 4/6] binder: Remove mmap_lock fallback Dave Hansen
2026-04-29 18:20 ` [PATCH 5/6] tcp: Remove mmap_lock fallback path Dave Hansen
2026-04-29 18:20 ` [PATCH 6/6] x86/mm: Avoid mmap lock for shadow stack pop fast path Dave Hansen
2026-05-04 23:15   ` Edgecombe, Rick P
2026-05-05 16:39     ` Dave Hansen [this message]
2026-04-29 18:22 ` [PATCH 0/6] mm: Make per-VMA locks available in all builds Dave Hansen
2026-04-30  8:11   ` Lorenzo Stoakes
2026-04-30 17:17     ` Suren Baghdasaryan
2026-04-30 17:20       ` Dave Hansen
2026-04-30  7:55 ` [syzbot ci] " syzbot ci
2026-04-30 16:59   ` Dave Hansen
     [not found] ` <20260430072053.e0be1b431bcff02831f07e9d@linux-foundation.org>
2026-04-30 16:52   ` [PATCH 0/6] " Dave Hansen

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=7a82a652-f861-4d72-8bd7-4e082af482f2@intel.com \
    --to=dave.hansen@intel.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=shakeel.butt@linux.dev \
    --cc=surenb@google.com \
    --cc=vbabka@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox