Re: [syzbot] [mm?] WARNING in deferred_split_folio

[Lance Yang <lance.yang@linux.dev>]

On Wed, Apr 01, 2026 at 01:22:58PM +0200, David Hildenbrand (Arm) wrote:
>On 4/1/26 13:20, Lance Yang wrote:
>> 
>> On Wed, Apr 01, 2026 at 01:00:13PM +0200, David Hildenbrand (Arm) wrote:
>>> On 4/1/26 12:53, Lance Yang wrote:
>>>>
>>>> +Cc Deepanshu
>>>>
>>>>
>>>> Afraid not, it closes the remove_migration_ptes() ->
>>>> deferred_split_folio() race, but opens a new one with the shrinker, IIUC
>>>>
>>>> Once dst is on the deferred split queue, deferred_split_scan() can
>>>> pick it up immediately. The shrinker unconditionally dequeues every
>>>> folio it visits:
>>>>
>>>> 	list_del_init(&folio->_deferred_list);   /* always */
>>>>
>>>> Then for a non-partially-mapped folio, if folio_trylock() fails
>>>> (dst is still locked by migration), it falls through to:
>>>>
>>>> next:
>>>> 		if (did_split || !folio_test_partially_mapped(folio))
>>>> 			continue;  /* not requeued, dst silently lost */
>>>>
>>>> so it is *not* requeued.
>>>
>>> How is that different to the shrinker just trying to lock the folio before we
>>> unlock it and failing? The race already exists?
>> 
>> Ouch, you're right, I was wrong - the trylock drop is a pre-existing
>> issue, not caused by the reorder ;)
>> 
>>>
>>> To sort out that race a trylock must not result in the folio getting
>>> discarded.
>> 
>> Nice, LGTM!
>> 
>> Given that the "trylock -> drop" behavior seems to exist already today,
>> do you think it's worth fixing that together with the reorder?
>
>I'd do it in a single shot if possible.

ACK.

>Can you craft something? (cc stable etc)

certainly, will do! But commit[1] ("mm: migrate: requeue destination
folio on deferred split queue") is only in mm-stable now, not yet
upstream/stable ...

[1] https://lore.kernel.org/mm-commits/20260329004127.334D2C4CEF7@smtp.kernel.org/