Otherwise the kernel ends up with multiple copies:
$ nm vmlinux | grep dummy_vm_ops
ffffffff81e4ea00 d dummy_vm_ops.2
ffffffff81e11760 d dummy_vm_ops.254
ffffffff81e406e0 d dummy_vm_ops.4
ffffffff81e3c780 d dummy_vm_ops.7
While here prefix it with vma_.
[if someone has better ideas where to put it, please move it]
Signed-off-by: Mateusz Guzik <[email protected]>
---
include/linux/mm.h | 6 +++---
mm/init-mm.c | 2 ++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 406ab9ea818f..14898e76bbf1 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -756,17 +756,17 @@ static inline void vma_mark_detached(struct vm_area_struct *vma,
#endif /* CONFIG_PER_VMA_LOCK */
+extern const struct vm_operations_struct vma_dummy_vm_ops;
+
/*
* WARNING: vma_init does not initialize vma->vm_lock.
* Use vm_area_alloc()/vm_area_free() if vma needs locking.
*/
static inline void vma_init(struct vm_area_struct *vma, struct mm_struct *mm)
{
- static const struct vm_operations_struct dummy_vm_ops = {};
-
memset(vma, 0, sizeof(*vma));
vma->vm_mm = mm;
- vma->vm_ops = &dummy_vm_ops;
+ vma->vm_ops = &vma_dummy_vm_ops;
INIT_LIST_HEAD(&vma->anon_vma_chain);
vma_mark_detached(vma, false);
vma_numab_state_init(vma);
diff --git a/mm/init-mm.c b/mm/init-mm.c
index efa97b57acfd..cfd367822cdd 100644
--- a/mm/init-mm.c
+++ b/mm/init-mm.c
@@ -17,6 +17,8 @@
#define INIT_MM_CONTEXT(name)
#endif
+const struct vm_operations_struct vma_dummy_vm_ops;
+
/*
* For dynamically allocated mm_structs, there is a dynamically sized cpumask
* at the end of the structure, the size of which depends on the maximum CPU
--
2.39.2
On Mon, Aug 07, 2023 at 01:16:11AM +0200, Mateusz Guzik wrote:
> Otherwise the kernel ends up with multiple copies:
> $ nm vmlinux | grep dummy_vm_ops
> ffffffff81e4ea00 d dummy_vm_ops.2
> ffffffff81e11760 d dummy_vm_ops.254
> ffffffff81e406e0 d dummy_vm_ops.4
> ffffffff81e3c780 d dummy_vm_ops.7
>
> While here prefix it with vma_.
It really shouldn't be prefixed with vma. Other than that, I love this
patch.
> [if someone has better ideas where to put it, please move it]
>
> Signed-off-by: Mateusz Guzik <[email protected]>
> ---
> include/linux/mm.h | 6 +++---
> mm/init-mm.c | 2 ++
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 406ab9ea818f..14898e76bbf1 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -756,17 +756,17 @@ static inline void vma_mark_detached(struct vm_area_struct *vma,
>
> #endif /* CONFIG_PER_VMA_LOCK */
>
> +extern const struct vm_operations_struct vma_dummy_vm_ops;
> +
> /*
> * WARNING: vma_init does not initialize vma->vm_lock.
> * Use vm_area_alloc()/vm_area_free() if vma needs locking.
> */
> static inline void vma_init(struct vm_area_struct *vma, struct mm_struct *mm)
> {
> - static const struct vm_operations_struct dummy_vm_ops = {};
> -
> memset(vma, 0, sizeof(*vma));
> vma->vm_mm = mm;
> - vma->vm_ops = &dummy_vm_ops;
> + vma->vm_ops = &vma_dummy_vm_ops;
> INIT_LIST_HEAD(&vma->anon_vma_chain);
> vma_mark_detached(vma, false);
> vma_numab_state_init(vma);
> diff --git a/mm/init-mm.c b/mm/init-mm.c
> index efa97b57acfd..cfd367822cdd 100644
> --- a/mm/init-mm.c
> +++ b/mm/init-mm.c
> @@ -17,6 +17,8 @@
> #define INIT_MM_CONTEXT(name)
> #endif
>
> +const struct vm_operations_struct vma_dummy_vm_ops;
> +
> /*
> * For dynamically allocated mm_structs, there is a dynamically sized cpumask
> * at the end of the structure, the size of which depends on the maximum CPU
> --
> 2.39.2
>
>
On 8/7/23, Matthew Wilcox <[email protected]> wrote:
> On Mon, Aug 07, 2023 at 01:16:11AM +0200, Mateusz Guzik wrote:
>> Otherwise the kernel ends up with multiple copies:
>> $ nm vmlinux | grep dummy_vm_ops
>> ffffffff81e4ea00 d dummy_vm_ops.2
>> ffffffff81e11760 d dummy_vm_ops.254
>> ffffffff81e406e0 d dummy_vm_ops.4
>> ffffffff81e3c780 d dummy_vm_ops.7
>>
>> While here prefix it with vma_.
>
> It really shouldn't be prefixed with vma. Other than that, I love this
> patch.
>
I think an unprefixed global is iffy, but I'm not going to insist on
semi-cosmetics.
The one thing I expected people to complain about is the location of
the struct. The mm_init.c file was the least bad choice I found, but
maybe something else is preferred?
I'm just trying to avoid sending V3 for this patch after someone
claims dummy ops should land elsewhere. ;)
--
Mateusz Guzik <mjguzik gmail.com>