On Mon, 2018-01-08 at 14:27 -0800, Andi Kleen wrote: > On Mon, Jan 08, 2018 at 09:35:26PM +0000, David Woodhouse wrote: > > On Mon, 2018-01-08 at 13:32 -0800, H.J. Lu wrote: > > > On Mon, Jan 8, 2018 at 8:46 AM, Andi Kleen <a...@linux.intel.com> wrote: > > > > > > > > "H.J. Lu" <hjl.to...@gmail.com> writes: > > > > > > > > > > > > > > > > > > > > > > > Talking about PIC thunks, those have I believe . character in their > > > > > > symbols, > > > > > > so that they can't be confused with user functions. Any reason > > > > > > these > > > > > > retpoline thunks aren't? > > > > > > > > > > > They used to have '.'. It was changed at the last minute since > > > > > kernel needs to > > > > > export them as regular symbols. > > > > The kernel doesn't actually need that to export the symbols. > > > > > > > > While symbol CRCs cannot be generated for symbols with '.', CRCs are not > > > > needed and there were already patches to hide the resulting warnings. > > > > > > > Andi, can you work it out with David? > > > > It wasn't CONFIG_MODVERSIONS but CONFIG_TRIM_UNUSED_SYMBOLS which was > > the straw that broke the camel's back on that one. I'm open to a > > solution for that one, but I couldn't see one that didn't make my eyes > > bleed. Except for making the symbols not have dots in. > > > > https://patchwork.kernel.org/patch/10148081/ > > I guess we can stay with it the underscore version in the compiler now. > > In theory it could conflict with something used in C, but the risk > is probably low.
If it makes anyone happier, we could perhaps stick with the dot version for the *inline* thunks but only use underscores for the external one? But really, any "innocent user" claiming to be *surprised* after writing their own C function and calling it __x86_indirect_thunk_rax is surely taking the piss.
smime.p7s
Description: S/MIME cryptographic signature
