Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1063545ybt; Wed, 1 Jul 2020 17:48:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJygM6B+YtWt13s9L26l2IOgIZxi8aMQidD2ZwBQHR50n1VyD1hWMv28D2lYE4qfZ6yP+0UP X-Received: by 2002:a05:6402:134e:: with SMTP id y14mr32387294edw.4.1593650917199; Wed, 01 Jul 2020 17:48:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593650917; cv=none; d=google.com; s=arc-20160816; b=WGvzkIkH69+imTcVD0leDegZj6Nzu/X+vaVyL1673XoVpFjAjGw27qC43ktUMHYnLK b+wlkl/SbTyDg6XBGEw4wCSVGa+UDp3NWYP0QQZVMNPkGud6+JimSqrqHTFvl9UaXp9u pRarYAfFGwW1BZBnbNKuliHRzEN6C5v4N738MU7zhTn4m5lmd9mlvtZOR5ChR5U6zFRH nIx3lLMcC97KxgRvzNeQ7ZfFOGBN+RfcPX6kbZP5JlMTKo/kyDEwujqzAxmkCwUNpIKQ FW/zCrkAN6nyqT20oiRzaOFIIhFjuj3Az8wpzRAdKceOVHMjYvDqPLRsu8yaNsiBqNoP aTjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=PH5l+sqsXbMggGvPRHxYnRwGaCk9bVKwfZVK4PY3YDQ=; b=xWgl0Zo14gf10lvnjNEvg9jSZEuKtUDVwe0bmdY4AkIi7sUNIq78q2+iRbDq/pXQZ1 Wo1c1bhhdhV9ks79Jhznq1ZsNrTroQ1E5gRxFlsX9erpw0SJS+ISKRu+kM9vkfVw8PI0 Cq8vzNyl6UqxbLSsLQqsolxOME3KNRIo1dsiUwc4Vs+Kw71lyChm10QEdfw0ppWN2Wxf EQezyPsWBxSg1lHWfDQDGROQBDExc87by8bHUtO2WgmCqWCeYdxDruymU3iB4MCYFO3m 9keOmB3yH5vzcwqV1uhQ23Ao47FU0uBRyIPTDhFy4cXBbT2xY/zRI2mIsJWeKYdAgcmg k/bw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=L0xUkYlU; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q27si4810550eja.643.2020.07.01.17.48.14; Wed, 01 Jul 2020 17:48:37 -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=@kernel.org header.s=default header.b=L0xUkYlU; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727053AbgGBAsC (ORCPT + 99 others); Wed, 1 Jul 2020 20:48:02 -0400 Received: from mail.kernel.org ([198.145.29.99]:45146 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726508AbgGBAsC (ORCPT ); Wed, 1 Jul 2020 20:48:02 -0400 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 823CB2083E for ; Thu, 2 Jul 2020 00:48:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593650881; bh=XEyn4rciJR68bCOMhcqvZPsUAaqbl3LjFAxVl5+yEJ8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=L0xUkYlUw943INWmd8Up0ldWkOlWr7zMj1L52awGzU4rl7zqrhskjKCw/nOnaWLLS WzCMhOa6hdmImfVBvVzZ67H8cGVCqDdSWG/Py6Ny2ffr6ia6kxYwghKafHnjssq1Kl 8l2fUs/3R+dErhPCz7GqiXsTvsNoGdeIv7RMtE64= Received: by mail-wm1-f48.google.com with SMTP id o8so24630999wmh.4 for ; Wed, 01 Jul 2020 17:48:01 -0700 (PDT) X-Gm-Message-State: AOAM532/vqXb7D8yKezmdj5PI0JrAUBACcezgebyxvrs5aHUqxx/sTuM edtu0xhEZIJ3JrU7uK3wFh+fPejrC9hhXSsRZyHQcQ== X-Received: by 2002:a1c:2402:: with SMTP id k2mr29132297wmk.138.1593650880105; Wed, 01 Jul 2020 17:48:00 -0700 (PDT) MIME-Version: 1.0 References: <5F1767D0-416A-4BA4-9DFF-E82D1EA3F5EE@amacapital.net> In-Reply-To: From: Andy Lutomirski Date: Wed, 1 Jul 2020 17:47:48 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: objtool clac/stac handling change.. To: Linus Torvalds Cc: Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , "the arch/x86 maintainers" , Linux Kernel Mailing List Content-Type: multipart/mixed; boundary="0000000000009b04ad05a96ac2b9" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --0000000000009b04ad05a96ac2b9 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 1, 2020 at 1:51 PM Linus Torvalds wrote: > > On Wed, Jul 1, 2020 at 1:36 PM Andy Lutomirski wrote: > > > > We ought to be able to do it the way I described and get decent code generation too. > > No, we really can't. > > Each access really needs to jump to an exception label. Otherwise any > time you have multiple operations (think "strncpy()" and friends) you > have to test in between each access. > > That is why *fundamnetally* the interface to "unsafe_get/put_user()" > takes a label for the error case. There is absolutely no way to make > any other interface work efficiently. You inspired me to mock it up. I don't think I did anything special here, except that I mocked up unsafe_put_user() and a fudged it a little bit because I'm using gcc 9.3.1 which doesn't support asm goto outputs. Code like this: if (unsafe_put_user(&a, user_a)) goto error; if (unsafe_put_user(&b, user_b)) goto error; if (unsafe_put_user(&c, user_c)) goto error; if (unsafe_put_user(&d, user_d)) goto error; generates a series of movs. The conditions are entirely omitted from the generated assembly output because gcc is smart enough to figure out that the return value of unsafe_put_user() indicates which way the asm goto went. I don't think I could generate better output by hand than gcc generated from my test. So I stand by my claim. :) Each access does need to jump, but that jump can be entirely within the exception entry, and we don't need to generate any actual jump instructions. --Andy --0000000000009b04ad05a96ac2b9 Content-Type: text/x-csrc; charset="US-ASCII"; name="asm_goto_opt.c" Content-Disposition: attachment; filename="asm_goto_opt.c" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kc42gtow0 I2RlZmluZSBFRkFVTFQgMTQKCnN0YXRpYyBpbnQgdW5zYWZlX3B1dF91c2VyKGludCAqdmFsdWUs IGludCAqcHRyKQp7Cglhc20gZ290byAoIjE6IG1vdmwgJVt2YWx1ZV0sICVbbWVtXVxuXHQiCgkJ ICAiLnB1c2hzZWN0aW9uIF9fZXhfdGFibGVcblx0IgoJCSAgIi5sb25nIDFiIC0gLlxuXHQiCgkJ ICAiLmxvbmcgZXJyIC0gLlxuXHQiCgkJICAiLnBvcHNlY3Rpb24iCgkJICA6OiBbdmFsdWVdICJy bWkiICgqdmFsdWUpLCBbbWVtXSAibSIgKCpwdHIpCgkJICA6OiBlcnIgKTsKCXJldHVybiAwOwoK ZXJyOgoJcmV0dXJuIC1FRkFVTFQ7Cn0KCmludCB0ZXN0KGludCAqdXNlcl9hLCBpbnQgKnVzZXJf YiwgaW50ICp1c2VyX2MsIGludCAqdXNlcl9kKQp7CglpbnQgYSA9IDEsIGIgPSAyLCBjID0gMywg ZCA9IDQ7CgoJaWYgKHVuc2FmZV9wdXRfdXNlcigmYSwgdXNlcl9hKSkKCQlnb3RvIGVycm9yOwoJ aWYgKHVuc2FmZV9wdXRfdXNlcigmYiwgdXNlcl9iKSkKCQlnb3RvIGVycm9yOwoJaWYgKHVuc2Fm ZV9wdXRfdXNlcigmYywgdXNlcl9jKSkKCQlnb3RvIGVycm9yOwoJaWYgKHVuc2FmZV9wdXRfdXNl cigmZCwgdXNlcl9kKSkKCQlnb3RvIGVycm9yOwoKCXJldHVybiAwOwoJCmVycm9yOgoJcmV0dXJu IC1FRkFVTFQ7Cn0K --0000000000009b04ad05a96ac2b9--