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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 93081D3C533 for ; Thu, 17 Oct 2024 22:05:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=nxarNPAwACJwqJb8USj46unjMf3KPclvu8FFUJSkAVI=; b=1B7M75m8iP8Bq+Do9QoKky3Uc1 2eiQDwIlBX/1qUAYl9LMHVOC15p588l5J5gAThTJvLN6MDCQJv3eKFRv+v78SdGzEiGGdlKr+Nkbl dZW2DTQ1TguIQxycC93UZgUIk5u8M/O8TzZtymuPQ2HjatSnNASReSYH/gxYNIwjF1PhBrH8o/47X 5pfspLbfLmYCew4gmcVutAZQAH9UwIQGXDUQatiTaMmbqMRFuQNNkBXxi4l6lNNeINga6ujgTqGg/ 14F9tIe+n4SCV9V5iLHFrSuxgT1VO2tEbRbIhzBHEPdcg8tOlcoXV73TJ4eknUlDokjCh/v6ldSFF mEsQwrJg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t1Yco-0000000GJ5p-1aOK; Thu, 17 Oct 2024 22:05:42 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t1YbM-0000000GIxK-46A3 for linux-arm-kernel@lists.infradead.org; Thu, 17 Oct 2024 22:04:14 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id D25115C5B7B; Thu, 17 Oct 2024 22:04:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B2DADC4CEC3; Thu, 17 Oct 2024 22:04:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1729202651; bh=WJiXraYnLFsn2UwSe85rbF1/b6U4gvtBHtFJkJLo8M8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DHOYOIAvZZ1gWxOepJPe/c72xDeAS/W3jVejl8b93mRbFAWpqpwrTNpEUJtlHCBNW yMFGcbUSxLWwvbZsFIlEfRjpNHgM6jyx3PE4XHScdFtLgoQo8xm6P9aFYa7I06HfxT oAaMYgZrdHGMrEfb3QXQcqJYfK/rRSsC56fX2LK7Fstd2fYKjufrSFNvRI0lVSoLxo sdMBwToKtfomEIqPus0RiGGTwv2tR0ySYxSGyGmztQwF9K9Os7OxEl+wCq6HgEP8Da qhYIrYkSCdH1NiCoSvYt5syp0fEAa3TblXqjcu/9qCMNNqPhKma2kQIwlKO1hoQC8f Fp63vCuEcRitg== Date: Thu, 17 Oct 2024 15:04:09 -0700 From: Eric Biggers To: Ard Biesheuvel Cc: Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, herbert@gondor.apana.org.au, will@kernel.org, catalin.marinas@arm.com, Kees Cook Subject: Re: [PATCH v3 0/2] arm64: Speed up CRC-32 using PMULL instructions Message-ID: <20241017220409.GC11717@sol.localdomain> References: <20241017094132.2482168-4-ardb+git@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241017_150413_078408_C4E43868 X-CRM114-Status: GOOD ( 13.24 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Oct 17, 2024 at 06:30:19PM +0200, Ard Biesheuvel wrote: > > Ard Biesheuvel (2): > > arm64/lib: Handle CRC-32 alternative in C code > > arm64/crc32: Implement 4-way interleave using PMULL > > > > I'll need to respin this - the crc32_be code doesn't actually work correctly. Right, good catch. It looks like it needs an rbit of the crc value at the beginning and end. lib/crc32test.c doesn't actually test crc32_be_arm64_4way() because it runs the tests with IRQs disabled; it probably shouldn't do that. On a slightly related topic, since any crc32_le() and __crc32c_le() functions in arch/*/lib/ are automatically exposed as shash algorithms via the crypto API (this was already the case, but your other patch makes this more explicit by properly separating them from the generic implementation), I wonder if all the remaining arch/*/crypto/crc32*.c should be migrated to arch/*/lib/, and then users of crc32 and crc32c like ext4 and f2fs should just use the library functions instead of shash. That would simply things greatly. See e.g. the horrible hacks used in ext4_chksum() and __f2fs_crc32()... The only crc32 and crc32c implementations that *aren't* software based are those in drivers/crypto/stm32/stm32-crc32.c and drivers/crypto/inside-secure/safexcel_hash.c. Access to those would be lost by going through lib. But I strongly suspect they exist just because the hardware supported it and not because they are actually useful. - Eric