Re: linux-next: manual merge of the slab tree with the mm-unstable tree

[Thomas Weißschuh]

On Fri, Nov 14, 2025 at 09:46:30AM +0100, Vlastimil Babka wrote:
> On 11/14/25 06:06, Christoph Hellwig wrote:
> > On Fri, Nov 14, 2025 at 03:13:21PM +1100, Stephen Rothwell wrote:
> >> Hi all,
> >> 
> >> Today's linux-next merge of the slab tree got a conflict in:
> >> 
> >>   mm/mempool.c
> >> 
> >> between commit:
> >> 
> >>   25c4d8d29dbb ("mempool: clarify behavior of mempool_alloc_preallocated()")
> >> 
> >> from the mm-unstable tree and commit:
> >> 
> >>   5c829783e5f8 ("mempool: improve kerneldoc comments")
> > 
> > Hmm, I guess we need to agree on which tree takes mempool patches, then
> > we can just rebase one side.
> 
> I can take that patch as mm-unstable (not -stable) means it's still
> droppable there at this point.
> 
> > I also find 25c4d8d29dbb odd.  Yes, with PREEMPT_RT anything taking
> > spinlocks could sleep in the normal sense, but pretty much everything
> > in Linux assumes spinlocks as spinning.

This is why the new documentation explicitly mentions the spinlock.
All callers can interpret this relative to their own usecase.

> > So if we want to update that
> > we should agree on global conventions for it and not starting to update
> > random little functions individually.

The behaviour of different locks under various kernel configurations is
already documented extensively. My change explicitly tried to defer to that.

We have the 'Context:' tag in kdoc. What about the following?

	Context: Any context. Takes and releases pool->lock.

> That's also true. Thomas, is this case special

No, not special. Just one of the few places which promises to "never sleep".

> or what motivated the patch in the first place?

I used the function in a tracepoint handler [0] and trusted its documentation
to "never sleep". That turned out to be incorrect.
Also see the discussion on the patch submission [1] about just this point,
where we didn't come up with better wording.

[0] https://lore.kernel.org/lkml/20250919-rv-reactor-signal-v1-1-fb0012034158@xxxxxxxxxxxxx/
[1] https://lore.kernel.org/lkml/20251014-mempool-doc-v1-1-bc9ebf169700@xxxxxxxxxxxxx/


Thomas