lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c9ee47d3-77cd-4333-805a-d457e4a1bb80@redhat.com>
Date: Fri, 24 May 2024 09:01:54 +0200
From: David Hildenbrand <david@...hat.com>
To: "Ritesh Harjani (IBM)" <ritesh.list@...il.com>,
 Andrew Morton <akpm@...ux-foundation.org>
Cc: Donet Tom <donettom@...ux.ibm.com>, Shuah Khan <shuah@...nel.org>,
 Matthew Wilcox <willy@...radead.org>, Tony Battersby
 <tonyb@...ernetics.com>, linux-mm@...ck.org,
 linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org,
 Mike Rapoport <rppt@...nel.org>, Muchun Song <songmuchun@...edance.com>
Subject: Re: [PATCH] selftest: mm: Test if hugepage does not get leaked during
 __bio_release_pages()

On 24.05.24 08:43, Ritesh Harjani (IBM) wrote:
> David Hildenbrand <david@...hat.com> writes:
> 
> dropping stable@...r.kernel.org
> 
>> On 24.05.24 04:57, Andrew Morton wrote:
>>> On Thu, 23 May 2024 22:40:25 +0200 David Hildenbrand <david@...hat.com> wrote:
>>>
>>>>> You have stable@...r.kernel.org in the mail headers, so I assume you're
>>>>> proposing this for backporting.  When doing this, please include
>>>>>
>>>>> Cc: <stable@...r.kernel.org>
>>>>>
>>>>> 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 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.

-- 
Cheers,

David / dhildenb


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ