Commit a8f80f53 authored by John Hubbard's avatar John Hubbard Committed by Linus Torvalds

mm/gup: update pin_user_pages.rst for "case 3" (mmu notifiers)

Update case 3 so that it covers the use of mmu notifiers, for hardware
that does, or does not have replayable page faults.

Also, elaborate case 4 slightly, as it was quite cryptic.
Signed-off-by: default avatarJohn Hubbard <jhubbard@nvidia.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Jérôme Glisse <jglisse@redhat.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Jan Kara <jack@suse.cz>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Link: http://lkml.kernel.org/r/20200527194953.11130-1-jhubbard@nvidia.comSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
parent dadbb612
...@@ -148,23 +148,28 @@ NOTE: Some pages, such as DAX pages, cannot be pinned with longterm pins. That's ...@@ -148,23 +148,28 @@ NOTE: Some pages, such as DAX pages, cannot be pinned with longterm pins. That's
because DAX pages do not have a separate page cache, and so "pinning" implies because DAX pages do not have a separate page cache, and so "pinning" implies
locking down file system blocks, which is not (yet) supported in that way. locking down file system blocks, which is not (yet) supported in that way.
CASE 3: Hardware with page faulting support CASE 3: MMU notifier registration, with or without page faulting hardware
------------------------------------------- -------------------------------------------------------------------------
Here, a well-written driver doesn't normally need to pin pages at all. However, Device drivers can pin pages via get_user_pages*(), and register for mmu
if the driver does choose to do so, it can register MMU notifiers for the range, notifier callbacks for the memory range. Then, upon receiving a notifier
and will be called back upon invalidation. Either way (avoiding page pinning, or "invalidate range" callback , stop the device from using the range, and unpin
using MMU notifiers to unpin upon request), there is proper synchronization with the pages. There may be other possible schemes, such as for example explicitly
both filesystem and mm (page_mkclean(), munmap(), etc). synchronizing against pending IO, that accomplish approximately the same thing.
Therefore, neither flag needs to be set. Or, if the hardware supports replayable page faults, then the device driver can
avoid pinning entirely (this is ideal), as follows: register for mmu notifier
In this case, ideally, neither get_user_pages() nor pin_user_pages() should be callbacks as above, but instead of stopping the device and unpinning in the
called. Instead, the software should be written so that it does not pin pages. callback, simply remove the range from the device's page tables.
This allows mm and filesystems to operate more efficiently and reliably.
Either way, as long as the driver unpins the pages upon mmu notifier callback,
then there is proper synchronization with both filesystem and mm
(page_mkclean(), munmap(), etc). Therefore, neither flag needs to be set.
CASE 4: Pinning for struct page manipulation only CASE 4: Pinning for struct page manipulation only
------------------------------------------------- -------------------------------------------------
Here, normal GUP calls are sufficient, so neither flag needs to be set. If only struct page data (as opposed to the actual memory contents that a page
is tracking) is affected, then normal GUP calls are sufficient, and neither flag
needs to be set.
page_maybe_dma_pinned(): the whole point of pinning page_maybe_dma_pinned(): the whole point of pinning
=================================================== ===================================================
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment