similar to: [PATCH] drm/nouveau/dmem: Fix a NULL vs IS_ERR() check

Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/nouveau/nouveau_dmem.c: In function 'nouveau_dmem_free': drivers/gpu/drm/nouveau/nouveau_dmem.c:103:22: warning: variable 'drm' set but not used [-Wunused-but-set-variable] struct nouveau_drm *drm; ^ Signed-off-by: YueHaibing <yuehaibing at huawei.com> ---

Hi Dan, Jérôme and Jason, below is a series that cleans up the dev_pagemap interface so that it is more easily usable, which removes the need to wrap it in hmm and thus allowing to kill a lot of code Note: this series is on top of the rdma/hmm branch + the dev_pagemap releas fix series from Dan that went into 5.2-rc5. Git tree: git://git.infradead.org/users/hch/misc.git

Hi Dan, Jérôme and Jason, below is a series that cleans up the dev_pagemap interface so that it is more easily usable, which removes the need to wrap it in hmm and thus allowing to kill a lot of code Diffstat: 22 files changed, 245 insertions(+), 802 deletions(-) Git tree: git://git.infradead.org/users/hch/misc.git hmm-devmem-cleanup Gitweb:

Hi Dan, Jérôme and Jason, below is a series that cleans up the dev_pagemap interface so that it is more easily usable, which removes the need to wrap it in hmm and thus allowing to kill a lot of code Note: this series is on top of Linux 5.2-rc5 and has some minor conflicts with the hmm tree that are easy to resolve. Diffstat summary: 32 files changed, 361 insertions(+), 1012 deletions(-) Git

Hi, just for your information and maybe for some help: with 5.1rc1 and SVM enabled i see the following backtrace [1] when the nouveau card (reverse prime) goes to sleep, for now i have papered over with [2] which leaves me with userspace hangs. Any pointers where to look for the actual culprit? PS: Card is: nouveau 0000:01:00.0: NVIDIA GP106 (136000a1) Greetings, Tobias [1]: BUG: unable

There isn't really much value add in the hmm_devmem_add wrapper. Just factor out a little helper to find the resource, and otherwise let the driver implement the dev_pagemap_ops directly. Signed-off-by: Christoph Hellwig <hch at lst.de> --- Documentation/vm/hmm.rst | 26 -------- include/linux/hmm.h | 129 --------------------------------------- mm/hmm.c | 115

This function has never been used since it was first added to the kernel more than a year and a half ago, and if we ever grow a consumer of the MEMORY_DEVICE_PUBLIC infrastructure it can easily use devm_memremap_pages directly now that we've simplified the API for it. Signed-off-by: Christoph Hellwig <hch at lst.de> --- include/linux/hmm.h | 3 --- mm/hmm.c | 54

This function has never been used since it was first added to the kernel more than a year and a half 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>

From: Yonatan Maman <Ymaman at Nvidia.com> This patch series addresses two critical issues in the Nouveau driver related to device channels, error handling, and sensitive data leaks. - Vulnerability in migrate_to_ram: The migrate_to_ram function might return a dirty HIGH_USER page when a copy push command (FW channel) fails, potentially exposing sensitive data and posing a security

From: Yonatan Maman <Ymaman at Nvidia.com> This patch series addresses two critical issues in the Nouveau driver related to device channels, error handling, and sensitive data leaks. - Vulnerability in migrate_to_ram: The migrate_to_ram function might return a dirty HIGH_USER page when a copy push command (FW channel) fails, potentially exposing sensitive data and posing a security

Keep the physical address allocation that hmm_add_device does with the rest of the resource code, and allow future reuse of it without the hmm wrapper. Signed-off-by: Christoph Hellwig <hch at lst.de> --- include/linux/ioport.h | 2 ++ kernel/resource.c | 39 +++++++++++++++++++++++++++++++++++++++ mm/hmm.c | 33 ++++----------------------------- 3 files changed, 45

Keep the physical address allocation that hmm_add_device does with the rest of the resource code, and allow future reuse of it without the hmm wrapper. 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> --- include/linux/ioport.h | 2 ++ kernel/resource.c | 39

On 6/13/19 2:43 AM, Christoph Hellwig wrote: > Keep the physical address allocation that hmm_add_device does with the > rest of the resource code, and allow future reuse of it without the hmm > wrapper. > > Signed-off-by: Christoph Hellwig <hch at lst.de> > --- > include/linux/ioport.h | 2 ++ > kernel/resource.c | 39 +++++++++++++++++++++++++++++++++++++++

The dev_pagemap is a growing too many callbacks. Move them into a separate ops structure so that they are not duplicated for multiple instances, and an attacker can't easily overwrite them. Signed-off-by: Christoph Hellwig <hch at lst.de> --- drivers/dax/device.c | 6 +++++- drivers/nvdimm/pmem.c | 18 +++++++++++++----- drivers/pci/p2pdma.c | 5

When acting on device private mappings a driver needs to know if the device (or other entity in case of kvmppc) actually owns this private mapping. This series adds an owner field and converts the migrate_vma code over to check it. I looked into doing the same for hmm_range_fault, but as far as I can tell that code has never been wired up to actually work for device private memory, so instead of

The dev_pagemap is a growing too many callbacks. Move them into a separate ops structure so that they are not duplicated for multiple instances, and an attacker can't easily overwrite them. Signed-off-by: Christoph Hellwig <hch at lst.de> Reviewed-by: Logan Gunthorpe <logang at deltatee.com> Reviewed-by: Jason Gunthorpe <jgg at mellanox.com> --- drivers/dax/device.c

On Thu, Jun 13, 2019 at 11:43:12AM +0200, Christoph Hellwig wrote: > Just check if there is a ->page_free operation set and take care of the > static key enable, as well as the put using device managed resources. > diff --git a/mm/hmm.c b/mm/hmm.c > index c76a1b5defda..6dc769feb2e1 100644 > +++ b/mm/hmm.c > @@ -1378,8 +1378,6 @@ struct hmm_devmem *hmm_devmem_add(const struct

struct dev_pagemap is always embedded into a containing structure, so there is no need to an additional private data field. Signed-off-by: Christoph Hellwig <hch at lst.de> --- drivers/nvdimm/pmem.c | 2 +- include/linux/memremap.h | 3 +-- kernel/memremap.c | 2 +- mm/hmm.c | 9 +++++---- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git

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 17, 2019 at 5:27 AM Christoph Hellwig <hch at lst.de> wrote: > > Keep the physical address allocation that hmm_add_device does with the > rest of the resource code, and allow future reuse of it without the hmm > wrapper. > > Signed-off-by: Christoph Hellwig <hch at lst.de> > Reviewed-by: Jason Gunthorpe <jgg at mellanox.com> > Reviewed-by: John