Received-SPF: pass (google.com: domain of linux-kernel+bounces-188555-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <3c6e5e78-aa49-4002-941f-af8fd2b81d10@linux.ibm.com>
Date: Fri, 24 May 2024 15:01:18 +0530
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] selftest: mm: Test if hugepage does not get leaked during
 __bio_release_pages()
Content-Language: en-US
To: David Hildenbrand <david@redhat.com>,
        "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
        Andrew Morton <akpm@linux-foundation.org>
Cc: Shuah Khan <shuah@kernel.org>, Matthew Wilcox <willy@infradead.org>,
        Tony Battersby <tonyb@cybernetics.com>, linux-mm@kvack.org,
        linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
        Mike Rapoport <rppt@kernel.org>,
        Muchun Song <songmuchun@bytedance.com>
References: <20240523063905.3173-1-donettom@linux.ibm.com>
 <20240523121344.6a67a109e0af2ba70973b34b@linux-foundation.org>
 <d551d1cd-a02f-42aa-9de2-10ff7757224c@redhat.com>
 <20240523195734.bc03a8822a34b1a97880fb65@linux-foundation.org>
 <7792c8ba-39e6-47ee-9b43-108270325c15@redhat.com> <87o78vsoav.fsf@gmail.com>
 <c9ee47d3-77cd-4333-805a-d457e4a1bb80@redhat.com>
From: Donet Tom <donettom@linux.ibm.com>
In-Reply-To: <c9ee47d3-77cd-4333-805a-d457e4a1bb80@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


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