Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755338AbcCUWww (ORCPT ); Mon, 21 Mar 2016 18:52:52 -0400 Received: from one.firstfloor.org ([193.170.194.197]:39039 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751159AbcCUWwv (ORCPT ); Mon, 21 Mar 2016 18:52:51 -0400 Date: Mon, 21 Mar 2016 23:52:48 +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: <20160321225248.GI5083@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> <20160321224152.GH5083@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: 851 Lines: 27 > No. My objection is that there needs to be an explicit statement what > the semantics are. If the agreed-upon semantics are "undefined > behavior if GS != 0 and GSBASE doesn't match the descriptor", so be > it, but this needs to be a conscious decision and needs to be weighed > against the alternatives. Documentation/x86/fsgs.txt already has this statement: >>> Another requirement is that the FS or GS selector has to be zero (is normally true unless changed explicitly). When it is non-zero the context switch assumes the bases were loaded through the LDT/GDT, and will reload that. <<< Is that sufficient? > > The actual implementation details are just details. They need to > match the intended semantics, of course. I believe my implementation matches the paragraph above. -Andi -- ak@linux.intel.com -- Speaking for myself only.