linux-kernel - Re: [PATCH 1/3] lockref: add a __cond_lock annotation for lockref_put_or

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: <CAADWXX_ORdj=PaW5oeMybV6sEV6UxbZnRw4=TDZpa1Ejt0vbJQ@mail.gmail.com>
Date: Fri, 14 Nov 2025 10:18:24 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Christoph Hellwig <hch@....de>
Cc: Carlos Maiolino <cem@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, 
	Luc Van Oostenryck <luc.vanoostenryck@...il.com>, Chris Li <sparse@...isli.org>, 
	linux-sparse@...r.kernel.org, linux-xfs@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] lockref: add a __cond_lock annotation for lockref_put_or_lock

[ Christoph, while I have some minor comments on the patch, the
primary reason for this reply is actually that this was in my spam
box.

  Your email sending is violating DKIM rules: your "From:" is
"lst.de", but you use "infradead.org" as your SMTP server, and the
DKIM signature then has d=infradead.org as a result.

  That's a so-called "alignment" failure, and is pretty fundamental
and a sign of spam. You can't verify that an email is from a valid
address by then using a different domain entirely as the "look, trust
me" thing.

  So your emails all end up with dmarc failures, and then are much
more likely to be marked as spam. ]

On Thu, Nov 13, 2025 at 9:54 PM Christoph Hellwig <hch@....de> wrote:
>
> -bool lockref_put_or_lock(struct lockref *lockref);
> +bool _lockref_put_or_lock(struct lockref *lockref);
> +#define lockref_put_or_lock(_lockref) \
> +       (!__cond_lock((_lockref)->lock, !_lockref_put_or_lock(_lockref)))

I don't think this is wrong per se, but rather than rename the
function, I wonder if it wouldn't be simpler to just have a

  #undef lockref_put_or_lock

in lib/lockref.c and just keep the same name for the function and the macro.

Macro expansion isn't recursive, and having

    #define a(x) something-something a(x)

is actually perfectly fine, and something we do intentionally for
other reasons (typically because it also allows us to then use "#ifdef
a" to check whether there is some architecture-specific implementation
of 'a()')

And yes, you do need that "#undef" to then not get crazy parse errors
in the actual definition and export of the function, but it would
allow us to avoid yet another "underscore version of the function".

I dunno. Not a big deal, but it seems annoying to make up a new name for this.

            Linus