Re: [PATCH v2] mm/memory-failure: fix concurrent access issue in min_order_for_split()

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Wed, Aug 05, 2026 at 12:03:24PM +0200, David Hildenbrand (Arm) wrote:
> >>  	/*
> >> @@ -2862,8 +2841,7 @@ static int soft_offline_in_use_page(struct page *page)
> >>  	};
> >>
> >>  	if (!huge && folio_test_large(folio)) {
> >> -		const int new_order = min_order_for_split(folio);
> >> -
> >> +		lock_page(page);
> >>  		/*
> >>  		 * If new_order (target split order) is not 0, do not split the
> >>  		 * folio at all to retain the still accessible large folio.
> >> @@ -2871,8 +2849,14 @@ static int soft_offline_in_use_page(struct page *page)
> >>  		 * preferred, split it to non-zero new_order like it is done in
> >>  		 * memory_failure().
> >>  		 */
> >> -		if (new_order || try_to_split_thp_page(page, /* new_order= */ 0,
> >> -						       /* release= */ true)) {
> >> +		if (!min_order_for_split(folio))
> >> +			ret = split_huge_page_to_order(page, 0);
> >> +		else
> >> +			ret = -EBUSY;
> >> +		unlock_page(page);
> >> +
> >> +		if (ret) {
> >> +			put_page(page);
> >>  			pr_info("%#lx: thp split failed\n", pfn);
> >>  			return -EBUSY;
> >
> > Maybe return ret here? Seems a bit pointless to set ret, gate on it then not
> > return it (even if result is the same)
>
> I didn't check whether a caller actually relies on -EBUSY. So I decided to leave
> the behavior unchanged.

yeah it'd still return -EBUSY it's just a code neatness thing, otherwise setting
ret = -EBUSY is kinda pointless above :)

>
> --
> Cheers,
>
> David

--
Cheers, Lorenzo