search for: mm_type

...viewed-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_notifier.h. Therefore: a) Move the last two traces of it out of mmu_notifier.h, and b) Put a forward declaration in mm_types.h, which is where it belongs because that's where it's referred to. So if you apply this incremental patch on top, I think it...

...ad of the mix of a dummy dependency symbol plus the actually selected one. Drop various odd dependencies, as the code is pretty portable. Signed-off-by: Christoph Hellwig <hch at lst.de> --- drivers/gpu/drm/nouveau/Kconfig | 3 +-- include/linux/hmm.h | 5 +---- include/linux/mm_types.h | 2 +- mm/Kconfig | 27 ++++----------------------- mm/Makefile | 2 +- mm/hmm.c | 2 -- 6 files changed, 8 insertions(+), 33 deletions(-) diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig in...

...mix of a dummy dependency symbol plus the actually selected one. Drop various odd dependencies, as the code is pretty portable. Signed-off-by: Christoph Hellwig <hch at lst.de> --- drivers/gpu/drm/nouveau/Kconfig | 3 +-- include/linux/hmm.h | 14 +++----------- include/linux/mm_types.h | 2 +- mm/Kconfig | 27 +++------------------------ mm/Makefile | 2 +- mm/hmm.c | 2 -- 6 files changed, 9 insertions(+), 41 deletions(-) diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig in...

...DAX uses ->pgmap and ->mapping from two different > sides of the union, but DAX doesn't use hmm_devmem_free). > > Signed-off-by: Christoph Hellwig <hch at lst.de> > --- > mm/hmm.c | 2 -- > 1 file changed, 2 deletions(-) Hurm, is hmm following this comment from mm_types.h? * If you allocate the page using alloc_pages(), you can use some of the * space in struct page for your own purposes. The five words in the main * union are available, except for bit 0 of the first word which must be * kept clear. Many users use this word to store a pointer to an object...

...irst/last? >>>> It is customary in the kernel to use start-end where end corresponds to >>>> the byte following the last in the range. See struct vm_area_struct >>>> vm_start and vm_end fields >>> Exactly my point: >>> >>> include/linux/mm_types.h: unsigned long vm_end; /* The first byte after our end address >>> >>> in this case Jason wants it to be the last byte, not one behind. >>> >>> >> Maybe start, size? Not ambiguous, and you don't need to do annoying >> calculatio...

...irst/last? >>>> It is customary in the kernel to use start-end where end corresponds to >>>> the byte following the last in the range. See struct vm_area_struct >>>> vm_start and vm_end fields >>> Exactly my point: >>> >>> include/linux/mm_types.h: unsigned long vm_end; /* The first byte after our end address >>> >>> in this case Jason wants it to be the last byte, not one behind. >>> >>> >> Maybe start, size? Not ambiguous, and you don't need to do annoying >> calculatio...

Hi All: This series introduces API for reporing IOVA range. This is a must for userspace to work correclty: - for the process that uses vhost-vDPA directly to properly allocate IOVA - for VM(qemu), when vIOMMU is not enabled, fail early if GPA is out of range - for VM(qemu), when vIOMMU is enabled, determine a valid guest address width Please review. Thanks Jason Wang (4): vdpa:

Hi All: This series introduces API for reporing IOVA range. This is a must for userspace to work correclty: - for the process that uses vhost-vDPA directly to properly allocate IOVA - for VM(qemu), when vIOMMU is not enabled, fail early if GPA is out of range - for VM(qemu), when vIOMMU is enabled, determine a valid guest address width Please review. Thanks Jason Wang (4): vdpa:

Hi everyone, Here are new releases of bio-cgroup. Changes from the previous version are as follows: - Accurate dirty-page tracking Support migrating pages between bio-cgroups with minimum overhead, but I think such a situation is quite rare. - Fix a bug of swapcache page handling Sometimes, "bad page state" is occurred since the memory controller has temporarily changed the

Hi everyone, Here are new releases of bio-cgroup. Changes from the previous version are as follows: - Accurate dirty-page tracking Support migrating pages between bio-cgroups with minimum overhead, but I think such a situation is quite rare. - Fix a bug of swapcache page handling Sometimes, "bad page state" is occurred since the memory controller has temporarily changed the

Hi everyone, Here are new releases of bio-cgroup. Changes from the previous version are as follows: - Accurate dirty-page tracking Support migrating pages between bio-cgroups with minimum overhead, but I think such a situation is quite rare. - Fix a bug of swapcache page handling Sometimes, "bad page state" is occurred since the memory controller has temporarily changed the

...t it is only the owner/driver to have > > a control over the page. Also the above is not possible as long as the > > owner/driver keeps a reference to the PageOffline page throughout the > > time it is marked that way. > > > > I was reading > > include/linux/mm_types.h: > > "If you want to use the refcount field, it must be used in such a way > that other CPUs temporarily incrementing and then decrementing the > refcount does not cause problems" > > And that made me think "anybody can go ahead and try get_page_unless_zero()...

...t it is only the owner/driver to have > > a control over the page. Also the above is not possible as long as the > > owner/driver keeps a reference to the PageOffline page throughout the > > time it is marked that way. > > > > I was reading > > include/linux/mm_types.h: > > "If you want to use the refcount field, it must be used in such a way > that other CPUs temporarily incrementing and then decrementing the > refcount does not cause problems" > > And that made me think "anybody can go ahead and try get_page_unless_zero()...

...guous. Is end in the range or just behind it? > > How about first/last? > > It is customary in the kernel to use start-end where end corresponds to > the byte following the last in the range. See struct vm_area_struct > vm_start and vm_end fields Exactly my point: include/linux/mm_types.h: unsigned long vm_end; /* The first byte after our end address in this case Jason wants it to be the last byte, not one behind. > > > > > > > > > /** > > > * vDPA_config_ops - operations for configuring a vDPA device. > > >...

...t; > > > > > It is customary in the kernel to use start-end where end corresponds to > > > the byte following the last in the range. See struct vm_area_struct > > > vm_start and vm_end fields > > > > Exactly my point: > > > > include/linux/mm_types.h: unsigned long vm_end; /* The first byte after our end address > > > > in this case Jason wants it to be the last byte, not one behind. > > > > > Maybe start, size? Not ambiguous, and you don't need to do annoying > calculations like size = la...

...omary in the kernel to use start-end where end corresponds to > > > > > the byte following the last in the range. See struct vm_area_struct > > > > > vm_start and vm_end fields > > > > Exactly my point: > > > > > > > > include/linux/mm_types.h: unsigned long vm_end; /* The first byte after our end address > > > > > > > > in this case Jason wants it to be the last byte, not one behind. > > > > > > > > > > > Maybe start, size? Not ambiguous, and you don't ne...

...| 13 ++++++++++ 2 files changed, 30 insertions(+), 29 deletions(-) diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h index 1bd8e6a09a3c27..12bd603d318ce7 100644 --- a/include/linux/mmu_notifier.h +++ b/include/linux/mmu_notifier.h @@ -7,8 +7,9 @@ #include <linux/mm_types.h> #include <linux/srcu.h> +struct mmu_notifier_mm; struct mmu_notifier; -struct mmu_notifier_ops; +struct mmu_notifier_range; /** * enum mmu_notifier_event - reason for the mmu notifier callback @@ -40,36 +41,8 @@ enum mmu_notifier_event { MMU_NOTIFY_SOFT_DIRTY, }; -#ifdef...

...| 13 ++++++++++ 2 files changed, 30 insertions(+), 29 deletions(-) diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h index 1bd8e6a09a3c27..12bd603d318ce7 100644 --- a/include/linux/mmu_notifier.h +++ b/include/linux/mmu_notifier.h @@ -7,8 +7,9 @@ #include <linux/mm_types.h> #include <linux/srcu.h> +struct mmu_notifier_mm; struct mmu_notifier; -struct mmu_notifier_ops; +struct mmu_notifier_range; /** * enum mmu_notifier_event - reason for the mmu notifier callback @@ -40,36 +41,8 @@ enum mmu_notifier_event { MMU_NOTIFY_SOFT_DIRTY, }; -#ifdef...

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

...ch/x86/kernel/sev-es.c +++ b/arch/x86/kernel/sev-es.c @@ -8,8 +8,13 @@ */ #include <linux/sched/debug.h> /* For show_regs() */ -#include <linux/kernel.h> +#include <linux/percpu-defs.h> +#include <linux/mem_encrypt.h> #include <linux/printk.h> +#include <linux/mm_types.h> +#include <linux/set_memory.h> +#include <linux/memblock.h> +#include <linux/kernel.h> #include <linux/mm.h> #include <asm/sev-es.h> @@ -29,6 +34,13 @@ static struct ghcb boot_ghcb_page __bss_decrypted __aligned(PAGE_SIZE); */ static struct ghcb __initdat...