Re: [PATCH] err.h: use __always_inline on all error pointer helpers

[Alexander Lobakin <aleksander.lobakin@intel.com>]

From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 26 May 2026 23:03:50 +0200

> On Tue, May 26, 2026, at 17:01, Alexander Lobakin wrote:
>> From: Arnd Bergmann <arnd@kernel.org>
>> Date: Tue, 26 May 2026 12:18:41 +0200
>>
>>> From: Arnd Bergmann <arnd@arndb.de>
>>>
>>> While testing randconfig builds on s390, I came across a
>>> link failure with CONFIG_DMA_SHARED_BUFFER disabled:
>>>
>>> ERROR: modpost: "dma_buf_put" [drivers/iommu/iommufd/iommufd.ko] undefined!
>>>
>>> The problem here is that IS_ERR() is not inlined and dead code elimination
>>> fails as a consequence.
>>>
>>> The err.h helpers all turn into a trivial assignment ot a bit mask
>>> and should never result in a function call, so force them to always be
>>> inline. This should generally result in better object code aside from
>>> avoiding the link failure above.
>>
>> bloat-o-meter would be nice to see but optional, it's obvious to me that
>> these helpers should always get inlined.
>>
>> Not sure why compilers sometimes decide to uninline a couple
>> instructions (feels like there's sorta dumb logic "oh it's used more
>> than X times -- uninline no matter what").
> 
> I've run bloat-o-meter on the vmlinux.o file now and indeed it shows
> what is going on: the configuration that triggered this has
> CONFIG_PROFILE_ANNOTATED_BRANCHES, which turns the unlikely()
> bit in IS_ERR() into two extra function calls, so my patch does
> end up adding a bit of bloat (see output below):
> 
>    text	   data	    bss	    dec	    hex	filename
> 20159943	5630468	16199728	41990139	280b7fb	build/s390/0xCED6EE04_defconfig/vmlinux-old.o
> 20217607	5630404	16199728	42047739	28198fb	build/s390/0xCED6EE04_defconfig/vmlinux-new.o
> 
> Without CONFIG_PROFILE_ANNOTATED_BRANCHES, the changes are
> very small, with around 100 functions growing or shrinking
> by a few bytes.
> 
> I don't think we care much about the size increase when that
> option is enabled, but I do wonder what behavior makes more

Yup, and even without this option, __always_inline is better here
regardless of how it affects the size. Such oneliners must be
transparent to the compiler

> sense regarding the annotation for every single IS_ERR(). 
> Does it make sense to have every instance get its own counter,
> or would it make sense to actually try to reduce these
> when profiling the annotations?

I'm not familiar with branch annotations, but from the stats above, it
really looks like it adds a lot of code bloat. Plenty of branches in
the kernel are sorta pointless to track (the ones which trigger once
in a thousand years, the unlikely() ones etc.), I guess.

> 
>        Arnd
Thanks,
Olek