Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1140134pxb; Wed, 10 Feb 2021 00:40:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJw/VdutIyeeG/JiFPw0V8pP5B85Ld0d5E1AEquG1TBUu8hGNQtTN/fYTkhlFUFXV5C+EQrs X-Received: by 2002:a50:e04d:: with SMTP id g13mr2163920edl.358.1612946411404; Wed, 10 Feb 2021 00:40:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612946411; cv=none; d=google.com; s=arc-20160816; b=oILolyBm2Y4x3sEb0ohTr526tL2HCtso6axomlkYWDbp+EJYIamXLbtpmC0DGC483Y wJeApnv4iAM2C6EjUXxQWN2SRBIJwmHd2flfuUKqAdn2CmeRuTlaJ4k8iZkN2/4D8wPe OPXIIiQiaVeoy6VbxjXnscgl4qqGJ1XzQvGb/7w4x6JOJQb/LjBX9CCeCjZQ/0LqTW0E 0KVA9y+GPxNK28QquPUg8Hgc1TW27WESDdOenQPObzcKA8aftPvLQ0fNL/mu7QcWcqJw 6w83a/dTCA9oMWe4/eOBdNhOO8WhZcHEbdflJDN28SN7bqcyugcSFZz1Mk+NsqK5CELy vD6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=jneCExN60aXN36zvebicDVanGrwwoACyzGzaXZezZlQ=; b=eBGu5UaTeNTXm5K5hj4lxGs5sYHLZVhwoJ0Yqb1Ib8O7NIkiaeNnmfxlxwtAVfMwT9 FqBQzExPlxYqVim0x63O6d3BBCkZS05S082ki251uJr+/uvuBfyhOByIhfcvog5NKsYx 0hGrTfGp5BoEdweq1m6gW6zhNvjqEmIZrbYd02zPIsuCNEZ+r2plY+PADpvSzFPsF8lD GOoRXQhBqO1El4/RJSWKEYR7xKLQanb2BuOnRlCBjnkmf9TvyFyeCHB3hMBwTJ9TyQ2s TZMsZ3Xc7c/WyrRjFKPtHfZc953g7hGKldGiWlw21Oof/X8mNIsvKXG/1Ocdq390WyMO YvTg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-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 v12si874388ejb.566.2021.02.10.00.39.46; Wed, 10 Feb 2021 00:40:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-crypto-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-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232386AbhBJHX6 (ORCPT + 99 others); Wed, 10 Feb 2021 02:23:58 -0500 Received: from helcar.hmeau.com ([216.24.177.18]:50248 "EHLO fornost.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232421AbhBJHX4 (ORCPT ); Wed, 10 Feb 2021 02:23:56 -0500 Received: from gwarestrin.arnor.me.apana.org.au ([192.168.103.7]) by fornost.hmeau.com with smtp (Exim 4.92 #5 (Debian)) id 1l9jq7-0001HR-KN; Wed, 10 Feb 2021 18:23:08 +1100 Received: by gwarestrin.arnor.me.apana.org.au (sSMTP sendmail emulation); Wed, 10 Feb 2021 18:23:07 +1100 Date: Wed, 10 Feb 2021 18:23:07 +1100 From: Herbert Xu To: Ard Biesheuvel Cc: linux-crypto@vger.kernel.org, linux-arm-kernel@lists.infradead.org, will@kernel.org, mark.rutland@arm.com, catalin.marinas@arm.com, Dave Martin , Eric Biggers Subject: Re: [PATCH v2 0/9] arm64: rework NEON yielding to avoid scheduling from asm code Message-ID: <20210210072307.GA4617@gondor.apana.org.au> References: <20210203113626.220151-1-ardb@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210203113626.220151-1-ardb@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Wed, Feb 03, 2021 at 12:36:17PM +0100, Ard Biesheuvel wrote: > Given how kernel mode NEON code disables preemption (to ensure that the > FP/SIMD register state is protected without having to context switch it), > we need to take care not to let those algorithms operate on unbounded > input data, or we may end up with excessive scheduling blackouts on > CONFIG_PREEMPT kernels. > > This is currently handled by the cond_yield_neon macros, which check the > preempt count and the TIF_NEED_RESCHED flag from assembler code, and call > into kernel_neon_end()+kernel_neon_begin(), triggering a reschedule. > This works as expected, but is a bit messy, given how much of the state > preserve/restore code in the algorithm needs to be duplicated, as well as > causing the need to manage the stack frame explicitly. All of this is better > handled by the compiler, especially now that we have enabled features such > as the shadow call stack and BTI, and are working to improve call stack > validation. > > In some cases, yielding is not necessary at all: algoritms that implement > skciphers and use the skcipher walk API will be invoked at page granularity, > which is granular enough for our purpose. > > In other cases, it is better to simply return early from the assembler > routine if a reschedule is pending, and let the C code handle with this, by > retrying the call until it completes. This removes any voluntary schedule() > calls from the call stack, making the code much easier to reason about in > the context of stack validation, rcu_tasks synchronization, etc. > > Practical note: assuming there are no objections to these changes, it may > be the most convenient to take patch #1 into the arm64 tree for v5.12, > and postpone the rest for merging via the crypto tree. (Note that this > series was created against the cryptodev tree, and so the arm64 maintainers > are also welcome to take the whole set if it applies cleanly to the arm64 > tree) > > Will: if you stick #1 on a separate branch, please base it on v5.11-rc1 > > Changes since v1: > - use sub+cbz instead of cmp+b.eq to avoid clobbering the flags in cond_yield > (patch #1) > > Cc: Dave Martin > Cc: Eric Biggers > > Ard Biesheuvel (9): > arm64: assembler: add cond_yield macro > crypto: arm64/sha1-ce - simplify NEON yield > crypto: arm64/sha2-ce - simplify NEON yield > crypto: arm64/sha3-ce - simplify NEON yield > crypto: arm64/sha512-ce - simplify NEON yield > crypto: arm64/aes-neonbs - remove NEON yield calls > crypto: arm64/aes-ce-mac - simplify NEON yield > crypto: arm64/crc-t10dif - move NEON yield to C code > arm64: assembler: remove conditional NEON yield macros > > arch/arm64/crypto/aes-glue.c | 21 +++-- > arch/arm64/crypto/aes-modes.S | 52 +++++-------- > arch/arm64/crypto/aes-neonbs-core.S | 8 +- > arch/arm64/crypto/crct10dif-ce-core.S | 43 +++-------- > arch/arm64/crypto/crct10dif-ce-glue.c | 30 ++++++-- > arch/arm64/crypto/sha1-ce-core.S | 47 ++++-------- > arch/arm64/crypto/sha1-ce-glue.c | 22 +++--- > arch/arm64/crypto/sha2-ce-core.S | 38 ++++----- > arch/arm64/crypto/sha2-ce-glue.c | 22 +++--- > arch/arm64/crypto/sha3-ce-core.S | 81 ++++++++------------ > arch/arm64/crypto/sha3-ce-glue.c | 14 ++-- > arch/arm64/crypto/sha512-ce-core.S | 29 ++----- > arch/arm64/crypto/sha512-ce-glue.c | 53 +++++++------ > arch/arm64/include/asm/assembler.h | 78 +++---------------- > 14 files changed, 209 insertions(+), 329 deletions(-) Patches 2-8 applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt