A On Wed, 15 Dec 2021 at 14:24, Mark Rutland <mark.rutland@xxxxxxx> wrote: > > On Tue, Dec 14, 2021 at 05:20:14PM +0100, Alexander Potapenko wrote: > > The new attribute maps to > > __attribute__((disable_sanitizer_instrumentation)), which will be > > supported by Clang >= 14.0. Future support in GCC is also possible. > > > > This attribute disables compiler instrumentation for kernel sanitizer > > tools, making it easier to implement noinstr. It is different from the > > existing __no_sanitize* attributes, which may still allow certain types > > of instrumentation to prevent false positives. > > When you say the __no_sanitize* attributes allow some instrumentation, does > that apply to any of the existing KASAN/KCSAN/KCOV support, or just for KMSAN? > > The documentation just says the same as the commit message: > > | This is not the same as __attribute__((no_sanitize(...))), which depending on > | the tool may still insert instrumentation to prevent false positive reports. > > ... which implies the other instrumentation might not be suprressed. > > I ask because architectures which select ARCH_WANTS_NO_INSTR *need* to be able > to suppress all instrumentation. It's fine if that means they need a new > version of clang for KMSAN, but if there's latent instrumentation we have more > bugs to fix first... Thus far, none of the existing K*SANs added other instrumentation. Apart from KMSAN here, this will change with KCSAN's barrier instrumentation, which is why this patch is also part of KCSAN's upcoming changes -- recall I said I fixed barrier instrumentation for arm64 as well, this is how :-) See https://lore.kernel.org/all/20211130114433.2580590-26-elver@xxxxxxxxxx/ how I resolved it for KCSAN on architectures that don't have objtool. I expect this patch will be dropped from the KMSAN series once it reaches mainline through the KCSAN changes. Also note, this applies only for bug-detection tools, that may want to avoid false positives. So by definition, it is irrelevant for KCOV (which had its own attribute woes a while back though). Yeah, it's been a long road to get the compilers to play along ... :-/ Thanks, -- Marco
