From mboxrd@z Thu Jan 1 00:00:00 1970 From: Herbert Xu Subject: Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1. Date: Fri, 3 Mar 2017 12:02:10 +0800 Message-ID: <20170303040210.GA24737@gondor.apana.org.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: davem@davemloft.net, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Krzysztof Kozlowski , Marek Szyprowski To: Nathan Royce Return-path: Received: from helcar.hengli.com.au ([209.40.204.226]:57933 "EHLO helcar.apana.org.au" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751332AbdCCG5j (ORCPT ); Fri, 3 Mar 2017 01:57:39 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-crypto-owner@vger.kernel.org List-ID: On Thu, Mar 02, 2017 at 05:35:30PM -0600, Nathan Royce wrote: > ARM ODroid XU4 > > $ cat /proc/config.gz | gunzip | grep XTS > CONFIG_CRYPTO_XTS=y > > $ grep xts /proc/crypto > //4.9.13 > name : xts(aes) > driver : xts(aes-generic) > //4.10.1 > > //cbc can be found though > > CRYPTTAB: > cryptswap1 UUID= /dev/urandom > swap,offset=2048,cipher=aes-xts-plain64:sha512,size=512,nofail > > FSTAB: > /dev/mapper/cryptswap1 none swap sw 0 0 > > Boot Log: > [ 10.535985] ------------[ cut here ]------------ > [ 10.539252] WARNING: CPU: 0 PID: 0 at crypto/skcipher.c:430 > skcipher_walk_first+0x13c/0x14c > [ 10.547542] Modules linked in: xor xor_neon aes_arm zlib_deflate > dm_crypt raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc > ip_tables x_tables > [ 10.561716] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.1-dirty #1 > [ 10.568049] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > [ 10.574171] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [ 10.581893] [] (show_stack) from [] > (dump_stack+0x84/0x98) > [ 10.589073] [] (dump_stack) from [] > (__warn+0xe8/0x100) > [ 10.595975] [] (__warn) from [] > (warn_slowpath_null+0x20/0x28) > [ 10.603546] [] (warn_slowpath_null) from [] > (skcipher_walk_first+0x13c/0x14c) > [ 10.612390] [] (skcipher_walk_first) from [] > (skcipher_walk_virt+0x1c/0x38) > [ 10.621056] [] (skcipher_walk_virt) from [] > (post_crypt+0x38/0x1c4) > [ 10.629022] [] (post_crypt) from [] > (decrypt_done+0x4c/0x54) > [ 10.636389] [] (decrypt_done) from [] > (s5p_aes_complete+0x70/0xfc) > [ 10.644274] [] (s5p_aes_complete) from [] > (s5p_aes_interrupt+0x134/0x1a0) > [ 10.652771] [] (s5p_aes_interrupt) from [] > (__handle_irq_event_percpu+0x9c/0x124) This looks like a bug in the s5p driver. It's calling the completion function straight from the IRQ handler, which is triggering the sanity check in skcipher_walk_first. The s5p driver needs to schedule a tasklet to call the completion function. Do you have crypto self-test enabled? If so it should've caught this at run-time. Otherwise you can disable the s5p driver until it's fixed. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt