Re: [PATCH 1/3] lockref: add a __cond_lock annotation for lockref_put_or_lock

[Linus Torvalds]

[ 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@xxxxxx> 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