Re: [PATCH] selftest: mm: Test if hugepage does not get leaked during __bio_release_pages()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 5/24/24 12:31, David Hildenbrand wrote:
On 24.05.24 08:43, Ritesh Harjani (IBM) wrote:
David Hildenbrand <david@xxxxxxxxxx> writes:

dropping stable@xxxxxxxxxxxxxxx

On 24.05.24 04:57, Andrew Morton wrote:
On Thu, 23 May 2024 22:40:25 +0200 David Hildenbrand <david@xxxxxxxxxx> wrote:

You have stable@xxxxxxxxxxxxxxx in the mail headers, so I assume you're
proposing this for backporting.  When doing this, please include

Cc: <stable@xxxxxxxxxxxxxxx>

in the changelog footers and also include a Fixes: target.  I'm
assuming the suitable Fixes: target for this patch is 38b43539d64b?

This adds a new selfest to make sure what was fixed (and backported to
stable) remains fixed.

Sure.  But we should provide -stable maintainers guidance for "how far
back to go".  There isn't much point in backporting this into kernels
where it's known to fail!

I'm probably missing something important.

1) It's a test that does not fall into the common stable kernels
categories (see Documentation/process/stable-kernel-rules.rst).

2) If it fails in a kernel *it achieved its goal* of highlighting that
something serious is broken.


I'm still thinking that we want this in kernels which have 38b43539d64b?

To hide that the other kernels are seriously broken and miss that fix?

Really (1) this shouldn't be backported. I'm not even sure it should be
a selftest (sounds more like a reproducer that we usually attach to
commits, but that's too late). And if people care about backporting it,
(2) you really want this test to succeed everywhere. Especially also to
find kernels *without* 38b43539d64b


Sorry about the noise and cc'd to stable. I believe we don't need to
backport this test. The idea of adding a selftests was "also" to catch any
future bugs like this.

Yes, for that purpose it's fine, but it has quite the "specific reproducer taste". Having it as part of something that is prepared to run against arbitrary kernels (which selftests frequently are not) to detect known problems feels better.

I have seen some hugetlbfs directio tests in LTP. If you think selftest is not the correct place to add this test, we can drop this test from selftests and add it to LTP.

Thanks
Donet


I am unaware of any functional test suite where we could add such tests
like how filesystems have fstests. Hence the ideas was to add this in
selftests.

LTP has quite some MM testcases in testcases/kernel/mem/. But it often has a different focus (CVE or advanced feature/syscall tests). Now that most things are CVEs ... it might not be a bad fit ... :)


So this begs the question which I also asked few people at LSFMM,
Does mm has any mmfvt (mm functional verification tests)? Should we have
something like this? Was it tried in past?

I think LTP is mostly the only "bigger" thing we have that is prepared to run against arbitrary kernel versions.





[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux