[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANsGZ6ZdJNxxYbARYCxNHvxwUsQTnBqZZ3SbpUS3aHg1jRF6SA@mail.gmail.com>
Date: Thu, 4 Jan 2018 13:37:55 -0800
From: Hugh Dickins <hughd@...gle.com>
To: Pavel Tatashin <pasha.tatashin@...cle.com>
Cc: Andy Lutomirski <luto@...capital.net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Thomas Voegtle <tv@...96.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Guenter Roeck <linux@...ck-us.net>,
Shuah Khan <shuahkh@....samsung.com>, patches@...nelci.org,
Ben Hutchings <ben.hutchings@...ethink.co.uk>,
lkft-triage@...ts.linaro.org, stable <stable@...r.kernel.org>
Subject: Re: [PATCH 4.4 00/37] 4.4.110-stable review
On Thu, Jan 4, 2018 at 1:23 PM, Pavel Tatashin
<pasha.tatashin@...cle.com> wrote:
> I tried cherry picking
> 435086b36f62 x86/vsyscall/64: Explicitly set _PAGE_USER in the
> pagetable hierarchy
>
> on top of 4.4.110-rc1, (needed to resolve a small 5level table to
> 4level page table conflict). Unfortunately, this does not solve the
> panic/hanging problem I reported. For some reason I do not see the
> panic message anymore. Machine hangs here:
>
> [ 5.023052] zswap: loaded using pool lzo/zbud
> [ 5.023063] page_owner is disabled
> [ 5.026492] Key type trusted registered
> [ 5.029325] Key type encrypted registered
> [ 5.029330] ima: No TPM chip found, activating TPM-bypass!
> [ 5.029365] evm: HMAC attrs: 0x1
> [ 5.034696] rtc_cmos 00:00: setting system clock to 2018-01-04
> 21:20:34 UTC (1515100834)
> [ 5.216862] Freeing unused kernel memory: 1856K
> <hang>
>
> And reboots after about half a minute.
Thanks for trying, but yes, I wouldn't expect a straight cherry-pick
of that to work in the context of 4.4.110: it needs to be
cherry-picked "in principle". Which Borislav has done, and I'll
forward you his (not yet reviewed) patch too, but frankly I've much
less hope that it will help your crash than Thomas's.
So please revert that cherry-pick; and if Borislav's patch doesn't
help, if you can send us a "Code:" line from the crash, that may still
give us more to go on.
As Linus remarked earlier, "The PTI patches obviously change percpu
stuff, but this looks like an odd place for that to manifest".
Exactly: segfault and panic when starting init is a "normal" symptom
when we get something wrong with Kaiser/PTI, but a kthread crashing in
dyntick_save_progress_counter is something new to me.
Hugh
Powered by blists - more mailing lists