All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: John Hubbard <jhubbard@nvidia.com>
Cc: "Peter Xu" <peterx@redhat.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Andrea Arcangeli" <aarcange@redhat.com>,
	"Jan Kara" <jack@suse.cz>, "Jérôme Glisse" <jglisse@redhat.com>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	"Alex Williamson" <alex.williamson@redhat.com>
Subject: Re: [PATCH] mm: Fix invalid page pointer returned with FOLL_PIN gups
Date: Wed, 26 Jan 2022 20:42:06 -0400	[thread overview]
Message-ID: <20220127004206.GP8034@ziepe.ca> (raw)
In-Reply-To: <f5400544-f602-0bb4-5cb1-5ac682e41974@nvidia.com>

On Wed, Jan 26, 2022 at 04:15:02PM -0800, John Hubbard wrote:

> > We had that -EEXIST logic since commit 1027e4436b6a ("mm: make GUP handle pfn
> > mapping unless FOLL_GET is requested") which seems very reasonable.  It could
> > be that when we reworked GUP with FOLL_PIN we could have overlooked that
> > special path in commit 3faa52c03f44 ("mm/gup: track FOLL_PIN pages"), even if
> > that commit rightfully touched up follow_devmap_pud() on checking FOLL_PIN when
> > it needs to return an -EEXIST.

It sounds like this commit was all about changing the behavior of
follow_page()

It feels like that is another ill-fated holdover from the effort to
make pageless DAX that doesn't exist anymore.

Can we safely drop it now?

Regardless..

> > diff --git a/mm/gup.c b/mm/gup.c
> > index f0af462ac1e2..8ebc04058e97 100644
> > +++ b/mm/gup.c
> > @@ -440,7 +440,7 @@ static int follow_pfn_pte(struct vm_area_struct *vma, unsigned long address,
> >   		pte_t *pte, unsigned int flags)
> >   {
> >   	/* No page to get reference */
> > -	if (flags & FOLL_GET)
> > +	if (flags & (FOLL_GET | FOLL_PIN))
> >   		return -EFAULT;
> 
> Yes. This clearly fixes the problem that the patch describes, and also
> clearly matches up with the Fixes tag. So that's correct.

It is a really confusing though, why not just always return -EEXIST
here?

The caller will always see the error code and refrain from trying to
pin it and unwind upwards, just the same as -EFAULT. 

We shouldn't need to test the flags at this point at all.

> >   	if (flags & FOLL_TOUCH) {
> > @@ -1181,7 +1181,13 @@ static long __get_user_pages(struct mm_struct *mm,
> >   			/*
> >   			 * Proper page table entry exists, but no corresponding
> >   			 * struct page.
> > +			 *
> > +			 * Warn if we jumped over even with a valid **pages.
> > +			 * It shouldn't trigger in practise, but when there's
> > +			 * buggy returns on -EEXIST we'll warn before returning
> > +			 * an invalid page pointer in the array.
> >   			 */
> > +			WARN_ON_ONCE(pages);
> 
> Here, however, I think we need to consider this a little more carefully,
> and attempt to actually fix up this case. It is never going to be OK
> here, to return a **pages array that has these little landmines of
> potentially uninitialized pointers. And so continuing on *at all* seems
> very wrong.

Indeed, it should just be like this:

@@ -1182,6 +1182,10 @@ static long __get_user_pages(struct mm_struct *mm,
                         * Proper page table entry exists, but no corresponding
                         * struct page.
                         */
+                       if (pages) {
+                               page = ERR_PTR(-EFAULT);
+                               goto out;
+                       }
                        goto next_page;
                } else if (IS_ERR(page)) {
                        ret = PTR_ERR(page);

Jason


  reply	other threads:[~2022-01-27  0:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-25  3:37 [PATCH] mm: Fix invalid page pointer returned with FOLL_PIN gups Peter Xu
2022-01-27  0:15 ` John Hubbard
2022-01-27  0:42   ` Jason Gunthorpe [this message]
2022-01-27  9:19     ` Peter Xu
2022-01-27 15:25       ` Jason Gunthorpe
2022-01-28  1:36         ` Peter Xu
2022-01-28  2:31           ` Jason Gunthorpe
2022-01-28  3:26             ` Peter Xu
2022-01-28  5:57               ` John Hubbard
2022-01-28  6:15                 ` Peter Xu
2022-01-28 14:12               ` Jason Gunthorpe
2022-01-28  2:32           ` John Hubbard
2022-01-28  3:30             ` Peter Xu

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=20220127004206.GP8034@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.williamson@redhat.com \
    --cc=jack@suse.cz \
    --cc=jglisse@redhat.com \
    --cc=jhubbard@nvidia.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.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.