mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: John Hubbard <jhubbard@nvidia.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, Oscar Salvador <osalvador@suse.de>,
	Vivek Kasireddy <vivek.kasireddy@intel.com>,
	Dave Airlie <airlied@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Matthew Wilcox <willy@infradead.org>,
	Christoph Hellwig <hch@infradead.org>,
	Jason Gunthorpe <jgg@nvidia.com>, Peter Xu <peterx@redhat.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Dongwon Kim <dongwon.kim@intel.com>,
	Hugh Dickins <hughd@google.com>,
	Junxiao Chang <junxiao.chang@intel.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH] mm/gup: handle NULL pages in unpin_user_pages()
Date: Tue, 19 Nov 2024 15:33:17 +0100	[thread overview]
Message-ID: <64d5e357-94b5-48b4-b6cf-0a7a578f82ae@redhat.com> (raw)
In-Reply-To: <20241119044923.194853-1-jhubbard@nvidia.com>

On 19.11.24 05:49, John Hubbard wrote:
> The recent addition of "pofs" (pages or folios) handling to gup has a
> flaw: it assumes that unpin_user_pages() handles NULL pages in the
> pages** array. That's not the case, as I discovered when I ran on a new
> configuration on my test machine.
> 
> Fix this by skipping NULL pages in unpin_user_pages(), just like
> unpin_folios() already does.
> 
> Details: when booting on x86 with "numa=fake=2 movablecore=4G" on Linux
> 6.12, and running this:
> 
>      tools/testing/selftests/mm/gup_longterm
> 
> ...I get the following crash:
> 
> BUG: kernel NULL pointer dereference, address: 0000000000000008
> RIP: 0010:sanity_check_pinned_pages+0x3a/0x2d0
> ...
> Call Trace:
>   <TASK>
>   ? __die_body+0x66/0xb0
>   ? page_fault_oops+0x30c/0x3b0
>   ? do_user_addr_fault+0x6c3/0x720
>   ? irqentry_enter+0x34/0x60
>   ? exc_page_fault+0x68/0x100
>   ? asm_exc_page_fault+0x22/0x30
>   ? sanity_check_pinned_pages+0x3a/0x2d0
>   unpin_user_pages+0x24/0xe0
>   check_and_migrate_movable_pages_or_folios+0x455/0x4b0
>   __gup_longterm_locked+0x3bf/0x820
>   ? mmap_read_lock_killable+0x12/0x50
>   ? __pfx_mmap_read_lock_killable+0x10/0x10
>   pin_user_pages+0x66/0xa0
>   gup_test_ioctl+0x358/0xb20
>   __se_sys_ioctl+0x6b/0xc0
>   do_syscall_64+0x7b/0x150
>   entry_SYSCALL_64_after_hwframe+0x76/0x7e
> 
> Fixes: 94efde1d1539 ("mm/gup: avoid an unnecessary allocation call for FOLL_LONGTERM cases")
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Oscar Salvador <osalvador@suse.de>
> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Christoph Hellwig <hch@infradead.org>
> Cc: Jason Gunthorpe <jgg@nvidia.com>
> Cc: Peter Xu <peterx@redhat.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Dongwon Kim <dongwon.kim@intel.com>
> Cc: Hugh Dickins <hughd@google.com>
> Cc: Junxiao Chang <junxiao.chang@intel.com>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
> ---
> 
> Hi,
> 
> I got a nasty shock when I tried out a new test machine setup last
> night--I wish I'd noticed the problem earlier! But anyway, this should
> make it all better...
> 
> I've asked Greg K-H to hold off on including commit 94efde1d1539
> ("mm/gup: avoid an unnecessary allocation call for FOLL_LONGTERM cases")
> in linux-stable (6.11.y), but if this fix-to-the-fix looks good, then
> maybe both fixes can ultimately end up in stable.
> 

Ouch!

> thanks,
> John Hubbard
> 
>   mm/gup.c | 17 +++++++++++++++--
>   1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/gup.c b/mm/gup.c
> index ad0c8922dac3..6e417502728a 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -52,7 +52,12 @@ static inline void sanity_check_pinned_pages(struct page **pages,
>   	 */
>   	for (; npages; npages--, pages++) {
>   		struct page *page = *pages;
> -		struct folio *folio = page_folio(page);
> +		struct folio *folio;
> +
> +		if (!page)
> +			continue;
> +
> +		folio = page_folio(page);
>   
>   		if (is_zero_page(page) ||
>   		    !folio_test_anon(folio))
> @@ -248,9 +253,14 @@ static inline struct folio *gup_folio_range_next(struct page *start,
>   static inline struct folio *gup_folio_next(struct page **list,
>   		unsigned long npages, unsigned long i, unsigned int *ntails)
>   {
> -	struct folio *folio = page_folio(list[i]);
> +	struct folio *folio;
>   	unsigned int nr;
>   
> +	if (!list[i])
> +		return NULL;
> +

I don't particularly enjoy returning NULL here, if we don't teach the 
other users of that function about that possibility. There are two other 
users.

Also: we are not setting "ntails" to 1. I think the callers uses that as 
"nr" to advance npages. So the caller has to make sure to set "nr = 1" 
in case it sees "NULL".

Alternatively ...

> +	folio = page_folio(list[i]);
> +
>   	for (nr = i + 1; nr < npages; nr++) {
>   		if (page_folio(list[nr]) != folio)
>   			break;
> @@ -410,6 +420,9 @@ void unpin_user_pages(struct page **pages, unsigned long npages)
>   	sanity_check_pinned_pages(pages, npages);
>   	for (i = 0; i < npages; i += nr) {

... handle it here

if (!pages[i]) {
	nr = 1;
	continue;
}

No strong opinion. But I think we should either update all callers to 
deal with returning NULL from this function, and set "nr = 1".

-- 
Cheers,

David / dhildenb


  reply	other threads:[~2024-11-19 14:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-19  4:49 John Hubbard
2024-11-19 14:33 ` David Hildenbrand [this message]
2024-11-20  3:28   ` John Hubbard

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=64d5e357-94b5-48b4-b6cf-0a7a578f82ae@redhat.com \
    --to=david@redhat.com \
    --cc=airlied@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dongwon.kim@intel.com \
    --cc=hch@infradead.org \
    --cc=hughd@google.com \
    --cc=jgg@nvidia.com \
    --cc=jhubbard@nvidia.com \
    --cc=junxiao.chang@intel.com \
    --cc=kraxel@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=osalvador@suse.de \
    --cc=peterx@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=vivek.kasireddy@intel.com \
    --cc=willy@infradead.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

all inboxes | Powered by JetHome®