Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp4617418pxu; Tue, 13 Oct 2020 03:00:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwzBMmdSf0/cZUYKDTnDa4cJi7QU/BSdCO2CIhgnupwdNtcFhQksDtJaH8GhCp9f7d2pGSo X-Received: by 2002:a50:fe98:: with SMTP id d24mr18877865edt.223.1602583207816; Tue, 13 Oct 2020 03:00:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602583207; cv=none; d=google.com; s=arc-20160816; b=rfeaT8nLTEPKqwQCP5bMd5hZEf6oEMDdtlzxa+AL6DWT9AY7h52BguLrCwUlJfbDE/ ri/8xthObteBzTJaH4e/19zuONWVdpa0SHu4LbbWM8MXypR48DpOYRun81hEfyFbpITj OyHNiMFfZ2Jbh5YwO3YcN+Z7gpMbF/N94vW1nLVZp8wFu5hfg6GkOoMvXAjhD60Y/ITS Nhwsm8f7AFslQcYlTfhOeM4G1tT3uwWRBC1PA/LBfeNEztnXFVoy1l4p32zRXRuMKnBU zrvTkRu4HSBoqq1clhAC3mqNzVo7jnq+xzCvZS1/1dSB6C8zUPnwRfrEwzSwObUSBw0d j/iQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:date:from:sender:dkim-signature; bh=xnzP63dYFUACzs4P/vR52kPPuEFcl8NjXjS4LexgAN0=; b=itR7c7hBu1M89N9GnLguAW0dxNEa+LP1iDctOCfC8oAOFmWhRlUjGAYgd89hAvoNvg rO1DZpvVuJ9UZ/lQKRpMdSjcM5VNHxgfcCpr6loHZ+MpaK11ppGxC9GedYoLOCqdSnXq pfi9Ogtxx8gvwH2+rFN4HPNjXOMLlyTZdiLSkQAzzFh3tGNTdJPM+OK3JR2mQkD/YT2X 9hF/ZGTCNygFcvtiM2trsyb9tsKwvufrqn0NMzI+6vozfG69eCEH0UxfW783O9z956dX bVFdQtpUCaWcrMHhjDhSBky2RBU834ZDmxwDedBGmBqt//KcWrFyR3haT4KrWXDGWMwl gZ2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=kCRS6a2w; 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 bh4si5872287ejb.551.2020.10.13.02.59.44; Tue, 13 Oct 2020 03:00:07 -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=@gmail.com header.s=20161025 header.b=kCRS6a2w; 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 S1727050AbgJLU1E (ORCPT + 99 others); Mon, 12 Oct 2020 16:27:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37818 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726636AbgJLU1E (ORCPT ); Mon, 12 Oct 2020 16:27:04 -0400 Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DC47EC0613D0 for ; Mon, 12 Oct 2020 13:27:03 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id s7so18810064qkh.11 for ; Mon, 12 Oct 2020 13:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=xnzP63dYFUACzs4P/vR52kPPuEFcl8NjXjS4LexgAN0=; b=kCRS6a2wraeE1XpLHBCaFnj13617RReTZWkNSIHsYQ1rTzi7GEzyAAhUroMOZW+P3K WWGdmIiUyeOG8n34oAyZaEK+etuYx4CAskhtet3P6MSbh+EwfjHUP0auxzsuhZfyLdot eJZ8ZBNYEqYkf5pd7MU+K9p9BMG+840Gd2fqrFYNnDgFPfIO2JyulX8TtdKVlUcjrRBb U2AvlOJUj/O171r3wfjaST8UiRvp+/mLb66+Y6K4Mve2naeBQc6IA5OB1+/ICjzYm14P Wts3jBUpHpt627K9/3tdoTc9RhCe5I1/v3TPZX7MnPN5tox8gVYioPs3FZQph2dKbjRl dkkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:date:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=xnzP63dYFUACzs4P/vR52kPPuEFcl8NjXjS4LexgAN0=; b=m2IAWi7UYCdAALhC+KPHEqp+pWudPsanl9wZoPTkgyZoC73/1XX9dvN0fd5s7pXO8E Jw2HFYq4S6e66UE5NgU+7nbLGChuTi1i+3JkdSdYDAtvycSEkleQspjqaHW58a2OXCzZ Stf2QfzKdgdgGgnFyxxfIwHi40AUmvojwIqRC0+xICOEW8uh7gmVrvKLRh7MhCf48kuE rwg7YFmPYtGmuxhAaFi5xbfd0RlAyMylKN36URW5wuurPdKMukx+VwTYree6LSysmsyH Rb9+eBVPQ295gY7R0BHzJHHRCGwwvv95Vwwx1/bEP18ap5MQzW7pdQy+SDOR42XPBB+e krjg== X-Gm-Message-State: AOAM532OyojwTJNu1lRRM4YrEGltstLQwBr+uoBFXbWJtmREhhqAC+PQ mfrkj9/ZtjsYzVdsveiLkH8= X-Received: by 2002:a05:620a:2054:: with SMTP id d20mr9405676qka.175.1602534422947; Mon, 12 Oct 2020 13:27:02 -0700 (PDT) Received: from rani.riverdale.lan ([2001:470:1f07:5f3::b55f]) by smtp.gmail.com with ESMTPSA id f3sm9338112qkl.134.2020.10.12.13.27.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Oct 2020 13:27:02 -0700 (PDT) Sender: Arvind Sankar From: Arvind Sankar X-Google-Original-From: Arvind Sankar Date: Mon, 12 Oct 2020 16:27:00 -0400 To: Linus Torvalds Cc: Borislav Petkov , Uros Bizjak , x86-ml , lkml Subject: Re: [GIT PULL] x86/asm updates for v5.10 Message-ID: <20201012202700.GA818459@rani.riverdale.lan> References: <20201012110557.GK25311@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 12, 2020 at 11:11:35AM -0700, Linus Torvalds wrote: > 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") It's not the "q", but the size of the l-value specified that tells the compiler what to use. So x_u8__ does make it use a byte register, and it would even with an "r" constraint. I think "q" is there only in case you want to access the low byte of a bigger operand, to force the compiler to use only a,b,c,d in 32-bit mode. > > 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