On Mon, Apr 16, 2018 at 10:01 AM, Shuah Khan <shua...@osg.samsung.com> wrote:
> [ 884.496588] BUG: unable to handle kernel paging request at fffffe8000010030
This is the LDT remap area.
> [ 884.496614] Oops: 0009 [#1] SMP KASAN PTI
This is RSVD + P, so it's a system read access that got a protection
fault due to reserved bits.
> [ 884.496741] RIP: 0033:0x4031c2
> [ 884.496745] RSP: 002b:00007ffd805b56d8 EFLAGS: 00010246
This is not actually a kernel paging request, it's all user space, but
it's user space that does a system access.
That's normal - something loading a segment in user space, and thus
accessing the system LDT.
> [ 884.496601] PGD 372870067 P4D 372870067 PUD 346e84067 PMD 34005f067 PTE
WTF? What's that odd bogus PTE entry?
That's also why it gets a RSVD fault. That's just garbage. All-ones is
not a valid PTE.
The other levels look valid, although it strikes me that maybe we
shouldn't have the user bit set in the kernel page tables. I realize
that we clear it at the leaf node, but..
So the user page table is somehow badly set up.
I don't see *why* it would be badly set up, and that test works fine
for me, though.
It doesn't seem to have anything to do with KASAN, although
> [ 884.650095] BUG: unable to handle kernel paging request at fffffe8000000000
> [ 884.650103] PGD 363699067 P4D 363699067 PUD 3371c6067 PMD 37cfbc067 PTE
> [ 884.650112] Oops: 0009 [#2] SMP KASAN PTI
> [ 884.650200] RIP: 0033:0x401471
> [ 884.650203] RSP: 002b:00007fc8e6775eb0 EFLAGS: 00010206
The other one is exactly the same thing.