similar to: [PATCH] mm: Take a page reference when removing device exclusive entries

Device exclusive page table entries are used to prevent CPU access to a page whilst it is being accessed from a device. Typically this is used to implement atomic operations when the underlying bus does not support atomic access. When a CPU thread encounters a device exclusive entry it locks the page and restores the original entry after calling mmu notifiers to signal drivers that exclusive

On Tue, Mar 28, 2023 at 01:14:34PM +1100, Alistair Popple wrote: > +++ b/mm/memory.c > @@ -3623,8 +3623,19 @@ static vm_fault_t remove_device_exclusive_entry(struct vm_fault *vmf) > struct vm_area_struct *vma = vmf->vma; > struct mmu_notifier_range range; > > - if (!folio_lock_or_retry(folio, vma->vm_mm, vmf->flags)) > + /* > + * We need a page reference to

On 3/27/23 19:14, Alistair Popple wrote: > Device exclusive page table entries are used to prevent CPU access to > a page whilst it is being accessed from a device. Typically this is > used to implement atomic operations when the underlying bus does not > support atomic access. When a CPU thread encounters a device exclusive > entry it locks the page and restores the original entry

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

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 ohh, and I really should have caught that too. I plead spending too much time recently in a somewhat more driver-centric

"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

*** BLURB HERE *** Bean Huo (5): fs/buffer: clean up block_commit_write fs/buffer.c: convert block_commit_write to return void ext4: No need to check return value of block_commit_write() fs/ocfs2: No need to check return value of block_commit_write() udf: No need to check return value of block_commit_write() fs/buffer.c | 24 +++++++-----------------

This series adds support for transparent huge page migration to migrate_vma_*() and adds nouveau SVM and HMM selftests as consumers. Earlier versions were posted previously [1] and [2]. The patches apply cleanly to the linux-mm 5.10.0-rc2 tree. There are a lot of other THP patches being posted. I don't think there are any semantic conflicts but there may be some merge conflicts depending on

This series adds support for transparent huge page migration to migrate_vma_*() and adds nouveau SVM and HMM selftests as consumers. An earlier version was posted previously [1]. This version now supports splitting a THP midway in the migration process which led to a number of changes. The patches apply cleanly to the current linux-mm tree. Since there are a couple of patches in linux-mm from Dan

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

These patches apply to linux-5.8.0-rc1. Patches 1-3 should probably go into 5.8, the others can be queued for 5.9. Patches 4-6 improve the HMM self tests. Patch 7-8 prepare nouveau for the meat of this series which adds support and testing for compound page mapping of system memory (patches 9-11) and compound page migration to device private memory (patches 12-16). Since these changes are split

Changelog: v1--v2: 1. Re-order patches to avoid breaking compilation. Bean Huo (5): fs/buffer: clean up block_commit_write ext4: No need to check return value of block_commit_write() fs/ocfs2: No need to check return value of block_commit_write() udf: No need to check return value of block_commit_write() fs/buffer.c: convert block_commit_write to return void fs/buffer.c

On Wed, Jun 26, 2019 at 02:27:11PM +0200, Christoph Hellwig wrote: > This replaces the hacky ->fault callback, which is currently directly > called from common code through a hmm specific data structure as an > exercise in layering violations. > > Signed-off-by: Christoph Hellwig <hch at lst.de> > Reviewed-by: Ralph Campbell <rcampbell at nvidia.com> > --- >

The fault code has been calling file_update_time after ->page_mkwrite after it drops the page lock, but this is annoying because this calls mark_inode_dirty which can fail in Btrfs, so we want to be able to do these updates in ->page_mkwrite so we can get an error back to the user. So get rid of the file_update_time calls in the fault code and push it into everybody who has a

Hello Christian K?nig, The patch 141b15e59175: "drm/nouveau: move io_reserve_lru handling into the driver v5" from Aug 21, 2020, leads to the following static checker warning: drivers/gpu/drm/nouveau/nouveau_ttm.c:148 nouveau_ttm_fault() warn: inconsistent returns '*bo->base.resv'. drivers/gpu/drm/nouveau/nouveau_ttm.c 126 static vm_fault_t nouveau_ttm_fault(struct

A copy push command might fail, causing `migrate_to_ram` to return a dirty HIGH_USER page to the user. This exposes a security vulnerability in the nouveau driver. To prevent memory leaks in `migrate_to_ram` upon a copy error, allocate a zero page for the destination page. Signed-off-by: Yonatan Maman <Ymaman at Nvidia.com> Signed-off-by: Gal Shalom <GalShalom at Nvidia.com> ---

Hi Jason, I love your patch! Yet something to improve: [auto build test ERROR on vhost/linux-next] [also build test ERROR on linus/master v5.7 next-20200529] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see

Hi Jason, I love your patch! Yet something to improve: [auto build test ERROR on vhost/linux-next] [also build test ERROR on linus/master v5.7 next-20200529] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see

On 2020/6/2 ??12:56, Michael S. Tsirkin wrote: > On Tue, Jun 02, 2020 at 03:22:49AM +0800, kbuild test robot wrote: >> Hi Jason, >> >> I love your patch! Yet something to improve: >> >> [auto build test ERROR on vhost/linux-next] >> [also build test ERROR on linus/master v5.7 next-20200529] >> [if your patch is applied to the wrong git tree, please drop

On 2020/6/2 ??12:56, Michael S. Tsirkin wrote: > On Tue, Jun 02, 2020 at 03:22:49AM +0800, kbuild test robot wrote: >> Hi Jason, >> >> I love your patch! Yet something to improve: >> >> [auto build test ERROR on vhost/linux-next] >> [also build test ERROR on linus/master v5.7 next-20200529] >> [if your patch is applied to the wrong git tree, please drop