[v3,0/8] selftests/mm fixes for arm64

  Hi All,

This is v3 of my series to clean up mm selftests so that they run correctly on
arm64. See [1] for full explanation.

Only patch 6 has changed vs v2. The rest are the same and already carry
reviewed/acked-bys. So I'm hoping I can get the final patch reviewed and this
series is hopefully then good enough to merge?

Changes Since v2 [2]
--------------------

  - Patch 6: Change approach to cleaning up child processes; Use "parent death
    signal", as suggested by David.
  - Added Reviewed-by/Acked-by tags: thanks to David, Mark and Peter!

Changes Since v1 [1]
--------------------

  - Patch 1: Explicitly set line buffer mode in ksft_print_header()
  - Dropped v1 patch 2 (set execute permissions): Andrew has taken this into his
    branch separately.
  - Patch 2: Don't compile `soft-dirty` suite for arm64 instead of skipping it
    at runtime.
  - Patch 2: Declare fewer tests and skip all of test_softdirty() if soft-dirty
    is not supported, rather than conditionally marking each check as skipped.
  - Added Reviewed-by tags: thanks DavidH!
  - Patch 8: Clarified commit message.


[1] https://lore.kernel.org/linux-mm/20230713135440.3651409-1-ryan.roberts@arm.com/
[2] https://lore.kernel.org/linux-mm/20230717103152.202078-1-ryan.roberts@arm.com/

Thanks,
Ryan


Ryan Roberts (8):
  selftests: Line buffer test program's stdout
  selftests/mm: Skip soft-dirty tests on arm64
  selftests/mm: Enable mrelease_test for arm64
  selftests/mm: Fix thuge-gen test bugs
  selftests/mm: va_high_addr_switch should skip unsupported arm64
    configs
  selftests/mm: Make migration test robust to failure
  selftests/mm: Optionally pass duration to transhuge-stress
  selftests/mm: Run all tests from run_vmtests.sh

 tools/testing/selftests/kselftest.h           |  9 ++
 tools/testing/selftests/kselftest/runner.sh   |  7 +-
 tools/testing/selftests/mm/Makefile           | 82 ++++++++++---------
 tools/testing/selftests/mm/madv_populate.c    | 26 +++++-
 tools/testing/selftests/mm/migration.c        | 12 ++-
 tools/testing/selftests/mm/mrelease_test.c    |  1 +
 tools/testing/selftests/mm/run_vmtests.sh     | 28 ++++++-
 tools/testing/selftests/mm/settings           |  2 +-
 tools/testing/selftests/mm/thuge-gen.c        |  4 +-
 tools/testing/selftests/mm/transhuge-stress.c | 12 ++-
 .../selftests/mm/va_high_addr_switch.c        |  2 +-
 11 files changed, 132 insertions(+), 53 deletions(-)

--
2.25.1
  

On Mon, 24 Jul 2023 09:25:14 +0100 Ryan Roberts <ryan.roberts@arm.com> wrote:

> This is v3 of my series to clean up mm selftests so that they run correctly on
> arm64. See [1] for full explanation.

Please don't do that.  Please maintain the [0/n] description alongside the
patchset and resend it each time you resend the series.

I could go over and copy-paste [1] into this patchset, but I don't know if it
is fully up to date.   I'll leave the patchset intro blank for now - please
review/edit [1] and send the result in reply to this email, thanks.
  

On 24/07/2023 17:38, Andrew Morton wrote:
> On Mon, 24 Jul 2023 09:25:14 +0100 Ryan Roberts <ryan.roberts@arm.com> wrote:
> 
>> This is v3 of my series to clean up mm selftests so that they run correctly on
>> arm64. See [1] for full explanation.
> 
> Please don't do that.  Please maintain the [0/n] description alongside the
> patchset and resend it each time you resend the series.

OK understood. Sorry about that. Do you have any docs for the mm submission
process? If not, please keep pointing issues out and I'll get it right eventually.

I previously thought that the cover letter was primarily for the email
recipients and the description on each patch was the part that went into git?
Clearly I'm wrong, but can't see anything in submitting-patches.rst so guess the
mm process is a bit different?

> 
> I could go over and copy-paste [1] into this patchset, but I don't know if it
> is fully up to date.   I'll leave the patchset intro blank for now - please
> review/edit [1] and send the result in reply to this email, thanks. 

I doubt you would want the whole cover letter in git, so here is the relavent intro:

---8<---

Hi All,

Given my on-going work on large anon folios and contpte mappings, I decided it
would be a good idea to start running mm selftests to help guard against
regressions. However, it soon became clear that I couldn't get the suite to run
cleanly on arm64 with a vanilla v6.5-rc1 kernel (perhaps I'm just doing it
wrong??), so got stuck in a rabbit hole trying to debug and fix all the issues.
Some were down to misconfigurations, but I also found a number of issues with
the tests and even a couple of issues with the kernel.

This series aims to fix (most of) the test issues. It applies on top of
v6.5-rc3.

Changes Since v2 [2]
--------------------

  - Patch 6: Change approach to cleaning up child processes; Use "parent death
    signal", as suggested by David.
  - Added Reviewed-by/Acked-by tags: thanks to David, Mark and Peter!

Changes Since v1 [1]
--------------------

  - Patch 1: Explicitly set line buffer mode in ksft_print_header()
  - Dropped v1 patch 2 (set execute permissions): Andrew has taken this into his
    branch separately.
  - Patch 2: Don't compile `soft-dirty` suite for arm64 instead of skipping it
    at runtime.
  - Patch 2: Declare fewer tests and skip all of test_softdirty() if soft-dirty
    is not supported, rather than conditionally marking each check as skipped.
  - Added Reviewed-by tags: thanks DavidH!
  - Patch 8: Clarified commit message.

---8<---

Thanks,
Ryan
  

On Mon, 24 Jul 2023 19:49:13 +0100 Ryan Roberts <ryan.roberts@arm.com> wrote:

> On 24/07/2023 17:38, Andrew Morton wrote:
> > On Mon, 24 Jul 2023 09:25:14 +0100 Ryan Roberts <ryan.roberts@arm.com> wrote:
> > 
> >> This is v3 of my series to clean up mm selftests so that they run correctly on
> >> arm64. See [1] for full explanation.
> > 
> > Please don't do that.  Please maintain the [0/n] description alongside the
> > patchset and resend it each time you resend the series.
> 
> OK understood. Sorry about that. Do you have any docs for the mm submission
> process? If not, please keep pointing issues out and I'll get it right eventually.

A work in progress ;)

> I previously thought that the cover letter was primarily for the email
> recipients and the description on each patch was the part that went into git?
> Clearly I'm wrong, but can't see anything in submitting-patches.rst so guess the
> mm process is a bit different?

I expect all subsystem maintainers would like the [0/N] intro to be
maintained and resent as the patchset evolves.

> > 
> > I could go over and copy-paste [1] into this patchset, but I don't know if it
> > is fully up to date.   I'll leave the patchset intro blank for now - please
> > review/edit [1] and send the result in reply to this email, thanks. 
> 
> I doubt you would want the whole cover letter in git, so here is the relavent intro:

Pasted, thanks.
  

On Mon, Jul 24, 2023 at 12:01:45PM -0700, Andrew Morton wrote:
> On Mon, 24 Jul 2023 19:49:13 +0100 Ryan Roberts <ryan.roberts@arm.com> wrote:
> > On 24/07/2023 17:38, Andrew Morton wrote:
> > > On Mon, 24 Jul 2023 09:25:14 +0100 Ryan Roberts <ryan.roberts@arm.com> wrote:

> > >> This is v3 of my series to clean up mm selftests so that they run correctly on
> > >> arm64. See [1] for full explanation.

> > > Please don't do that.  Please maintain the [0/n] description alongside the
> > > patchset and resend it each time you resend the series.

> > I previously thought that the cover letter was primarily for the email
> > recipients and the description on each patch was the part that went into git?
> > Clearly I'm wrong, but can't see anything in submitting-patches.rst so guess the
> > mm process is a bit different?

> I expect all subsystem maintainers would like the [0/N] intro to be
> maintained and resent as the patchset evolves.

Speaking for myself having everything directly in the e-mail makes the 
whole process easier, it means that everything that's needed is there
immediately without having to go locate some external information or
dredge things up from memory.  This is especially useful when whoever's
reading the series has poor connectivity for whatever reason (eg, I
often go through my patch backlog while on trains).

Cover letters that I get do also tend up to find their way into git in
some form, generally edited a bit, due to the way I CI incoming changes:

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/?h=for-6.6&id=85d12eda2382cd5b93eed720b5a08f39d42cfef4

though most people don't do anything like that.