Re: [PATCH v3 0/2] lib/list_sort: Clean up list_sort() scheduling workarounds

From: Andrew Morton

Date: Fri Mar 20 2026 - 21:21:12 EST


On Fri, 20 Mar 2026 18:09:36 +0000 Kuan-Wei Chiu <visitorckw@xxxxxxxxx> wrote:

> Historically, list_sort() included a hack in merge_final() that
> periodically invoked dummy cmp(priv, b, b) calls when merging highly
> unbalanced lists. This allowed the caller to invoke cond_resched()
> within their comparison callbacks to avoid soft lockups.
>
> However, an audit of the kernel tree shows that fs/ubifs/ has been the
> sole user of this mechanism. For all other generic list_sort() users,
> this results in wasted function calls and unnecessary overhead in a
> tight loop.
>
> Recent discussions and code inspection confirmed that the lists being
> sorted in UBIFS are bounded in size (a few thousand elements at most),
> and the comparison functions are extremely lightweight. Therefore,
> UBIFS does not actually need to rely on this mechanism.

Thanks. AI review found a now-unused local, which I'll fix.

https://sashiko.dev/#/patchset/20260320180938.1827148-1-visitorckw@xxxxxxxxx