| Message ID | 20200529234309.484480-2-jhubbard@nvidia.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | vhost, docs: convert to pin_user_pages(), new "case 5" | expand |
On Sat, May 30, 2020 at 5:13 AM John Hubbard <jhubbard@nvidia.com> wrote: > > There are four cases listed in pin_user_pages.rst. These are > intended to help developers figure out whether to use > get_user_pages*(), or pin_user_pages*(). However, the four cases > do not cover all the situations. For example, drivers/vhost/vhost.c > has a "pin, write to page, set page dirty, unpin" case. > > Add a fifth case, to help explain that there is a general pattern > that requires pin_user_pages*() API calls. > > Cc: Vlastimil Babka <vbabka@suse.cz> > Cc: Jan Kara <jack@suse.cz> > Cc: Jérôme Glisse <jglisse@redhat.com> > Cc: Dave Chinner <david@fromorbit.com> > Cc: Jonathan Corbet <corbet@lwn.net> > Cc: linux-doc@vger.kernel.org > Cc: linux-fsdevel@vger.kernel.org > Signed-off-by: John Hubbard <jhubbard@nvidia.com> > --- > Documentation/core-api/pin_user_pages.rst | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/Documentation/core-api/pin_user_pages.rst b/Documentation/core-api/pin_user_pages.rst > index 4675b04e8829..b9f2688a2c67 100644 > --- a/Documentation/core-api/pin_user_pages.rst > +++ b/Documentation/core-api/pin_user_pages.rst > @@ -171,6 +171,26 @@ 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. > > +CASE 5: Pinning in order to write to the data within the page > +------------------------------------------------------------- > +Even though neither DMA nor Direct IO is involved, just a simple case of "pin, > +access page's data, unpin" can cause a problem. Will it be, *"pin, access page's data, set page dirty, unpin" * ? Case 5 may be considered a > +superset of Case 1, plus Case 2, plus anything that invokes that pattern. In > +other words, if the code is neither Case 1 nor Case 2, it may still require > +FOLL_PIN, for patterns like this: > + > +Correct (uses FOLL_PIN calls): > + pin_user_pages() > + access the data within the pages > + set_page_dirty_lock() > + unpin_user_pages() > + > +INCORRECT (uses FOLL_GET calls): > + get_user_pages() > + access the data within the pages > + set_page_dirty_lock() > + put_page() > + > page_maybe_dma_pinned(): the whole point of pinning > =================================================== > > -- > 2.26.2 >
On 2020-05-31 00:11, Souptick Joarder wrote: ... >> diff --git a/Documentation/core-api/pin_user_pages.rst b/Documentation/core-api/pin_user_pages.rst >> index 4675b04e8829..b9f2688a2c67 100644 >> --- a/Documentation/core-api/pin_user_pages.rst >> +++ b/Documentation/core-api/pin_user_pages.rst >> @@ -171,6 +171,26 @@ 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. >> >> +CASE 5: Pinning in order to write to the data within the page >> +------------------------------------------------------------- >> +Even though neither DMA nor Direct IO is involved, just a simple case of "pin, >> +access page's data, unpin" can cause a problem. > > Will it be, *"pin, access page's data, set page dirty, unpin" * ? Well...the problem can show up with just accessing (writing) the data. But it is true that this statement is a little different from the patterns below, which is confusing. I'll delete set_page_dirty() from each of them, in order to avoid confusing things. (Although each is correct.) And I'll also change the above to "pin, write to a page's data, upin". set_page_dirty() interactions are really just extra credit here. :) And fully read-only situations won't cause a problem. > > Case 5 may be considered a >> +superset of Case 1, plus Case 2, plus anything that invokes that pattern. In >> +other words, if the code is neither Case 1 nor Case 2, it may still require >> +FOLL_PIN, for patterns like this: >> + >> +Correct (uses FOLL_PIN calls): >> + pin_user_pages() >> + access the data within the pages >> + set_page_dirty_lock() >> + unpin_user_pages() >> + >> +INCORRECT (uses FOLL_GET calls): >> + get_user_pages() >> + access the data within the pages >> + set_page_dirty_lock() >> + put_page() >> + I'll send a v2 shortly. thanks,
On Fri, May 29, 2020 at 04:43:08PM -0700, John Hubbard wrote: > +CASE 5: Pinning in order to write to the data within the page > +------------------------------------------------------------- > +Even though neither DMA nor Direct IO is involved, just a simple case of "pin, > +access page's data, unpin" can cause a problem. Case 5 may be considered a > +superset of Case 1, plus Case 2, plus anything that invokes that pattern. In > +other words, if the code is neither Case 1 nor Case 2, it may still require > +FOLL_PIN, for patterns like this: > + > +Correct (uses FOLL_PIN calls): > + pin_user_pages() > + access the data within the pages > + set_page_dirty_lock() > + unpin_user_pages() > + > +INCORRECT (uses FOLL_GET calls): > + get_user_pages() > + access the data within the pages > + set_page_dirty_lock() > + put_page() Why does this case need to pin? Why can't it just do ... get_user_pages() lock_page(page); ... modify the data ... set_page_dirty(page); unlock_page(page);
On 2020-06-12 12:24, Matthew Wilcox wrote: > On Fri, May 29, 2020 at 04:43:08PM -0700, John Hubbard wrote: >> +CASE 5: Pinning in order to write to the data within the page >> +------------------------------------------------------------- >> +Even though neither DMA nor Direct IO is involved, just a simple case of "pin, >> +access page's data, unpin" can cause a problem. Case 5 may be considered a >> +superset of Case 1, plus Case 2, plus anything that invokes that pattern. In >> +other words, if the code is neither Case 1 nor Case 2, it may still require >> +FOLL_PIN, for patterns like this: >> + >> +Correct (uses FOLL_PIN calls): >> + pin_user_pages() >> + access the data within the pages >> + set_page_dirty_lock() >> + unpin_user_pages() >> + >> +INCORRECT (uses FOLL_GET calls): >> + get_user_pages() >> + access the data within the pages >> + set_page_dirty_lock() >> + put_page() > > Why does this case need to pin? Why can't it just do ... > > get_user_pages() > lock_page(page); > ... modify the data ... > set_page_dirty(page); > unlock_page(page); > Yes, it could do that. And that would also make a good additional "correct" example. Especially for the case of just dealing with a single page, lock_page() has the benefit of completely fixing the problem *today*, without waiting for the pin_user_pages*() handling improvements to get implemented. And it's also another (probably better) way to fix the vhost.c problem, than commit 690623e1b496 ("vhost: convert get_user_pages() --> pin_user_pages()"). I'm inclined to leave vhost.c alone for now, unless someone really prefers it to be changed, but to update the Case 5 documentation with your point above. Sound about right? thanks,
diff --git a/Documentation/core-api/pin_user_pages.rst b/Documentation/core-api/pin_user_pages.rst index 4675b04e8829..b9f2688a2c67 100644 --- a/Documentation/core-api/pin_user_pages.rst +++ b/Documentation/core-api/pin_user_pages.rst @@ -171,6 +171,26 @@ 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. +CASE 5: Pinning in order to write to the data within the page +------------------------------------------------------------- +Even though neither DMA nor Direct IO is involved, just a simple case of "pin, +access page's data, unpin" can cause a problem. Case 5 may be considered a +superset of Case 1, plus Case 2, plus anything that invokes that pattern. In +other words, if the code is neither Case 1 nor Case 2, it may still require +FOLL_PIN, for patterns like this: + +Correct (uses FOLL_PIN calls): + pin_user_pages() + access the data within the pages + set_page_dirty_lock() + unpin_user_pages() + +INCORRECT (uses FOLL_GET calls): + get_user_pages() + access the data within the pages + set_page_dirty_lock() + put_page() + page_maybe_dma_pinned(): the whole point of pinning ===================================================
There are four cases listed in pin_user_pages.rst. These are intended to help developers figure out whether to use get_user_pages*(), or pin_user_pages*(). However, the four cases do not cover all the situations. For example, drivers/vhost/vhost.c has a "pin, write to page, set page dirty, unpin" case. Add a fifth case, to help explain that there is a general pattern that requires pin_user_pages*() API calls. Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Jan Kara <jack@suse.cz> Cc: Jérôme Glisse <jglisse@redhat.com> Cc: Dave Chinner <david@fromorbit.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-doc@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Signed-off-by: John Hubbard <jhubbard@nvidia.com> --- Documentation/core-api/pin_user_pages.rst | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)