Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755978AbcCUWl4 (ORCPT ); Mon, 21 Mar 2016 18:41:56 -0400 Received: from one.firstfloor.org ([193.170.194.197]:38978 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750745AbcCUWly (ORCPT ); Mon, 21 Mar 2016 18:41:54 -0400 Date: Mon, 21 Mar 2016 23:41:52 +0100 From: Andi Kleen To: Andy Lutomirski Cc: Andi Kleen , X86 ML , "linux-kernel@vger.kernel.org" Subject: Re: Updated version of RD/WR FS/GS BASE patchkit Message-ID: <20160321224152.GH5083@two.firstfloor.org> References: <1458576969-13309-1-git-send-email-andi@firstfloor.org> <20160321190322.GZ5083@two.firstfloor.org> <20160321194027.GB5083@two.firstfloor.org> <20160321221148.GF5083@two.firstfloor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 755 Lines: 27 > Imagine that some brilliant lightweight threading library does: > > - set GS to nonzero (by whatever means -- arch_prctl(ARCH_SET_GS, > whatever) on a pre-IVB host followed by migration, some modify_ldt > garbage, simple bloody-mindedness, whatever); Migration is only possible when the CPUID flags match. > - WRGSBASE > - Use GS for a bit > > This will work most of the time until it gets unlucky with preemption. As soon as a kernel thread or something else schedules the value will be lost. > And yes, runtime library authors really do mess up in amazing ways. > > It's an issue. It needs conscious design. Ok. So your only objection is the order of the context switch updates? -Andi -- ak@linux.intel.com -- Speaking for myself only.