linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: SeongJae Park <sj@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, "Liam R . Howlett" <Liam.Howlett@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Matthew Wilcox <willy@infradead.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
	Eric Biederman <ebiederm@xmission.com>,
	Kees Cook <kees@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Shuah Khan <shuah@kernel.org>,
	Brendan Higgins <brendanhiggins@google.com>,
	David Gow <davidgow@google.com>, Rae Moar <rmoar@google.com>
Subject: Re: [PATCH v3 4/7] mm: move internal core VMA manipulation functions to own file
Date: Tue, 23 Jul 2024 09:58:25 -0700	[thread overview]
Message-ID: <20240723165825.196416-1-sj@kernel.org> (raw)
In-Reply-To: <36667fcc4fcf9e6341239a4eb0e15f6143cdc5c2.1721648367.git.lorenzo.stoakes@oracle.com>

Hi Lorenzo,

On Mon, 22 Jul 2024 12:50:22 +0100 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:

> This patch introduces vma.c and moves internal core VMA manipulation
> functions to this file from mmap.c.
> 
> This allows us to isolate VMA functionality in a single place such that we
> can create userspace testing code that invokes this functionality in an
> environment where we can implement simple unit tests of core functionality.
> 
> This patch ensures that core VMA functionality is explicitly marked as such
> by its presence in mm/vma.h.
> 
> It also places the header includes required by vma.c in vma_internal.h,
> which is simply imported by vma.c. This makes the VMA functionality
> testable, as userland testing code can simply stub out functionality
> as required.
> 
> Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> ---
>  include/linux/mm.h |   35 -
>  mm/Makefile        |    2 +-
>  mm/internal.h      |  236 +-----
>  mm/mmap.c          | 1980 +++-----------------------------------------
>  mm/mmu_notifier.c  |    2 +
>  mm/vma.c           | 1766 +++++++++++++++++++++++++++++++++++++++
>  mm/vma.h           |  364 ++++++++
>  mm/vma_internal.h  |   52 ++
>  8 files changed, 2294 insertions(+), 2143 deletions(-)
>  create mode 100644 mm/vma.c
>  create mode 100644 mm/vma.h
>  create mode 100644 mm/vma_internal.h
> 
[...]
> diff --git a/mm/vma_internal.h b/mm/vma_internal.h
> new file mode 100644
> index 000000000000..e13e5950df78
> --- /dev/null
> +++ b/mm/vma_internal.h
> @@ -0,0 +1,52 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * vma_internal.h
> + *
> + * Headers required by vma.c, which can be substituted accordingly when testing
> + * VMA functionality.
> + */
> +
> +#ifndef __MM_VMA_INTERNAL_H
> +#define __MM_VMA_INTERNAL_H
> +
[...]
> +#include <asm/current.h>
> +#include <asm/page_types.h>
> +#include <asm/pgtable_types.h>

I found the latest mm-unstable fails build for arm64 and kunit (tenically
speaking, UM) with errors including below.  And 'git bisect' points this patch.

From arm64 build:
      CC      mm/vma.o
    In file included from /mm/vma.c:7:
    /mm/vma_internal.h:46:10: fatal error: asm/page_types.h: No such file or directory
       46 | #include <asm/page_types.h>
          |          ^~~~~~~~~~~~~~~~~~
    compilation terminated.

From kunit build:

    $ ./tools/testing/kunit/kunit.py build
    [...]
    $ make ARCH=um O=.kunit --jobs=36
    ERROR:root:../lib/iomap.c:156:5: warning: no previous prototype for ‘ioread64_lo_hi’ [-Wmissing-prototypes]
      156 | u64 ioread64_lo_hi(const void __iomem *addr)
          |     ^~~~~~~~~~~~~~
    ../lib/iomap.c:163:5: warning: no previous prototype for ‘ioread64_hi_lo’ [-Wmissing-prototypes]
      163 | u64 ioread64_hi_lo(const void __iomem *addr)
          |     ^~~~~~~~~~~~~~
    ../lib/iomap.c:170:5: warning: no previous prototype for ‘ioread64be_lo_hi’ [-Wmissing-prototypes]
      170 | u64 ioread64be_lo_hi(const void __iomem *addr)
          |     ^~~~~~~~~~~~~~~~
    ../lib/iomap.c:178:5: warning: no previous prototype for ‘ioread64be_hi_lo’ [-Wmissing-prototypes]
      178 | u64 ioread64be_hi_lo(const void __iomem *addr)
          |     ^~~~~~~~~~~~~~~~
    ../lib/iomap.c:264:6: warning: no previous prototype for ‘iowrite64_lo_hi’ [-Wmissing-prototypes]
      264 | void iowrite64_lo_hi(u64 val, void __iomem *addr)
          |      ^~~~~~~~~~~~~~~
    ../lib/iomap.c:272:6: warning: no previous prototype for ‘iowrite64_hi_lo’ [-Wmissing-prototypes]
      272 | void iowrite64_hi_lo(u64 val, void __iomem *addr)
          |      ^~~~~~~~~~~~~~~
    ../lib/iomap.c:280:6: warning: no previous prototype for ‘iowrite64be_lo_hi’ [-Wmissing-prototypes]
      280 | void iowrite64be_lo_hi(u64 val, void __iomem *addr)
          |      ^~~~~~~~~~~~~~~~~
    ../lib/iomap.c:288:6: warning: no previous prototype for ‘iowrite64be_hi_lo’ [-Wmissing-prototypes]
      288 | void iowrite64be_hi_lo(u64 val, void __iomem *addr)
          |      ^~~~~~~~~~~~~~~~~
    In file included from ../mm/vma_internal.h:46,
                     from ../mm/vma.c:7:

Maybe the above two #include need to be removed or protected for some configs?
I confirmed simply removing the two lines as below makes at least kunit, arm64,
and my x86_64 builds happy, but would like to hear your thoughts.

"""
diff --git a/mm/vma_internal.h b/mm/vma_internal.h
index e13e5950df78..14c24d5cb582 100644
--- a/mm/vma_internal.h
+++ b/mm/vma_internal.h
@@ -43,8 +43,6 @@
 #include <linux/userfaultfd_k.h>

 #include <asm/current.h>
-#include <asm/page_types.h>
-#include <asm/pgtable_types.h>
 #include <asm/tlb.h>

 #include "internal.h"
"""


Thanks,
SJ

[...]

  reply	other threads:[~2024-07-23 16:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-22 11:50 [PATCH v3 0/7] Make core VMA operations internal and testable Lorenzo Stoakes
2024-07-22 11:50 ` [PATCH v3 1/7] userfaultfd: move core VMA manipulation logic to mm/userfaultfd.c Lorenzo Stoakes
2024-07-22 11:50 ` [PATCH v3 2/7] mm: move vma_modify() and helpers to internal header Lorenzo Stoakes
2024-07-22 11:50 ` [PATCH v3 3/7] mm: move vma_shrink(), vma_expand() " Lorenzo Stoakes
2024-07-22 11:50 ` [PATCH v3 4/7] mm: move internal core VMA manipulation functions to own file Lorenzo Stoakes
2024-07-23 16:58   ` SeongJae Park [this message]
2024-07-23 17:15     ` Lorenzo Stoakes
2024-07-22 11:50 ` [PATCH v3 5/7] MAINTAINERS: Add entry for new VMA files Lorenzo Stoakes
2024-07-22 11:50 ` [PATCH v3 6/7] tools: separate out shared radix-tree components Lorenzo Stoakes
2024-07-23  9:25   ` Mike Rapoport
2024-07-23  9:35     ` Lorenzo Stoakes
2024-07-25 10:20   ` Lorenzo Stoakes
2024-07-28 20:15   ` Andrew Morton
2024-07-22 11:50 ` [PATCH v3 7/7] tools: add skeleton code for userland testing of VMA logic Lorenzo Stoakes
2024-07-23 17:20 ` [PATCH v3 0/7] Make core VMA operations internal and testable Lorenzo Stoakes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240723165825.196416-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=brendanhiggins@google.com \
    --cc=davidgow@google.com \
    --cc=ebiederm@xmission.com \
    --cc=jack@suse.cz \
    --cc=kees@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=rmoar@google.com \
    --cc=shuah@kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).