Re: [PATCH 0/4] printk_index: Fix false positives

[Petr Mladek]

On Wed 2024-02-28 15:00:01, Geert Uytterhoeven wrote:
> 	Hi all,
> 
> When printk-indexing is enabled, each printk() invocation emits a
> pi_entry structure, containing the format string and other information
> related to its location in the kernel sources.  This is even true when
> the printk() is protected by an always-false check, as is typically the
> case for debug messages: while the actual code to print the message is
> optimized out by the compiler, the pi_entry structure is still emitted.
> Hence when debugging is disabled, this leads to the inclusion in the
> index of lots of printk formats that cannot be emitted by the current
> kernel.
> 
> This series fixes that for the common debug helpers under include/.
> It reduces the size of an arm64 defconfig kernel with
> CONFIG_PRINTK_INDEX=y by ca. 1.5 MiB, or 28% of the overhead of
> enabling CONFIG_PRINTK_INDEX=y.
> 
> Notes:
>   - netdev_(v)dbg() and netif_(v)dbg() are not affected, as
>     net{dev,if}_printk() do not implement printk-indexing, except
>     for the single global internal instance of __netdev_printk().
>   - This series fixes only debug code in global header files under
>     include/.  There are more cases to fix in subsystem-specific header
>     files and in sources files.
> 
> Thanks for your comments!
> 
> Geert Uytterhoeven (4):
>   printk: Let no_printk() use _printk()
>   dev_printk: Add and use dev_no_printk()
>   dyndbg: Use *no_printk() helpers
>   ceph: Use no_printk() helper
> 
>  include/linux/ceph/ceph_debug.h | 18 +++++++-----------
>  include/linux/dev_printk.h      | 25 +++++++++++++------------
>  include/linux/dynamic_debug.h   |  4 ++--
>  include/linux/printk.h          |  2 +-
>  4 files changed, 23 insertions(+), 26 deletions(-)

The whole series looks good to me:

Reviewed-by: Petr Mladek <pmladek@xxxxxxxx>

I am going take it via printk tree for 6.10.

I am sorry that I haven't looked at it in time before the merge
window for 6.9. I have been snowed under various tasks. The changes
are not complicated. But they also are not critical to be pushed
an expedite way.

Best Regards,
Petr