Re: cryptsetup not working under 3.6 - RT patch set seem to break it

Re: cryptsetup not working under 3.6 - RT patch set seem to break it

[Tvrtko Ursulin]

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




_______________________________________________
dm-crypt mailing list
dm-crypt-4q3lyFh4P1g@public.gmane.org
http://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] cryptsetup not working under 3.6 - RT patch set seem to break it

[Thomas Gleixner]

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

Re: [dm-crypt] cryptsetup not working under 3.6 - RT patch set seem to break it

[Uwe Kleine-König]

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/  |

Re: [dm-crypt] cryptsetup not working under 3.6 - RT patch set seem to break it

[Milan Broz]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Fix crypto api init for 3.6.4-rt10

[Milan Broz]

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 <mbroz@redhat.com>

--- 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;
 }

Re: [PATCH] Fix crypto api init for 3.6.4-rt10

[Thomas Gleixner]

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 <mbroz@redhat.com>
> 
> --- 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH] Fix crypto api init for 3.6.4-rt10

[Uwe Kleine-König]

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/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Fix crypto api init for 3.6.4-rt10

[Tvrtko Ursulin]

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