The information gathering scripts may have taken my host kernel 4.20) I'll double check from proc/config.g

Sent from ProtonMail mobile

-------- Original Message --------
On Jan 10, 2019, 4:03 PM, Qian Cai wrote:

> On Thu, 2019-01-10 at 20:47 +0000, Esme wrote:
>> Sure thing;
>>
>> cmdline;
>> qemu-system-x86_64 -kernel linux//arch/x86/boot/bzImage -append console=ttyS0
>> root=/dev/sda debug earlyprintk=serial slub_debug=QUZ -hda stretch.img -net
>> user,hostfwd=tcp::10021-:22 -net nic -enable-kvm -nographic -m 2G -smp 2
>> -pidfile
>>
>> CONFIG_PAGE*; (full file attached);
>>
>> # CONFIG_DEBUG_PAGEALLOC is not set
>> CONFIG_PAGE_POISONING=y
>> CONFIG_PAGE_POISONING_NO_SANITY=y
>> # CONFIG_PAGE_POISONING_ZERO is not set
>> # CONFIG_DEBUG_PAGE_REF is not set
>> CONFIG_FAIL_PAGE_ALLOC=y
>
> Confused.
>
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1896410.html
>
> It said 5.0.0-rc1+
>
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1896410/repro.repor
> t
>
> It said 4.20.0+, and it also have,
>
> "general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI"
>
> which indicated CONFIG_DEBUG_PAGEALLOC=y but your .config said NO.
>
> However, it looks like a mess that KASAN does not play well with all those
> SLUB_DEBUG, CONFIG_DEBUG_PAGEALLOC etc, because it essentially step into each
> others' toes by redzoning, poisoning in allocate and free pages.