Re: livepatch: reuse module loader code to write relocations
From: Josh Poimboeuf <hidden>
Date: 2016-03-21 21:34:50
Also in:
linux-s390, lkml
On Mon, Mar 21, 2016 at 10:16:17PM +0100, Jiri Kosina wrote:
quoted hunk ↗ jump to hunk
On Mon, 21 Mar 2016, Jessica Yu wrote:quoted
Yes, this is a concern and I'm not sure what the best way to fix it is. If both MODULE_NAME_LEN and KSYM_NAME_LEN were straight up constants, then I think Josh's stringify approach would have worked perfectly. However since MODULE_NAME_LEN translates to an expression (64 - sizeof(unsigned long)), which the preprocessor cannot evaluate, we will need another approach. Building the format strings at run time might be messier than we'd like. Alternatively we could just go the simple route and simply be a bit more aggressive on the upper bound for the format width; though the size of long varies on different architectures, afaik the max size it could ever be on any arch is 8 bytes, so perhaps 64 - 8 = 56 (then - 1 to make room for \0) might be an appropriate field width. This would deserve a comment as well.So how about actually modifying MAX_PARAM_PREFIX_LEN so that it's actually properly evaluable at preprocessing time, i.e. something along the lines ofdiff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h index 52666d9..954dae9 100644 --- a/include/linux/moduleparam.h +++ b/include/linux/moduleparam.h@@ -14,7 +14,7 @@ #endif /* Chosen so that structs with an unsigned long line up. */ -#define MAX_PARAM_PREFIX_LEN (64 - sizeof(unsigned long)) +#define MAX_PARAM_PREFIX_LEN (64 - __SIZEOF_LONG__) #ifdef MODULE #define __MODULE_INFO(tag, name, info) \
According to my test that still results in the literal value of "(64 - 8)". -- Josh