All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Yang Shi <yang@os.amperecomputing.com>
Cc: peterx@redhat.com, yangge1116@126.com, david@redhat.com,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org,
	Vivek Kasireddy <vivek.kasireddy@intel.com>
Subject: Re: [v2 PATCH] mm: gup: do not call try_grab_folio() in slow path
Date: Thu, 27 Jun 2024 15:54:25 -0700	[thread overview]
Message-ID: <20240627155425.a31792e7c4709facfcbd417c@linux-foundation.org> (raw)
In-Reply-To: <20240627221413.671680-1-yang@os.amperecomputing.com>

On Thu, 27 Jun 2024 15:14:13 -0700 Yang Shi <yang@os.amperecomputing.com> wrote:

> The try_grab_folio() is supposed to be used in fast path and it elevates
> folio refcount by using add ref unless zero.  We are guaranteed to have
> at least one stable reference in slow path, so the simple atomic add
> could be used.  The performance difference should be trivial, but the
> misuse may be confusing and misleading.
> 
> In another thread [1] a kernel warning was reported when pinning folio
> in CMA memory when launching SEV virtual machine.  The splat looks like:
> 
> [  464.325306] WARNING: CPU: 13 PID: 6734 at mm/gup.c:1313 __get_user_pages+0x423/0x520
> [  464.325464] CPU: 13 PID: 6734 Comm: qemu-kvm Kdump: loaded Not tainted 6.6.33+ #6
> [  464.325477] RIP: 0010:__get_user_pages+0x423/0x520
> [  464.325515] Call Trace:
> [  464.325520]  <TASK>
> [  464.325523]  ? __get_user_pages+0x423/0x520
> [  464.325528]  ? __warn+0x81/0x130
> [  464.325536]  ? __get_user_pages+0x423/0x520
> [  464.325541]  ? report_bug+0x171/0x1a0
> [  464.325549]  ? handle_bug+0x3c/0x70
> [  464.325554]  ? exc_invalid_op+0x17/0x70
> [  464.325558]  ? asm_exc_invalid_op+0x1a/0x20
> [  464.325567]  ? __get_user_pages+0x423/0x520
> [  464.325575]  __gup_longterm_locked+0x212/0x7a0
> [  464.325583]  internal_get_user_pages_fast+0xfb/0x190
> [  464.325590]  pin_user_pages_fast+0x47/0x60
> [  464.325598]  sev_pin_memory+0xca/0x170 [kvm_amd]
> [  464.325616]  sev_mem_enc_register_region+0x81/0x130 [kvm_amd]
> 
> ...
>
> Fixes: 57edfcfd3419 ("mm/gup: accelerate thp gup even for "pages != NULL"")
> Cc: <stable@vger.kernel.org> [6.6+]

So we want something against Linus mainline for backporting ease.

>    3. Rebased onto the latest mm-unstable

mm-unstable is quite different - memfd_pin_folios() doesn't exist in
mainline!

So can you please prepare the fix against current -linus?  I'll hang
onto this patch to guide myself when I redo Vivek's "mm/gup: Introduce
memfd_pin_folios() for pinning memfd folios" series on top.



  reply	other threads:[~2024-06-27 22:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-27 22:14 [v2 PATCH] mm: gup: do not call try_grab_folio() in slow path Yang Shi
2024-06-27 22:54 ` Andrew Morton [this message]
2024-06-27 23:02   ` Yang Shi
2024-06-27 23:19 ` Peter Xu
2024-06-27 23:32   ` Andrew Morton
2024-06-27 23:39     ` Yang Shi
2024-06-27 23:43     ` Peter Xu
2024-06-28  1:25       ` Ge Yang
2024-06-28  6:09       ` Ge Yang
2024-06-28  6:35 ` Christoph Hellwig
2024-06-28 18:27   ` Yang Shi

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=20240627155425.a31792e7c4709facfcbd417c@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=vivek.kasireddy@intel.com \
    --cc=yang@os.amperecomputing.com \
    --cc=yangge1116@126.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.