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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251114094900-ca266dde-cf71-4536-882d-dcc8591fe6bd@linutronix.de>
Date: Fri, 14 Nov 2025 10:13:40 +0100
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Vlastimil Babka <vbabka@...e.cz>, Christoph Hellwig <hch@....de>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>, 
	Andrew Morton <akpm@...ux-foundation.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 
	Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: manual merge of the slab tree with the mm-unstable
 tree

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@linutronix.de/
[1] https://lore.kernel.org/lkml/20251014-mempool-doc-v1-1-bc9ebf169700@linutronix.de/


Thomas