Re: [peterz-queue:core/rcu 31/33] arch/x86/kernel/alternative.c:961:26: error: inlining failed in call to always_inline 'try_get_desc': function attribute mismatch

[Peter Zijlstra <peterz@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]

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.

A well, can't have it all it seems.