From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B53D2C433EF for ; Thu, 27 Jan 2022 23:33:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 234D76B0071; Thu, 27 Jan 2022 18:33:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1BDEB6B0072; Thu, 27 Jan 2022 18:33:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 036D76B0073; Thu, 27 Jan 2022 18:33:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0192.hostedemail.com [216.40.44.192]) by kanga.kvack.org (Postfix) with ESMTP id E2B016B0071 for ; Thu, 27 Jan 2022 18:33:18 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 914FB8249980 for ; Thu, 27 Jan 2022 23:33:18 +0000 (UTC) X-FDA: 79077670476.18.31E8C47 Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com [209.85.215.173]) by imf16.hostedemail.com (Postfix) with ESMTP id 3441E180006 for ; Thu, 27 Jan 2022 23:33:18 +0000 (UTC) Received: by mail-pg1-f173.google.com with SMTP id e16so3709219pgn.4 for ; Thu, 27 Jan 2022 15:33:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=pITh0ffjadrUQOaU2KwCuZyyLPNTIW84DGhaNVnbVqw=; b=Q7NtIHy4Hxp5NgKGxUh60134j+g5dctZA3EsK+hPi3Pe9Vp/2/wwA2Eob4c8d7J0I4 ND1ViXWiZGyMdB+NDyuZZZX5vVc+QMiRVSjf6Gn1uchpPEFWIp/sZDKzTmyOgouUk/rX VQadx6vORLFxIz91QvmBcFE3M6yIaIO/SglMIGuoFP/4NUqZ5T9zc3N7Kn8n/h4uwHts zOYSS+ewSqKKAYiI2UPNooQFWu8QwqaCVhzMfiygHV7GQ0deAlGAvOVHEnSJp4I8Gbsv PmEctop8YVISDxI8rS7vFnvwGEjFyZlQS033mcz9hVbEdGnVIXmaohevHIuSp5n6Kq8e QZKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=pITh0ffjadrUQOaU2KwCuZyyLPNTIW84DGhaNVnbVqw=; b=0H4UpW6XPvTnbNfpHoIsboazG68D33FYQIpugod+YDWlroatvfUEPQS18dtuQkocij gjhmp+B55JVSNI9VJYbE/VVOp3Hd/466AbchRJjKY+B4Ijv3IZdEQFeN+ub9YOAel5UT ke9WKlakbJH6diPsuA9kQ1pOppc4+AidbA0+H5FaHJbIOh90Gq/5fmwqXlA7qSeuNNFa bOjuTGMF2YLJ5ACvb5CQcfvw26EQjLA8w36Y8YPsmy7VTJV7VEF3nxPwNof5U23OoECn P2yZ5yt3sem80iDH7HE4YBD1E7nTm3hVBOxB/wpe/Gq3RffzswbyFtVsCEsQBhG6i/kV u1/g== X-Gm-Message-State: AOAM531cn18WckcqokBM/iwpuUOvghIoy4wIkGvS+5sBDBt+9SCKxubX BQtbnN5e8oNdjozpsumrtyTVrQ== X-Google-Smtp-Source: ABdhPJwFU98JcQ0OAm4YbgoIGxfgDdE/Z28f64GtL1o7Gr6yY6tlbjG9r5yjHmX66IuBD9wFeMrOGA== X-Received: by 2002:a05:6a00:a16:: with SMTP id p22mr5043763pfh.40.1643326396809; Thu, 27 Jan 2022 15:33:16 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id q11sm3604085pfk.149.2022.01.27.15.33.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Jan 2022 15:33:16 -0800 (PST) Date: Thu, 27 Jan 2022 23:33:12 +0000 From: Sean Christopherson To: Peter Zijlstra Cc: mingo@redhat.com, tglx@linutronix.de, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-api@vger.kernel.org, x86@kernel.org, pjt@google.com, posk@google.com, avagin@google.com, jannh@google.com, tdelisle@uwaterloo.ca, mark.rutland@arm.com, posk@posk.io, Nick Desaulniers Subject: Re: [RFC][PATCH v2 4/5] x86/uaccess: Implement unsafe_try_cmpxchg_user() Message-ID: References: <20220120155517.066795336@infradead.org> <20220120160822.852009966@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 3441E180006 X-Stat-Signature: q7ffsm659msfpx6nbs4685zby81w6pmi Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Q7NtIHy4; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of seanjc@google.com designates 209.85.215.173 as permitted sender) smtp.mailfrom=seanjc@google.com X-Rspam-User: nil X-HE-Tag: 1643326398-352810 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: +Nick On Thu, Jan 27, 2022, Peter Zijlstra wrote: > On Thu, Jan 27, 2022 at 06:36:19AM +0000, Sean Christopherson wrote: > > On Thu, Jan 27, 2022, Sean Christopherson wrote: > > > Doh, I should have specified that KVM needs 8-byte CMPXCHG on 32-bi= t kernels due > > > to using it to atomically update guest PAE PTEs and LTR descriptors= (yay). > > >=20 > > > Also, KVM's use case isn't a tight loop, how gross would it be to a= dd a slightly > > > less unsafe version that does __uaccess_begin_nospec()? KVM pre-ch= ecks the address > > > way ahead of time, so the access_ok() check can be omitted. Altern= atively, KVM > > > could add its own macro, but that seems a little silly. E.g. somet= hign like this, > > > though I don't think this is correct > >=20 > > *sigh* > >=20 > > Finally realized I forgot to add back the page offset after convertin= g from guest > > page frame to host virtual address. Anyways, this is what I ended up= with, will > > test more tomorrow. >=20 > Looks about right :-) (famous last words etc..) And it was right, but clang-13 ruined the party :-/ clang barfs on asm goto with a "+m" input/output. Change the "+m" to "=3D= m" and clang is happy. Remove usage of the label, clang is happy. I tried a bunch of different variants to see if anything would squeak by,= but clang found a way to die on everything I threw at it. $ clang --version Debian clang version 13.0.0-9+build1 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin As written, with a named label param, clang yields: $ echo 'int foo(int *x) { asm goto (".long (%l[bar]) - .\n": "+m"(*x) := :: bar); return *x; bar: return 0; }' | clang -x c - -c -o /dev/null :1:29: error: invalid operand in inline asm: '.long (${1:l}) - .= ' int foo(int *x) { asm goto (".long (%l[bar]) - .\n": "+m"(*x) ::: bar);= return *x; bar: return 0; } ^ :1:29: error: unknown token in expression :1:9: note: instantiated into assembly here .long () - . ^ 2 errors generated. While clang is perfectly happy switching "+m" to "=3Dm": $ echo 'int foo(int *x) { asm goto (".long (%l[bar]) - .\n": "=3Dm"(*x)= ::: bar); return *x; bar: return 0; }' | clang -x c - -c -o /dev/null Referencing the label with a numbered param yields either the original er= ror: $ echo 'int foo(int *x) { asm goto (".long (%l1) - .\n": "+m"(*x) ::: b= ar); return *x; bar: return 0; }' | clang -x c - -c -o /dev/null :1:29: error: invalid operand in inline asm: '.long (${1:l}) - .= ' int foo(int *x) { asm goto (".long (%l1) - .\n": "+m"(*x) ::: bar); ret= urn *x; bar: return 0; } ^ :1:29: error: unknown token in expression :1:9: note: instantiated into assembly here .long () - . ^ 2 errors generated. Bumping the param number (more below) yields a different error (I tried d= efining tmp1, that didn't work :-) ). $ echo 'int foo(int *x) { asm goto (".long (%l2) - .\n": "+m"(*x) ::: b= ar); return *x; bar: return 0; }' | clang -x c - -c -o /dev/null error: Undefined temporary symbol .Ltmp1 1 error generated. Regarding the param number, gcc also appears to have a goof with asm goto= and "+m", but bumping the param number in that case remedies its woes. $echo 'int foo(int *x) { asm goto (".long (%l1) - .\n": "+m"(*x) ::: ba= r); return *x; bar: return 0; }' | gcc -x c - -c -o /dev/null : In function =E2=80=98foo=E2=80=99: :1:19: error: invalid 'asm': '%l' operand isn't a label $ echo 'int foo(int *x) { asm goto (".long (%l2) - .\n": "+m"(*x) ::: b= ar); return *x; bar: return 0; }' | gcc -x c - -c -o /dev/null So my immediate question: how do we want to we deal with this in the kern= el? Keeping in mind that I'd really like to send this to stable@ to fix the KVM mess. I can think of few options that are varying degrees of gross. 1) Use a more complex sequence for probing CC_HAS_ASM_GOTO_OUTPUT. 2) Use an output-only "=3Dm" operand. 3) Use an input register param. Option #1 has the obvious downside of the fancier asm goto for __get_use= r_asm() and friends being collateral damage. The biggest benefit is it'd reduce = the likelihood of someone else having to debug similar errors, which was quit= e painful. Options #2 and #3 are quite gross, but I _think_ would be ok since the se= quence is tagged as clobbering memory anyways?