* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
@ 2017-03-03 10:36 Nathan Royce
2017-03-03 12:04 ` Herbert Xu
0 siblings, 1 reply; 21+ messages in thread
From: Nathan Royce @ 2017-03-03 10:36 UTC (permalink / raw)
To: Herbert Xu
Cc: davem, linux-crypto, linux-kernel, Krzysztof Kozlowski, Marek Szyprowski
I do have ECB selected as well:
DM_CRYPT=y
CRYPTO_ECB=y
CRYPTO_XTS=y
name : ecb(aes)
driver : ecb-aes-s5p
module : kernel
priority : 100
refcnt : 1
selftest : passed
internal : no
type : ablkcipher
async : yes
blocksize : 16
min keysize : 16
max keysize : 32
ivsize : 0
geniv : <default>
//still no "xts" can be found in the list
I saw this about the regression that sounds similar to my issue,
except even when I built-in dm_crypt (no initramfs. just diving
straight into system), it still fails:
http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg23748.html
On Fri, Mar 3, 2017 at 3:33 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Fri, Mar 03, 2017 at 03:00:26AM -0600, Nathan Royce wrote:
>> OK, I went ahead and enabled self tests
>> "CRYPTO_MANAGER_DISABLE_TESTS=n", and my system was able to boot,
>> albeit with failures:
>> *****
>> Mar 02 23:14:38 server kernel: ---[ end trace 1c8a91f28cbcebf3 ]---
>> Mar 02 23:14:38 server kernel: alg: skcipher: encryption failed on
>> test 1 for xts(ecb-aes-s5p): ret=35
>> Mar 02 23:14:38 server kernel: device-mapper: table: 254:0: crypt:
>> Error allocating crypto tfm
>> Mar 02 23:14:38 server kernel: device-mapper: ioctl: error adding
>> target to table
>> Mar 02 23:14:39 server systemd-cryptsetup[234]: Failed to activate
>> with key file '/dev/urandom': Invalid argument
>> *****
>> (weird that it asked for the passphrase)
>>
>> But I do question whether the root issue is related to s5p... Maybe
>> there is a correlation in the warning, but to me it looks like the
>> issue is something else.
>
> I see. Do you have ECB enabled in your config? The new XTS requires
> ECB to be present so that could be your problem.
>
> There is already a patch on its way to stable to add the Kconfig
> select on ECB.
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
2017-03-03 10:36 XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1 Nathan Royce
@ 2017-03-03 12:04 ` Herbert Xu
2017-03-03 14:08 ` Nathan Royce
0 siblings, 1 reply; 21+ messages in thread
From: Herbert Xu @ 2017-03-03 12:04 UTC (permalink / raw)
To: Nathan Royce
Cc: davem, linux-crypto, linux-kernel, Krzysztof Kozlowski, Marek Szyprowski
On Fri, Mar 03, 2017 at 04:36:18AM -0600, Nathan Royce wrote:
> I do have ECB selected as well:
> DM_CRYPT=y
> CRYPTO_ECB=y
> CRYPTO_XTS=y
>
> name : ecb(aes)
> driver : ecb-aes-s5p
> module : kernel
> priority : 100
> refcnt : 1
> selftest : passed
> internal : no
> type : ablkcipher
> async : yes
> blocksize : 16
> min keysize : 16
> max keysize : 32
> ivsize : 0
> geniv : <default>
> //still no "xts" can be found in the list
Weird. So you can't find any instances of xts in /proc/crypto
at all? Even if the self-test fails it should still register an
entry there...
In any case, I think disabling the s5p driver should work at
least.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
2017-03-03 12:04 ` Herbert Xu
@ 2017-03-03 14:08 ` Nathan Royce
0 siblings, 0 replies; 21+ messages in thread
From: Nathan Royce @ 2017-03-03 14:08 UTC (permalink / raw)
To: Herbert Xu
Cc: davem, linux-crypto, linux-kernel, Krzysztof Kozlowski, Marek Szyprowski
Yup, when I disabled the s5p driver, xts DID show in the /proc/crypto list.
Heh, I was about to ask if it was something I should push towards
another maintainer for s5p stuff, but found you listed in that as
well.
If I am incorrect in that assumption, do let me know whom else I
should make aware of this issue.
Also let me know if you would like the rest of the kernel panic. Maybe
you already have enough to go on and don't need it.
Thanks for all that clarity.
On Fri, Mar 3, 2017 at 6:04 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Fri, Mar 03, 2017 at 04:36:18AM -0600, Nathan Royce wrote:
>> I do have ECB selected as well:
>> DM_CRYPT=y
>> CRYPTO_ECB=y
>> CRYPTO_XTS=y
>>
>> name : ecb(aes)
>> driver : ecb-aes-s5p
>> module : kernel
>> priority : 100
>> refcnt : 1
>> selftest : passed
>> internal : no
>> type : ablkcipher
>> async : yes
>> blocksize : 16
>> min keysize : 16
>> max keysize : 32
>> ivsize : 0
>> geniv : <default>
>> //still no "xts" can be found in the list
>
> Weird. So you can't find any instances of xts in /proc/crypto
> at all? Even if the self-test fails it should still register an
> entry there...
>
> In any case, I think disabling the s5p driver should work at
> least.
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
@ 2017-03-06 16:18 Nathan Royce
2017-03-06 17:35 ` Krzysztof Kozlowski
0 siblings, 1 reply; 21+ messages in thread
From: Nathan Royce @ 2017-03-06 16:18 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Herbert Xu, davem, linux-crypto, linux-kernel, Marek Szyprowski
I tried the patch you submitted, however it also fails for the most part.
"For the most part" because "xts" is now found.
$ grep xts /proc/crypto
name : xts(aes)
driver : xts(ecb-aes-s5p)
Fail:
*****
[ 21.057756] xor: using function: neon (352.000 MB/sec)
[ 21.064243] Unable to handle kernel NULL pointer dereference at
virtual address 00000004
[ 21.070966] pgd = c0004000
[ 21.073599] [00000004] *pgd=00000000
[ 21.077165] Internal error: Oops: 17 [#1] SMP ARM
[ 21.081836] Modules linked in: xor aes_arm xor_neon zlib_deflate
raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc
ip_tables x_tables
[ 21.095239] CPU: 5 PID: 121 Comm: irq/69-10830000 Not tainted 4.10.1-dirty #1
[ 21.102288] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 21.108355] task: ee3e3700 task.stack: edcf6000
[ 21.112821] PC is at post_crypt+0x1b4/0x1c4
[ 21.116972] LR is at post_crypt+0x1a8/0x1c4
[ 21.121131] pc : [<c0335c68>] lr : [<c0335c5c>] psr: 200c0093
[ 21.121131] sp : edcf7e68 ip : ec59dcf4 fp : 117ce9ac
[ 21.132576] r10: 244525e3 r9 : c0c0540c r8 : ec59dc00
[ 21.137768] r7 : 00000000 r6 : 00000400 r5 : 00000000 r4 : 00000000
[ 21.144267] r3 : ef49fcde r2 : 00000200 r1 : 00000200 r0 : 00000000
[ 21.150768] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment none
[ 21.157964] Control: 10c5387d Table: 6618c06a DAC: 00000051
[ 21.163677] Process irq/69-10830000 (pid: 121, stack limit = 0xedcf6218)
[ 21.170350] Stack: (0xedcf7e68 to 0xedcf8000)
[ 21.174684] 7e60: ef49fcdc ec93f200 ef49fcdc
ec93f200 ec59dddc 00000400
[ 21.182853] 7e80: 00000000 00000000 00000400 00000000 ef49fcdc
c01100fc 00000000 00000000
[ 21.190983] 7ea0: 00000000 00000000 00000000 c0110f80 00000010
00000010 0000000f 00040a01
[ 21.199128] 7ec0: 00000000 ec59dc00 c0c0540c 00000000 00000000
600c0013 00000002 00000000
[ 21.207274] 7ee0: ee889d20 c033608c eea21c90 c05a80d0 eea21ce8
eea21c90 0000000c 00040a01
[ 21.215418] 7f00: eea21ce8 eea21c90 0000000c 00000000 eea21ce8
c05a8290 00000000 00000001
[ 21.223564] 7f20: eea2a600 eea8a400 eea8a400 eea2a600 c016ee68
c0c0540c 00000000 c016ee84
[ 21.231710] 7f40: edcf6000 eea2a624 eea8a400 c016f198 eea2a640
00000000 c016ef7c 00040a01
[ 21.239868] 7f60: 00000000 eeb58280 edcf6000 00000000 eea2a640
eea2a600 c016f04c eeb582a8
[ 21.248000] 7f80: ee889d20 c0138710 edcf6000 eea2a640 c0138608
00000000 00000000 00000000
[ 21.256145] 7fa0: 00000000 00000000 00000000 c0107a38 00000000
00000000 00000000 00000000
[ 21.264291] 7fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 21.272428] 7fe0: 00000000 00000000 00000000 00000000 00000013
00000000 00000000 00000000
[ 21.280580] [<c0335c68>] (post_crypt) from [<c033608c>]
(decrypt_done+0x4c/0x54)
[ 21.287946] [<c033608c>] (decrypt_done) from [<c05a80d0>]
(s5p_aes_complete+0x70/0xfc)
[ 21.295845] [<c05a80d0>] (s5p_aes_complete) from [<c05a8290>]
(s5p_aes_interrupt+0x134/0x1a0)
[ 21.304323] [<c05a8290>] (s5p_aes_interrupt) from [<c016ee84>]
(irq_thread_fn+0x1c/0x54)
[ 21.312378] [<c016ee84>] (irq_thread_fn) from [<c016f198>]
(irq_thread+0x14c/0x204)
[ 21.320004] [<c016f198>] (irq_thread) from [<c0138710>] (kthread+0x108/0x138)
[ 21.327109] [<c0138710>] (kthread) from [<c0107a38>]
(ret_from_fork+0x14/0x3c)
[ 21.334300] Code: eb0114aa e598c118 e58d001c e1a04000 (e5906004)
[ 21.340363] ---[ end trace e87f375304ecdd42 ]---
[ 21.344961] genirq: exiting task "irq/69-10830000" (121) is an
active IRQ thread (irq 69)
[ 21.870157] irq 69: nobody cared (try booting with the "irqpoll" option)
[ 21.875435] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G D
4.10.1-dirty #1
[ 21.883027] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 21.889134] [<c010eb54>] (unwind_backtrace) from [<c010b408>]
(show_stack+0x10/0x14)
[ 21.896826] [<c010b408>] (show_stack) from [<c036c34c>]
(dump_stack+0x84/0x98)
[ 21.904015] [<c036c34c>] (dump_stack) from [<c01706cc>]
(__report_bad_irq+0x2c/0xcc)
[ 21.911716] [<c01706cc>] (__report_bad_irq) from [<c0170ad0>]
(note_interrupt+0x28c/0x2dc)
[ 21.919948] [<c0170ad0>] (note_interrupt) from [<c016dd20>]
(handle_irq_event_percpu+0x5c/0x7c)
[ 21.928614] [<c016dd20>] (handle_irq_event_percpu) from
[<c016dd78>] (handle_irq_event+0x38/0x5c)
[ 21.937451] [<c016dd78>] (handle_irq_event) from [<c0171470>]
(handle_fasteoi_irq+0xb8/0x190)
[ 21.945944] [<c0171470>] (handle_fasteoi_irq) from [<c016cf70>]
(generic_handle_irq+0x24/0x34)
[ 21.954522] [<c016cf70>] (generic_handle_irq) from [<c016d48c>]
(__handle_domain_irq+0x5c/0xb4)
[ 21.963188] [<c016d48c>] (__handle_domain_irq) from [<c01014e8>]
(gic_handle_irq+0x38/0x74)
[ 21.971505] [<c01014e8>] (gic_handle_irq) from [<c010bf8c>]
(__irq_svc+0x6c/0x90)
[ 21.978953] Exception stack(0xc0c01e68 to 0xc0c01eb0)
[ 21.983975] 1e60: 00200102 c0c5cec0 00000000
00000000 00000040 00000000
[ 21.992127] 1e80: c0c00000 00000001 c0c02080 c0c00000 00000000
efffc7c0 c0c01f00 c0c01eb8
[ 22.000271] 1ea0: c0120b58 c01206d4 600e0113 ffffffff
[ 22.005299] [<c010bf8c>] (__irq_svc) from [<c01206d4>]
(__do_softirq+0x90/0x21c)
[ 22.012667] [<c01206d4>] (__do_softirq) from [<c0120b58>]
(irq_exit+0xd8/0x140)
[ 22.019945] [<c0120b58>] (irq_exit) from [<c016d490>]
(__handle_domain_irq+0x60/0xb4)
[ 22.027743] [<c016d490>] (__handle_domain_irq) from [<c01014e8>]
(gic_handle_irq+0x38/0x74)
[ 22.036061] [<c01014e8>] (gic_handle_irq) from [<c010bf8c>]
(__irq_svc+0x6c/0x90)
[ 22.043510] Exception stack(0xc0c01f38 to 0xc0c01f80)
[ 22.048529] 1f20:
00000001 00000000
[ 22.056685] 1f40: 00000000 c0114e60 c0c00000 c0c05490 c0c0542c
c0b4ff88 c0c01f90 00000000
[ 22.064832] 1f60: 00000000 efffc7c0 600e0013 c0c01f88 c0108480
c0108484 600e0013 ffffffff
[ 22.072978] [<c010bf8c>] (__irq_svc) from [<c0108484>]
(arch_cpu_idle+0x38/0x3c)
[ 22.080347] [<c0108484>] (arch_cpu_idle) from [<c015da70>]
(do_idle+0x164/0x1f8)
[ 22.087708] [<c015da70>] (do_idle) from [<c015dda0>]
(cpu_startup_entry+0x18/0x1c)
[ 22.095258] [<c015dda0>] (cpu_startup_entry) from [<c0b00c74>]
(start_kernel+0x374/0x394)
[ 22.103389] handlers:
[ 22.105635] [<c016dde8>] irq_default_primary_handler threaded
[<c05a815c>] s5p_aes_interrupt
[ 22.114046] Disabling IRQ #69
[ 23.496638] Btrfs loaded, crc32c=crc32c-generic
*****
Do I need to add "irqpoll" to my u-boot boot config now?
Yeah, the mailing list bounced my original email because I wasn't
using plain-text, but my full post shows in Herbert's reply.
On Sun, Mar 5, 2017 at 11:16 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Fri, Mar 03, 2017 at 12:02:10PM +0800, Herbert Xu wrote:
>> 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
>> > <blank>
>> > //cbc can be found though
>> >
>> > CRYPTTAB:
>> > cryptswap1 UUID=<sanitized> /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] [<c010eb54>] (unwind_backtrace) from [<c010b408>]
>> > (show_stack+0x10/0x14)
>> > [ 10.581893] [<c010b408>] (show_stack) from [<c036772c>]
>> > (dump_stack+0x84/0x98)
>> > [ 10.589073] [<c036772c>] (dump_stack) from [<c011bb20>]
>> > (__warn+0xe8/0x100)
>> > [ 10.595975] [<c011bb20>] (__warn) from [<c011bc30>]
>> > (warn_slowpath_null+0x20/0x28)
>> > [ 10.603546] [<c011bc30>] (warn_slowpath_null) from [<c0329a48>]
>> > (skcipher_walk_first+0x13c/0x14c)
>> > [ 10.612390] [<c0329a48>] (skcipher_walk_first) from [<c0329b30>]
>> > (skcipher_walk_virt+0x1c/0x38)
>> > [ 10.621056] [<c0329b30>] (skcipher_walk_virt) from [<c0330ed0>]
>> > (post_crypt+0x38/0x1c4)
>> > [ 10.629022] [<c0330ed0>] (post_crypt) from [<c0331470>]
>> > (decrypt_done+0x4c/0x54)
>> > [ 10.636389] [<c0331470>] (decrypt_done) from [<c05a03f0>]
>> > (s5p_aes_complete+0x70/0xfc)
>> > [ 10.644274] [<c05a03f0>] (s5p_aes_complete) from [<c05a05b0>]
>> > (s5p_aes_interrupt+0x134/0x1a0)
>> > [ 10.652771] [<c05a05b0>] (s5p_aes_interrupt) from [<c016dc3c>]
>> > (__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.
>
> Tasklet... or threaded IRQ handler maybe? I sent a fix.
>
> BTW, I subscribe the crypto list but I could not find the original email
> there.
>
> Best regards,
> Krzysztof
>
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
2017-03-06 16:18 Nathan Royce
@ 2017-03-06 17:35 ` Krzysztof Kozlowski
2017-03-06 21:29 ` Nathan Royce
0 siblings, 1 reply; 21+ messages in thread
From: Krzysztof Kozlowski @ 2017-03-06 17:35 UTC (permalink / raw)
To: Nathan Royce
Cc: Herbert Xu, davem, linux-crypto, linux-kernel, Marek Szyprowski
On Mon, Mar 06, 2017 at 10:18:45AM -0600, Nathan Royce wrote:
> I tried the patch you submitted, however it also fails for the most part.
>
> "For the most part" because "xts" is now found.
> $ grep xts /proc/crypto
> name : xts(aes)
> driver : xts(ecb-aes-s5p)
Ah, so probably I did not fix the original issue but some other... or
maybe there are multiple issues.
Could you attach your config and any other essential reproduction steps (unusual settings?).
I saw you tried v4.10.1, could you try just v4.10?
Best regards,
Krzysztof
>
> Fail:
> *****
> [ 21.057756] xor: using function: neon (352.000 MB/sec)
> [ 21.064243] Unable to handle kernel NULL pointer dereference at
> virtual address 00000004
> [ 21.070966] pgd = c0004000
> [ 21.073599] [00000004] *pgd=00000000
> [ 21.077165] Internal error: Oops: 17 [#1] SMP ARM
> [ 21.081836] Modules linked in: xor aes_arm xor_neon zlib_deflate
> raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc
> ip_tables x_tables
> [ 21.095239] CPU: 5 PID: 121 Comm: irq/69-10830000 Not tainted 4.10.1-dirty #1
> [ 21.102288] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [ 21.108355] task: ee3e3700 task.stack: edcf6000
> [ 21.112821] PC is at post_crypt+0x1b4/0x1c4
> [ 21.116972] LR is at post_crypt+0x1a8/0x1c4
> [ 21.121131] pc : [<c0335c68>] lr : [<c0335c5c>] psr: 200c0093
> [ 21.121131] sp : edcf7e68 ip : ec59dcf4 fp : 117ce9ac
> [ 21.132576] r10: 244525e3 r9 : c0c0540c r8 : ec59dc00
> [ 21.137768] r7 : 00000000 r6 : 00000400 r5 : 00000000 r4 : 00000000
> [ 21.144267] r3 : ef49fcde r2 : 00000200 r1 : 00000200 r0 : 00000000
> [ 21.150768] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM
> Segment none
> [ 21.157964] Control: 10c5387d Table: 6618c06a DAC: 00000051
> [ 21.163677] Process irq/69-10830000 (pid: 121, stack limit = 0xedcf6218)
> [ 21.170350] Stack: (0xedcf7e68 to 0xedcf8000)
> [ 21.174684] 7e60: ef49fcdc ec93f200 ef49fcdc
> ec93f200 ec59dddc 00000400
> [ 21.182853] 7e80: 00000000 00000000 00000400 00000000 ef49fcdc
> c01100fc 00000000 00000000
> [ 21.190983] 7ea0: 00000000 00000000 00000000 c0110f80 00000010
> 00000010 0000000f 00040a01
> [ 21.199128] 7ec0: 00000000 ec59dc00 c0c0540c 00000000 00000000
> 600c0013 00000002 00000000
> [ 21.207274] 7ee0: ee889d20 c033608c eea21c90 c05a80d0 eea21ce8
> eea21c90 0000000c 00040a01
> [ 21.215418] 7f00: eea21ce8 eea21c90 0000000c 00000000 eea21ce8
> c05a8290 00000000 00000001
> [ 21.223564] 7f20: eea2a600 eea8a400 eea8a400 eea2a600 c016ee68
> c0c0540c 00000000 c016ee84
> [ 21.231710] 7f40: edcf6000 eea2a624 eea8a400 c016f198 eea2a640
> 00000000 c016ef7c 00040a01
> [ 21.239868] 7f60: 00000000 eeb58280 edcf6000 00000000 eea2a640
> eea2a600 c016f04c eeb582a8
> [ 21.248000] 7f80: ee889d20 c0138710 edcf6000 eea2a640 c0138608
> 00000000 00000000 00000000
> [ 21.256145] 7fa0: 00000000 00000000 00000000 c0107a38 00000000
> 00000000 00000000 00000000
> [ 21.264291] 7fc0: 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000
> [ 21.272428] 7fe0: 00000000 00000000 00000000 00000000 00000013
> 00000000 00000000 00000000
> [ 21.280580] [<c0335c68>] (post_crypt) from [<c033608c>]
> (decrypt_done+0x4c/0x54)
> [ 21.287946] [<c033608c>] (decrypt_done) from [<c05a80d0>]
> (s5p_aes_complete+0x70/0xfc)
> [ 21.295845] [<c05a80d0>] (s5p_aes_complete) from [<c05a8290>]
> (s5p_aes_interrupt+0x134/0x1a0)
> [ 21.304323] [<c05a8290>] (s5p_aes_interrupt) from [<c016ee84>]
> (irq_thread_fn+0x1c/0x54)
> [ 21.312378] [<c016ee84>] (irq_thread_fn) from [<c016f198>]
> (irq_thread+0x14c/0x204)
> [ 21.320004] [<c016f198>] (irq_thread) from [<c0138710>] (kthread+0x108/0x138)
> [ 21.327109] [<c0138710>] (kthread) from [<c0107a38>]
> (ret_from_fork+0x14/0x3c)
> [ 21.334300] Code: eb0114aa e598c118 e58d001c e1a04000 (e5906004)
> [ 21.340363] ---[ end trace e87f375304ecdd42 ]---
> [ 21.344961] genirq: exiting task "irq/69-10830000" (121) is an
> active IRQ thread (irq 69)
> [ 21.870157] irq 69: nobody cared (try booting with the "irqpoll" option)
> [ 21.875435] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G D
> 4.10.1-dirty #1
> [ 21.883027] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [ 21.889134] [<c010eb54>] (unwind_backtrace) from [<c010b408>]
> (show_stack+0x10/0x14)
> [ 21.896826] [<c010b408>] (show_stack) from [<c036c34c>]
> (dump_stack+0x84/0x98)
> [ 21.904015] [<c036c34c>] (dump_stack) from [<c01706cc>]
> (__report_bad_irq+0x2c/0xcc)
> [ 21.911716] [<c01706cc>] (__report_bad_irq) from [<c0170ad0>]
> (note_interrupt+0x28c/0x2dc)
> [ 21.919948] [<c0170ad0>] (note_interrupt) from [<c016dd20>]
> (handle_irq_event_percpu+0x5c/0x7c)
> [ 21.928614] [<c016dd20>] (handle_irq_event_percpu) from
> [<c016dd78>] (handle_irq_event+0x38/0x5c)
> [ 21.937451] [<c016dd78>] (handle_irq_event) from [<c0171470>]
> (handle_fasteoi_irq+0xb8/0x190)
> [ 21.945944] [<c0171470>] (handle_fasteoi_irq) from [<c016cf70>]
> (generic_handle_irq+0x24/0x34)
> [ 21.954522] [<c016cf70>] (generic_handle_irq) from [<c016d48c>]
> (__handle_domain_irq+0x5c/0xb4)
> [ 21.963188] [<c016d48c>] (__handle_domain_irq) from [<c01014e8>]
> (gic_handle_irq+0x38/0x74)
> [ 21.971505] [<c01014e8>] (gic_handle_irq) from [<c010bf8c>]
> (__irq_svc+0x6c/0x90)
> [ 21.978953] Exception stack(0xc0c01e68 to 0xc0c01eb0)
> [ 21.983975] 1e60: 00200102 c0c5cec0 00000000
> 00000000 00000040 00000000
> [ 21.992127] 1e80: c0c00000 00000001 c0c02080 c0c00000 00000000
> efffc7c0 c0c01f00 c0c01eb8
> [ 22.000271] 1ea0: c0120b58 c01206d4 600e0113 ffffffff
> [ 22.005299] [<c010bf8c>] (__irq_svc) from [<c01206d4>]
> (__do_softirq+0x90/0x21c)
> [ 22.012667] [<c01206d4>] (__do_softirq) from [<c0120b58>]
> (irq_exit+0xd8/0x140)
> [ 22.019945] [<c0120b58>] (irq_exit) from [<c016d490>]
> (__handle_domain_irq+0x60/0xb4)
> [ 22.027743] [<c016d490>] (__handle_domain_irq) from [<c01014e8>]
> (gic_handle_irq+0x38/0x74)
> [ 22.036061] [<c01014e8>] (gic_handle_irq) from [<c010bf8c>]
> (__irq_svc+0x6c/0x90)
> [ 22.043510] Exception stack(0xc0c01f38 to 0xc0c01f80)
> [ 22.048529] 1f20:
> 00000001 00000000
> [ 22.056685] 1f40: 00000000 c0114e60 c0c00000 c0c05490 c0c0542c
> c0b4ff88 c0c01f90 00000000
> [ 22.064832] 1f60: 00000000 efffc7c0 600e0013 c0c01f88 c0108480
> c0108484 600e0013 ffffffff
> [ 22.072978] [<c010bf8c>] (__irq_svc) from [<c0108484>]
> (arch_cpu_idle+0x38/0x3c)
> [ 22.080347] [<c0108484>] (arch_cpu_idle) from [<c015da70>]
> (do_idle+0x164/0x1f8)
> [ 22.087708] [<c015da70>] (do_idle) from [<c015dda0>]
> (cpu_startup_entry+0x18/0x1c)
> [ 22.095258] [<c015dda0>] (cpu_startup_entry) from [<c0b00c74>]
> (start_kernel+0x374/0x394)
> [ 22.103389] handlers:
> [ 22.105635] [<c016dde8>] irq_default_primary_handler threaded
> [<c05a815c>] s5p_aes_interrupt
> [ 22.114046] Disabling IRQ #69
> [ 23.496638] Btrfs loaded, crc32c=crc32c-generic
> *****
> Do I need to add "irqpoll" to my u-boot boot config now?
>
> Yeah, the mailing list bounced my original email because I wasn't
> using plain-text, but my full post shows in Herbert's reply.
>
> On Sun, Mar 5, 2017 at 11:16 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Fri, Mar 03, 2017 at 12:02:10PM +0800, Herbert Xu wrote:
> >> 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
> >> > <blank>
> >> > //cbc can be found though
> >> >
> >> > CRYPTTAB:
> >> > cryptswap1 UUID=<sanitized> /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] [<c010eb54>] (unwind_backtrace) from [<c010b408>]
> >> > (show_stack+0x10/0x14)
> >> > [ 10.581893] [<c010b408>] (show_stack) from [<c036772c>]
> >> > (dump_stack+0x84/0x98)
> >> > [ 10.589073] [<c036772c>] (dump_stack) from [<c011bb20>]
> >> > (__warn+0xe8/0x100)
> >> > [ 10.595975] [<c011bb20>] (__warn) from [<c011bc30>]
> >> > (warn_slowpath_null+0x20/0x28)
> >> > [ 10.603546] [<c011bc30>] (warn_slowpath_null) from [<c0329a48>]
> >> > (skcipher_walk_first+0x13c/0x14c)
> >> > [ 10.612390] [<c0329a48>] (skcipher_walk_first) from [<c0329b30>]
> >> > (skcipher_walk_virt+0x1c/0x38)
> >> > [ 10.621056] [<c0329b30>] (skcipher_walk_virt) from [<c0330ed0>]
> >> > (post_crypt+0x38/0x1c4)
> >> > [ 10.629022] [<c0330ed0>] (post_crypt) from [<c0331470>]
> >> > (decrypt_done+0x4c/0x54)
> >> > [ 10.636389] [<c0331470>] (decrypt_done) from [<c05a03f0>]
> >> > (s5p_aes_complete+0x70/0xfc)
> >> > [ 10.644274] [<c05a03f0>] (s5p_aes_complete) from [<c05a05b0>]
> >> > (s5p_aes_interrupt+0x134/0x1a0)
> >> > [ 10.652771] [<c05a05b0>] (s5p_aes_interrupt) from [<c016dc3c>]
> >> > (__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.
> >
> > Tasklet... or threaded IRQ handler maybe? I sent a fix.
> >
> > BTW, I subscribe the crypto list but I could not find the original email
> > there.
> >
> > Best regards,
> > Krzysztof
> >
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
2017-03-06 17:35 ` Krzysztof Kozlowski
@ 2017-03-06 21:29 ` Nathan Royce
2017-03-08 17:45 ` Krzysztof Kozlowski
0 siblings, 1 reply; 21+ messages in thread
From: Nathan Royce @ 2017-03-06 21:29 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Herbert Xu, davem, linux-crypto, linux-kernel, Marek Szyprowski
[-- Attachment #1: Type: text/plain, Size: 9163 bytes --]
OK, I just tried 4.10.0 and the output is looking the same.
I can't say my setup is all that odd. The cryptographic use is only
with the swap partition found in my original email (seen in Herbert's
reply).
My normal build goes as such:
1) git clean -xdf
2) git reset --hard
3) curl https://github.com/tobetter/linux/commit/9cdf86bac1db2d74bf98508226e86679581f8f80.patch
| git apply -
//usb: host: xhci-plat: Get PHYs for xhci's hcds
4) curl https://github.com/tobetter/linux/commit/142cf1b68fa0e1710f3623875d5c269cbbc2f005.patch
| git apply -
//base: platform: name the device already during allocation
5) curl https://github.com/tobetter/linux/commit/3772f11d73289ea40825f40ba5c64b5b0e3888ff.patch
| git apply -
//phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
6) sed -i -e "s/static void exynos5420_usbdrd_phy_calibrate/static int
exynos5420_usbdrd_phy_calibrate/" ./drivers/phy/phy-exynos5-usbdrd.c
7) //duplicate entry in drivers/media/usb/au0828/au0828-cards.c for my
0x400 vid tuner.
8) HOST_EXTRACFLAGS="-O3 -pipe -mfpu=neon-vfpv4 -mfloat-abi=hard
-march=armv7-a -mtune=cortex-a15.cortex-a7" make -j 8 zImage
exynos5422-odroidxu4.dtb modules 2>&1 | tee make.log
9) INSTALL_MOD_PATH=./tmp INSTALL_FW_PATH=./tmp make modules_install
firmware_install 2>&1 | tee makeModFirm.log
10) sudo cp -rv ./tmp/lib/* /usr/lib
11) sudo cp -v ./arch/arm/boot/zImage /boot/zImage-4.10.0
12) sudo cp -v ./arch/arm/boot/dts/exynos5422-odroidxu4.dtb
/boot/exynos5422-odroidxu4-4.10.0.dtb
13) sudo ln -s /boot/zImage-4.10.0 /boot/zImage
14) sudo ln -s /boot/exynos5422-odroidxu4-4.10.0.dtb
/boot/exynos5422-odroidxu4.dtb
15) sudo sync
16) sudo systemctl reboot
I've attached the config I use.
On Mon, Mar 6, 2017 at 11:35 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Mon, Mar 06, 2017 at 10:18:45AM -0600, Nathan Royce wrote:
>> I tried the patch you submitted, however it also fails for the most part.
>>
>> "For the most part" because "xts" is now found.
>> $ grep xts /proc/crypto
>> name : xts(aes)
>> driver : xts(ecb-aes-s5p)
>
> Ah, so probably I did not fix the original issue but some other... or
> maybe there are multiple issues.
>
> Could you attach your config and any other essential reproduction steps (unusual settings?).
>
> I saw you tried v4.10.1, could you try just v4.10?
>
> Best regards,
> Krzysztof
>
>>
>> Fail:
>> *****
>> [ 21.057756] xor: using function: neon (352.000 MB/sec)
>> [ 21.064243] Unable to handle kernel NULL pointer dereference at
>> virtual address 00000004
>> [ 21.070966] pgd = c0004000
>> [ 21.073599] [00000004] *pgd=00000000
>> [ 21.077165] Internal error: Oops: 17 [#1] SMP ARM
>> [ 21.081836] Modules linked in: xor aes_arm xor_neon zlib_deflate
>> raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc
>> ip_tables x_tables
>> [ 21.095239] CPU: 5 PID: 121 Comm: irq/69-10830000 Not tainted 4.10.1-dirty #1
>> [ 21.102288] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [ 21.108355] task: ee3e3700 task.stack: edcf6000
>> [ 21.112821] PC is at post_crypt+0x1b4/0x1c4
>> [ 21.116972] LR is at post_crypt+0x1a8/0x1c4
>> [ 21.121131] pc : [<c0335c68>] lr : [<c0335c5c>] psr: 200c0093
>> [ 21.121131] sp : edcf7e68 ip : ec59dcf4 fp : 117ce9ac
>> [ 21.132576] r10: 244525e3 r9 : c0c0540c r8 : ec59dc00
>> [ 21.137768] r7 : 00000000 r6 : 00000400 r5 : 00000000 r4 : 00000000
>> [ 21.144267] r3 : ef49fcde r2 : 00000200 r1 : 00000200 r0 : 00000000
>> [ 21.150768] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM
>> Segment none
>> [ 21.157964] Control: 10c5387d Table: 6618c06a DAC: 00000051
>> [ 21.163677] Process irq/69-10830000 (pid: 121, stack limit = 0xedcf6218)
>> [ 21.170350] Stack: (0xedcf7e68 to 0xedcf8000)
>> [ 21.174684] 7e60: ef49fcdc ec93f200 ef49fcdc
>> ec93f200 ec59dddc 00000400
>> [ 21.182853] 7e80: 00000000 00000000 00000400 00000000 ef49fcdc
>> c01100fc 00000000 00000000
>> [ 21.190983] 7ea0: 00000000 00000000 00000000 c0110f80 00000010
>> 00000010 0000000f 00040a01
>> [ 21.199128] 7ec0: 00000000 ec59dc00 c0c0540c 00000000 00000000
>> 600c0013 00000002 00000000
>> [ 21.207274] 7ee0: ee889d20 c033608c eea21c90 c05a80d0 eea21ce8
>> eea21c90 0000000c 00040a01
>> [ 21.215418] 7f00: eea21ce8 eea21c90 0000000c 00000000 eea21ce8
>> c05a8290 00000000 00000001
>> [ 21.223564] 7f20: eea2a600 eea8a400 eea8a400 eea2a600 c016ee68
>> c0c0540c 00000000 c016ee84
>> [ 21.231710] 7f40: edcf6000 eea2a624 eea8a400 c016f198 eea2a640
>> 00000000 c016ef7c 00040a01
>> [ 21.239868] 7f60: 00000000 eeb58280 edcf6000 00000000 eea2a640
>> eea2a600 c016f04c eeb582a8
>> [ 21.248000] 7f80: ee889d20 c0138710 edcf6000 eea2a640 c0138608
>> 00000000 00000000 00000000
>> [ 21.256145] 7fa0: 00000000 00000000 00000000 c0107a38 00000000
>> 00000000 00000000 00000000
>> [ 21.264291] 7fc0: 00000000 00000000 00000000 00000000 00000000
>> 00000000 00000000 00000000
>> [ 21.272428] 7fe0: 00000000 00000000 00000000 00000000 00000013
>> 00000000 00000000 00000000
>> [ 21.280580] [<c0335c68>] (post_crypt) from [<c033608c>]
>> (decrypt_done+0x4c/0x54)
>> [ 21.287946] [<c033608c>] (decrypt_done) from [<c05a80d0>]
>> (s5p_aes_complete+0x70/0xfc)
>> [ 21.295845] [<c05a80d0>] (s5p_aes_complete) from [<c05a8290>]
>> (s5p_aes_interrupt+0x134/0x1a0)
>> [ 21.304323] [<c05a8290>] (s5p_aes_interrupt) from [<c016ee84>]
>> (irq_thread_fn+0x1c/0x54)
>> [ 21.312378] [<c016ee84>] (irq_thread_fn) from [<c016f198>]
>> (irq_thread+0x14c/0x204)
>> [ 21.320004] [<c016f198>] (irq_thread) from [<c0138710>] (kthread+0x108/0x138)
>> [ 21.327109] [<c0138710>] (kthread) from [<c0107a38>]
>> (ret_from_fork+0x14/0x3c)
>> [ 21.334300] Code: eb0114aa e598c118 e58d001c e1a04000 (e5906004)
>> [ 21.340363] ---[ end trace e87f375304ecdd42 ]---
>> [ 21.344961] genirq: exiting task "irq/69-10830000" (121) is an
>> active IRQ thread (irq 69)
>> [ 21.870157] irq 69: nobody cared (try booting with the "irqpoll" option)
>> [ 21.875435] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G D
>> 4.10.1-dirty #1
>> [ 21.883027] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [ 21.889134] [<c010eb54>] (unwind_backtrace) from [<c010b408>]
>> (show_stack+0x10/0x14)
>> [ 21.896826] [<c010b408>] (show_stack) from [<c036c34c>]
>> (dump_stack+0x84/0x98)
>> [ 21.904015] [<c036c34c>] (dump_stack) from [<c01706cc>]
>> (__report_bad_irq+0x2c/0xcc)
>> [ 21.911716] [<c01706cc>] (__report_bad_irq) from [<c0170ad0>]
>> (note_interrupt+0x28c/0x2dc)
>> [ 21.919948] [<c0170ad0>] (note_interrupt) from [<c016dd20>]
>> (handle_irq_event_percpu+0x5c/0x7c)
>> [ 21.928614] [<c016dd20>] (handle_irq_event_percpu) from
>> [<c016dd78>] (handle_irq_event+0x38/0x5c)
>> [ 21.937451] [<c016dd78>] (handle_irq_event) from [<c0171470>]
>> (handle_fasteoi_irq+0xb8/0x190)
>> [ 21.945944] [<c0171470>] (handle_fasteoi_irq) from [<c016cf70>]
>> (generic_handle_irq+0x24/0x34)
>> [ 21.954522] [<c016cf70>] (generic_handle_irq) from [<c016d48c>]
>> (__handle_domain_irq+0x5c/0xb4)
>> [ 21.963188] [<c016d48c>] (__handle_domain_irq) from [<c01014e8>]
>> (gic_handle_irq+0x38/0x74)
>> [ 21.971505] [<c01014e8>] (gic_handle_irq) from [<c010bf8c>]
>> (__irq_svc+0x6c/0x90)
>> [ 21.978953] Exception stack(0xc0c01e68 to 0xc0c01eb0)
>> [ 21.983975] 1e60: 00200102 c0c5cec0 00000000
>> 00000000 00000040 00000000
>> [ 21.992127] 1e80: c0c00000 00000001 c0c02080 c0c00000 00000000
>> efffc7c0 c0c01f00 c0c01eb8
>> [ 22.000271] 1ea0: c0120b58 c01206d4 600e0113 ffffffff
>> [ 22.005299] [<c010bf8c>] (__irq_svc) from [<c01206d4>]
>> (__do_softirq+0x90/0x21c)
>> [ 22.012667] [<c01206d4>] (__do_softirq) from [<c0120b58>]
>> (irq_exit+0xd8/0x140)
>> [ 22.019945] [<c0120b58>] (irq_exit) from [<c016d490>]
>> (__handle_domain_irq+0x60/0xb4)
>> [ 22.027743] [<c016d490>] (__handle_domain_irq) from [<c01014e8>]
>> (gic_handle_irq+0x38/0x74)
>> [ 22.036061] [<c01014e8>] (gic_handle_irq) from [<c010bf8c>]
>> (__irq_svc+0x6c/0x90)
>> [ 22.043510] Exception stack(0xc0c01f38 to 0xc0c01f80)
>> [ 22.048529] 1f20:
>> 00000001 00000000
>> [ 22.056685] 1f40: 00000000 c0114e60 c0c00000 c0c05490 c0c0542c
>> c0b4ff88 c0c01f90 00000000
>> [ 22.064832] 1f60: 00000000 efffc7c0 600e0013 c0c01f88 c0108480
>> c0108484 600e0013 ffffffff
>> [ 22.072978] [<c010bf8c>] (__irq_svc) from [<c0108484>]
>> (arch_cpu_idle+0x38/0x3c)
>> [ 22.080347] [<c0108484>] (arch_cpu_idle) from [<c015da70>]
>> (do_idle+0x164/0x1f8)
>> [ 22.087708] [<c015da70>] (do_idle) from [<c015dda0>]
>> (cpu_startup_entry+0x18/0x1c)
>> [ 22.095258] [<c015dda0>] (cpu_startup_entry) from [<c0b00c74>]
>> (start_kernel+0x374/0x394)
>> [ 22.103389] handlers:
>> [ 22.105635] [<c016dde8>] irq_default_primary_handler threaded
>> [<c05a815c>] s5p_aes_interrupt
>> [ 22.114046] Disabling IRQ #69
>> [ 23.496638] Btrfs loaded, crc32c=crc32c-generic
>> *****
>> Do I need to add "irqpoll" to my u-boot boot config now?
>>
>> Yeah, the mailing list bounced my original email because I wasn't
>> using plain-text, but my full post shows in Herbert's reply.
[-- Attachment #2: config-4.10.0.gz --]
[-- Type: application/x-gzip, Size: 28178 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
2017-03-06 21:29 ` Nathan Royce
@ 2017-03-08 17:45 ` Krzysztof Kozlowski
2017-03-08 21:15 ` Krzysztof Kozlowski
0 siblings, 1 reply; 21+ messages in thread
From: Krzysztof Kozlowski @ 2017-03-08 17:45 UTC (permalink / raw)
To: Nathan Royce
Cc: Herbert Xu, davem, linux-crypto, linux-kernel, Marek Szyprowski
On Mon, Mar 06, 2017 at 03:29:48PM -0600, Nathan Royce wrote:
> OK, I just tried 4.10.0 and the output is looking the same.
>
> I can't say my setup is all that odd. The cryptographic use is only
> with the swap partition found in my original email (seen in Herbert's
> reply).
You have quite specific/customized config and compilation flags.
I doubt that it causes the issue but at least the config is unusable on
anything other then XU3/XU4.
Anyway I reproduced some of the issues with tcrypt on Odroid U3 on v4.10
and v4.11-rc1, with regular exynos defconfig plus some more crypto
algorithms:
1. Without my patch: the original warning.
2. With my patch:
[ 95.170527] testing speed of async lrw(aes) (lrw(ecb-aes-s5p)) encryption
[ 95.173990] tcrypt: test 0 (256 bit key, 16 byte blocks): 19007 operations in 1 seconds (304112 bytes)
[ 96.175986] tcrypt: test 1 (256 bit key, 64 byte blocks): 15753 operations in 1 seconds (1008192 bytes)
[ 97.176099] tcrypt: test 2 (256 bit key, 256 byte blocks): 14293 operations in 1 seconds (3659008 bytes)
[ 98.176177] tcrypt: test 3 (256 bit key, 1024 byte blocks): 11906 operations in 1 seconds (12191744 bytes)
[ 99.176407] tcrypt: test 4 (256 bit key, 8192 byte blocks):
[ 99.177235] BUG: spinlock recursion on CPU#1, irq/84-10830000/89
[ 99.188034] lock: 0xeea99a68, .magic: dead4ead, .owner: irq/84-10830000/89, .owner_cpu: 1
[ 99.196282] CPU: 1 PID: 89 Comm: irq/84-10830000 Not tainted 4.11.0-rc1-00001-g897ca6d0800d #559
[ 99.205038] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 99.211158] [<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[ 99.218863] [<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[ 99.226060] [<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[ 99.233962] [<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[ 99.242733] [<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[ 99.251240] [<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[ 99.259230] [<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[ 99.267628] [<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[ 99.276046] [<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[ 99.284558] [<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[ 99.292624] [<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[ 99.300269] [<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[ 99.307382] [<c0136a28>] (kthread) from [<c0107778>] (ret_from_fork+0x14/0x3c)
I will take a look into this.
Thanks for the report.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
2017-03-08 17:45 ` Krzysztof Kozlowski
@ 2017-03-08 21:15 ` Krzysztof Kozlowski
2017-03-09 11:16 ` Nathan Royce
0 siblings, 1 reply; 21+ messages in thread
From: Krzysztof Kozlowski @ 2017-03-08 21:15 UTC (permalink / raw)
To: Nathan Royce
Cc: Herbert Xu, davem, linux-crypto, linux-kernel, Marek Szyprowski
On Wed, Mar 08, 2017 at 07:45:42PM +0200, Krzysztof Kozlowski wrote:
> On Mon, Mar 06, 2017 at 03:29:48PM -0600, Nathan Royce wrote:
> > OK, I just tried 4.10.0 and the output is looking the same.
> >
> > I can't say my setup is all that odd. The cryptographic use is only
> > with the swap partition found in my original email (seen in Herbert's
> > reply).
>
> You have quite specific/customized config and compilation flags.
> I doubt that it causes the issue but at least the config is unusable on
> anything other then XU3/XU4.
>
> Anyway I reproduced some of the issues with tcrypt on Odroid U3 on v4.10
> and v4.11-rc1, with regular exynos defconfig plus some more crypto
> algorithms:
> 1. Without my patch: the original warning.
> 2. With my patch:
I sent a fix. At least for spin lock recursion in tcrypt.
Could you give it a try?
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
2017-03-08 21:15 ` Krzysztof Kozlowski
@ 2017-03-09 11:16 ` Nathan Royce
2017-03-10 18:06 ` Krzysztof Kozlowski
0 siblings, 1 reply; 21+ messages in thread
From: Nathan Royce @ 2017-03-09 11:16 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Herbert Xu, davem, linux-crypto, linux-kernel, Marek Szyprowski
Gave it a try on 4.10.1, but still to no avail:
*****
[ 8.516138] raid6: using intx1 recovery algorithm
[ [0;32m OK [0m] Started Flush Journal to Persistent Storage.
[ 9.692091] Unable to handle kernel NULL pointer dereference at
virtual address 00000004
[ 9.698896] pgd = c0004000
[ 9.701489] [00000004] *pgd=00000000
[ 9.705055] Internal error: Oops: 17 [#1] SMP ARM
[ 9.709677] Modules linked in: xor_neon zlib_deflate aes_arm
raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc
ip_tables x_tables
[ 9.719177] xor: measuring software checksum speed
[ 9.727455] CPU: 2 PID: 121 Comm: irq/69-10830000 Not tainted 4.10.1-dirty #1
[ 9.728911] arm4regs : 304.000 MB/sec
[ 9.738707] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 9.738913] 8regs : 224.000 MB/sec
[ 9.748924] 32regs : 208.000 MB/sec
[ 9.753095] task: edc80b00 task.stack: edd08000
[ 9.757626] PC is at post_crypt+0x1b4/0x1c4
[ 9.758914] neon : 316.000 MB/sec
[ 9.758927] xor: using function: neon (316.000 MB/sec)
[ 9.771040] LR is at post_crypt+0x1a8/0x1c4
[ 9.775197] pc : [<c0335c68>] lr : [<c0335c5c>] psr: 200c0013
[ 9.775197] sp : edd09e90 ip : edcd64f4 fp : 02cfca75
[ 9.786670] r10: 3df4074e r9 : c0c0540c r8 : edcd6400
[ 9.791831] r7 : 00000000 r6 : 00000400 r5 : 00000000 r4 : 00000000
[ 9.798333] r3 : ef4a775a r2 : 00000200 r1 : 00000200 r0 : 00000000
[ 9.804834] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 9.811901] Control: 10c5387d Table: 6c61c06a DAC: 00000051
[ 9.817618] Process irq/69-10830000 (pid: 121, stack limit = 0xedd08218)
[ 9.824291] Stack: (0xedd09e90 to 0xedd0a000)
[ 9.828624] 9e80: ef4a7758
ecca6200 ef4a7758 ecca6200
[ 9.836781] 9ea0: edcd65dc 00000400 00000000 00000000 00000400
00000000 eea8f810 00000002
[ 9.844926] 9ec0: 00000000 00000000 00000000 00000000 00000000
00000000 00000010 00000010
[ 9.853072] 9ee0: 0000000f 00040a01 ee958390 edcd6400 ee9583bc
0000000c ee9583e8 00000000
[ 9.861217] 9f00: 00000000 600c0013 ee889d20 c033608c ee958390
c05a7ea8 00000000 00000001
[ 9.869363] 9f20: ee957b40 eea8a400 eea8a400 ee957b40 c016ee68
c0c0540c 00000000 c016ee84
[ 9.877508] 9f40: edd08000 ee957b64 eea8a400 c016f198 ee957b80
00000000 c016ef7c 00040a01
[ 9.885653] 9f60: 00000000 eea21380 edd08000 00000000 ee957b80
ee957b40 c016f04c eea213a8
[ 9.893800] 9f80: ee889d20 c0138710 edd08000 ee957b80 c0138608
00000000 00000000 00000000
[ 9.901944] 9fa0: 00000000 00000000 00000000 c0107a38 00000000
00000000 00000000 00000000
[ 9.910089] 9fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 9.918235] 9fe0: 00000000 00000000 00000000 00000000 00000013
00000000 00000000 00000000
[ 9.926399] [<c0335c68>] (post_crypt) from [<c033608c>]
(decrypt_done+0x4c/0x54)
[ 9.933761] [<c033608c>] (decrypt_done) from [<c05a7ea8>]
(s5p_aes_interrupt+0x1bc/0x208)
[ 9.941908] [<c05a7ea8>] (s5p_aes_interrupt) from [<c016ee84>]
(irq_thread_fn+0x1c/0x54)
[ 9.949956] [<c016ee84>] (irq_thread_fn) from [<c016f198>]
(irq_thread+0x14c/0x204)
[ 9.957585] [<c016f198>] (irq_thread) from [<c0138710>] (kthread+0x108/0x138)
[ 9.964681] [<c0138710>] (kthread) from [<c0107a38>]
(ret_from_fork+0x14/0x3c)
[ 9.971871] Code: eb0114aa e598c118 e58d001c e1a04000 (e5906004)
[ 9.977963] ---[ end trace 8c160bf6676cfe1c ]---
[ 9.982560] genirq: exiting task "irq/69-10830000" (121) is an
active IRQ thread (irq 69)
[ 11.715339] Btrfs loaded, crc32c=crc32c-generic
*****
Also for the sake of testing, I did not add any FLAGS for compilation this time.
On Wed, Mar 8, 2017 at 3:15 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Wed, Mar 08, 2017 at 07:45:42PM +0200, Krzysztof Kozlowski wrote:
> I sent a fix. At least for spin lock recursion in tcrypt.
>
> Could you give it a try?
>
> Best regards,
> Krzysztof
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
2017-03-09 11:16 ` Nathan Royce
@ 2017-03-10 18:06 ` Krzysztof Kozlowski
2017-03-10 21:44 ` Nathan Royce
0 siblings, 1 reply; 21+ messages in thread
From: Krzysztof Kozlowski @ 2017-03-10 18:06 UTC (permalink / raw)
To: Nathan Royce
Cc: Herbert Xu, davem, linux-crypto, linux-kernel, Marek Szyprowski
On Thu, Mar 09, 2017 at 05:16:35AM -0600, Nathan Royce wrote:
> Gave it a try on 4.10.1, but still to no avail:
(...)
> Also for the sake of testing, I did not add any FLAGS for compilation this time.
Damn, I am fixing bugs around but not the one you are hitting. Can you
also check if exynos_defconfig (+XTS + any other needed setting sfor
you) also has this issue?
I want to reproduce it but my setup does not use cryptswap. Probably I
will have to set it up.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
2017-03-10 18:06 ` Krzysztof Kozlowski
@ 2017-03-10 21:44 ` Nathan Royce
2017-03-12 19:13 ` Krzysztof Kozlowski
0 siblings, 1 reply; 21+ messages in thread
From: Nathan Royce @ 2017-03-10 21:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Herbert Xu, davem, linux-crypto, linux-kernel, Marek Szyprowski
[-- Attachment #1: Type: text/plain, Size: 3838 bytes --]
Sure, I went ahead and rebuilt it just using the bare exynos_defconfig
and adding XTS and ECB and no other changes.
No flags were used. No patches were used other than the 2 you
provided. Just the barest of bears, the barest of bones, the barest of
deserts, the barest of hairless cats.
I also wiped out the 4.10.1 modules directory and zImage and dtb
before copying them into place.
*****
[ 16.280951] s5p-jpeg 11f60000.jpeg: Samsung S5P JPEG codec
[ 16.327434] CPU: 3 PID: 115 Comm: irq/69-10830000 Not tainted 4.10.1-dirty #1
[ 16.334527] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 16.340533] task: edc52d00 task.stack: edcc0000
[ 16.345040] PC is at post_crypt+0x194/0x1a0 [xts]
[ 16.349712] LR is at post_crypt+0x188/0x1a0 [xts]
[ 16.354390] pc : [<bf182370>] lr : [<bf182364>] psr: 200d0113
[ 16.354390] sp : edcc1ea8 ip : ed6f38f4 fp : 30702272
[ 16.365838] r10: 8ee5436d r9 : 00000000 r8 : ed6f3800
[ 16.371023] r7 : 00000000 r6 : 00000400 r5 : 00000000 r4 : 00000000
[ 16.377523] r3 : ef5ead22 r2 : 00000200 r1 : 00000200 r0 : 00000000
[ 16.384024] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 16.391128] Control: 10c5387d Table: 6d6f806a DAC: 00000051
[ 16.396847] Process irq/69-10830000 (pid: 115, stack limit = 0xedcc0210)
[ 16.403519] Stack: (0xedcc1ea8 to 0xedcc2000)
[ 16.407853] 1ea0: c0c08304 ef5ead20 ecd69200
ef5ead20 ecd69200 ed6f39dc
[ 16.416011] 1ec0: 00000400 00000000 00000000 00000400 00000000
c010f774 c0113bac 00000000
[ 16.424156] 1ee0: 00000000 00000000 00000000 00000000 00000000
00000010 00000010 0000000f
[ 16.432302] 1f00: ed6f3800 edcae3bc 0000000c edcae3e8 00000000
600d0113 ee889d5c bf182764
[ 16.440447] 1f20: edcae390 c0566d84 00000000 00000001 edcacec0
eea14b00 00000000 eea14b00
[ 16.448592] 1f40: edcacec0 c01651c4 eeb00528 c01651e0 edcc0000
edcacee4 00000000 c01654b4
[ 16.456738] 1f60: 00000000 c01652b8 eeb00500 edcc0000 00000000
edcacf00 edcacec0 c0165388
[ 16.464884] 1f80: eeb00528 c013673c edcc0000 edcacf00 c0136634
00000000 00000000 00000000
[ 16.473029] 1fa0: 00000000 00000000 00000000 c0107778 00000000
00000000 00000000 00000000
[ 16.481174] 1fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 16.489320] 1fe0: 00000000 00000000 00000000 00000000 00000013
00000000 00000000 00000000
[ 16.497473] [<bf182370>] (post_crypt [xts]) from [<bf182764>]
(decrypt_done+0x4c/0x54 [xts])
[ 16.505877] [<bf182764>] (decrypt_done [xts]) from [<c0566d84>]
(s5p_aes_interrupt+0x1bc/0x208)
[ 16.514544] [<c0566d84>] (s5p_aes_interrupt) from [<c01651e0>]
(irq_thread_fn+0x1c/0x54)
[ 16.522592] [<c01651e0>] (irq_thread_fn) from [<c01654b4>]
(irq_thread+0x12c/0x1e0)
[ 16.530220] [<c01654b4>] (irq_thread) from [<c013673c>] (kthread+0x108/0x138)
[ 16.537324] [<c013673c>] (kthread) from [<c0107778>]
(ret_from_fork+0x14/0x3c)
[ 16.544514] Code: eb471ad2 e598c118 e58d0020 e1a04000 (e5906004)
[ 16.550709] ---[ end trace 0e5ce4ea2ad2d7e2 ]---
[ 16.555224] genirq: exiting task "irq/69-10830000" (115) is an
active IRQ thread (irq 69)
*****
I'm sure you could just copy my crypttab and fstab entries that is
shown in my first email.
On Fri, Mar 10, 2017 at 12:06 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Thu, Mar 09, 2017 at 05:16:35AM -0600, Nathan Royce wrote:
>> Gave it a try on 4.10.1, but still to no avail:
>
> (...)
>
>> Also for the sake of testing, I did not add any FLAGS for compilation this time.
>
> Damn, I am fixing bugs around but not the one you are hitting. Can you
> also check if exynos_defconfig (+XTS + any other needed setting sfor
> you) also has this issue?
>
> I want to reproduce it but my setup does not use cryptswap. Probably I
> will have to set it up.
>
> Best regards,
> Krzysztof
>
[-- Attachment #2: config_s5psss.tar.gz --]
[-- Type: application/x-gzip, Size: 31980 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
2017-03-10 21:44 ` Nathan Royce
@ 2017-03-12 19:13 ` Krzysztof Kozlowski
2017-03-13 17:06 ` Krzysztof Kozlowski
0 siblings, 1 reply; 21+ messages in thread
From: Krzysztof Kozlowski @ 2017-03-12 19:13 UTC (permalink / raw)
To: Nathan Royce
Cc: Herbert Xu, davem, linux-crypto, linux-kernel, Marek Szyprowski
On Fri, Mar 10, 2017 at 03:44:45PM -0600, Nathan Royce wrote:
> Sure, I went ahead and rebuilt it just using the bare exynos_defconfig
> and adding XTS and ECB and no other changes.
>
> No flags were used. No patches were used other than the 2 you
> provided. Just the barest of bears, the barest of bones, the barest of
> deserts, the barest of hairless cats.
>
Okay, I reproduced it. Beside enabling crypto tests, ECB and XTS, the
important step is to disable the "ARM Accelerated Cryptographic
Algorithms" so S5P-SSS will be used with XTS. The xts(ecb-aes-s5p))
itself passes TCRYPT tests but oopses on cryptswap.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
2017-03-12 19:13 ` Krzysztof Kozlowski
@ 2017-03-13 17:06 ` Krzysztof Kozlowski
2017-03-14 9:20 ` Herbert Xu
2017-04-06 9:54 ` Herbert Xu
0 siblings, 2 replies; 21+ messages in thread
From: Krzysztof Kozlowski @ 2017-03-13 17:06 UTC (permalink / raw)
To: Nathan Royce, Herbert Xu
Cc: davem, linux-crypto, linux-kernel, Marek Szyprowski
On Sun, Mar 12, 2017 at 09:13:22PM +0200, Krzysztof Kozlowski wrote:
> On Fri, Mar 10, 2017 at 03:44:45PM -0600, Nathan Royce wrote:
> > Sure, I went ahead and rebuilt it just using the bare exynos_defconfig
> > and adding XTS and ECB and no other changes.
> >
> > No flags were used. No patches were used other than the 2 you
> > provided. Just the barest of bears, the barest of bones, the barest of
> > deserts, the barest of hairless cats.
> >
>
> Okay, I reproduced it. Beside enabling crypto tests, ECB and XTS, the
> important step is to disable the "ARM Accelerated Cryptographic
> Algorithms" so S5P-SSS will be used with XTS. The xts(ecb-aes-s5p))
> itself passes TCRYPT tests but oopses on cryptswap.
Hi Herbert,
I bisected this to commit f1c131b45410 ("crypto: xts - Convert to
skcipher"). The s5p-sss driver stays the same... but the xts changes and
as a result we have a NULL pointer dereference (actually of value
00000004):
[ 18.930195] Unable to handle kernel NULL pointer dereference at virtual address 00000004
...
[ 18.972325] [<c0313c98>] (post_crypt) from [<c031408c>] (decrypt_done+0x4c/0x54)
[ 18.972343] [<c031408c>] (decrypt_done) from [<c056309c>] (s5p_aes_interrupt+0x1bc/0x208)
[ 18.972360] [<c056309c>] (s5p_aes_interrupt) from [<c0164930>] (irq_thread_fn+0x1c/0x54)
Any hints?
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
2017-03-13 17:06 ` Krzysztof Kozlowski
@ 2017-03-14 9:20 ` Herbert Xu
2017-04-06 9:54 ` Herbert Xu
1 sibling, 0 replies; 21+ messages in thread
From: Herbert Xu @ 2017-03-14 9:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Nathan Royce, davem, linux-crypto, linux-kernel, Marek Szyprowski
On Mon, Mar 13, 2017 at 07:06:01PM +0200, Krzysztof Kozlowski wrote:
>
> I bisected this to commit f1c131b45410 ("crypto: xts - Convert to
> skcipher"). The s5p-sss driver stays the same... but the xts changes and
> as a result we have a NULL pointer dereference (actually of value
> 00000004):
> [ 18.930195] Unable to handle kernel NULL pointer dereference at virtual address 00000004
> ...
> [ 18.972325] [<c0313c98>] (post_crypt) from [<c031408c>] (decrypt_done+0x4c/0x54)
> [ 18.972343] [<c031408c>] (decrypt_done) from [<c056309c>] (s5p_aes_interrupt+0x1bc/0x208)
> [ 18.972360] [<c056309c>] (s5p_aes_interrupt) from [<c0164930>] (irq_thread_fn+0x1c/0x54)
Well that's hardly surprising since xts prior to this commit used
simple AES as opposed to ecb(aes) so it couldn't have triggered
this bug.
> Any hints?
I'll have a look when I have time but no promises.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
2017-03-13 17:06 ` Krzysztof Kozlowski
2017-03-14 9:20 ` Herbert Xu
@ 2017-04-06 9:54 ` Herbert Xu
2017-04-08 2:02 ` Herbert Xu
1 sibling, 1 reply; 21+ messages in thread
From: Herbert Xu @ 2017-04-06 9:54 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Nathan Royce, davem, linux-crypto, linux-kernel, Marek Szyprowski
On Mon, Mar 13, 2017 at 07:06:01PM +0200, Krzysztof Kozlowski wrote:
>
> I bisected this to commit f1c131b45410 ("crypto: xts - Convert to
> skcipher"). The s5p-sss driver stays the same... but the xts changes and
> as a result we have a NULL pointer dereference (actually of value
> 00000004):
> [ 18.930195] Unable to handle kernel NULL pointer dereference at virtual address 00000004
> ...
> [ 18.972325] [<c0313c98>] (post_crypt) from [<c031408c>] (decrypt_done+0x4c/0x54)
> [ 18.972343] [<c031408c>] (decrypt_done) from [<c056309c>] (s5p_aes_interrupt+0x1bc/0x208)
> [ 18.972360] [<c056309c>] (s5p_aes_interrupt) from [<c0164930>] (irq_thread_fn+0x1c/0x54)
>
> Any hints?
I haven't found any smoking guns, but the locking between the
tasklet and the IRQ routine looks suspect. First of all the
tasklet is modifying the dev structure without holding any locks.
More importantly, the IRQ routine does not seem to be robust in
the face of spurious interrupts. Should a spurious interrupt
arrive, it is entirely possible for the tasklet's modifying of
dev->req to race with the IRQ routine which reads dev->req.
However, this does depend on there being a spurious interrupt so
I don't know how likely it is.
Anyway, if we can't get to the bottom of this, we should disable
the broken functionality.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
2017-04-06 9:54 ` Herbert Xu
@ 2017-04-08 2:02 ` Herbert Xu
2017-04-08 12:23 ` Krzysztof Kozlowski
0 siblings, 1 reply; 21+ messages in thread
From: Herbert Xu @ 2017-04-08 2:02 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Nathan Royce, davem, linux-crypto, linux-kernel, Marek Szyprowski
On Thu, Apr 06, 2017 at 05:54:14PM +0800, Herbert Xu wrote:
> On Mon, Mar 13, 2017 at 07:06:01PM +0200, Krzysztof Kozlowski wrote:
> >
> > I bisected this to commit f1c131b45410 ("crypto: xts - Convert to
> > skcipher"). The s5p-sss driver stays the same... but the xts changes and
> > as a result we have a NULL pointer dereference (actually of value
> > 00000004):
> > [ 18.930195] Unable to handle kernel NULL pointer dereference at virtual address 00000004
> > ...
> > [ 18.972325] [<c0313c98>] (post_crypt) from [<c031408c>] (decrypt_done+0x4c/0x54)
> > [ 18.972343] [<c031408c>] (decrypt_done) from [<c056309c>] (s5p_aes_interrupt+0x1bc/0x208)
> > [ 18.972360] [<c056309c>] (s5p_aes_interrupt) from [<c0164930>] (irq_thread_fn+0x1c/0x54)
> >
> > Any hints?
>
> I haven't found any smoking guns, but the locking between the
> tasklet and the IRQ routine looks suspect. First of all the
> tasklet is modifying the dev structure without holding any locks.
I think I see the problem. Could you please try this patch and
let me know if it fixes the crash?
---8<---
Subject: crypto: xts - Fix use-after-free on EINPROGRESS
When we get an EINPROGRESS completion in xts, we will end up marking
the request as done and freeing it. This then blows up when the
request is really completed as we've already freed the memory.
Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher")
Cc: <stable@vger.kernel.org>
Reported-by: Nathan Royce <nroycea+kernel@gmail.com>
Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/crypto/xts.c b/crypto/xts.c
index e197e64..d86c11a 100644
--- a/crypto/xts.c
+++ b/crypto/xts.c
@@ -286,6 +286,13 @@ static void encrypt_done(struct crypto_async_request *areq, int err)
struct rctx *rctx;
rctx = skcipher_request_ctx(req);
+
+ if (err == -EINPROGRESS) {
+ if (rctx->left != req->cryptlen)
+ return;
+ goto out;
+ }
+
subreq = &rctx->subreq;
subreq->base.flags &= CRYPTO_TFM_REQ_MAY_BACKLOG;
@@ -293,6 +300,7 @@ static void encrypt_done(struct crypto_async_request *areq, int err)
if (rctx->left)
return;
+out:
skcipher_request_complete(req, err);
}
@@ -330,6 +338,13 @@ static void decrypt_done(struct crypto_async_request *areq, int err)
struct rctx *rctx;
rctx = skcipher_request_ctx(req);
+
+ if (err == -EINPROGRESS) {
+ if (rctx->left != req->cryptlen)
+ return;
+ goto out;
+ }
+
subreq = &rctx->subreq;
subreq->base.flags &= CRYPTO_TFM_REQ_MAY_BACKLOG;
@@ -337,6 +352,7 @@ static void decrypt_done(struct crypto_async_request *areq, int err)
if (rctx->left)
return;
+out:
skcipher_request_complete(req, err);
}
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related [flat|nested] 21+ messages in thread* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
2017-04-08 2:02 ` Herbert Xu
@ 2017-04-08 12:23 ` Krzysztof Kozlowski
0 siblings, 0 replies; 21+ messages in thread
From: Krzysztof Kozlowski @ 2017-04-08 12:23 UTC (permalink / raw)
To: Herbert Xu
Cc: Nathan Royce, davem, linux-crypto, linux-kernel, Marek Szyprowski
On Sat, Apr 08, 2017 at 10:02:46AM +0800, Herbert Xu wrote:
> On Thu, Apr 06, 2017 at 05:54:14PM +0800, Herbert Xu wrote:
> > On Mon, Mar 13, 2017 at 07:06:01PM +0200, Krzysztof Kozlowski wrote:
> > >
> > > I bisected this to commit f1c131b45410 ("crypto: xts - Convert to
> > > skcipher"). The s5p-sss driver stays the same... but the xts changes and
> > > as a result we have a NULL pointer dereference (actually of value
> > > 00000004):
> > > [ 18.930195] Unable to handle kernel NULL pointer dereference at virtual address 00000004
> > > ...
> > > [ 18.972325] [<c0313c98>] (post_crypt) from [<c031408c>] (decrypt_done+0x4c/0x54)
> > > [ 18.972343] [<c031408c>] (decrypt_done) from [<c056309c>] (s5p_aes_interrupt+0x1bc/0x208)
> > > [ 18.972360] [<c056309c>] (s5p_aes_interrupt) from [<c0164930>] (irq_thread_fn+0x1c/0x54)
> > >
> > > Any hints?
> >
> > I haven't found any smoking guns, but the locking between the
> > tasklet and the IRQ routine looks suspect. First of all the
> > tasklet is modifying the dev structure without holding any locks.
>
> I think I see the problem. Could you please try this patch and
> let me know if it fixes the crash?
Yes, fixed! Thanks.
Tested on Odroid XU3 with following script:
https://github.com/krzk/tools/blob/master/tests/s5p-sss-cryptsetup.sh
Tested-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <CALaQ_hoZ6wh-H_NNoT80r6kthvFpL05zNWr7upVqispknXMEvg@mail.gmail.com>]
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
[not found] <CALaQ_hoZ6wh-H_NNoT80r6kthvFpL05zNWr7upVqispknXMEvg@mail.gmail.com>
@ 2017-03-03 4:02 ` Herbert Xu
2017-03-03 9:00 ` Nathan Royce
2017-03-05 17:16 ` Krzysztof Kozlowski
0 siblings, 2 replies; 21+ messages in thread
From: Herbert Xu @ 2017-03-03 4:02 UTC (permalink / raw)
To: Nathan Royce
Cc: davem, linux-crypto, linux-kernel, Krzysztof Kozlowski, Marek Szyprowski
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
> <blank>
> //cbc can be found though
>
> CRYPTTAB:
> cryptswap1 UUID=<sanitized> /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] [<c010eb54>] (unwind_backtrace) from [<c010b408>]
> (show_stack+0x10/0x14)
> [ 10.581893] [<c010b408>] (show_stack) from [<c036772c>]
> (dump_stack+0x84/0x98)
> [ 10.589073] [<c036772c>] (dump_stack) from [<c011bb20>]
> (__warn+0xe8/0x100)
> [ 10.595975] [<c011bb20>] (__warn) from [<c011bc30>]
> (warn_slowpath_null+0x20/0x28)
> [ 10.603546] [<c011bc30>] (warn_slowpath_null) from [<c0329a48>]
> (skcipher_walk_first+0x13c/0x14c)
> [ 10.612390] [<c0329a48>] (skcipher_walk_first) from [<c0329b30>]
> (skcipher_walk_virt+0x1c/0x38)
> [ 10.621056] [<c0329b30>] (skcipher_walk_virt) from [<c0330ed0>]
> (post_crypt+0x38/0x1c4)
> [ 10.629022] [<c0330ed0>] (post_crypt) from [<c0331470>]
> (decrypt_done+0x4c/0x54)
> [ 10.636389] [<c0331470>] (decrypt_done) from [<c05a03f0>]
> (s5p_aes_complete+0x70/0xfc)
> [ 10.644274] [<c05a03f0>] (s5p_aes_complete) from [<c05a05b0>]
> (s5p_aes_interrupt+0x134/0x1a0)
> [ 10.652771] [<c05a05b0>] (s5p_aes_interrupt) from [<c016dc3c>]
> (__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 <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
2017-03-03 4:02 ` Herbert Xu
@ 2017-03-03 9:00 ` Nathan Royce
2017-03-03 9:33 ` Herbert Xu
2017-03-05 17:16 ` Krzysztof Kozlowski
1 sibling, 1 reply; 21+ messages in thread
From: Nathan Royce @ 2017-03-03 9:00 UTC (permalink / raw)
To: Herbert Xu
Cc: davem, linux-crypto, linux-kernel, Krzysztof Kozlowski, Marek Szyprowski
OK, I went ahead and enabled self tests
"CRYPTO_MANAGER_DISABLE_TESTS=n", and my system was able to boot,
albeit with failures:
*****
Mar 02 23:14:38 server kernel: ---[ end trace 1c8a91f28cbcebf3 ]---
Mar 02 23:14:38 server kernel: alg: skcipher: encryption failed on
test 1 for xts(ecb-aes-s5p): ret=35
Mar 02 23:14:38 server kernel: device-mapper: table: 254:0: crypt:
Error allocating crypto tfm
Mar 02 23:14:38 server kernel: device-mapper: ioctl: error adding
target to table
Mar 02 23:14:39 server systemd-cryptsetup[234]: Failed to activate
with key file '/dev/urandom': Invalid argument
*****
(weird that it asked for the passphrase)
But I do question whether the root issue is related to s5p... Maybe
there is a correlation in the warning, but to me it looks like the
issue is something else.
In my OP, I noted that the xts crypto isn't even found in /proc/crypto
in 4.10. I'd think it would at least be listed, even if it isn't used.
CBC is listed in /proc/crypto with kernel 4.9.13 and 4.10.1 (cbc-aes-s5p)
XTS is listed in /proc/crypto with kernel 4.9.13 but NOT 4.10.1
I should also add that I didn't include other tainted messages since
they followed the messages I first posted.
I was assuming that when the first issue would work, the others would
follow suit. I just didn't want to inundate with possible junk.
I still have the log file if you think it would be helpful to post the rest.
PS: I also noticed the bounce from my first mail submission because I
didn't enable plain-text for the e-mail (marked as spam because the
email contained html). I rectified that for this reply.
On Thu, Mar 2, 2017 at 10:02 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> 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
>> <blank>
>> //cbc can be found though
>>
>> CRYPTTAB:
>> cryptswap1 UUID=<sanitized> /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] [<c010eb54>] (unwind_backtrace) from [<c010b408>]
>> (show_stack+0x10/0x14)
>> [ 10.581893] [<c010b408>] (show_stack) from [<c036772c>]
>> (dump_stack+0x84/0x98)
>> [ 10.589073] [<c036772c>] (dump_stack) from [<c011bb20>]
>> (__warn+0xe8/0x100)
>> [ 10.595975] [<c011bb20>] (__warn) from [<c011bc30>]
>> (warn_slowpath_null+0x20/0x28)
>> [ 10.603546] [<c011bc30>] (warn_slowpath_null) from [<c0329a48>]
>> (skcipher_walk_first+0x13c/0x14c)
>> [ 10.612390] [<c0329a48>] (skcipher_walk_first) from [<c0329b30>]
>> (skcipher_walk_virt+0x1c/0x38)
>> [ 10.621056] [<c0329b30>] (skcipher_walk_virt) from [<c0330ed0>]
>> (post_crypt+0x38/0x1c4)
>> [ 10.629022] [<c0330ed0>] (post_crypt) from [<c0331470>]
>> (decrypt_done+0x4c/0x54)
>> [ 10.636389] [<c0331470>] (decrypt_done) from [<c05a03f0>]
>> (s5p_aes_complete+0x70/0xfc)
>> [ 10.644274] [<c05a03f0>] (s5p_aes_complete) from [<c05a05b0>]
>> (s5p_aes_interrupt+0x134/0x1a0)
>> [ 10.652771] [<c05a05b0>] (s5p_aes_interrupt) from [<c016dc3c>]
>> (__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 <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
2017-03-03 9:00 ` Nathan Royce
@ 2017-03-03 9:33 ` Herbert Xu
0 siblings, 0 replies; 21+ messages in thread
From: Herbert Xu @ 2017-03-03 9:33 UTC (permalink / raw)
To: Nathan Royce
Cc: davem, linux-crypto, linux-kernel, Krzysztof Kozlowski, Marek Szyprowski
On Fri, Mar 03, 2017 at 03:00:26AM -0600, Nathan Royce wrote:
> OK, I went ahead and enabled self tests
> "CRYPTO_MANAGER_DISABLE_TESTS=n", and my system was able to boot,
> albeit with failures:
> *****
> Mar 02 23:14:38 server kernel: ---[ end trace 1c8a91f28cbcebf3 ]---
> Mar 02 23:14:38 server kernel: alg: skcipher: encryption failed on
> test 1 for xts(ecb-aes-s5p): ret=35
> Mar 02 23:14:38 server kernel: device-mapper: table: 254:0: crypt:
> Error allocating crypto tfm
> Mar 02 23:14:38 server kernel: device-mapper: ioctl: error adding
> target to table
> Mar 02 23:14:39 server systemd-cryptsetup[234]: Failed to activate
> with key file '/dev/urandom': Invalid argument
> *****
> (weird that it asked for the passphrase)
>
> But I do question whether the root issue is related to s5p... Maybe
> there is a correlation in the warning, but to me it looks like the
> issue is something else.
I see. Do you have ECB enabled in your config? The new XTS requires
ECB to be present so that could be your problem.
There is already a patch on its way to stable to add the Kconfig
select on ECB.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
2017-03-03 4:02 ` Herbert Xu
2017-03-03 9:00 ` Nathan Royce
@ 2017-03-05 17:16 ` Krzysztof Kozlowski
1 sibling, 0 replies; 21+ messages in thread
From: Krzysztof Kozlowski @ 2017-03-05 17:16 UTC (permalink / raw)
To: Herbert Xu
Cc: Nathan Royce, davem, linux-crypto, linux-kernel, Marek Szyprowski
On Fri, Mar 03, 2017 at 12:02:10PM +0800, Herbert Xu wrote:
> 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
> > <blank>
> > //cbc can be found though
> >
> > CRYPTTAB:
> > cryptswap1 UUID=<sanitized> /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] [<c010eb54>] (unwind_backtrace) from [<c010b408>]
> > (show_stack+0x10/0x14)
> > [ 10.581893] [<c010b408>] (show_stack) from [<c036772c>]
> > (dump_stack+0x84/0x98)
> > [ 10.589073] [<c036772c>] (dump_stack) from [<c011bb20>]
> > (__warn+0xe8/0x100)
> > [ 10.595975] [<c011bb20>] (__warn) from [<c011bc30>]
> > (warn_slowpath_null+0x20/0x28)
> > [ 10.603546] [<c011bc30>] (warn_slowpath_null) from [<c0329a48>]
> > (skcipher_walk_first+0x13c/0x14c)
> > [ 10.612390] [<c0329a48>] (skcipher_walk_first) from [<c0329b30>]
> > (skcipher_walk_virt+0x1c/0x38)
> > [ 10.621056] [<c0329b30>] (skcipher_walk_virt) from [<c0330ed0>]
> > (post_crypt+0x38/0x1c4)
> > [ 10.629022] [<c0330ed0>] (post_crypt) from [<c0331470>]
> > (decrypt_done+0x4c/0x54)
> > [ 10.636389] [<c0331470>] (decrypt_done) from [<c05a03f0>]
> > (s5p_aes_complete+0x70/0xfc)
> > [ 10.644274] [<c05a03f0>] (s5p_aes_complete) from [<c05a05b0>]
> > (s5p_aes_interrupt+0x134/0x1a0)
> > [ 10.652771] [<c05a05b0>] (s5p_aes_interrupt) from [<c016dc3c>]
> > (__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.
Tasklet... or threaded IRQ handler maybe? I sent a fix.
BTW, I subscribe the crypto list but I could not find the original email
there.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2017-04-08 12:23 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-03 10:36 XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1 Nathan Royce
2017-03-03 12:04 ` Herbert Xu
2017-03-03 14:08 ` Nathan Royce
-- strict thread matches above, loose matches on Subject: below --
2017-03-06 16:18 Nathan Royce
2017-03-06 17:35 ` Krzysztof Kozlowski
2017-03-06 21:29 ` Nathan Royce
2017-03-08 17:45 ` Krzysztof Kozlowski
2017-03-08 21:15 ` Krzysztof Kozlowski
2017-03-09 11:16 ` Nathan Royce
2017-03-10 18:06 ` Krzysztof Kozlowski
2017-03-10 21:44 ` Nathan Royce
2017-03-12 19:13 ` Krzysztof Kozlowski
2017-03-13 17:06 ` Krzysztof Kozlowski
2017-03-14 9:20 ` Herbert Xu
2017-04-06 9:54 ` Herbert Xu
2017-04-08 2:02 ` Herbert Xu
2017-04-08 12:23 ` Krzysztof Kozlowski
[not found] <CALaQ_hoZ6wh-H_NNoT80r6kthvFpL05zNWr7upVqispknXMEvg@mail.gmail.com>
2017-03-03 4:02 ` Herbert Xu
2017-03-03 9:00 ` Nathan Royce
2017-03-03 9:33 ` Herbert Xu
2017-03-05 17:16 ` Krzysztof Kozlowski
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).