From patchwork Fri Dec 1 21:19:22 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 120383 Delivered-To: patch@linaro.org Received: by 10.140.22.227 with SMTP id 90csp1655331qgn; Fri, 1 Dec 2017 13:25:58 -0800 (PST) X-Google-Smtp-Source: AGs4zMbPbQjvG7h7DIpgyuuw3XD9Hx13kncsLPrbMGIfA18jqw79SONtZpSIq8/IVAufdkRwRPfd X-Received: by 10.159.218.9 with SMTP id v9mr7226030plp.2.1512163558478; Fri, 01 Dec 2017 13:25:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1512163558; cv=none; d=google.com; s=arc-20160816; b=qNeEgBGb7Pr2cq4ma2quv3xxfgfr0OuHK7LEXEY6WQ5K9lnDM8IkoDim3eWN7xAKB3 qmAYq3dT8JrfmA3/EXVRxdTyBCMXsDjV73rdKyI+vGtqQKl8pXWYSEgGJoUdyOS59Eqn FW1SOI7DOJrbwqrgvxLSFtbNacNVGeftYmMjRBPnKaiUAvuo8/9r9ae3f1dbjPxQ9Eyv RR6M5z5pNvFPBGybAbcE4t3XvNY+VRqks9CHUVhW6nG7ydgmSRv5/Daf/I96RaGRTb/a NLv1dvWi8H1DSjloVoz1+YWDuDyKVHZbAx5Xnf9PXX7o96iKa+7gNCHkHRNpEtYtz4KY lxzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=Qt/xd+KegyReHZGqvmJO7B/Y1Ox6Ni6Bea4zhL7ay3A=; b=NGC3HX7WAJsJsh3qLA2opGFgIgeKN4PS7AoKfTZ7rfmtgX8+o4eadTBpmfXyMyLgmR 30lLt/2OobLXsE/EZJkZ98vHlocBKkRh+5d5qdaeyJ67Huy271wJI0W3cZKTvnUXo4/2 ZnQNk0xNtB8wo8dF9tJlBMulgl4vbXusLE7MduI3Rdth0CXBXvhgrnILI1V1Ws6gyKuu HCImIJ4SJzWr/dMNohtETXDZUaDCggu+zzOEnLZEkKZlWPkl0n4/iIKcM82b5CQ+rwiC b1sA5DJduKNDHovgqt4OrsROqfvzkuyNLBxkIvJSCVZXHa3sUfsKcksv8G+mzk9uQ3+H 1fkw== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org header.s=google header.b=ETXsPjKl; spf=pass (google.com: best guess record for domain of linux-rt-users-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-rt-users-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v5si5382509pgb.228.2017.12.01.13.25.58; Fri, 01 Dec 2017 13:25:58 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-rt-users-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org header.s=google header.b=ETXsPjKl; spf=pass (google.com: best guess record for domain of linux-rt-users-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-rt-users-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751039AbdLAVZ5 (ORCPT + 4 others); Fri, 1 Dec 2017 16:25:57 -0500 Received: from mail-wm0-f51.google.com ([74.125.82.51]:42721 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750742AbdLAVZ4 (ORCPT ); Fri, 1 Dec 2017 16:25:56 -0500 Received: by mail-wm0-f51.google.com with SMTP id l141so5815667wmg.1 for ; Fri, 01 Dec 2017 13:25:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=Qy+1B30JQiX13ylYDX0/X+LmSW0hYSP+tQMfDX+bpoQ=; b=ETXsPjKlrdKmfbRxrifHzx4Z+CrcmVrDx8vNT0lbJqIb3B6BJJY6BdxIFiVan9WA8C nozErTplaBpUPSyoZfPV5pGAcmVXfYxD+1B5L3Nm9Jc7+NeWk+wOff0DDEplaT3TCl/W vm0NBg9nvg6Lm4pH54wg2+rRgQT/TAikgBshg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=Qy+1B30JQiX13ylYDX0/X+LmSW0hYSP+tQMfDX+bpoQ=; b=loAsxlczrnEoQ2rstZwrscQ4fz6Py3Wr4jkcV23YrIhIFVsXnbKhbaRrl5aE6OfVEE 2jum65DYu7QzTuHOHZV1eveCvau5AwzJ7gk4yX1WhXQFxbzVIPSGssdm6diZM5YiqRy5 LCxxywoQOsWAKHeKelr4lvIXOczJKl1mfmf7Z4M/iA9aWfn1/+1gTIofz6hGOvPa9R+A OsxuUtnvKX8DOcUH2xbAfM5fvvDzC5YWlCRo+dlvBAJ5RLaOx9OGxDkaMvdhTApEp4xO SDOazo6WJF9J0S26Gyk1zhMEBwsNixKbhDnkDJ8TTvO/b2DgpUq0xRnV/B121MNfwPMv Rheg== X-Gm-Message-State: AJaThX62/UUbZLGmDHX3njRKTcA4olf3IYep7eahYKhjqOdnH5KW8+r6 Ys/FXspQkIoC8VgoFJnJLGk4Mw== X-Received: by 10.28.6.2 with SMTP id 2mr2171690wmg.37.1512163554727; Fri, 01 Dec 2017 13:25:54 -0800 (PST) Received: from localhost.localdomain ([105.150.171.234]) by smtp.gmail.com with ESMTPSA id p17sm2161682wma.23.2017.12.01.13.25.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Dec 2017 13:25:53 -0800 (PST) From: Ard Biesheuvel To: linux-crypto@vger.kernel.org Cc: herbert@gondor.apana.org.au, linux-arm-kernel@lists.infradead.org, Ard Biesheuvel , Dave Martin , Russell King - ARM Linux , Sebastian Andrzej Siewior , Mark Rutland , linux-rt-users@vger.kernel.org, Peter Zijlstra , Catalin Marinas , Will Deacon , Steven Rostedt , Thomas Gleixner Subject: [PATCH 0/5] crypto: arm64 - disable NEON across scatterwalk API calls Date: Fri, 1 Dec 2017 21:19:22 +0000 Message-Id: <20171201211927.24653-1-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.11.0 Sender: linux-rt-users-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rt-users@vger.kernel.org As reported by Sebastian, the way the arm64 NEON crypto code currently keeps kernel mode NEON enabled across calls into skcipher_walk_xxx() is causing problems with RT builds, given that the skcipher walk API may allocate and free temporary buffers it uses to present the input and output arrays to the crypto algorithm in blocksize sized chunks (where blocksize is the natural blocksize of the crypto algorithm), and doing so with NEON enabled means we're alloc/free'ing memory with preemption disabled. This was deliberate: when this code was introduced, each kernel_neon_begin() and kernel_neon_end() call incurred a fixed penalty of storing resp. loading the contents of all NEON registers to/from memory, and so doing it less often had an obvious performance benefit. However, in the mean time, we have refactored the core kernel mode NEON code, and now kernel_neon_begin() only incurs this penalty the first time it is called after entering the kernel, and the NEON register restore is deferred until returning to userland. This means pulling those calls into the loops that iterate over the input/output of the crypto algorithm is not a big deal anymore (although there are some places in the code where we relied on the NEON registers retaining their values between calls) So let's clean this up for arm64: update the NEON based skcipher drivers to no longer keep the NEON enabled when calling into the skcipher walk API. Note that the remaining crypto drivers simply operate on fixed buffers, so while the RT crowd may still feel the need to disable those (and the ones below as well, perhaps), they don't call back into the crypto layer like the ones updated by this series, and so there's no room for improvement there AFAICT. Cc: Dave Martin Cc: Russell King - ARM Linux Cc: Sebastian Andrzej Siewior Cc: Mark Rutland Cc: linux-rt-users@vger.kernel.org Cc: Peter Zijlstra Cc: Catalin Marinas Cc: Will Deacon Cc: Steven Rostedt Cc: Thomas Gleixner Ard Biesheuvel (5): crypto: arm64/aes-ce-ccm - move kernel mode neon en/disable into loop crypto: arm64/aes-blk - move kernel mode neon en/disable into loop crypto: arm64/aes-bs - move kernel mode neon en/disable into loop crypto: arm64/chacha20 - move kernel mode neon en/disable into loop crypto: arm64/ghash - move kernel mode neon en/disable into loop arch/arm64/crypto/aes-ce-ccm-glue.c | 47 +++++----- arch/arm64/crypto/aes-glue.c | 81 +++++++++--------- arch/arm64/crypto/aes-modes.S | 90 ++++++++++---------- arch/arm64/crypto/aes-neonbs-glue.c | 38 ++++----- arch/arm64/crypto/chacha20-neon-glue.c | 4 +- arch/arm64/crypto/ghash-ce-glue.c | 9 +- 6 files changed, 132 insertions(+), 137 deletions(-) -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html