From: John Hubbard <jhubb...@nvidia.com>
Hi,
I just ran across this on the latest (well, any -rc1) linux.git, while
working on something else. It generates an ugly multiline warning:
In file included from arch/x86/kernel/head64.c:35:
In function ?sanitize_boot_params?,
inlined from ?copy_bootdata? at arch/x86/kernel/head64.c:391:2:
./arch/x86/include/asm/bootparam_utils.h:40:3: warning:
?memset? offset [197, 448] from the object at ?boot_params? is out
of the bounds of referenced subobject ?ext_ramdisk_image? with type
?unsigned int? at offset 192 [-Warray-bounds]
40 | memset(&boot_params->ext_ramdisk_image, 0,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
41 | (char *)&boot_params->efi_info -
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
42 | (char *)&boot_params->ext_ramdisk_image);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./arch/x86/include/asm/bootparam_utils.h:43:3: warning: ?memset?
offset [493, 497] from the object at ?boot_params? is out of the
bounds of referenced subobject ?kbd_status? with type
?unsigned char? at offset 491 [-Warray-bounds]
43 | memset(&boot_params->kbd_status, 0,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
44 | (char *)&boot_params->hdr -
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~
45 | (char *)&boot_params->kbd_status);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It looks like this hasn't been touched since 2013, so maybe gcc is
just getting more agressive about warnings. Well, we know it is, actually.
Because struct boot_params is __packed__, normal variable
variable assignment will work just as well as a memset here.
Change three u32 fields to be cleared to zero that way, and
just memset the _pad4 field.
This clears up the build warnings for me.
Testing: just did a basic boot test on my x86_64 machine, no problems
seen. Not that that tests much, but it's something.
John Hubbard (1):
x86/boot: clear some fields explicitly
arch/x86/include/asm/bootparam_utils.h | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
--
2.22.0
