On Thu, Mar 5, 2020 at 7:47 PM Peter Zijlstra <peterz(a)infradead.org> wrote:
On Thu, Mar 05, 2020 at 05:29:27PM +0100, Dmitry Vyukov wrote:
> On Thu, Mar 5, 2020 at 4:55 PM Peter Zijlstra <peterz(a)infradead.org> wrote:
> > On Thu, Mar 05, 2020 at 04:23:11PM +0100, Dmitry Vyukov wrote:
> > > Compilers just don't allow this: asking to inline sanitized function
> > > into a non-sanitized function. But I don't know the
> > > code good enough to suggest the right alternative (don't call
> > > user_mode, copy user_mode, or something else).
> > Does it work if we inline into a .c file and build it with:
> > KASAN_SANITIZE := n
> > UBSAN_SANITIZE := n
> > KCOV_INSTRUMENT := n
> > Which would be effectively the very same, just more cumbersome.
> I think it should work, because then user_mode will also not be instrumented.
Right, but then I have to ask how this is different vs inlining things
into a __no_sanitize function.
We ask compiler to do slightly different things in these cases. In the
original case we asked to sanitize user_mode. If we have a separate
file, we ask to not sanitize user_mode. A more explicit analog of this
would be to introduce user_mode2 with no_sanitize attribute and call
it from the poke_int3_handler.
Strictly saying what you are going to do is sort of ODR violation,
because now we have user_mode that is sanitized and another user_mode
which is not sanitized (different behavior). It should work for
force_inline functions because we won't actually have the user_mode
symbol materizalied. But generally one needs to be careful with such
tricks, say if the function would be inline and compiled to a real
symbol, an instrumented or non-instrumented version will be chosen
randomly and we may end up with silent unexpected results.