Received-SPF: pass (google.com: domain of linux-kernel+bounces-64787-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Message-ID: <bc1a5e36-1983-1a39-4d06-8062993a4ca4@quicinc.com>
Date: Wed, 14 Feb 2024 12:04:10 +0530
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Subject: Re: [PATCH] mm/huge_memory: fix swap entry values of tail pages of
 THP
Content-Language: en-US
To: David Hildenbrand <david@redhat.com>, <gregkh@linuxfoundation.org>,
        <akpm@linux-foundation.org>, <willy@infradead.org>, <vbabka@suse.cz>,
        <dhowells@redhat.com>, <surenb@google.com>
CC: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
        # see patch
 description <stable@vger.kernel.org>
References: <1707814102-22682-1-git-send-email-quic_charante@quicinc.com>
 <a683e199-ce8a-4534-a21e-65f2528415a6@redhat.com>
 <8620c1a0-e091-46e9-418a-db66e621b9c4@quicinc.com>
 <845ca78f-913b-4a92-8b40-ff772a7ad333@redhat.com>
From: Charan Teja Kalla <quic_charante@quicinc.com>
In-Reply-To: <845ca78f-913b-4a92-8b40-ff772a7ad333@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

Thanks David.

On 2/14/2024 12:06 AM, David Hildenbrand wrote:
>>>
>>> Isn't there a way to bite the bullet and backport that series to 6.1
>>> instead?
>>
>> My worry is that, because of merge conflicts, not sure If It can end up
>> in inducing some other issues.
> 
> I can have a look this/next week. I don't recall if there was any
> particular dependency.
> 

That would help me...

>>
>> Although we didn't test THP on older kernels, from the code walk, it
>> seems issue persists to me on older to 6.1 kernel, unless I am missing
>> something here. So back porting of this series to all those LTS kernels,
>> may not be a straight forward?
>>
>> So, I am really not sure of what is the way forward here...
> 
> Again, if we want to fix this properly, we should first identify the
> commit that actually broke it.
> 
> If it predates folios, we'd need different fixes for different stable
> kernels most likely.
> 
> The big question are:
> 
> 1) Is it broken in 5.15? Did you actually try to reproduce or is this
>    just a guess?
> 

We didn't run the tests with THP enabled on 5.15, __so we didn't
encounter this issue__ on older to 6.1 kernels.

I mentioned that issue exists is based on my understanding after code
walk through. To be specific, I just looked to the
migrate_pages()->..->migrate_page_move_mapping() &
__split_huge_page_tail() where the ->private field of thp sub-pages is
not filled with swap entry. If it could have set, I think these are the
only places where it would have done, per my understanding. CMIW.

> 2) How did you come up with 417013e0d18 ("mm/migrate: Add
>    folio_migrate_mapping()")
OOPS, I mean it is Fixes: 3417013e0d18 ("mm/migrate: Add
folio_migrate_mapping()").

My understanding is that it a miss in folio_migrate_mapping() where the
sub-pages should've the ->private set. But this is just a
reimplementation of migrate_page_move_mapping()(where also the issue
exists, tmk).

commit 3417013e0d183be9b42d794082eec0ec1c5b5f15
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Fri May 7 07:28:40 2021 -0400

    mm/migrate: Add folio_migrate_mapping()

    Reimplement migrate_page_move_mapping() as a wrapper around
    folio_migrate_mapping().  Saves 193 bytes of kernel text.

Thanks.