Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp4170343pxu; Mon, 12 Oct 2020 11:14:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzLPxO4u9vaGR30PVCq7dVawZjPcpF+zt06bgZKynj2+wnvTZj+s4TPi1tsuDH18Ghqb9mL X-Received: by 2002:a17:906:2301:: with SMTP id l1mr28286200eja.488.1602526462701; Mon, 12 Oct 2020 11:14:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602526462; cv=none; d=google.com; s=arc-20160816; b=GUkmWtW1Ta1KRV+rBt/uYbRWbKPY0STjRZGV94AAiQ/O3GzUe0x7iTijn0+aSmB+pz LLp9p0x+XUZDn4y5WRwvBmILeQf4nFzl5B4nSr0fxm49csGjnaY9fYbgjgbUjWiaAjSd aSsN4Y6mCXaq26v1XSeYan69THRHimZFzB0Zn3pv2eeUQY3S6+99pFFHCelsiCiqOuwx 1MMgyWd4/59MrHHGTN/9WPSxaocmpLhpc+UT56C0nuLzogKhdNS+ovZf2re/XUFn3DOk wqVhU7CCi/odMYyysaHqYAfUj+Ahyece82SWXHBRsg5+IKD0bvYOYz8BhbMLI4dT2OQn dMEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=APvCR81d2hsCRE8d93iR5IJ6VoWmDP6Sd07Qtx7ztAY=; b=LCfEd1M+arDJmd4BhF7Co4IXyxWHoMOzi2dZfuHLX7ZGzH4SnjQqO7j2hQMH4GwyHX R+V3qHtuj0OcqCS7IGg5TkfuNqUVkAieOyDXdhOMbplmMPihSTDY9p80f8DhacWoQWQG kk/2EckKBnUfk3DnkE5k8LUWhDtnbFd9/3dkqT6qrmEuQwsZYjIw2KVwLThyks/OZPKq D4BhpwVmR+G36+CHIxGGm6JifLpLGggA5h7TP73lBw933T+HWGydNOWeznQy4zFizw+e +E6hL7j4dg47AOqN5/zOc36xI++5GpqqXccmavQHyNwy5KeVFNKrtiHCqklZhxidFv/X tRqg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=ajA6jGFD; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g22si11379ejx.308.2020.10.12.11.13.58; Mon, 12 Oct 2020 11:14:22 -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=pass header.i=@linux-foundation.org header.s=google header.b=ajA6jGFD; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404107AbgJLSL4 (ORCPT + 99 others); Mon, 12 Oct 2020 14:11:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44864 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730322AbgJLSLz (ORCPT ); Mon, 12 Oct 2020 14:11:55 -0400 Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7675AC0613D0 for ; Mon, 12 Oct 2020 11:11:55 -0700 (PDT) Received: by mail-lf1-x144.google.com with SMTP id a9so19277180lfc.7 for ; Mon, 12 Oct 2020 11:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=APvCR81d2hsCRE8d93iR5IJ6VoWmDP6Sd07Qtx7ztAY=; b=ajA6jGFD1565DLMI9D7lePL4+erBlXYH85Kb8ZIKS24mHntwKMM2MNwB+Bk43dV0J/ Z4uwxRRP2mU2qpcp8tGxyq+ja7Xgq8yQVEigbbjwTeNASrTyUiYD95F6DbH7duMnpbU6 QGa6k+bTMqNOi/QQDOgDAnwsRMEfkBE/942GM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=APvCR81d2hsCRE8d93iR5IJ6VoWmDP6Sd07Qtx7ztAY=; b=VSc/haBMXeFSiqT+9xHeeJ84XJXbalRIVmQgFZdiYLeR4dinnrTugXk7RMUNOfvu3F LKCZRZsVWPGh19yAH6ufKxV2P/t2o9oFoSBzB8p1/YfHwreVTfUB/hTxQx75jKGrFYnh ljzSi9XhRShibF2HvSguHjvwimh1pJn0aR3FGnpUtc33nEelO9IDjEKg0kTsKW6bOeWg h3wf/vVTwIV7589yt+MIYEgdswl4jYXIKLfyreQbrVrRI6DiLI2j/AUKA45jPLrMB+YL NHxRppToVjFb46ttG6jvsakqBs/sTOFhijvU+m9N+acD6EogesnwyvBH9VGXJWcAKlBY p61w== X-Gm-Message-State: AOAM533tJWgPmT5vsVKdDCSrNRnYtSdIEB7ykJxyDvRhzGG3+XUoK0lq /6GKTDZzZuC/dSzt5XvMw56oEMbAM9pQbg== X-Received: by 2002:a05:6512:3b1:: with SMTP id v17mr7982622lfp.262.1602526313261; Mon, 12 Oct 2020 11:11:53 -0700 (PDT) Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com. [209.85.167.43]) by smtp.gmail.com with ESMTPSA id m132sm2104913lfa.34.2020.10.12.11.11.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2020 11:11:51 -0700 (PDT) Received: by mail-lf1-f43.google.com with SMTP id a7so18187736lfk.9 for ; Mon, 12 Oct 2020 11:11:51 -0700 (PDT) X-Received: by 2002:ac2:5f48:: with SMTP id 8mr2531215lfz.344.1602526311213; Mon, 12 Oct 2020 11:11:51 -0700 (PDT) MIME-Version: 1.0 References: <20201012110557.GK25311@zn.tnic> In-Reply-To: <20201012110557.GK25311@zn.tnic> From: Linus Torvalds Date: Mon, 12 Oct 2020 11:11:35 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [GIT PULL] x86/asm updates for v5.10 To: Borislav Petkov , Uros Bizjak Cc: x86-ml , lkml Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 12, 2020 at 4:06 AM Borislav Petkov wrote: > > * Use XORL instead of XORQ to avoid a REX prefix and save some bytes in > the .fixup section, by Uros Bizjak. I think this one is actually buggy. For the 1-byte case, it does this: __get_user_asm(x_u8__, ptr, retval, "b", "=q"); and ends up doing "xorl" on a register that we told the compiler is a byte register (with that "=q") Yes, it uses "%k[output]" to turn that byte register into the word version of the register, but there's no fundamental reason why the register might not be something like "%ah". Does the "xorl" work? Does it build? Yes, and yes. But maybe %al contains SOMETHING ELSE, and it now clears that too, because the asm is basically doing something completely different than what we told the compiler it would do. Now, afaik, gcc (and presumably clang) basically almost never use the high byte registers. But I still think this patch is fundamentally wrong and conceptually completely buggy, even if it might work in practice. Also, I'm going to uninline this nasty __get_user() function anyway for 5.10, so the patch ends up being not just wrong, but pointless. This is not some kind of hot code that should be optimized, and the extra byte is not a lot to worry about. Annoying. Because the other patch in this pull request is fine, and people want it. But I'm going to skip this pull request, because I really think it's dangerously and subtly buggy even if there might not be any case that matters in reality. Linus