On Thu, Mar 5, 2020 at 9:29 PM Peter Zijlstra <peterz(a)infradead.org> wrote:
On Thu, Mar 05, 2020 at 09:13:26PM +0100, Dmitry Vyukov wrote:
> > 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.
Right, so I'd completely understand the compiler yelling at me if the
functions were indeed instantiated, but exactly because of the
force-inline I was expecting it to actually work.
But then the compiler will start to silently and randomly sanitizing
functions that developer asked to not sanitize and not sanitizing that
developers asked to sanitize, without any developer visibility and
It's just happens so that in this single, very particular case it's
what you would need. But there are lots and lots of cases where it's
the opposite of what you would want. Say, consider, poke_int3_handler
gets inlines in LTO build, and compiler says: you know what, I am just
going to silently ignore your no_sanitize attribute to give you fun of
re-debugging the issue you think you fixed ;)