From: John Hubbard <jhubbard@nvidia.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
Peter Xu <peterx@redhat.com>
Cc: Linux MM Mailing List <linux-mm@kvack.org>,
Jason Gunthorpe <jgg@nvidia.com>, Jan Kara <jack@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: Possible race with page_maybe_dma_pinned?
Date: Wed, 29 Sep 2021 18:57:33 -0700 [thread overview]
Message-ID: <9636a101-4445-0ede-e3ad-4cecd531f433@nvidia.com> (raw)
In-Reply-To: <CAHk-=wjdiXyXFukBUwLKdSXRrwTzyRnynLFvJUe1BM4D6wBvsw@mail.gmail.com>
On 9/29/21 15:47, Linus Torvalds wrote:
> On Wed, Sep 29, 2021 at 12:57 PM Peter Xu <peterx@redhat.com> wrote:
>>
>> Now we have 3 callers of page_maybe_dma_pinned():
>>
>> 1. page_needs_cow_for_dma
>> 2. pte_is_pinned
>> 3. shrink_page_list
>>
>> The 1st one is good as it takes the seqlock for write properly. The 2nd & 3rd
>> are missing, we may need to add them.
>
> Well, the pte_is_pinned() case at least could do the seqlock in
> clear_soft_dirty() - it has the vma and mm available.
That part seems straightforward, OK.
>
> The page shrinker has always been problematic since it doesn't have
> the vm (and by "always" I mean "modern times" - long ago we used to
> scan virtually, in the days before rmap)
>
> One option might be for fast-gup to give up on locked pages. I think
> the page lock is the only thing that shrink_page_list() serializes
> with.
>
In order to avoid locked pages in gup fast, it is easiest to do a
check for locked pages *after* fast-pinning them, and unpin them before
returning to the caller. This makes the change much smaller.
However, doing so leaves a window of time during which the pages are
still marked as maybe-dma-pinned, although those pages are never
returned to the caller as such. There is already code that is subject to
this in lockless_pages_from_mm(), for the case of a failed seqlock read.
I'm thinking it's probably OK, because the pages are not going to be
held long-term. They will be unpinned before returning from
lockless_pages_from_mm().
The counter argument is that this is merely making the race window
smaller, which is usually something that I argue against because it just
leads to harder-to-find bugs...
To be specific, here's what I mean:
diff --git a/mm/gup.c b/mm/gup.c
index 886d6148d3d03..8ba871a927668 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2657,6 +2657,7 @@ static unsigned long lockless_pages_from_mm(unsigned long start,
{
unsigned long flags;
int nr_pinned = 0;
+ int i;
unsigned seq;
if (!IS_ENABLED(CONFIG_HAVE_FAST_GUP) ||
@@ -2693,7 +2694,23 @@ static unsigned long lockless_pages_from_mm(unsigned long start,
unpin_user_pages(pages, nr_pinned);
return 0;
}
+
+ /*
+ * Avoiding locked pages, in this fast/lockless context, will
+ * avoid interfering with shrink_page_list(), in particular.
+ * Give up upon finding the first locked page, but keep the
+ * earlier pages, so that slow gup does not have to re-pin them.
+ */
+ for (i = 0; i < nr_pinned; i++) {
+ if (PageLocked(pages[i])) {
+ unpin_user_pages(&pages[i], nr_pinned - i);
+ nr_pinned = i + 1;
+ break;
+ }
+ }
}
+
+
return nr_pinned;
}
thanks,
--
John Hubbard
NVIDIA
next prev parent reply other threads:[~2021-09-30 1:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-29 19:57 Possible race with page_maybe_dma_pinned? Peter Xu
2021-09-29 22:47 ` Linus Torvalds
2021-09-30 1:57 ` John Hubbard [this message]
2021-09-30 11:11 ` Jan Kara
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=9636a101-4445-0ede-e3ad-4cecd531f433@nvidia.com \
--to=jhubbard@nvidia.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--cc=jgg@nvidia.com \
--cc=linux-mm@kvack.org \
--cc=peterx@redhat.com \
--cc=torvalds@linux-foundation.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 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.