On 11/02/2018 04:46 AM, Linus Torvalds wrote: > On Thu, Nov 1, 2018 at 10:06 AM Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >> >> The logic for using __no_sanitize_address *used* to be >> >> #if GCC_VERSION >= 40902 > > Ok, looking around, I think this has less to do with the attribute > being recognized, and simply just being because KASAN itself wants > gcc-4.9.2. > > I'm actually not seeing that KASAN dependency in the Kconfig scripts > (and it probably _should_ be now that we can just add compiler version > dependencies there), but that explains why the gcc version check is > different from "gcc supports the attribute". > > Anyway, I decided to do the merge by just getting rid of the > GCC_VERSION check around __no_sanitize_address_or_inline entirely. If > you enable KASAN, then a function with that marking just won't be > marked inline. > > End result: pulled. I'm as confused as you are as to why > __no_sanitize_address_or_inline is in the gcc header, but I guess it > ends up being the same issue: KASAN depends on gcc even if that > dependency doesn't seem to be spelled out in lib/Kconfig.kasan. > > So I _think_ the KASAN config should have a > > depends on CC_IS_GCC && GCC_VERSION >= 40902 > > on it, but maybe there is something I'm missing. > I'd rather use cc-option instead of version check, since we also support clang. It should be possible to express compiler requirements for subfeatures like stack/inline instrumentation in Kconfig. But that would be not that trivial, see the scripts/Makefile.kasan > But from a pull standpoint, I don't want to mess with those > (unrelated) issues, so I just kept the merge resolution as simple and > straightforward as possible. > > Miguel, please do double-check the merge (it's not pushed out yet, I'm > doing the usual build tests etc first). > > Linus >
