Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1224950ybh; Thu, 23 Jul 2020 03:45:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyoQsjfLSMjW4P5eQXPdpjw5vI5+GFH0lV78zgvYkT/poFwOIiiR31snnkLBEury1QWQAWN X-Received: by 2002:a17:906:17c1:: with SMTP id u1mr3700239eje.536.1595501155758; Thu, 23 Jul 2020 03:45:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595501155; cv=none; d=google.com; s=arc-20160816; b=c7DHEEKZnYl5GQ6RZNrAIjrUTZoE5dSPAXbQn4tdWwPHflIkPuYaYxd7zYrIE1KYcJ Ja7Qf0Y5xBsQgOkRULRyYxxBmsbsQNIqdc814zWJAdd/3e/G13w8tHpS7hgGLwiLBRz0 8a6sZuysyNMDk9BI4Fy+sQMnUyHsLhVSN2lo0d7dnfRxEN4AM3OL+IAnGD+6P1cwoXtM qj3UzpcohNNc4NHB0I3sqRod0CpoQvO5LB+P4OZxSFbGj+TINh6+Mkm9CWk60HpoS1Fp dYGVngDA6LfV05hyHMfrm+gltGa9OdIsECbiiZSsMV6+joqaGvcASCPm+Pxuxa0uHGuO F9sg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :robot-unsubscribe:robot-id:message-id:mime-version:references :in-reply-to:cc:subject:to:reply-to:from:dkim-signature :dkim-signature:date; bh=Xgn/PBeBQmOoAg0U/oX6YBE51LNtdNydLKBKAukUbM0=; b=d4jw3Z+lfdlZonQ0H3CtWIXlJl6GtYsCix0y4tDUf57WpdDGnn/A9XFOgAM0ZOwKzJ U04UMYTSx3THe33l+7fcBRd7f9MH8OOAYXENlnxozFnmlj+25TqFr9UmvIJ2jiqr5ubl ZbhOdUxznBoLRziSM7aFG3USs6Q4NM2eF24rhRoFrdaf7cLH56xxnAWTlgY1Fu4lyP8E sgg78p51jDJNpn+suqrg1b+YLvxxormLAfdHPeMZNaJTbsAKtRkTiEysH7uzfKKfzAQb 8Gf2fsyIcKSFKuzUwbRd4ztDTzE3eM3DSDBpmYrm+D8UYHH9vkDX+JW6qi69ZHhYdzKB 0Tug== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@linutronix.de header.s=2020 header.b=Zzt73+wd; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x22si1807211ejj.461.2020.07.23.03.45.33; Thu, 23 Jul 2020 03:45:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@linutronix.de header.s=2020 header.b=Zzt73+wd; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728445AbgGWKnn (ORCPT + 99 others); Thu, 23 Jul 2020 06:43:43 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:57048 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728254AbgGWKnm (ORCPT ); Thu, 23 Jul 2020 06:43:42 -0400 Date: Thu, 23 Jul 2020 10:43:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1595501019; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Xgn/PBeBQmOoAg0U/oX6YBE51LNtdNydLKBKAukUbM0=; b=Zzt73+wd+EJDZW4+wiA0hJh4wGCe5ZYqSyU/8/7bUrGLbGRHe3KRwgf4FaSnJsRLvW93eG T3WJJs2sRxxj9SKAwFk5+3Oali7W1a9Jlls9odgyZMN9nOkkuLKNE4Dx1wToRfXm9EINSr Sxu90+hkX4MZeRPVY8gHwyEqhfSSCC1o6kBD1+5YvSc9Q+CFD8waDnbyJmoyF87Ioc6nb/ ElGdbffXC/8/MVKhUA3qe6Xwx7P5CrMtmCpaevyGUsYCrEdzJbza/0zgqp9Qh1kFPMc+eq hvQclSv+n00bTA+avlZ9as/eUqevFt86SAhgB5ptyI6VzNoQNK1WUoBMpxxxsA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1595501019; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Xgn/PBeBQmOoAg0U/oX6YBE51LNtdNydLKBKAukUbM0=; b=yLPlHr3n3vDGga4rqAOJ9iGTexXhKx+izX7A5enA7oweoszCsJ41w3V1x5SbJaSyJDt0CT f7tKpwt6eluDSbAg== From: "tip-bot2 for Nick Desaulniers" Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: x86/asm] x86/uaccess: Make __get_user_size() Clang compliant on 32-bit Cc: Arnd Bergmann , David Woodhouse , Dmitry Golovin , Linus Torvalds , Nick Desaulniers , Thomas Gleixner , Sedat Dilek , Dennis Zhou , x86 , LKML In-Reply-To: <20200720204925.3654302-12-ndesaulniers@google.com> References: <20200720204925.3654302-12-ndesaulniers@google.com> MIME-Version: 1.0 Message-ID: <159550101883.4006.16106494273357713858.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The following commit has been merged into the x86/asm branch of tip: Commit-ID: 158807de5822d1079e162a3762956fd743dd483e Gitweb: https://git.kernel.org/tip/158807de5822d1079e162a3762956fd743dd483e Author: Nick Desaulniers AuthorDate: Mon, 20 Jul 2020 13:49:25 -07:00 Committer: Thomas Gleixner CommitterDate: Thu, 23 Jul 2020 12:38:31 +02:00 x86/uaccess: Make __get_user_size() Clang compliant on 32-bit Clang fails to compile __get_user_size() on 32-bit for the following code: long long val; __get_user(val, usrptr); with: error: invalid output size for constraint '=q' GCC compiles the same code without complaints. The reason is that GCC and Clang are architecturally different, which leads to subtle issues for code that's invalid but clearly dead, i.e. with code that emulates polymorphism with the preprocessor and sizeof. GCC will perform semantic analysis after early inlining and dead code elimination, so it will not warn on invalid code that's dead. Clang strictly performs optimizations after semantic analysis, so it will warn for dead code. Neither Clang nor GCC like this very much with -m32: long long ret; asm ("movb $5, %0" : "=q" (ret)); However, GCC can tolerate this variant: long long ret; switch (sizeof(ret)) { case 1: asm ("movb $5, %0" : "=q" (ret)); break; case 8:; } Clang, on the other hand, won't accept that because it validates the inline asm for the '1' case before the optimisation phase where it realises that it wouldn't have to emit it anyway. If LLVM (Clang's "back end") fails such as during instruction selection or register allocation, it cannot provide accurate diagnostics (warnings / errors) that contain line information, as the AST has been discarded from memory at that point. While there have been early discussions about having C/C++ specific language optimizations in Clang via the use of MLIR, which would enable such earlier optimizations, such work is not scoped and likely a multi-year endeavor. It was discussed to change the asm output constraint for the one byte case from "=q" to "=r". While it works for 64-bit, it fails on 32-bit. With '=r' the compiler could fail to chose a register accessible as high/low which is required for the byte operation. If that happens the assembly will fail. Use a local temporary variable of type 'unsigned char' as output for the byte copy inline asm and then assign it to the real output variable. This prevents Clang from failing the semantic analysis in the above case. The resulting code for the actual one byte copy is not affected as the temporary variable is optimized out. [ tglx: Amended changelog ] Reported-by: Arnd Bergmann Reported-by: David Woodhouse Reported-by: Dmitry Golovin Reported-by: Linus Torvalds Signed-off-by: Nick Desaulniers Signed-off-by: Thomas Gleixner Tested-by: Sedat Dilek Acked-by: Linus Torvalds Acked-by: Dennis Zhou Link: https://bugs.llvm.org/show_bug.cgi?id=33587 Link: https://github.com/ClangBuiltLinux/linux/issues/3 Link: https://github.com/ClangBuiltLinux/linux/issues/194 Link: https://github.com/ClangBuiltLinux/linux/issues/781 Link: https://lore.kernel.org/lkml/20180209161833.4605-1-dwmw2@infradead.org/ Link: https://lore.kernel.org/lkml/CAK8P3a1EBaWdbAEzirFDSgHVJMtWjuNt2HGG8z+vpXeNHwETFQ@mail.gmail.com/ Link: https://lkml.kernel.org/r/20200720204925.3654302-12-ndesaulniers@google.com --- arch/x86/include/asm/uaccess.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h index 18dfa07..2f3e8f2 100644 --- a/arch/x86/include/asm/uaccess.h +++ b/arch/x86/include/asm/uaccess.h @@ -314,11 +314,14 @@ do { \ #define __get_user_size(x, ptr, size, retval) \ do { \ + unsigned char x_u8__; \ + \ retval = 0; \ __chk_user_ptr(ptr); \ switch (size) { \ case 1: \ - __get_user_asm(x, ptr, retval, "b", "=q"); \ + __get_user_asm(x_u8__, ptr, retval, "b", "=q"); \ + (x) = x_u8__; \ break; \ case 2: \ __get_user_asm(x, ptr, retval, "w", "=r"); \