similar to: [PATCH v2 0/2] vhost, docs: convert to pin_user_pages(), new "case 5"

Hi, It recently became clear to me that there are some get_user_pages*() callers that don't fit neatly into any of the four cases that are so far listed in pin_user_pages.rst. vhost.c is one of those. Add a Case 5 to the documentation, and refer to that when converting vhost.c. Thanks to Jan Kara for helping me (again) in understanding the interaction between get_user_pages() and page

On Sat, May 30, 2020 at 5:13 AM John Hubbard <jhubbard at 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

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

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

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

This code was using get_user_pages*(), in approximately a "Case 5" scenario (accessing the data within a page), using the categorization from [1]. That means that it's time to convert the get_user_pages*() + put_page() calls to pin_user_pages*() + unpin_user_pages() calls. There is some helpful background in [2]: basically, this is a small part of fixing a long-standing disconnect

From: John Hubbard <jhubbard at nvidia.com> Hi, This is mostly Jerome's work, converting the block/bio and related areas to call put_user_page*() instead of put_page(). Because I've changed Jerome's patches, in some cases significantly, I'd like to get his feedback before we actually leave him listed as the author (he might want to disown some or all of these). I added a

From: John Hubbard <jhubbard at nvidia.com> Hi, This is mostly Jerome's work, converting the block/bio and related areas to call put_user_page*() instead of put_page(). Because I've changed Jerome's patches, in some cases significantly, I'd like to get his feedback before we actually leave him listed as the author (he might want to disown some or all of these). I added a

From: John Hubbard <jhubbard at nvidia.com> In commit d241a95f3514 ("block: optionally mark pages dirty in bio_release_pages"), new "bool mark_dirty" argument was added to bio_release_pages. In upcoming work, another bool argument (to indicate that the pages came from get_user_pages) is going to be added. That's one bool too many, because it's not desirable have

Pinned pages are not properly accounted particularly when mapping error occurs on IOTLB update. Clean up dangling pinned pages for the error path. As the inflight pinned pages, specifically for memory region that strides across multiple chunks, would need more than one free page for book keeping and accounting. For simplicity, pin pages for all memory in the IOVA range in one go rather than have

Pinned pages are not properly accounted particularly when mapping error occurs on IOTLB update. Clean up dangling pinned pages for the error path. As the inflight pinned pages, specifically for memory region that strides across multiple chunks, would need more than one free page for book keeping and accounting. For simplicity, pin pages for all memory in the IOVA range in one go rather than have

On 2020-06-22 16:38, Ralph Campbell wrote: > The patch to add zero page migration to GPU memory inadvertantly included inadvertently > part of a future change which broke normal page migration to GPU memory > by copying too much data and corrupting GPU memory. > Fix this by only copying one page instead of a byte count. > > Fixes: 9d4296a7d4b3 ("drm/nouveau/nouveau/hmm:

On 8/2/18 12:51 PM, Gustavo A. R. Silva wrote: > Hi all, > > Friendly ping! Who can take this? > > Thanks > -- > Gustavo > > On 07/24/2018 08:27 AM, Gustavo A. R. Silva wrote: >> In case memory resources for *bl_desc* were allocated, release >> them before return. >> >> Addresses-Coverity-ID: 1472021 ("Resource leak") >> Fixes:

On Mon, Feb 06, 2023 at 07:00:35AM +0000, Arseniy Krasnov wrote: >This adds main logic of MSG_ZEROCOPY flag processing for packet >creation. When this flag is set and user's iov iterator fits for >zerocopy transmission, call 'get_user_pages()' and add returned >pages to the newly created skb. > >Signed-off-by: Arseniy Krasnov <AVKrasnov at sberdevices.ru>

On 2020/10/30 ??3:45, Si-Wei Liu wrote: > This reverts commit 7ed9e3d97c32d969caded2dfb6e67c1a2cc5a0b1. > > Signed-off-by: Si-Wei Liu <si-wei.liu at oracle.com> > --- > drivers/vhost/vdpa.c | 119 +++++++++++++++++++++------------------------------ > 1 file changed, 48 insertions(+), 71 deletions(-) I saw this has been reverted there

On Mon, 27 Mar 2023 23:25:49 -0700 John Hubbard <jhubbard at nvidia.com> wrote: > On the patch process, I see that this applies to linux-stable's 6.1.y > branch. I'd suggest two things: > > 1) Normally, what I've seen done is to post against either the current > top of tree linux.git, or else against one of the mm-stable branches. > And then after it's

On Wed, Feb 15, 2023 at 01:15:55PM +0800, Longpeng (Mike, Cloud Infrastructure Service Product Dept.) wrote: > > > ? 2023/2/15 10:56, Jason Wang ??: > > On Wed, Feb 15, 2023 at 10:49 AM Longpeng (Mike, Cloud Infrastructure > > Service Product Dept.) <longpeng2 at huawei.com> wrote: > > > > > > > > > > > > ? 2023/2/15 10:00, Jason

In nouveau_dmem_pages_alloc(), the drm->dmem->mutex is unlocked before calling nouveau_dmem_chunk_alloc(). Reacquire the lock before continuing to the next page. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> --- I found this while testing Jason Gunthorpe's hmm tree but this is independant of those changes. I guess it could go through David Airlie's tree for nouveau

On Mon, Jun 22, 2020 at 4:02 PM John Hubbard <jhubbard at nvidia.com> wrote: > > On 2020-06-22 15:33, Yang Shi wrote: > > On Mon, Jun 22, 2020 at 3:30 PM Yang Shi <shy828301 at gmail.com> wrote: > >> On Mon, Jun 22, 2020 at 2:53 PM Zi Yan <ziy at nvidia.com> wrote: > >>> On 22 Jun 2020, at 17:31, Ralph Campbell wrote: > >>>> On

On 7/23/19 11:17 PM, Christoph Hellwig wrote: > On Tue, Jul 23, 2019 at 09:25:06PM -0700, john.hubbard at gmail.com wrote: >> * Store, in the iov_iter, a "came from gup (get_user_pages)" parameter. >> Then, use the new iov_iter_get_pages_use_gup() to retrieve it when >> it is time to release the pages. That allows choosing between put_page() >> and