[PATCH v6 8/8] x86/kernel: jump_table: use relative references
From: rostedt@goodmis.org (Steven Rostedt)
Date: 2017-12-28 16:39:23
Also in:
linux-mips, linuxppc-dev, lkml, sparclinux
From: rostedt@goodmis.org (Steven Rostedt)
Date: 2017-12-28 16:39:23
Also in:
linux-mips, linuxppc-dev, lkml, sparclinux
On Thu, 28 Dec 2017 16:26:07 +0000 Ard Biesheuvel [off-list ref] wrote:
On 28 December 2017 at 16:19, Steven Rostedt [off-list ref] wrote:quoted
On Wed, 27 Dec 2017 08:50:33 +0000 Ard Biesheuvel [off-list ref] wrote:quoted
static inline jump_label_t jump_entry_code(const struct jump_entry *entry) { - return entry->code; + return (jump_label_t)&entry->code + entry->code;I'm paranoid about doing arithmetic on abstract types. What happens in the future if jump_label_t becomes a pointer? You will get a different result.In general, I share your concern. In this case, however, jump_label_t is typedef'd three lines up and is never used anywhere else.
I would agree if this was in a .c file, but it's in a header file, which causes me to be more paranoid.
quoted
Could we switch these calculations to something like: return (jump_label_t)((long)&entrty->code + entry->code);jump_label_t is local to this .h file, so it can be defined as u32 or u64 depending on the word size. I don't mind adding the extra cast, but I am not sure if your paranoia is justified in this particular case. Perhaps we should just use 'unsigned long' throughout?
Actually, that may be better. Have the return value be jump_label_t,
but the cast be "unsigned long". That way it should always work.
static inline jump_label_t jump_entry_code(...)
{
return (unsigned long)&entry->code + entry->code;
}
-- Steve