On Fri, Jul 15, 2022 at 09:42AM +0200, Alexander Potapenko wrote: [...] > > This sentence might still be confusing. I think it should highlight > > that runtime and compiler go together, but depending on the scope of > > the value, the compiler invokes the runtime to persist the shadow. > > Changed to: > """ > Compiler instrumentation also tracks the shadow values as they are used along > the code. When needed, instrumentation code invokes the runtime library in > ``mm/kmsan/`` to persist shadow values. > """ Ack. [...] > > > +Passing uninitialized values to functions > > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > + > > > +KMSAN instrumentation pass has an option, ``-fsanitize-memory-param-retval``, > > > > "KMSAN instrumentation pass" -> "Clang's instrumentation support" ? > > Because it seems wrong to say that KMSAN has the instrumentation pass. > How about "Clang's MSan instrumentation pass"? Maybe just "Clang's MemorySanitizer instrumentation" - no abbreviation, and "pass" is very compiler-implementation specific and not everyone might know what "pass" even means in this context, so I'd leave it out. [...] > > It would be useful to move this section somewhere to the beginning, > > closer to usage and the example, as this is information that a user of > > KMSAN might want to know (but they might not want to know much about > > how KMSAN works). > > I restructured the TOC as follows: > > == The Kernel Memory Sanitizer (KMSAN) > == Usage > --- Building the kernel > --- Example report > --- Disabling the instrumentation > == Support > == How KMSAN works > --- KMSAN shadow memory > --- Origin tracking > ~~~~ Origin chaining > --- Clang instrumentation API > ~~~~ Shadow manipulation > ~~~~ Handling locals > ~~~~ Access to per-task data > ~~~~ Passing uninitialized values to functions > ~~~~ String functions > ~~~~ Error reporting > ~~~~ Inline assembly instrumentation > --- Runtime library > ~~~~ Per-task KMSAN state > ~~~~ KMSAN contexts > ~~~~ Metadata allocation > == References LGTM. Thanks, -- Marco
