On 10/23/2014 02:00 PM, Jakub Jelinek wrote: > On Thu, Oct 23, 2014 at 11:55:32AM +0200, Jakub Jelinek wrote: >> On Thu, Oct 23, 2014 at 01:51:12PM +0400, Andrey Ryabinin wrote: >>> IMO we don't need different versions of __asan_load* and >>> __asan_load*_noabort, because >>> -fno-sanitize-recover=kernel-address will never work with the linux kernel. >>> >>> I already said this before, and repeat this once again: >>> There is few places in kernel where we validly touch poisoned memory, >>> so we need to disable error reporting in runtime for such memory accesses. >>> I use per-thread flag which is raised before the valid access to poisoned >>> memory. >>> This flag checked in __asan_report*() function. If it raised then we >>> shouldn't print any error message, >>> just silently exit from report. >> >> Can't you just use __attribute__((no_sanitize_address)) on the functions >> that have such a code? Or you could use special macros for those accesses >> (which could e.g. call function to read memory or write memory, implemented >> in assembly or in __attribute__((no_sanitize_address)) function), or >> temporarily unpoison and poison again. > > Also, if you always rely on recovery for kernel-address, wonder why all the > effort to make it optional (when it could be decided based on > flag_sanitize & SANITIZE_KERNEL_ADDRESS), and whether I should wait > with 4.9.2-rc1 for that (given that 4.9 branch now has kasan support > backported, but not -fsanitize-recover (neither old style, nor new style)). > I'd really like to release 4.9.2 soon... >
-fsanitize-recover needed only for inline instrumentation, and 4.9 don't support inline instrumentation for kernel-address. There is no reason to delay release unless you want to see inline support in 4.9. > Jakub >
