Message ID | 20230724082522.1202616-1-ryan.roberts@arm.com (mailing list archive) |
---|---|
Headers | show |
Series | selftests/mm fixes for arm64 | expand |
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.