similar to: linux-next 20200508 - build failure in kernel/resource.c w/ SPARSEMEM=n

CONFIG_DEVICE_PRIVATE cannot be selected in configurations without ZONE_DEVICE: WARNING: unmet direct dependencies detected for DEVICE_PRIVATE Depends on [n]: ZONE_DEVICE [=n] Selected by [y]: - DRM_NOUVEAU_SVM [=y] && HAS_IOMEM [=y] && DRM_NOUVEAU [=y] && MMU [=y] && STAGING [=y] kernel/resource.c:1653:28: error: use of undeclared identifier

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 +++++++++++++++++++++++++++++++++++++++

I think the problem is the select of CONFIG_DEVICE_PRIVATE. Jason is looking into it already.

On Fri, 1 May 2020 15:20:44 -0300 Jason Gunthorpe <jgg at ziepe.ca> wrote: > From: Jason Gunthorpe <jgg at mellanox.com> > > There is no reason for a user to select this or not directly - it should > be selected by drivers that are going to use the feature, similar to how > CONFIG_HMM_MIRROR works. > > Currently all drivers provide a feature kconfig that will

On Thu, Jun 13, 2019 at 11:43:09AM +0200, 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

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> --- include/linux/hmm.h | 6 ------ include/linux/memremap.h | 6 ++++++ include/linux/swapops.h | 15 --------------- kernel/memremap.c | 31

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> --- include/linux/hmm.h | 6 ------ include/linux/memremap.h | 6 ++++++ include/linux/swapops.h | 15

On 6/13/19 2:43 AM, 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> > --- > include/linux/hmm.h | 6 ------ > include/linux/memremap.h | 6 ++++++

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. Signed-off-by: Christoph Hellwig <hch at lst.de> --- drivers/nvdimm/pmem.c | 23 +++-------------- include/linux/mm.h | 10 -------- kernel/memremap.c | 59 +++++++++++++++++++++++++++---------------- mm/hmm.c | 2 -- 4 files

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. Also check that a ->page_free is provided for the pgmaps types that require it, and check for a valid type as well while we are at it. Note that this also fixes the fact that hmm never called dev_pagemap_put_ops and thus would leave the slow path

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. Also check that a ->page_free is provided for the pgmaps types that require it, and check for a valid type as well while we are at it. Note that this also fixes the fact that hmm never called dev_pagemap_put_ops and thus would leave the slow path

On Wed, Jun 26, 2019 at 02:27:10PM +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. > Also check that a ->page_free is provided for the pgmaps types that > require it, and check for a valid type as well while we are at it. > > Note that this also

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next head: b072ae74df177c3ad7704c5fbe66e3f10aad9d4e commit: b072ae74df177c3ad7704c5fbe66e3f10aad9d4e [12/12] vhost: use vhost_desc instead of vhost_log config: s390-debug_defconfig (attached as .config) compiler: s390-linux-gcc (GCC) 7.5.0 reproduce: wget

On Tue, Mar 3, 2015 at 2:06 AM, David Vrabel <david.vrabel at citrix.com> wrote: > On 03/03/15 09:40, Luis R. Rodriguez wrote: >> Andrey, >> >> I believe that on Xen we should disable kasan, would like confirmation > > Why? This is the first of heard of this. Andrey chimed in here confirming this. >> from someone on xen-devel though. Here's the thing

On Tue, Mar 3, 2015 at 2:06 AM, David Vrabel <david.vrabel at citrix.com> wrote: > On 03/03/15 09:40, Luis R. Rodriguez wrote: >> Andrey, >> >> I believe that on Xen we should disable kasan, would like confirmation > > Why? This is the first of heard of this. Andrey chimed in here confirming this. >> from someone on xen-devel though. Here's the thing

The code hasn't been used since it was added to the tree, and doesn't appear to actually be usable. Signed-off-by: Christoph Hellwig <hch at lst.de> Reviewed-by: Jason Gunthorpe <jgg at mellanox.com> Acked-by: Michal Hocko <mhocko at suse.com> --- include/linux/hmm.h | 4 ++-- include/linux/ioport.h | 1 - include/linux/memremap.h | 8 --------

CONFIG_MIGRATE_VMA_HELPER guards helpers that are required for proper devic private memory support. Remove the option and just check for CONFIG_DEVICE_PRIVATE instead. Signed-off-by: Christoph Hellwig <hch at lst.de> --- drivers/gpu/drm/nouveau/Kconfig | 1 - mm/Kconfig | 3 --- mm/migrate.c | 4 ++-- 3 files changed, 2 insertions(+), 6 deletions(-)

On Fri, May 8, 2020 at 5:00 PM Jason Gunthorpe <jgg at mellanox.com> wrote: > > On Fri, May 08, 2020 at 04:40:09PM +0200, Arnd Bergmann wrote: > > CONFIG_DEVICE_PRIVATE cannot be selected in configurations > > without ZONE_DEVICE: > > It is kind of unfortunate to lift dependencies from DEVICE_PRIVATE > into the users, is this really how kconfig is supposed to work