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] [day] [month] [year] [list]

Message-ID: <66a3f286-04d4-48f4-93d7-6c9254ff1f97@suse.cz>
Date: Thu, 20 Nov 2025 18:51:28 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
 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 11/20/25 14:31, Thomas Weißschuh wrote:
> On Fri, Nov 14, 2025 at 12:55:38PM +0100, Christoph Hellwig wrote:
>> On Fri, Nov 14, 2025 at 10:13:40AM +0100, Thomas Weißschuh wrote:
>> > We have the 'Context:' tag in kdoc. What about the following?
>> > 
>> > 	Context: Any context. Takes and releases pool->lock.
>> 
>> Which in this case would be ok.  But what about functions that take
>> non-irqsave spinlocks?
>> 
>> > I used the function in a tracepoint handler [0] and trusted its documentation
>> > to "never sleep". That turned out to be incorrect.
>> 
>> Heh, you'll find a lot of those..
> 
> Yeah... But people are working on fixing them.
> 
>> > Also see the discussion on the patch submission [1] about just this point,
>> > where we didn't come up with better wording.
>> 
>> Can we please start a discussion on this on say linux-doc and
>> linux-kernel?  I don't really have a good answer, but this current
>> idea feels a bit lacking.  I don't meant that as trying to block
>> this patch, but I think we need to come up with a better convention.
> 
> Make sense. Right now I don't really have the capacity to see this through,
> but hopefully I get to it later.
> My patch not really critical, so if it gets in the way it can be dropped.
> Nearly nobody is using this function anyways.
I've left your patch in the slab/for-next as-is.