Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp844524ybt; Wed, 1 Jul 2020 11:25:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwweEjnNncL2SkkM17dU4q0SpbHcyRZ9f+KkAJOdMt7vh/9iOvClxCyIIDL5DWm9IU90tfX X-Received: by 2002:a05:6402:543:: with SMTP id i3mr11238885edx.182.1593627912044; Wed, 01 Jul 2020 11:25:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593627912; cv=none; d=google.com; s=arc-20160816; b=gXHhIy1es+N8cZu0xmRsBYdDgt9s30OkOCFr+0FalbxV7wtGoYXZSeUvk2vnmowOvh 0M5OuUNdw3kvGKZ2CmjgA17Vs/1T+w+Q9s/yp8fG4GbAL6oE7+lHotwv6XrXcCRMgjTj gvs93FheDrPgl7Pcx3IhaOyJpwOmqv6DAKS5UD5kT5J7xO4JrqBbj2AdE2vMCogGILDc 43MnRbiu4VszxLdfNSTeJOjplgeCyFckx0yqh93vpRlkDADorwGn5GkhK2lt9dX7w9Q9 UCogNM9zCZzpssKwwrWDgYF5XJUYrhnhuamRp4W3Zxpj3abXwqOyBz91Xp6l1Z/n9l5C wiGg== 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 :mime-version:dkim-signature; bh=x81wUyeE6edhNLmeEDm3xlnjGBDJuLBR3gciagbrLEM=; b=ZkTvc6b+h7IpSGGIWppMS3uXYpVcjcOVkjfg3+cyxIe9eBZNjgTNPGgODGdcRqMhuZ r4dhJGkReQGTpKZj+Z+IDzijBLIQOQCCs2+sRpEPWTlK8i/teliqpuge29VnRQtaBZbL GriUyzUsLyGSn9EC9njuhxJATQEzMoaoPxKnzKYtSrHFIJ9qIcHrozQPqeOplOQ5Zrou zY7ham6HFg6GCQoQ/USbZXsuwQtDZeYlWJ1OSNrnT4Uebx45S8/Eq9yPmNluGsKSucKX r2FhfAEOxdZdgFlJtzDyZqcfnosshS+7NLTNkWQDPT3iJNV7dpcAxcvO/WsAuffaXJT9 blww== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=FHw+TPEw; 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 nb1si4281104ejb.565.2020.07.01.11.24.47; Wed, 01 Jul 2020 11:25:12 -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=FHw+TPEw; 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 S1731491AbgGASWW (ORCPT + 99 others); Wed, 1 Jul 2020 14:22:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58888 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728467AbgGASWV (ORCPT ); Wed, 1 Jul 2020 14:22:21 -0400 Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7B3EDC08C5C1 for ; Wed, 1 Jul 2020 11:22:21 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id q7so15125004ljm.1 for ; Wed, 01 Jul 2020 11:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=x81wUyeE6edhNLmeEDm3xlnjGBDJuLBR3gciagbrLEM=; b=FHw+TPEwLbaCt17n6/gR1qq+Ag4lAR2XNknHb/iCF+Gpc7OGHu3lA0/y2uBYeAEIED Q22P4oZ0jXxsEzWhlMPe2dIc87i5jCgcODu7EI+G9yScCNogl8AHEppLJ6+tWoc+w5YE /ta+3B1KyE7lAE8Mi+b+C2xwsi5lBrylEuaSE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=x81wUyeE6edhNLmeEDm3xlnjGBDJuLBR3gciagbrLEM=; b=RwsfJs41W0yRXAucAFaLMQ+DQ4ep98FfL/pebyDc6H0L0j63oIyYEIdnnwZMpNOR7D tQwSGv2F+2qEX6gYjYUIAebN8nPEkln/g7pmt7BbdxArA+pX+VR7cKwJdyaTJkXEJ4RK mYKTK1MxX3UtxNGsliOP2XQVICiCL2k8s08JtpSUd65ZWMYSCIJaBRahW7wvYEVgrU1R OD0URthfe8HMWE/Uzkkg3IGVNk/pvqK0hPSoFqbMm8v6Ld2bDhz8HkUCxAshE9fHyozs LvglIEzFTicDVThVR/BnhGcQryyQc0L4Qs55UZ6ptr92Ou4ujtEEavicN7YnuextLFd0 KL0Q== X-Gm-Message-State: AOAM533lh0AJdubx7+QsnlHziql12z/VTo2tzWQBhvcc1p0ekrwKkagn EM7KvjSeb382aaGLs7JqHgqmbwhPmuU= X-Received: by 2002:a2e:b889:: with SMTP id r9mr14180341ljp.92.1593627739401; Wed, 01 Jul 2020 11:22:19 -0700 (PDT) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com. [209.85.167.44]) by smtp.gmail.com with ESMTPSA id g7sm2085587ljl.7.2020.07.01.11.22.18 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Jul 2020 11:22:18 -0700 (PDT) Received: by mail-lf1-f44.google.com with SMTP id o4so14289065lfi.7 for ; Wed, 01 Jul 2020 11:22:18 -0700 (PDT) X-Received: by 2002:ac2:5a5e:: with SMTP id r30mr15931800lfn.30.1593627737906; Wed, 01 Jul 2020 11:22:17 -0700 (PDT) MIME-Version: 1.0 From: Linus Torvalds Date: Wed, 1 Jul 2020 11:22:01 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: objtool clac/stac handling change.. To: Josh Poimboeuf , Peter Zijlstra Cc: "the arch/x86 maintainers" , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Josh / PeterZ, it turns out that clang seems to now have fixed the last known nagging details with "asm goto" with outputs, so I'm looking at actually trying to merge the support for that in the kernel. The main annoyance isn't actually using "asm goto" at all, the main annoyance is just that it will all have to be conditional on whether the compiler supports it or not. We have the config option for that already, but it will just end up with two copies of the code depending on that option. It's not a huge deal: the recent cleanups wrt the x86 uaccess code have made the code _much_ more straightforward and legible, and I'm not so worried about it all. Except that when I looked at this, I realized that I really had picked the wrong model for how exceptions are handled wrt stac/clac. In particular user access exceptions return with stac set, so we end up having a code pattern where the error case will also have to do the user_access_end() to finish the STAC region. Adding a user_access_end() to the user exception fault handler is trivial. But the thing I'm asking you for is how nasty it would be to change objtool to have those rules? IOW, right now we have if (!user_acces_begin(...)) goto efault; unsafe_get/put_user(ptr, val, label); user_access_end(); return 0; label: user_access_end(); efaulr: return -EFAULT; and I'd like to make the "label" case just go to "efault", with objtool knowing that the exception handling already did the user_access_end(). That would end up cleaning up the flow for a number of cases. Nasty? Trivial? Linus