search for: jhubbard

...b!\n"); >> + kfree(bl_desc); >> return -EINVAL; >> } >> >> Hi Gustavo, Seeing as how I've been working on this corner of Nouveau lately (don't ask, haha), I reviewed and also tested this. It looks good, you can add: Reviewed-by: John Hubbard <jhubbard at nvidia.com> thanks, -- John Hubbard NVIDIA

...worth of byte count, but this fix looks accurate to me. It's better for maintenance, too, because the function never intends to migrate "some number of bytes". It intends to migrate exactly one page. Hope I'm not missing something fundamental, but: Reviewed-by: John Hubbard <jhubbard at nvidia.com thanks, -- John Hubbard NVIDIA

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 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 br...

...the interaction between get_user_pages() and page writeback [2]. Note that I have only compile-tested the vhost.c patch, although that does also include cross-compiling for a few other arches. Any run-time testing would be greatly appreciated. [1] https://lore.kernel.org/r/20200527194953.11130-1-jhubbard at nvidia.com [2] https://lore.kernel.org/r/20200529070343.GL14550 at quack2.suse.cz John Hubbard (2): docs: mm/gup: pin_user_pages.rst: add a "case 5" vhost: convert get_user_pages() --> pin_user_pages() Documentation/core-api/pin_user_pages.rst | 18 ++++++++++++++++++ drivers...

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 th...

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 th...

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 add...

On Fri, Sep 7, 2018 at 8:02 PM, John Hubbard <jhubbard at nvidia.com> wrote: > 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 re...

...ago, and if we ever grow a consumer of the > MEMORY_DEVICE_PUBLIC infrastructure it can easily use devm_memremap_pages > directly. > > Signed-off-by: Christoph Hellwig <hch at lst.de> > Reviewed-by: Jason Gunthorpe <jgg at mellanox.com> > Reviewed-by: John Hubbard <jhubbard at nvidia.com> > Acked-by: Michal Hocko <mhocko at suse.com> > --- > include/linux/hmm.h | 3 --- > mm/hmm.c | 50 --------------------------------------------- > 2 files changed, 53 deletions(-) This should be squashed to the new earlier patch? Jason

On Tue, 23 Jun 2020 at 10:51, John Hubbard <jhubbard at nvidia.com> wrote: > > 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 m...

John Hubbard <jhubbard at nvidia.com> writes: > On 3/28/23 20:16, Matthew Wilcox wrote: > ... >>> + if (!get_page_unless_zero(vmf->page)) >>> + return 0; >> From a folio point of view: what the hell are you doing here? Tail >> pages don't have individual refcounts; all th...

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 &...

..."some people" (people like me) from having to guess, if they want to apply the patch locally and poke around at it. Anyway, all of the above are just little documentation and process suggestions, but the patch itself looks great, so please feel free to add: Reviewed-by: John Hubbard <jhubbard at nvidia.com> thanks, -- John Hubbard NVIDIA > > diff --git a/mm/memory.c b/mm/memory.c > index 8c8420934d60..b499bd283d8e 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -3623,8 +3623,19 @@ static vm_fault_t remove_device_exclusive_entry(struct vm_fault *vmf) >...

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 Ca...

...return ret; >> } >> + mutex_lock(&drm->dmem->mutex); >> continue; >> } >> >> > > The above comment is about pre-existing potential problems, but your patch itself > looks correct, so: > > Reviewed-by: John Hubbard <jhubbard at nvidia.com> > > > thanks, > The crash was the NULL pointer bug in Christoph's patch #10. I sent a separate reply for that. Below is the console output I got, then I made the changes just based on code inspection. Do you think I should include it in the change log? As for...

...jgg at mellanox.com> > --- > include/linux/mmu_notifier.h | 46 +++++++++++++----------------------- > mm/mmu_notifier.c | 13 ++++++++++ > 2 files changed, 30 insertions(+), 29 deletions(-) > Because this is correct as-is, you can add: Reviewed-by: John Hubbard <jhubbard at nvidia.com> ...whether or not you take the following recommendation, which is: you've only done part of the job of making struct mmu_notifier_mm private to mmu_notifier.c. There's more: * struct mmu_notifier_mm is referred to in two places now: mm_types.h and (still) mmu_notifie...

...owing a reference to be taken on an unrelated folio. This case is also detected by the PTE check and the folio is unlocked without further changes. Signed-off-by: Alistair Popple <apopple at nvidia.com> Reviewed-by: Ralph Campbell <rcampbell at nvidia.com> Reviewed-by: John Hubbard <jhubbard at nvidia.com> Fixes: b756a3b5e7ea ("mm: device exclusive memory access") Cc: stable at vger.kernel.org --- Changes for v2: - Rebased to Linus master - Reworded commit message - Switched to using folios (thanks Matthew!) - Added Reviewed-by's --- mm/memory.c | 16 ++++++++++...

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

...ges array either. > + return 0; > return ret; > } > + mutex_lock(&drm->dmem->mutex); > continue; > } > > The above comment is about pre-existing potential problems, but your patch itself looks correct, so: Reviewed-by: John Hubbard <jhubbard at nvidia.com> thanks, -- John Hubbard NVIDIA