Re: [PATCHv3] gcc: disable '-Wstrignop-overread' universally for gcc-13+ and FORTIFY_SOURCE

[Yury Norov <yury.norov@gmail.com>]

On Mon, Dec 09, 2024 at 01:03:00PM -0700, Nathan Chancellor wrote:
> Maybe people are not using CONFIG_WERROR=y and W=e when hitting this so
> they do not notice? It also only became visible in 6.12 because of the
> 'inline' -> '__always_inline' changes in bitmap.h and cpumask.h, since
> prior to that, the size of the objects being passed to memcpy() were not
> known, so FORTIFY could not catch them (another +1 for that change).

Thanks, but I'm actually not happy with that series (ab6b1010dab68f6d4).
The original motivation was that one part of compiler decided to outline
the pure wrappers or lightweight inline implementation for small bitmaps,
like those fitting inside a machine word. 

After that, another part of compiler started complaining that outlined
helpers mismatch the sections - .text and .init.data.

(Not mentioning that the helpers were not designed to be real outlined
functions, and doing that adds ~3k to kernel image.)

I don't like forcing compiler to do this or that, but in this case I
just don't know how to teach it to outline the function twice, if it
wants to do that. This should be done automatically, I guess...

Similarly, I don't know how to teach it to keep the functions inlined,
other than forcing it to do so. I really wonder what made it thinking
that this deserves to be a real function:

 static __always_inline
 bool cpumask_andnot(struct cpumask *dstp, const struct cpumask *src1p,
                     const struct cpumask *src2p)
 {
         return bitmap_andnot(cpumask_bits(dstp), cpumask_bits(src1p),
                                           cpumask_bits(src2p), small_cpumask_bits);
 }

I guess, there are more 'functions' of that sort that outlined for nothing
in the kernel, and who knows how bloated is it?