search for: apopple

...e just converted might be able to trigger it. Cc: Karol Herbst <kherbst at redhat.com> Cc: Lyude Paul <lyude at redhat.com> Cc: Danilo Krummrich <dakr at kernel.org> Cc: David Airlie <airlied at gmail.com> Cc: Simona Vetter <simona at ffwll.ch> Cc: Alistair Popple <apopple at nvidia.com> David Hildenbrand (2): nouveau/svm: fix missing folio unlock + put after make_device_exclusive_range() nouveau/svm: don't initialize ret in nouveau_atomic_range_fault() drivers/gpu/drm/nouveau/nouveau_svm.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deleti...

...to warnings such as PAGE_FLAGS_CHECK_AT_FREE due to the page being locked when the refcount drops to zero. Note that during removal of the device exclusive entry the PTE is currently re-checked under the PTL so no futher bad page accesses occur once it is locked. Signed-off-by: Alistair Popple <apopple at nvidia.com> Fixes: b756a3b5e7ea ("mm: device exclusive memory access") Cc: stable at vger.kernel.org --- mm/memory.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/mm/memory.c b/mm/memory.c index 8c8420934d60..b499bd283d8e 100644 --- a/mm/memory....

...aborts if the entry is no longer there. It is also possible the folio has been unmapped, freed and re-allocated allowing 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 com...

This is an initial series of patches to improve channel recovery on Turing GPUs with the goal of improving reliability enough to eventually enable SVM for Turing. It's likely follow up patches will be required to fully address problems with less trivial workloads than what I have been able to test thus far. This series primarily addresses a number of hardware changes to interrupt layout and

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 the refcounts are actually I had stuck with using the page because none of

...the correct one." ? ...well, maybe that's not all that much help. But it does at least provide the traditional description of what the patch *does*, at the end of the commit description. But please treat this as just an optional suggestion. > > Signed-off-by: Alistair Popple <apopple at nvidia.com> > Fixes: b756a3b5e7ea ("mm: device exclusive memory access") > Cc: stable at vger.kernel.org > --- > mm/memory.c | 14 +++++++++++++- > 1 file changed, 13 insertions(+), 1 deletion(-) On the patch process, I see that this applies to linux-stable's 6....

Christoph Hellwig <hch at infradead.org> writes: > s/page/folio/ in the entire commit log? I debated that but settled on leaving it as is because device exclusive entries only deal with non-compound pages for now and didn't want to give any other impression. Happy to change that though if people think it would be better/clearer.

"Zhou, Xianrong" <Xianrong.Zhou at amd.com> writes: > [AMD Official Use Only - General] > >> >>>>> The vmf_insert_pfn_prot could cause unnecessary double faults on a >> >>>>> device pfn. Because currently the vmf_insert_pfn_prot does not >> >>>>> make the pfn writable so the pte entry is normally read-only or