[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMe9rOqzvPARD6srX5BZym2ah1Ga4Z_QuJNQV-GG3d3tQ3RKCg@mail.gmail.com>
Date: Mon, 23 Jul 2018 07:51:35 -0700
From: "H.J. Lu" <hjl.tools@...il.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: Dave Hansen <dave.hansen@...el.com>,
Dave Jones <davej@...emonkey.org.uk>,
"H. Peter Anvin" <hpa@...or.com>,
LKML <linux-kernel@...r.kernel.org>,
Andy Lutomirski <luto@...nel.org>,
Mel Gorman <mgorman@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Rik van Riel <riel@...riel.com>,
Minchan Kim <minchan@...nel.org>
Subject: Re: Kernel 4.17.4 lockup
On Fri, Jul 20, 2018 at 2:35 PM, Andy Lutomirski <luto@...capital.net> wrote:
>
>> On Jul 16, 2018, at 6:05 AM, H.J. Lu <hjl.tools@...il.com> wrote:
>>
>>> On Fri, Jul 13, 2018 at 7:08 PM, Andy Lutomirski <luto@...capital.net> wrote:
>>> I'm not at all convinced that this is the problem, but the series here
>>> will give a better diagnostic if the issue really is an IRQ stack
>>> overflow:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/guard_pages
>>>
>>
>> This kernel won't boot with this configure file.
>
> Bah humbug. You’ll need to turn KASAN off (and maybe even compile it out entirely) if you want to test this. I need to bug the KASAN folks to unbreak their interaction with stacks in vmap space. It’s been broken literally forever, but I keep incorrectly imagining that it’s been fixed already.
>
This particular kernel oops has been fixed by kernel 4.17.7. But now
I am running into
another kernel oops:
https://bugzilla.redhat.com/show_bug.cgi?id=1597559
--
H.J.
Powered by blists - more mailing lists