Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2657185ybt; Fri, 3 Jul 2020 15:15:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz1qBLoiJSOTkozd7tBVFvQepvy+VV2DbPKJKl17wD6EtIfDRfChXu1/rOH0C9MbrjVIHTW X-Received: by 2002:a17:906:7a46:: with SMTP id i6mr32770933ejo.475.1593814554990; Fri, 03 Jul 2020 15:15:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593814554; cv=none; d=google.com; s=arc-20160816; b=xPwmhRoClrT/k1wBYDAxdXBXGkg1klTEyong5sEgiT8FCe7VbBtUc7XaxDlXfh4Mky CDlHji+a8SwbNu8RCicsobyA+DfBjVzGe/g1gK0yN+EJomqUx4k2/ZD9MCkH0lXHpjU5 bvDcIi6nUM7c81QmLrY5YXjTO4peE2EFFeTusmZjfpWr/yTodD93dVaVWqrzqpSk8ntw BYG3mZslDtksVjR6inTvyt4mnO9O2GIaQvOIQo8Ht0zUjsK1AuXLIfsRL2TyTLA9fbJT bi46b9nqVrQElaGEcqWvyKrSplzpYRiF2nMgW1ibmvBEGoIDGYCobs4EXiFx54jpYaoN aA7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=QUcRKxTGKqHrLCQeVF1jmfCxQ6tdrq7gxaS5I5Jqcm4=; b=Q5xgXH6kBBMckt7UtedW/mkM2hnpZesjGnX/qGEHNGAGXKCCMNJzL7vRaFp4FUivim 322UWLfQ8VeAXgeM4ZUzD0TUfZbsc2GCbW2/nod9orzhpk6JSmugejjxlN5QGG6hcu1F VGWlvuAqnia4ZYUYukprmju+4UMFgfjpDDu6NBF5l2kBqqc7Ve35m8a28D1QrZxEXcxd oj2IUl4+OrAyPYn8NwF5LaJGlpABjtl5PgU/frgdIi3fnFUOVuMUEfPpfBK2vCqEwKeg H5+GJX+WflYfGcHt2ZgnrfjydO4+041cZiLUoaaDzOt29EKcihY2OYflylhwFNAJkSjR zNOQ== ARC-Authentication-Results: i=1; mx.google.com; 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 w6si8484418ejn.265.2020.07.03.15.15.32; Fri, 03 Jul 2020 15:15:54 -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; 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 S1726610AbgGCWM3 (ORCPT + 99 others); Fri, 3 Jul 2020 18:12:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57718 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726258AbgGCWM3 (ORCPT ); Fri, 3 Jul 2020 18:12:29 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4FDF4C061794 for ; Fri, 3 Jul 2020 15:12:29 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jrTut-004r8S-IE; Fri, 03 Jul 2020 22:12:19 +0000 Date: Fri, 3 Jul 2020 23:12:19 +0100 From: Al Viro To: Linus Torvalds Cc: Michael Ellerman , Christophe Leroy , Josh Poimboeuf , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List Subject: Re: objtool clac/stac handling change.. Message-ID: <20200703221219.GV2786714@ZenIV.linux.org.uk> References: <87lfk26nx4.fsf@mpe.ellerman.id.au> <20200702201755.GO2786714@ZenIV.linux.org.uk> <20200702205902.GP2786714@ZenIV.linux.org.uk> <20200703013328.GQ2786714@ZenIV.linux.org.uk> <20200703210237.GS2786714@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 03, 2020 at 02:10:08PM -0700, Linus Torvalds wrote: > Yeah, the "stac" instruction isn't hugely fast, and serializes the > pipeline, so it's a nasty 20 cycles or something. > > But for chissake, this > (a) happens approximately never > (b) is after a fault that took a thousand cycles > > so the trivial thing to do is to just say "yeah, you need to add the > STAC when your optimistic thing failed and you have to fall back to > the byte-at-a-time tail case". Not the problem I'm concerned about, really. However, I would really like to lift stac/clac into the *callers* of raw_copy_from_user() et.al. and fold them into user_access_begin/user_access_end there. And that's where the rules become very interesting - raw_copy_from_user() is not "succeed or fail" thing, it's "tell me how much has been left to copy" one. Put it that way - here we really do have outputs on fault. PS: I hope to kill __copy_from_user()/__copy_to_user() outside of arch/* this cycle; not much is left by now. So I'm not talking about lifting stac/clac out into the wild - it will merge with access_ok into user_access_begin/end.