All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Yu Zhao <yuzhao@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	dev@der-flo.net, Linux-MM <linux-mm@kvack.org>,
	Uladzislau Rezki <urezki@gmail.com>,
	bugzilla-daemon@kernel.org
Subject: Re: [Bug 216489] New: Machine freezes due to memory lock
Date: Fri, 16 Sep 2022 02:46:39 -0700	[thread overview]
Message-ID: <202209160230.CE9E0E51@keescook> (raw)
In-Reply-To: <YyQ2CSdIJdvQPSPO@casper.infradead.org>

On Fri, Sep 16, 2022 at 09:38:33AM +0100, Matthew Wilcox wrote:
> On Thu, Sep 15, 2022 at 05:59:56PM -0600, Yu Zhao wrote:
> > I think this is a manifest of the lockdep warning I reported a couple
> > of weeks ago:
> > https://lore.kernel.org/r/CAOUHufaPshtKrTWOz7T7QFYUNVGFm0JBjvM700Nhf9qEL9b3EQ@mail.gmail.com/
> 
> That would certainly match the symptoms.
> 
> Turning vmap_lock into an NMI-safe lock would be bad.  I don't even know
> if we have primitives for that (it's not like you can disable an NMI
> ...)
> 
> I don't quite have time to write a patch right now.  Perhaps something
> like:
> 
> struct vmap_area *find_vmap_area_nmi(unsigned long addr)
> {
>         struct vmap_area *va;
> 
>         if (spin_trylock(&vmap_area_lock))
> 		return NULL;
>         va = __find_vmap_area(addr, &vmap_area_root);
>         spin_unlock(&vmap_area_lock);
> 
>         return va;
> }
> 
> and then call find_vmap_area_nmi() in check_heap_object().  I may have
> the polarity of the return value of spin_trylock() incorrect.

I think we'll need something slightly tweaked, since this would
return NULL under any contention (and a NULL return is fatal in
check_heap_object()). It seems like we need to explicitly check
for being in nmi context in check_heap_object() to deal with it?
Like this (only build tested):


diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index 096d48aa3437..c8a00f181a11 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -216,6 +216,7 @@ void free_vm_area(struct vm_struct *area);
 extern struct vm_struct *remove_vm_area(const void *addr);
 extern struct vm_struct *find_vm_area(const void *addr);
 struct vmap_area *find_vmap_area(unsigned long addr);
+struct vmap_area *find_vmap_area_try(unsigned long addr);
 
 static inline bool is_vm_area_hugepages(const void *addr)
 {
diff --git a/mm/usercopy.c b/mm/usercopy.c
index c1ee15a98633..9f943c29e7ec 100644
--- a/mm/usercopy.c
+++ b/mm/usercopy.c
@@ -173,7 +173,16 @@ static inline void check_heap_object(const void *ptr, unsigned long n,
 	}
 
 	if (is_vmalloc_addr(ptr)) {
-		struct vmap_area *area = find_vmap_area(addr);
+		struct vmap_area *area;
+
+		if (!in_nmi()) {
+			area = find_vmap_area(addr);
+		} else {
+			area = find_vmap_area_try(addr);
+			/* Give up under NMI to avoid deadlocks. */
+			if (!area)
+				return;
+		}
 
 		if (!area)
 			usercopy_abort("vmalloc", "no area", to_user, 0, n);
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index dd6cdb201195..f14f1902c2f6 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1840,6 +1840,17 @@ struct vmap_area *find_vmap_area(unsigned long addr)
 	return va;
 }
 
+struct vmap_area *find_vmap_area_try(unsigned long addr)
+{
+	struct vmap_area *va = NULL;
+
+	if (spin_trylock(&vmap_area_lock)) {
+		va = __find_vmap_area(addr, &vmap_area_root);
+		spin_unlock(&vmap_area_lock);
+	}
+	return va;
+}
+
 /*** Per cpu kva allocator ***/
 
 /*

-- 
Kees Cook


  reply	other threads:[~2022-09-16  9:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-216489-27@https.bugzilla.kernel.org/>
2022-09-15 20:39 ` [Bug 216489] New: Machine freezes due to memory lock Andrew Morton
2022-09-15 22:42   ` Matthew Wilcox
2022-09-15 23:59     ` Yu Zhao
2022-09-16  8:38       ` Matthew Wilcox
2022-09-16  9:46         ` Kees Cook [this message]
2022-09-16 12:28           ` Uladzislau Rezki
2022-09-16 12:32             ` Uladzislau Rezki
2022-09-16 14:15           ` Matthew Wilcox
2022-09-16 14:42             ` Kees Cook
2022-09-16 18:47             ` Uladzislau Rezki

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=202209160230.CE9E0E51@keescook \
    --to=keescook@chromium.org \
    --cc=akpm@linux-foundation.org \
    --cc=bugzilla-daemon@kernel.org \
    --cc=dev@der-flo.net \
    --cc=linux-mm@kvack.org \
    --cc=urezki@gmail.com \
    --cc=willy@infradead.org \
    --cc=yuzhao@google.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.