https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #33 from Martin Liška <marxin at gcc dot gnu.org> --- (In reply to Arnd Bergmann from comment #32) > (In reply to Martin Liška from comment #31) > > (In reply to Arnd Bergmann from comment #30) > > > (In reply to Martin Liška from comment #29) > > > > Which is very promising improvement I would say. > > > > > > Agreed, this looks great. With most of the warnings against the > > > 2048 byte limit gone, we can probably work around the remaining > > > ones by doing local code changes in the kernel. I had patches for > > > some of these in the past, which I can dig up then. > > > > Just out of curiosity. Am I right that you're using KASAN build for > > syzkaller or an other fuzzer? If so, I bet you can't hit most of the > > stack overflows in drivers as you very probably don't have the > > real hardware? > > No, I don't do any fuzzing myself. The side project that I'm > interested in here is to build the kernel in all random > configurations without compile-time warnings that may indicate > bugs. I tend to build several hundred such kernels per day to > catch new bugs in both the (linux-next) kernel and in the > toolchain (clang and gcc). Ok, btw. it helped to expose multiple issues in ASAN implementation in GCC. So then it's useful even though you're then not running the instrumented kernels.
