Messages in this thread Patch in this message | | | Subject | Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! | From | Tommi Rantala <> | Date | Fri, 31 Mar 2017 09:59:44 +0300 |
| |
On 31.03.2017 08:40, Tommi Rantala wrote: >> The only thing that I can think of would be a rogue ptr in the bios >> table, but that seems unlikely. Tommi, can you put strace of x86info >> -mp somewhere? >> That will confirm/deny whether we're at least asking the kernel to do >> sane things. > > Indeed the bug happens when reading from /dev/mem: > > https://pastebin.com/raw/ZEJGQP1X > > # strace -f -y x86info -mp > [...] > open("/dev/mem", O_RDONLY) = 3</dev/mem> > lseek(3</dev/mem>, 1038, SEEK_SET) = 1038 > read(3</dev/mem>, "\300\235", 2) = 2 > lseek(3</dev/mem>, 646144, SEEK_SET) = 646144 > read(3</dev/mem>, > "\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., > 1024) = 1024 > lseek(3</dev/mem>, 1043, SEEK_SET) = 1043 > read(3</dev/mem>, "w\2", 2) = 2 > lseek(3</dev/mem>, 645120, SEEK_SET) = 645120 > read(3</dev/mem>, > "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., > 1024) = 1024 > lseek(3</dev/mem>, 654336, SEEK_SET) = 654336 > read(3</dev/mem>, > "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., > 1024) = 1024 > lseek(3</dev/mem>, 983040, SEEK_SET) = 983040 > read(3</dev/mem>, > "IFE$\245S\0\0\1\0\0\0\0\360y\0\0\360\220\260\30\237{=\23\10\17\0000\276\17\0"..., > 65536) = 65536 > lseek(3</dev/mem>, 917504, SEEK_SET) = 917504 > read(3</dev/mem>, > "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., > 65536) = 65536 > lseek(3</dev/mem>, 524288, SEEK_SET) = 524288 > read(3</dev/mem>, <unfinished ...>) = ? > +++ killed by SIGSEGV +++
That last read is done in mptable.c:347, trying to read GROPE_AREA1.
# ./x86info --debug x86info v1.31pre get_intel_topology: Siblings: 2 Physical Processor ID: 0 Processor Core ID: 0 get_intel_topology: Siblings: 2 Physical Processor ID: 0 Processor Core ID: 1 get_intel_topology: Siblings: 2 Physical Processor ID: 0 Processor Core ID: 2 get_intel_topology: Siblings: 2 Physical Processor ID: 0 Processor Core ID: 3 get_intel_topology: Siblings: 2 Physical Processor ID: 0 Processor Core ID: 0 get_intel_topology: Siblings: 2 Physical Processor ID: 0 Processor Core ID: 1 get_intel_topology: Siblings: 2 Physical Processor ID: 0 Processor Core ID: 2 get_intel_topology: Siblings: 2 Physical Processor ID: 0 Processor Core ID: 3 Found 8 identical CPUs EBDA points to: 9dc0 EBDA segment ptr: 9dc00 Segmentation fault
If I comment out the GROPE_AREA1 read, the same kernel bug still happens with the GROPE_AREA2 read.
Removing both GROPE_AREA1 and GROPE_AREA2 reads avoids the crash:
$ git diff diff --git a/mptable.c b/mptable.c index 480f19b..00fff35 100644 --- a/mptable.c +++ b/mptable.c @@ -342,6 +342,7 @@ static int apic_probe(unsigned long* paddr) }
/* search additional memory */ + /* target = GROPE_AREA1; seekEntry(target); if (readEntry(buffer, GROPE_SIZE)) { @@ -371,6 +372,7 @@ static int apic_probe(unsigned long* paddr) return 6; } } + */
*paddr = (unsigned long)0; return 0; # ./x86info -mp x86info v1.31pre Found 8 identical CPUs Extended Family: 0 Extended Model: 5 Family: 6 Model: 94 Stepping: 3 Type: 0 (Original OEM) CPU Model (x86info's best guess): Unknown model. Processor name string (BIOS programmed): Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
Total processor threads: 8 This system has 1 quad-core processor with hyper-threading (2 threads per core) running at an estimated 2.70GHz #
-Tommi
| |