* Rafael J. Wysocki rafael@kernel.org wrote:
On Thu, Mar 14, 2024 at 4:05 PM Dave Hansen dave.hansen@intel.com wrote:
On 3/14/24 07:26, Anton Altaparmakov wrote:
/* image of the saved processor state */ struct saved_context {
/** On x86_32, all segment registers except gs are saved at kernel* entry in pt_regs.*/u16 gs; unsigned long cr0, cr2, cr3, cr4; u64 misc_enable; struct saved_msrs saved_msrs;@@ -27,6 +22,11 @@ struct saved_context { unsigned long tr; unsigned long safety; unsigned long return_address;
/** On x86_32, all segment registers except gs are saved at kernel* entry in pt_regs.*/u16 gs; bool misc_enable_saved;} __attribute__((packed));
Isn't this just kinda poking at the symptoms? This seems to be basically the exact same bug as b0b592cf08, just with a different source of unaligned structure members.
There's nothing to keep folks from reintroducing these kinds of issues and evidently no way to detect when they happen without lengthy reproducers.
This change is fine with me FWIW,
thx, I've added your:
Acked-by: "Rafael J. Wysocki" rafael@kernel.org
but I agree that making it for kmemleak reasons feels kind of misguided.
Yeah, so it's a workaround, but kmemleak is also a useful debugging facility that is finding memory leaks that static checkers are missing.
The fact that we don't have an easy way to prevent these problems from being introduced is I think properly counterbalanced by the facts that:
1) Only kmemleak users are inconvenienced by the false positives.
2) kmemleak users & maintainers have created the patch. There was no pressure on us x86 maintainers other than to apply a root-cause analyzed patch.
2) Over a timespan of ~10 years only 2 such alignment problems were introduced, and they were fixed by the kmemleak folks. I think that's a fair price to pay for a useful facility.
Ie. I don't think there's any long-term maintenance burder concern.
So I've applied this workaround to x86/urgent, with a change to the title to make sure this isn't understood as a real bug in the PM code, but a workaround:
37fb408c99af x86/pm: Work around false positive kmemleak report in msr_build_context()
... lemme know if you feel strongly about this. :-)
Thanks,
Ingo