Received: by 10.223.185.116 with SMTP id b49csp1637330wrg; Thu, 22 Feb 2018 00:06:09 -0800 (PST) X-Google-Smtp-Source: AH8x224qDPMxhvO37njIBnL/eks5O24N9dB0d1E3ZEKKb933NZOeRjkKx93Vw2LqjeNefilB3OuT X-Received: by 10.98.198.1 with SMTP id m1mr5950735pfg.90.1519286769124; Thu, 22 Feb 2018 00:06:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519286769; cv=none; d=google.com; s=arc-20160816; b=TO1G0/hW101KAdibsjlPSJXnx0Th3sQ+JHysako/KAVbMVlTQ3ZlaKiUiBHU2L3bSF CYp7Mg3hvpclYxWUrS4KlI8Yxt5Q/2vYMfJEpFZr23Osnu05736O9UP21iOx7s4oDVC8 DGODuVOx13Ej609yh186g266pkAQ6a6QUz3O/OCDoys3c5yuhWVSq7obDVBgu0imjyoH bYuQE7+E8EkP4V9mfOA+etB7zis1l71gQuX95vRLgQnDS0BMZUQKXi6f0sU89rHfR34B nHtplalv2l03E/HaPzp5KJIpaEFveaDZOYXrirZLsrgtYPdOw4ofFliMktWLIbe/rKcz nz7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-disposition :content-transfer-encoding:mime-version:in-reply-to:references :subject:cc:to:from:date:message-id:arc-authentication-results; bh=6aulrrGc8R4pPRPdoULqmu0GsCPk0wK9isX6W1jY+8c=; b=JVc6vnPsfOcwyl9g3QZYTkbUZ4wEdW10vyrt7fLoFHpcpK4h+TyAqtAiGR7Hv3+DCH 0MZ8sxbox46KFBmT0EpAMGgLQSqhoaoRornAPA8tBoYkYZnTO8+zjk5iGodyni3rMRpN pzFFxo78Mrp9M4Ja+1vXxw316KlGh9rF/3Er9K90/FxLtlrJggOOn8rdjCo6XUIP1fnf czCcaFPVoZPLlKme4UW0lsXofqMOVzb9AmPNAATLU+TNmBvj53Uec77LnD+ebhtSGOKh XUwePJw2DiqB7TwIE8AtXiKSKqbd74kI36+3uOY3hn+L7yjQaDTLzb9o9F7Dm5hACBlq ocSQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y4-v6si3882775plb.568.2018.02.22.00.05.52; Thu, 22 Feb 2018 00:06:09 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752658AbeBVIFM convert rfc822-to-8bit (ORCPT + 99 others); Thu, 22 Feb 2018 03:05:12 -0500 Received: from prv-mh.provo.novell.com ([137.65.248.74]:46382 "EHLO prv-mh.provo.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751669AbeBVIFL (ORCPT ); Thu, 22 Feb 2018 03:05:11 -0500 Received: from INET-PRV-MTA by prv-mh.provo.novell.com with Novell_GroupWise; Thu, 22 Feb 2018 01:05:10 -0700 Message-Id: <5A8E87C502000078001AA3A3@prv-mh.provo.novell.com> X-Mailer: Novell GroupWise Internet Agent 18.0.0 Date: Thu, 22 Feb 2018 01:05:09 -0700 From: "Jan Beulich" To: "Kees Cook" Cc: "Ingo Molnar" , "Thomas Gleixner" , "LKML" , "H. Peter Anvin" Subject: Re: [PATCH] x86/asm: improve how GEN_*_SUFFIXED_RMWcc() specify clobbers References: <5A8AF1F802000078001A91E1@prv-mh.provo.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>> On 21.02.18 at 22:39, wrote: > On Mon, Feb 19, 2018 at 6:49 AM, Jan Beulich wrote: >> Commit df3405245a ("x86/asm: Add suffix macro for GEN_*_RMWcc()") >> introduced "suffix" RMWcc operations, adding bogus clobber specifiers: >> For one, on x86 there's no point explicitly clobbering "cc". In fact, > > Do you have more details on this? It seems from the GCC clobbers > docs[1] that "cc" is needed for asm that changes the flags register. > Given the explicit subl and decl being used for these macros, it seems > needed to me. > >> with gcc properly fixed, this results in an overlap being detected by >> the compiler between outputs and clobbers. Further more it seems bad > > Do you mean the flags register is already being included as an > implicit clobber because there is an output of any kind? I can't find > documentation that says this is true. If anything it looks like it > could be "improved" from a full "cc" clobber to an output operand > flag, like =@ccs. As hpa has already said, "cc" has been automatically included as a clobber forever on x86 (until the condition code outputs appeared, at which point the clobber became added only if no such output was present). >> --- 4.16-rc2/arch/x86/include/asm/rmwcc.h >> +++ 4.16-rc2-x86-rmwcc-clobbers/arch/x86/include/asm/rmwcc.h >> @@ -2,8 +2,7 @@ >> #ifndef _ASM_X86_RMWcc >> #define _ASM_X86_RMWcc >> >> -#define __CLOBBERS_MEM "memory" >> -#define __CLOBBERS_MEM_CC_CX "memory", "cc", "cx" >> +#define __CLOBBERS_MEM(clb...) "memory", ## clb > > This leaves a trailing comma in the non-cx case. I thought that caused > me problems in the past, but maybe that's GCC version-specific? No, it's formally specified to drop the comma. Note this is using a gcc extension, not the C99 way of having a macro with variable number of arguments (where - without again some gcc special handling - this indeed would be a problem). Jan