Re: [PATCH] Handle clock_gettime(CLOCK_TAI) in VDSO

[David Woodhouse]

On Tue, 2018-08-14 at 07:20 -0700, Andy Lutomirski wrote:
> > +ÂÂÂÂÂÂ /* Doubled switch statement to work around kernel Makefile error */
> > +ÂÂÂÂÂÂ /* See: https://www.mail-archive.com/gcc-bugs@xxxxxxxxxxx/msg567499.htmlÂ*/
> 
> NAK.
> 
> The issue here (after reading that thread) is that, with our current
> compile options, gcc generates a jump table once the switch statement
> hits five entries. And it uses retpolines for it, and somehow it
> generates the relocations in such a way that the vDSO build fails.Â
> We
> need to address this so that the vDSO build is reliable, but there's
> an important question here:
> 
> Should the vDSO be built with retpolines, or should it be built with
> indirect branches? Or should we go out of our way to make sure that
> the vDSO contains neither retpolines nor indirect branches?
> 
> We could accomplish the latter (sort of) by manually converting the
> switch into the appropriate if statements, but that's rather ugly.
> 
> (Hmm. We should add exports to directly read each clock source.
> They'll be noticeably faster, especially when
> cache-and-predictor-code.)

Surely it's kind of expected that the vDSO can't find an externally
provided __x86_indirect_thunk_rax symbol, since we only provide one as
part of the kernel image.

Building the vDSO with -mindirect-branch=thunk(|-inline) should fix
that, if we want retpolines in the vDSO.

There's also -fno-jump-tables.

Attachment: smime.p7s
Description: S/MIME cryptographic signature