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 X-Spam-Level: X-Spam-Status: No, score=-4.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C4240C4338F for ; Thu, 29 Jul 2021 17:14:21 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8F2F260F21 for ; Thu, 29 Jul 2021 17:14:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8F2F260F21 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=3c/IVsZYELkcj09mZ0d1GSfJjhB0eHEZTlbkS8mXrqE=; b=jrpiUTsLarI/oZ ++XrpLPM+38QnjLMncAevGxauZ3PkuHkbaldAFD3tyZ70gJtHv7dTkhNPdFdVkqVTMacYAmFboNCc U27eKVfkZn6DVFUeLJdH8jaCfvt4CqRk2RKKH6fJShCQHWzMtPsHn0QuT+tJPmObdylWAen/UG4Nu UG3Nu1rj9nW+HkSxsWWz4IiuY+csMvnA7XrKm71wZ2Kr442it/r1zSoc7Vlm7uFnoet3ghxISAwRd FgVM+IQXiF3T2ks2tM9nBcfId5K6T2QGdnZCuZjP38k5UTHuhVGh67cb4Y3lg3S7uKnZOcA3oB4VU Z+/PfaGGsoM/60fm2q9w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m99Zp-005GKm-JM; Thu, 29 Jul 2021 17:12:10 +0000 Received: from galois.linutronix.de ([2a0a:51c0:0:12e:550::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m99Z5-005Fuw-At for linux-arm-kernel@lists.infradead.org; Thu, 29 Jul 2021 17:11:25 +0000 Date: Thu, 29 Jul 2021 19:11:19 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1627578680; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=oZNx+VTgL+LSYGgINBXyUMNhiX9TfICOnzxw9wMkYnM=; b=DljP8kHnxrvFj+9VfTx5Us/0i0oKAcNRIKwlmDLm9YLg4di5Uw6MYetSoZzBMjta6xFixh OnLhceaN8nZPjmdLO2NYyCVtVxNdV4jY1pc3kZevVbEuLAF3QZY0PcFGfJ8JaW552463pB tzn5KvOWgE91/CDJwOpo+xOkOEoxigjFl6IwgGTyo/xP2mHPOGE3/NX1mgsmLGmVAevkeQ 3eK5FtHduZqQ3K1Cws/ZJJS7e7mehqxf1I4mMkLp6mzMFX+hMV8xDHxQIFENy8xsMtbm+K sEDR0QOjTb1C/1FE+ZFUD7OPfAOUKS/3+CNpy9nFrLu07pg7gTNzHOHRiuLrUw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1627578680; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=oZNx+VTgL+LSYGgINBXyUMNhiX9TfICOnzxw9wMkYnM=; b=rQdxTJnTz+c2H118cy33gRv2YJWhLFRnplhv0u6DyAGK+XVINWNZLUyO29jZpbHAh6H2zH 22Y0YIdjEoKq6qDw== From: Sebastian Andrzej Siewior To: Dave Martin Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , Thomas Gleixner Subject: Re: [PATCH] arm64/sve: Make kernel FPU protection RT friendly Message-ID: <20210729171119.5iu532i65hgmgypi@linutronix.de> References: <20210729105215.2222338-1-bigeasy@linutronix.de> <20210729105215.2222338-3-bigeasy@linutronix.de> <20210729135459.GL1724@arm.com> <20210729141748.q66pfjoma2a2qd2k@linutronix.de> <20210729153422.GN1724@arm.com> <20210729160030.p76p56r56vx4qoql@linutronix.de> <20210729160756.s6kvhvbdy2erqeq7@linutronix.de> <20210729163227.GR1724@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210729163227.GR1724@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210729_101123_560724_F399F0F2 X-CRM114-Status: GOOD ( 28.87 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2021-07-29 17:32:27 [+0100], Dave Martin wrote: > On Thu, Jul 29, 2021 at 06:07:56PM +0200, Sebastian Andrzej Siewior wrote: > > On 2021-07-29 18:00:31 [+0200], To Dave Martin wrote: > > > > > > But I get what you mean. I'm just not sure regarding the naming since > > > the code behaves the same on x86 and arm64 here. > > > > Assuming that everyone follows this pattern what about > > fpregs_lock() > > fpregs_unlock() > > I'm not sure about the "fpregs". This is really about CPU-local > resources that are contended between softirq and task context. > > Some arches might not to use fp in softirq context and then their fp > regs wouldn't need this; others might have other resources that aren't > "fp" regs, but are contended in the same way. if FP / SIMD is used in crypto then it is likely that they will aim for softirq for ipsec reasons. Wireguard, dm-crypt perform crypto in process context if I remember correctly. > My "local_bh" was meaning purely softirqs running on this CPU. This was > the original meaning of "local" in this API IIUC. This is one reason > why they must disable preemption: "local" is meaningless if preemption > is enabled, since otherwise we might randomly migrate between CPUs. You assume that BH also disable preemption which is an implementation detail. On RT local_bh_disable() disables BH on the current CPU. The task won't migrate to another CPU while preempted and another task, which invokes local_bh_disable() on the same CPU, will wait until the previous local_bh_disable() section completes. So all semantics which are expected by local_bh_disable() are preserved in RT - except for the part where preemption is disabled. > I guess the "local" was preserved in the naming on PREEMPT_RT to reduce > the amount of noise that would have resulted from a treewide rename, but > this word seems confusing if there is no CPU-localness involved. As I explained above, the BH on the local/current CPU is disabled as in no softirq is currently running on this CPU. The context however remains preemptible so there is no need for a rename. > In this particular case, we really do want to bind ourselves onto the > current CPU and disable softirqs on this CPU -- if they continue to run > elsewhere, that's just fine. > > What do you think about: > > get_bh_cpu_context() > put_bh_cpu_context() > > or something along those lines? So you are not buying the fpregs_lock()? Then I don't need to reach for the simd_lock() or such from the shelf? The problem I have with _bh_ is that on RT the BH/softirq context is not forced to complete if preempted as it would be the case with local_bh_disable(). So that is misleading. It is just that it happens not to matter in this case and it is sufficient on RT to disable preemption. It would be wrong to disable BH and preemption on RT (but it might be okay / needed in other cases). powerpc for instance has arch/powerpc/crypto/crc32c-vpmsum_glue.c doing doing crc32c with ALTIVEC (simd). They only disable preemption and their crypto_simd_usable() (the generic version of it) forbids an invocation in the softirq context. So matter how I look at it, it really comes down to the specific SIMD usage on an architecture. > Cheers > ---Dave Sebastian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel