https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
Bug ID: 108552
Summary: Linux i386 kernel 5.14 memory corruption for
pre_compound_page() when gcov is enabled
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: feng.tang at intel dot com
Target Milestone: ---
Created attachment 54345
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54345&action=edit
objdump of prep_compound_page()
0Day found a i386 Linux kernel boot issue, and bisection shows the first bad
commit is 7118fc2906e29 ("hugetlb: address ref count racing in
prep_compound_gigantic_page"). It happens 94 times out of 999 runs. Details and
some debug analysis from Linus/Vlastimil and us could be found in the following
link:
https://lore.kernel.org/lkml/202301170941.49728982-oliver.s...@intel.com/t/
Debug shows it is related with one function prep_compound_page() in
mm/page_alloc.c:
* If we use '#pragma GCC optimize ("O1")' for that function (kernel normally
uses O2), the issue will be gone
* If we disable GCOV for page_alloc.c, can't reproduce it
* If we disable UBSAN for page_alloc.c, can't reproduce it
* Not reproducable for x86_64 build
It seems to be a loop corruption, the pesudo code is:
for (i = 1; i < nr_pages; i++)
set_meta_data(page[i];
It should happen for page[1]...page[nr_pages - 1], but from memory dump, seems
that one more page, the page[nr_pages] is also called with set_meta_data[].
https://lore.kernel.org/all/202212312021.bc1efe86-oliver.s...@intel.com/t/
The kernel log, i386 config and the objdump of prep_compound_page() of first
bad commit are attached, please let know if you need more info, thanks!
