On 21/10/12 13:20, Zdenek Kaspar wrote:
>>> I would say you are still missing some modules.
>>>
>>>> Kernel says this:
>>>> device-mapper: table: 252:1: crypt: Error allocating crypto tfm
>>>> device-mapper: ioctl: error adding target to table
>>>
>>> It complains about aes-cbc-essiv:sha256.
>>>
>>> It can be missing CBC od SHA256, but according the message I bet
>>> you have no "cbc" block cipher mode module compiled.
>>>
>>> Can you grep your final .config for CONFIG_CRYPTO_CBC and
>>> CONFIG_CRYPTO_SHA256 a paste it here?
>>
>> I both working 3.4 and non-working 3.6 situation is the same:
>>
>> CONFIG_CRYPTO_CBC=y
>> CONFIG_CRYPTO_SHA256=m
>
> Compare please:
> grep CONFIG_CRYPTO /boot/config-3.4
> grep CONFIG_CRYPTO /boot/config-3.6
>
> One of the problem could be that your configuration misses something
> like: CONFIG_CRYPTO_BLKCIPHER, CONFIG_CRYPTO_MANAGER, etc.. or some of
> those could changed into modules and are not getting loaded..
Here it is:
--- 3.4 2012-10-21 13:32:27.289602863 +0100
+++ 3.6 2012-10-21 13:32:23.824602841 +0100
@@ -1,3 +1,4 @@
+CONFIG_CRYPTO_ABLK_HELPER_X86=m
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_AES=m
@@ -27,15 +28,14 @@
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_DES=m
-CONFIG_CRYPTO_DEV_PADLOCK_AES=m
-CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
-CONFIG_CRYPTO_DEV_PADLOCK=y
+# CONFIG_CRYPTO_DEV_PADLOCK is not set
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_GCM=m
CONFIG_CRYPTO_GF128MUL=m
CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=m
CONFIG_CRYPTO_GHASH=m
+CONFIG_CRYPTO_GLUE_HELPER_X86=m
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HMAC=y
@@ -64,6 +64,7 @@
CONFIG_CRYPTO_SALSA20_X86_64=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SEQIV=m
+CONFIG_CRYPTO_SERPENT_AVX_X86_64=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_SERPENT_SSE2_X86_64=m
CONFIG_CRYPTO_SHA1=m
@@ -73,6 +74,7 @@
CONFIG_CRYPTO_TEA=m
# CONFIG_CRYPTO_TEST is not set
CONFIG_CRYPTO_TGR192=m
+CONFIG_CRYPTO_TWOFISH_AVX_X86_64=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=m
Tvrtko
On 10/21/2012 02:36 PM, Tvrtko Ursulin wrote:
> On 21/10/12 13:20, Zdenek Kaspar wrote:
>>>> I would say you are still missing some modules.
>>>>
>>>>> Kernel says this:
>>>>> device-mapper: table: 252:1: crypt: Error allocating crypto tfm
>>>>> device-mapper: ioctl: error adding target to table
>>>>
>>>> It complains about aes-cbc-essiv:sha256.
>>>>
>>>> It can be missing CBC od SHA256, but according the message I bet
>>>> you have no "cbc" block cipher mode module compiled.
>>>>
>>>> Can you grep your final .config for CONFIG_CRYPTO_CBC and
>>>> CONFIG_CRYPTO_SHA256 a paste it here?
>>>
>>> I both working 3.4 and non-working 3.6 situation is the same:
>>>
>>> CONFIG_CRYPTO_CBC=y
>>> CONFIG_CRYPTO_SHA256=m
>>
>> Compare please:
>> grep CONFIG_CRYPTO /boot/config-3.4
>> grep CONFIG_CRYPTO /boot/config-3.6
>>
>> One of the problem could be that your configuration misses something
>> like: CONFIG_CRYPTO_BLKCIPHER, CONFIG_CRYPTO_MANAGER, etc.. or some of
>> those could changed into modules and are not getting loaded..
>
> Here it is:
Hm, so it should work without problem. Can you paste full output of failing
cryptsetup command (with added --debug switch) and your full kernel .config?
Cryptsetup itself has regression tests which test almost all common
combinations of ciphers so the problem is almost surely in some kernel
part misconfiguration.
Any other related messages in syslog beside two lines you posted?
Thanks,
Milan
On 21/10/12 20:29, Milan Broz wrote:
> On 10/21/2012 02:36 PM, Tvrtko Ursulin wrote:
>> On 21/10/12 13:20, Zdenek Kaspar wrote:
>>>>> I would say you are still missing some modules.
>>>>>
>>>>>> Kernel says this:
>>>>>> device-mapper: table: 252:1: crypt: Error allocating crypto tfm
>>>>>> device-mapper: ioctl: error adding target to table
>>>>>
>>>>> It complains about aes-cbc-essiv:sha256.
>>>>>
>>>>> It can be missing CBC od SHA256, but according the message I bet
>>>>> you have no "cbc" block cipher mode module compiled.
>>>>>
>>>>> Can you grep your final .config for CONFIG_CRYPTO_CBC and
>>>>> CONFIG_CRYPTO_SHA256 a paste it here?
>>>>
>>>> I both working 3.4 and non-working 3.6 situation is the same:
>>>>
>>>> CONFIG_CRYPTO_CBC=y
>>>> CONFIG_CRYPTO_SHA256=m
>>>
>>> Compare please:
>>> grep CONFIG_CRYPTO /boot/config-3.4
>>> grep CONFIG_CRYPTO /boot/config-3.6
>>>
>>> One of the problem could be that your configuration misses something
>>> like: CONFIG_CRYPTO_BLKCIPHER, CONFIG_CRYPTO_MANAGER, etc.. or some of
>>> those could changed into modules and are not getting loaded..
>>
>> Here it is:
>
> Hm, so it should work without problem. Can you paste full output of failing
> cryptsetup command (with added --debug switch) and your full kernel .config?
Attached.
> Cryptsetup itself has regression tests which test almost all common
> combinations of ciphers so the problem is almost surely in some kernel
> part misconfiguration.
> Any other related messages in syslog beside two lines you posted?
No just those two.
Thanks,
Tvrtko
Hi,
On 21/10/12 21:03, Tvrtko Ursulin wrote:
> On 21/10/12 20:29, Milan Broz wrote:
>> On 10/21/2012 02:36 PM, Tvrtko Ursulin wrote:
>>> On 21/10/12 13:20, Zdenek Kaspar wrote:
>>>>>> I would say you are still missing some modules.
>>>>>>
>>>>>>> Kernel says this:
>>>>>>> device-mapper: table: 252:1: crypt: Error allocating crypto tfm
>>>>>>> device-mapper: ioctl: error adding target to table
>>>>>>
>>>>>> It complains about aes-cbc-essiv:sha256.
>>>>>>
>>>>>> It can be missing CBC od SHA256, but according the message I bet
>>>>>> you have no "cbc" block cipher mode module compiled.
>>>>>>
>>>>>> Can you grep your final .config for CONFIG_CRYPTO_CBC and
>>>>>> CONFIG_CRYPTO_SHA256 a paste it here?
>>>>>
>>>>> I both working 3.4 and non-working 3.6 situation is the same:
>>>>>
>>>>> CONFIG_CRYPTO_CBC=y
>>>>> CONFIG_CRYPTO_SHA256=m
>>>>
>>>> Compare please:
>>>> grep CONFIG_CRYPTO /boot/config-3.4
>>>> grep CONFIG_CRYPTO /boot/config-3.6
>>>>
>>>> One of the problem could be that your configuration misses something
>>>> like: CONFIG_CRYPTO_BLKCIPHER, CONFIG_CRYPTO_MANAGER, etc.. or some of
>>>> those could changed into modules and are not getting loaded..
>>>
>>> Here it is:
>>
>> Hm, so it should work without problem. Can you paste full output of
>> failing
>> cryptsetup command (with added --debug switch) and your full kernel
>> .config?
>
> Attached.
>
>> Cryptsetup itself has regression tests which test almost all common
>> combinations of ciphers so the problem is almost surely in some kernel
>> part misconfiguration.
>> Any other related messages in syslog beside two lines you posted?
>
> No just those two.
Just tried 3.6.4 and it is still broken. Is there anything else I could
try to debug this?
Thanks,
Tvrtko
On 10/29/2012 08:31 PM, Tvrtko Ursulin wrote:
> Just tried 3.6.4 and it is still broken. Is there anything else I could
> try to debug this?
See response from response from Ondra on dmcrypt list - your kernel config
is perhaps broken.
Please use fresh checkout, run make oldconfig and try again.
(Many people use 3.6 already and there is no other report.)
Milan
On 29/10/12 19:47, Milan Broz wrote:
> On 10/29/2012 08:31 PM, Tvrtko Ursulin wrote:
>> Just tried 3.6.4 and it is still broken. Is there anything else I could
>> try to debug this?
>
> See response from response from Ondra on dmcrypt list - your kernel config
> is perhaps broken.
I don't think that reached me - perhaps I was not copied.
Weird yes, I mean no one can spot anything bad with my config...
> Please use fresh checkout, run make oldconfig and try again.
> (Many people use 3.6 already and there is no other report.)
... and I just used it today to configure a fresh 3.6.4 (plus -rt10
patches) without a problem.
Unless RT patchset is the culprit. Hm.. that would be unexpected, but I
guess it is worth a shot. I'll let you know what happens without -rt.
Thanks,
Tvrtko
On 29/10/12 20:14, Tvrtko Ursulin wrote:
> On 29/10/12 19:47, Milan Broz wrote:
>> On 10/29/2012 08:31 PM, Tvrtko Ursulin wrote:
>>> Just tried 3.6.4 and it is still broken. Is there anything else I could
>>> try to debug this?
>>
>> See response from response from Ondra on dmcrypt list - your kernel
>> config
>> is perhaps broken.
>
> I don't think that reached me - perhaps I was not copied.
>
> Weird yes, I mean no one can spot anything bad with my config...
>
>> Please use fresh checkout, run make oldconfig and try again.
>> (Many people use 3.6 already and there is no other report.)
>
> ... and I just used it today to configure a fresh 3.6.4 (plus -rt10
> patches) without a problem.
>
> Unless RT patchset is the culprit. Hm.. that would be unexpected, but I
> guess it is worth a shot. I'll let you know what happens without -rt.
Ha, this is exciting, vanilla 3.6.4 works, with -rt10 patch it does not.
Copying in linux-rt-users.
To recap, 3.6 RT seems to break dm-crypt. Try it like this:
cryptsetup --debug --key-file=- luksOpen /some/luks/formatted/file any-label
And kernel will fail like this:
Kernel says this:
device-mapper: table: 252:1: crypt: Error allocating crypto tfm
device-mapper: ioctl: error adding target to table
I think crypto modules are not getting auto loaded for some reason, but
even if I load them manually before hand and still breaks in the same way.
Maybe someone will have a "ah yes" moment? Here is the diff between
working (vanilla 3.6.4) and non-working (3.6.4-rt10) configs:
--- 1 2012-10-29 20:37:49.472306922 +0000
+++ 2 2012-10-29 20:37:52.319732779 +0000
@@ -892,7 +892,6 @@
# CONFIG_DEBUG_SECTION_MISMATCH is not set
# CONFIG_DEBUG_SET_MODULE_RONX is not set
# CONFIG_DEBUG_SG is not set
-# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
@@ -1810,7 +1809,7 @@
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR=y
# CONFIG_MULTICORE_RAID456 is not set
-CONFIG_MUTEX_SPIN_ON_OWNER=y
+# CONFIG_MUTEX_SPIN_ON_OWNER is not set
# CONFIG_MWAVE is not set
CONFIG_NAMESPACES=y
CONFIG_NATIONAL_PHY=y
@@ -1842,7 +1841,6 @@
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_U32=m
CONFIG_NET_CLS=y
-# CONFIG_NETCONSOLE is not set
CONFIG_NET_CORE=y
CONFIG_NETDEVICES=y
# CONFIG_NET_DSA is not set
@@ -2260,9 +2258,13 @@
CONFIG_PPP=y
# CONFIG_PPS is not set
CONFIG_PREEMPT_COUNT=y
+# CONFIG_PREEMPT__LL is not set
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_PREEMPT_RCU=y
+CONFIG_PREEMPT_RT_BASE=y
+# CONFIG_PREEMPT_RTB is not set
+CONFIG_PREEMPT_RT_FULL=y
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
@@ -2368,11 +2370,10 @@
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_LIB=y
-# CONFIG_RT_GROUP_SCHED is not set
CONFIG_RT_MUTEXES=y
# CONFIG_RT_MUTEX_TESTER is not set
-# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
-CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_RWSEM_GENERIC_SPINLOCK=y
+# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set
# CONFIG_SAMPLES is not set
# CONFIG_SATA_ACARD_AHCI is not set
CONFIG_SATA_AHCI=m
@@ -2851,7 +2852,6 @@
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_TRACE_SINK is not set
CONFIG_TRACING_SUPPORT=y
-# CONFIG_TRANSPARENT_HUGEPAGE is not set
CONFIG_TREE_PREEMPT_RCU=y
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_TUN=y
@@ -2867,7 +2867,6 @@
CONFIG_UID16=y
# CONFIG_UIO is not set
# CONFIG_ULTRIX_PARTITION is not set
-CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX_DIAG=y
# CONFIG_UNIXWARE_DISKLABEL is not set
No crypto related differences.
Tvrtko
On 10/29/2012 09:14 PM, Tvrtko Ursulin wrote:
> Unless RT patchset is the culprit. Hm.. that would be unexpected, but I
> guess it is worth a shot. I'll let you know what happens without -rt.
Yes, try not patched mainline first.
Focus on the crypto api - if the crypto modules are not loading automatically, as you
said in previous mails, something is misconfigured there - it can be even
related to userspace tools (modprobe, udev, ...) check that you have recent versions.
It works for me here after "make oldconfig" with the .config you sent...
Milan
On Mon, 29 Oct 2012, Tvrtko Ursulin wrote:
> On 29/10/12 20:14, Tvrtko Ursulin wrote:
> > Unless RT patchset is the culprit. Hm.. that would be unexpected, but I
> > guess it is worth a shot. I'll let you know what happens without -rt.
>
> Ha, this is exciting, vanilla 3.6.4 works, with -rt10 patch it does not.
>
> Copying in linux-rt-users.
>
> To recap, 3.6 RT seems to break dm-crypt. Try it like this:
>
> cryptsetup --debug --key-file=- luksOpen /some/luks/formatted/file any-label
>
> And kernel will fail like this:
>
> Kernel says this:
> device-mapper: table: 252:1: crypt: Error allocating crypto tfm
> device-mapper: ioctl: error adding target to table
>
> I think crypto modules are not getting auto loaded for some reason, but even
> if I load them manually before hand and still breaks in the same way.
I don't think it's a module problem. That code is not very helpful due
to _NOT_ showing the error number so it's hard to decode what actually
fails.
I put this on my todo list, but TBH it's low on my radar. If you are
interested then try to capture the failure with the function
tracer. Put a tracing_off() call into the failure code path, i.e.:
ret = crypt_alloc_tfms(cc, cipher_api);
if (ret < 0) {
+ tracing_off();
ti->error = "Error allocating crypto tfm";
goto bad;
}
Enable the function tracer before doing the cryptsetup invocation and
after that read out the trace, compress it and put it somewhere to
download or send it to me in private mail if you don't have a place to
put it.
I can decode the trace, but I don't have the capacity at the moment to
setup all the necessary stuff here and do the debugging myself.
Thanks,
tglx
On Mon, Oct 29, 2012 at 08:45:38PM +0000, Tvrtko Ursulin wrote:
> On 29/10/12 20:14, Tvrtko Ursulin wrote:
> >On 29/10/12 19:47, Milan Broz wrote:
> >>On 10/29/2012 08:31 PM, Tvrtko Ursulin wrote:
> >>>Just tried 3.6.4 and it is still broken. Is there anything else I could
> >>>try to debug this?
> >>
> >>See response from response from Ondra on dmcrypt list - your kernel
> >>config
> >>is perhaps broken.
> >
> >I don't think that reached me - perhaps I was not copied.
> >
> >Weird yes, I mean no one can spot anything bad with my config...
> >
> >>Please use fresh checkout, run make oldconfig and try again.
> >>(Many people use 3.6 already and there is no other report.)
> >
> >... and I just used it today to configure a fresh 3.6.4 (plus -rt10
> >patches) without a problem.
> >
> >Unless RT patchset is the culprit. Hm.. that would be unexpected, but I
> >guess it is worth a shot. I'll let you know what happens without -rt.
>
> Ha, this is exciting, vanilla 3.6.4 works, with -rt10 patch it does not.
I experienced that problem, too. This is on a laptop with encrypted
rootfs, so debugging is a bit harder here. I am just setting up another
machine to debug that.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
On 10/30/2012 10:40 AM, Uwe Kleine-K?nig wrote:
>> Ha, this is exciting, vanilla 3.6.4 works, with -rt10 patch it does not.
> I experienced that problem, too. This is on a laptop with encrypted
> rootfs, so debugging is a bit harder here. I am just setting up another
> machine to debug that.
FYI the problematic patch is peterz-srcu-crypto-chain.patch in rt10
patchset, after that, crypto_alloc_ablkcipher() now returns -ENOENT (-2)
in dmcrypt.
(I will check it later but maybe someone already playing with it...)
Milan
Fix crypto api for 3.6.4-rt10 (broken only in realtime patchset)
In peterz-srcu-crypto-chain.patch the blocking notifier is changed
to srcu notifier and added initialization to module init fucntion.
Later, in crypto-make-core-static-and-init-scru-early.patch, is that
initialization added also to core_initcall().
This patch removes crypto_chain init from algapi initialization,
because this function is called later and already initialized
cryptomgr notifier is lost.
This cause a failure in initialization of larval algorithms,
like e.g. cbc(aes).
Signed-off-by: Milan Broz <[email protected]>
--- crypto/algapi.c.old 2012-10-30 16:11:23.000000000 +0100
+++ crypto/algapi.c 2012-10-30 16:12:14.988847944 +0100
@@ -956,7 +956,6 @@ EXPORT_SYMBOL_GPL(crypto_xor);
static int __init crypto_algapi_init(void)
{
- srcu_init_notifier_head(&crypto_chain);
crypto_init_proc();
return 0;
}
On Tue, 30 Oct 2012, Milan Broz wrote:
> Fix crypto api for 3.6.4-rt10 (broken only in realtime patchset)
>
> In peterz-srcu-crypto-chain.patch the blocking notifier is changed
> to srcu notifier and added initialization to module init fucntion.
>
> Later, in crypto-make-core-static-and-init-scru-early.patch, is that
> initialization added also to core_initcall().
>
> This patch removes crypto_chain init from algapi initialization,
> because this function is called later and already initialized
> cryptomgr notifier is lost.
Grrr. So I forgot top zap the one Peter added. Stupid me.
> This cause a failure in initialization of larval algorithms,
> like e.g. cbc(aes).
Thanks for spotting!
> Signed-off-by: Milan Broz <[email protected]>
>
> --- crypto/algapi.c.old 2012-10-30 16:11:23.000000000 +0100
> +++ crypto/algapi.c 2012-10-30 16:12:14.988847944 +0100
> @@ -956,7 +956,6 @@ EXPORT_SYMBOL_GPL(crypto_xor);
>
> static int __init crypto_algapi_init(void)
> {
> - srcu_init_notifier_head(&crypto_chain);
> crypto_init_proc();
> return 0;
> }
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Hi,
On 30/10/12 15:27, Milan Broz wrote:
> Fix crypto api for 3.6.4-rt10 (broken only in realtime patchset)
>
> In peterz-srcu-crypto-chain.patch the blocking notifier is changed
> to srcu notifier and added initialization to module init fucntion.
>
> Later, in crypto-make-core-static-and-init-scru-early.patch, is that
> initialization added also to core_initcall().
>
> This patch removes crypto_chain init from algapi initialization,
> because this function is called later and already initialized
> cryptomgr notifier is lost.
>
> This cause a failure in initialization of larval algorithms,
> like e.g. cbc(aes).
Thanks for the quick fix!
Tvrtko
Hello,
On Tue, Oct 30, 2012 at 06:57:37PM +0100, Thomas Gleixner wrote:
> On Tue, 30 Oct 2012, Milan Broz wrote:
>
> > Fix crypto api for 3.6.4-rt10 (broken only in realtime patchset)
> >
> > In peterz-srcu-crypto-chain.patch the blocking notifier is changed
> > to srcu notifier and added initialization to module init fucntion.
> >
> > Later, in crypto-make-core-static-and-init-scru-early.patch, is that
> > initialization added also to core_initcall().
> >
> > This patch removes crypto_chain init from algapi initialization,
> > because this function is called later and already initialized
> > cryptomgr notifier is lost.
>
> Grrr. So I forgot top zap the one Peter added. Stupid me.
>
> > This cause a failure in initialization of larval algorithms,
> > like e.g. cbc(aes).
>
> Thanks for spotting!
This patch fixes booting my laptop. But now it hangs after login.
thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |