GitHub-Mirror/Star64_linux
2
0
Fork 0
mirror of https://github.com/Fishwaldo/Star64_linux.git synced 2025-06-22 22:51:37 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

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

Browse source 
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: John Hubbard <jhubbard@nvidia.com>
Signed-off-by: Andrew 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.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
John Hubbard 2020-06-07 21:40:59 -07:00 • committed by Linus Torvalds
parent dadbb612f6
commit a8f80f53fb
1 changed files with 17 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

29
Documentation/core-api/pin_user_pages.rst
View file

@ -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
callbacks as above, but instead of stopping the device and unpinning in the
callback, simply remove the range from the device's page tables.
In this case, ideally, neither get_user_pages() nor pin_user_pages() should be Either way, as long as the driver unpins the pages upon mmu notifier callback,
called. Instead, the software should be written so that it does not pin pages. then there is proper synchronization with both filesystem and mm
This allows mm and filesystems to operate more efficiently and reliably. (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
=================================================== ===================================================