[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240703132653.3cb26750f5ff160d6b698cae@linux-foundation.org>
Date: Wed, 3 Jul 2024 13:26:53 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, "Liam R . Howlett" <Liam.Howlett@...cle.com>, Vlastimil
Babka <vbabka@...e.cz>, Matthew Wilcox <willy@...radead.org>, Alexander
Viro <viro@...iv.linux.org.uk>, Christian Brauner <brauner@...nel.org>, Jan
Kara <jack@...e.cz>, Eric Biederman <ebiederm@...ssion.com>, Kees Cook
<kees@...nel.org>, Suren Baghdasaryan <surenb@...gle.com>
Subject: Re: [PATCH 0/7] Make core VMA operations internal and testable
On Wed, 3 Jul 2024 12:57:31 +0100 Lorenzo Stoakes <lorenzo.stoakes@...cle.com> wrote:
> Kernel functionality is stubbed and shimmed as needed in tools/testing/vma/
> which contains a fully functional userland vma_internal.h file and which
> imports mm/vma.c and mm/vma.h to be directly tested from userland.
Cool stuff.
Now we need to make sure that anyone who messes with vma code has run
the tests. And has added more testcases, if appropriate.
Does it make sense to execute this test under selftests/ in some
fashion? Quite a few people appear to be running the selftest code
regularly and it would be good to make them run this as well.
> 51 files changed, 3914 insertions(+), 2453 deletions(-)
eep. The best time for me to merge this is late in the -rc cycle so
the large skew between mainline and mm.git doesn't spend months
hampering ongoing development. But that merge time is right now.
Powered by blists - more mailing lists