Re: [PATCH] netlink: move nla_put_{u8,u16,u32} out of line

[Arnd Bergmann]

On Thursday, February 9, 2017 4:51:25 PM CET Dmitry Vyukov wrote:
> On Thu, Feb 9, 2017 at 3:33 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> >>>
> >>> Thanks for the list, that looks very helpful. The ones I found myself
> >>> seem to be a strict (and small) subset of those, using gcc-7.0.1 on x86-64
> >>> with allmodconfig and a few hundred randconfig builds. Which compiler
> >>> version did you use for your testing? If new versions are better than old
> >>> ones, we could start by fixing the ones that are still present in gcc-6 and
> >>> gcc-7, and making the warning conditionally on the compiler version.
> >>>
> >>> Another idea might be to separate out asan_stack=1 into a separate
> >>> Kconfig option and warn if that is enabled with compilers that are known
> >>> to be relatively bad it keeping the stack small.
> >>
> >>
> >> Mine is gcc version 7.0.0 20161208. Make sure you enable KASAN_INLINE
> >> and I also enabled CONFIG_KCOV. Other than that I just did
> >> allyesconfig + make -k.
> >
> > Ok, I see my mistake now: On the allmodconfig build, I had KASAN_INLINE
> > disabled, which made the problem go away for almost all files (almost all
> > frame sizes are below 2048 bytes, except for the two issues I posted patches
> > for (hisilicon ethernet driver, and nla_put_* users).
> >
> > On the randconfig build test, I have a long series of patches applied that
> > address all known warnings, including my earlier "kasan: turn off
> > -fsanitize-address-use-after-scope for now" (see
> > https://patchwork.kernel.org/patch/9442323/). Without
> > -fsanitize-address-use-after-scope, the problem is also mostly gone
> > (a few cases show up in drivers/media/, and also in block/sed-opal.c
> > and drivers/tty/vt/keyboard.c). I now have initial patches for all of
> > them to bring the stack size below 2048 bytes.
> >
> > As far as I can see, the remaining problems with scary stack frame sizes
> > you found only show up with the combination of all three: KASAN_INLINE,
> > asan_stack=1 and -fsanitize-address-use-after-scope. If all three were
> > separately configurable and we merge the patches I made, I think we could
> > enable the normal 2048 byte warning in all configurations that have at least
> > one of the turned off, but I don't know which of those combinations would
> > actually be sensible for production kernels.
> 
> FWIW I use all of them (+KCOV which is additional instrumentation).
> If you ask which is the least important one, it is
> -fsanitize-address-use-after-scope. I have not see any single report
> due to it (probably due to kernel coding style).

Ok, I'm testing with this patch now and will let you know if I run
into any other warnings on my x86 randconfig build. I'll also try
to get some results from other compiler versions and architectures.

Let me know what you think of this approach.

	Arnd