[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <c2bfe1aa390777b10d810d2b76a35b97fbd32a1c.camel@intel.com>
Date: Sat, 18 Jul 2020 10:57:27 -0700
From: Yu-cheng Yu <yu-cheng.yu@...el.com>
To: LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
Andy Lutomirski <luto@...nel.org>,
Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H.J. Lu" <hjl.tools@...il.com>, Ingo Molnar <mingo@...hat.com>,
"Ravi V. Shankar" <ravi.v.shankar@...el.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Tony Luck <tony.luck@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Weijiang Yang <weijiang.yang@...el.com>
Subject: Random shadow stack pointer corruption
Hi,
My shadow stack tests start to have random shadow stack pointer corruption after
v5.7 (excluding). The symptom looks like some locking issue or the kernel is
confused about which CPU a task is on. In later tip/master, this can be
triggered by creating two tasks and each does continuous
pthread_create()/pthread_join(). If the kernel has max_cpus=1, the issue goes
away. I also checked XSAVES/XRSTORS, but this does not seem to be an issue
coming from there.
The tests I run take a long time to complete, and some commit points in bisect
do not show failures right away. However, the issue can be more easily
triggered after the point of:
d77290507ab2 x86/entry/32: Convert IRET exception to IDTENTRY_SW
Can anyone help me find places to look at?
Thanks,
Yu-cheng
Powered by blists - more mailing lists