[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yy46KbD/PvhaHA6X@ziepe.ca>
Date: Fri, 23 Sep 2022 19:58:49 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Logan Gunthorpe <logang@...tatee.com>
Cc: linux-kernel@...r.kernel.org, linux-nvme@...ts.infradead.org,
linux-block@...r.kernel.org, linux-pci@...r.kernel.org,
linux-mm@...ck.org, Christoph Hellwig <hch@....de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Dan Williams <dan.j.williams@...el.com>,
Christian König <christian.koenig@....com>,
John Hubbard <jhubbard@...dia.com>,
Don Dutile <ddutile@...hat.com>,
Matthew Wilcox <willy@...radead.org>,
Daniel Vetter <daniel.vetter@...ll.ch>,
Minturn Dave B <dave.b.minturn@...el.com>,
Jason Ekstrand <jason@...kstrand.net>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Xiong Jianxin <jianxin.xiong@...el.com>,
Bjorn Helgaas <helgaas@...nel.org>,
Ira Weiny <ira.weiny@...el.com>,
Robin Murphy <robin.murphy@....com>,
Martin Oliveira <martin.oliveira@...eticom.com>,
Chaitanya Kulkarni <ckulkarnilinux@...il.com>,
Ralph Campbell <rcampbell@...dia.com>,
Stephen Bates <sbates@...thlin.com>
Subject: Re: [PATCH v10 1/8] mm: introduce FOLL_PCI_P2PDMA to gate getting
PCI P2PDMA pages
On Fri, Sep 23, 2022 at 02:11:03PM -0600, Logan Gunthorpe wrote:
>
>
> On 2022-09-23 13:53, Jason Gunthorpe wrote:
> > On Fri, Sep 23, 2022 at 01:08:31PM -0600, Logan Gunthorpe wrote:
> > I'm encouraging Dan to work on better infrastructure in pgmap core
> > because every pgmap implementation has this issue currently.
> >
> > For that reason it is probably not so relavent to this series.
> >
> > Perhaps just clarify in the commit message that the FOLL_LONGTERM
> > restriction is to copy DAX until the pgmap page refcounts are fixed.
>
> Ok, I'll add that note.
>
> Per the fix for the try_grab_page(), to me it doesn't fit well in
> try_grab_page() without doing a bunch of cleanup to change the
> error handling, and the same would have to be added to try_grab_folio().
> So I think it's better to leave it where it was, but move it below the
> respective grab calls. Does the incremental patch below look correct?
Oh? I was thinking of just a very simple thing:
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -225,6 +225,11 @@ bool __must_check try_grab_page(struct page *page, unsigned int flags)
node_stat_mod_folio(folio, NR_FOLL_PIN_ACQUIRED, 1);
}
+ if (unlikely(!(flags & FOLL_PCI_P2PDMA) && is_pci_p2pdma_page(page))) {
+ gup_put_folio(page_folio(page), 1, flags);
+ return false;
+ }
+
return true;
}
> I am confused about what happens if neither FOLL_PIN or FOLL_GET
> are set (which the documentation for try_grab_x() says is possible, but
> other documentation suggests that FOLL_GET is automatically set).
> In which case it'd be impossible to do the check if we can't
> access the page.
try_grab_page is operating under the PTL so it can probably touch the
page OK (though perhaps we don't need to even check anything)
try_grab_folio cannot be called without PIN/GET, so like this perhaps:
@@ -123,11 +123,14 @@ static inline struct folio *try_get_folio(struct page *page, int refs)
*/
struct folio *try_grab_folio(struct page *page, int refs, unsigned int flags)
{
+ struct folio *folio;
+
+ if (WARN_ON((flags & (FOLL_GET | FOLL_PIN)) == 0))
+ return NULL;
+
if (flags & FOLL_GET)
- return try_get_folio(page, refs);
+ folio = try_get_folio(page, refs);
else if (flags & FOLL_PIN) {
- struct folio *folio;
-
/*
* Can't do FOLL_LONGTERM + FOLL_PIN gup fast path if not in a
* right zone, so fail and let the caller fall back to the slow
@@ -160,11 +163,14 @@ struct folio *try_grab_folio(struct page *page, int refs, unsigned int flags)
refs * (GUP_PIN_COUNTING_BIAS - 1));
node_stat_mod_folio(folio, NR_FOLL_PIN_ACQUIRED, refs);
- return folio;
}
- WARN_ON_ONCE(1);
- return NULL;
+ if (unlikely(!(flags & FOLL_PCI_P2PDMA) && is_pci_p2pdma_page(page))) {
+ gup_put_folio(page, 1, flags);
+ return NULL;
+ }
+
+ return folio;
}
Jason
Powered by blists - more mailing lists