Received: by 10.223.185.116 with SMTP id b49csp1234619wrg; Wed, 21 Feb 2018 14:45:09 -0800 (PST) X-Google-Smtp-Source: AH8x2265QYU2o8bQT/xd+4gFThtMpMSci1C/q4uJ3el+IbTdWtdxOa4SOxBqqC3lc6EXLvBB3LOM X-Received: by 2002:a17:902:540f:: with SMTP id d15-v6mr4621931pli.224.1519253109244; Wed, 21 Feb 2018 14:45:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519253109; cv=none; d=google.com; s=arc-20160816; b=EclmbtR6lOZkdf2udX0QrzW++UH42vckptTJIBHt5DTtuIhzOPWUjb+yjChebLvH24 6wwvGIS3hBxTWCIlpt8/C+cqwn1pOD7uNS9gXfUP2Bn+C3lsukx2IBbDnxi7h09+WC7U jAAP/4HRMMyZj1DPlDe83/KW/+fNgzL2XCHsshuVkCN/5bWHdpNyxc06cbHQsyk1cQ2R nWUu3QnQx5p9y7qBvtGvOLXfTInvM0WBTFhkDbJPKdbnXEltOnqwAzGS9VhYRSs+B1gk FzFKqotzMXBz9uYKAsjb71i4Vpc34OhqY4gOFJ6oFU/5HDH+DVMGKRUXQqcyr8IG+1du +BzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:from:cc:to:subject :content-transfer-encoding:mime-version:references:in-reply-to :user-agent:date:arc-authentication-results; bh=lPb8QkctO2+Goe5MmPff0/UYna0vBhcVhmRntP+2aOY=; b=P4pEeujHo8zgT4SoeR8cKFZG0A9NcO79NcoDDCXSmMLfpEO9S1ljEC3jtZJMTPt8DX TE2sNVKNKUKY/9Gkj+2/6Q6EPxGtBM+9WAFIoULoi+RoT6aLuo/I+w/WlZOA6tThUyPV 5tHEmv4XLpqRMzC4h8Jm86SCVngA09PsZpHM9hoMoAgkaPIYHvmuk8jO+h/XQQA3CAMj hCfcsWlB6WFCkzxB1blvxASxhXe7C6tmsZAv3CQVlOwQvfXTOLv+42yL/YYDkjrFcHMf 287+jy3hkJeG8XgmP2/Rt/rALQLKF/7d0X/M4ev9UWGDwmaYt3u4FYKCo70wVae5myjn dl5Q== 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 z7si1537221pfg.51.2018.02.21.14.44.54; Wed, 21 Feb 2018 14:45: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 S1751547AbeBUWjE convert rfc822-to-8bit (ORCPT + 99 others); Wed, 21 Feb 2018 17:39:04 -0500 Received: from terminus.zytor.com ([198.137.202.136]:50185 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751312AbeBUWjD (ORCPT ); Wed, 21 Feb 2018 17:39:03 -0500 Received: from [10.170.141.104] ([192.55.54.58]) (authenticated bits=0) by mail.zytor.com (8.15.2/8.15.2) with ESMTPSA id w1LMclF0029956 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 21 Feb 2018 14:38:47 -0800 Date: Wed, 21 Feb 2018 14:38:44 -0800 User-Agent: K-9 Mail for Android In-Reply-To: References: <5A8AF1F802000078001A91E1@prv-mh.provo.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Subject: Re: [PATCH] x86/asm: improve how GEN_*_SUFFIXED_RMWcc() specify clobbers To: Kees Cook , Jan Beulich CC: Ingo Molnar , Thomas Gleixner , LKML From: hpa@zytor.com Message-ID: <228E231D-AE31-4803-B630-051614CEE0B4@zytor.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On February 21, 2018 1:39:18 PM PST, Kees Cook 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. > >> practice to me to have clobber specification and use of the clobbered >> register(s) disconnected - it should rather be at the invocation >place >> of that GEN_{UN,BIN}ARY_SUFFIXED_RMWcc() macros that the clobber is >> specified which this particular invocation needs. >> >> Drop the "cc" clobber altogether and move the "cx" one to refcount.h. >> >> Signed-off-by: Jan Beulich >> Cc: Kees Cook >> --- >> arch/x86/include/asm/refcount.h | 4 ++-- >> arch/x86/include/asm/rmwcc.h | 16 ++++++++-------- >> 2 files changed, 10 insertions(+), 10 deletions(-) >> >> --- 4.16-rc2/arch/x86/include/asm/refcount.h >> +++ 4.16-rc2-x86-rmwcc-clobbers/arch/x86/include/asm/refcount.h >> @@ -67,13 +67,13 @@ static __always_inline __must_check >> bool refcount_sub_and_test(unsigned int i, refcount_t *r) >> { >> GEN_BINARY_SUFFIXED_RMWcc(LOCK_PREFIX "subl", >REFCOUNT_CHECK_LT_ZERO, >> - r->refs.counter, "er", i, "%0", e); >> + r->refs.counter, "er", i, "%0", e, >"cx"); >> } >> >> static __always_inline __must_check bool >refcount_dec_and_test(refcount_t *r) >> { >> GEN_UNARY_SUFFIXED_RMWcc(LOCK_PREFIX "decl", >REFCOUNT_CHECK_LT_ZERO, >> - r->refs.counter, "%0", e); >> + r->refs.counter, "%0", e, "cx"); >> } >> >> static __always_inline __must_check >> --- 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? > >> #if !defined(__GCC_ASM_FLAG_OUTPUTS__) && defined(CC_HAVE_ASM_GOTO) >> >> @@ -40,18 +39,19 @@ do { > \ >> #endif /* defined(__GCC_ASM_FLAG_OUTPUTS__) || >!defined(CC_HAVE_ASM_GOTO) */ >> >> #define GEN_UNARY_RMWcc(op, var, arg0, cc) > \ >> - __GEN_RMWcc(op " " arg0, var, cc, __CLOBBERS_MEM) >> + __GEN_RMWcc(op " " arg0, var, cc, __CLOBBERS_MEM()) >> >> -#define GEN_UNARY_SUFFIXED_RMWcc(op, suffix, var, arg0, cc) > \ >> +#define GEN_UNARY_SUFFIXED_RMWcc(op, suffix, var, arg0, cc, >clobbers...)\ >> __GEN_RMWcc(op " " arg0 "\n\t" suffix, var, cc, > \ >> - __CLOBBERS_MEM_CC_CX) >> + __CLOBBERS_MEM(clobbers)) >> >> #define GEN_BINARY_RMWcc(op, var, vcon, val, arg0, cc) > \ >> __GEN_RMWcc(op __BINARY_RMWcc_ARG arg0, var, cc, > \ >> - __CLOBBERS_MEM, vcon (val)) >> + __CLOBBERS_MEM(), vcon (val)) >> >> -#define GEN_BINARY_SUFFIXED_RMWcc(op, suffix, var, vcon, val, arg0, >cc) \ >> +#define GEN_BINARY_SUFFIXED_RMWcc(op, suffix, var, vcon, val, arg0, >cc, \ >> + clobbers...) > \ >> __GEN_RMWcc(op __BINARY_RMWcc_ARG arg0 "\n\t" suffix, var, >cc, \ >> - __CLOBBERS_MEM_CC_CX, vcon (val)) >> + __CLOBBERS_MEM(clobbers), vcon (val)) >> >> #endif /* _ASM_X86_RMWcc */ > >Anyway, I'm fine to clean it up, sure, but I'd like more details on >why this doesn't break things. :) > >Thanks! > >-Kees > >[1] https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html On x86, gcc always assumes the flags are clobbered; technically it is because the x86 flags aren't implemented using the gcc "cc" internal. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.