On Thu, Oct 23, 2014 at 02:33:42PM +0400, Yury Gribov wrote:
Actually this is a historical artifact. If inlining proves to be
significantly faster, they may want to switch.
Ok.
So, at that point you can include your ugly hacks in __asan_load* logic in
the kernel, the difference between __asan_load4 and __asan_load4_noabort
will be just that the latter will always return, while the former will not
if some error has been reported.
All the __asan_load* and __asan_store* entrypoints, regardless of
-f{,no-}sanitize-recover=kernel-address are by definition not noreturn, they
in the common case (if the code is not buggy) return.
Perhaps we should just keep __asan_load* as is and leave the decision
whether to abort or continue for the runtime? This would make semantics of
-fsanitize-recover cumbersome though (because it wouldn't work if user
selects outline instrumentation).
Well, the "don't ever report anything while some per-CPU flag is set" thing
can be considered as part of the "is this memory access ok" test, it is
pretending everything is accessible.
But, otherwise, if it is supposed to be developer's decision at compile
time, __asan_load*_noabort should better always continue, even if it
reported issues, and __asan_load* should better not return after reporting
errors.