Hi, > -----Original Message----- > From: Simon Baatz [mailto:gmbnomis@xxxxxxxxx] > Sent: Sunday, May 06, 2012 00:50 > To: Frank; 'Sebastian Andrzej Siewior'; uri@xxxxxxxxxxxx; linux- > crypto@xxxxxxxxxxxxxxx; Herbert Xu; Catalin Marinas; linux-arm- > kernel@xxxxxxxxxxxxxxxxxxxxxx > Subject: mv_cesa dcache problem since 2.6.37 was: Re: mv_cesa hash > functions > > Hi, > > Am 23.02.2012 19:34, schrieb Phil Sutter: > > But you might suffer from another problem, which is only present on > > ARM machines with VIVT cache and linux >= 2.6.37: due to commit > > f8b63c1, "ARM: 6382/1: Remove superfluous flush_kernel_dcache_page()" > > which prevents pages being flushed from inside the scatterlist > > iterator API. This patch seems to introduce problems in other places > > (namely NFS), too but I sadly did not have time to investigate this > > further. I will post a possible (cryptodev-internal) solution to > > cryptodev-linux-devel@xxxxxxx, maybe this fixes the problem with > > openssl. Greetings, Phil > > since there has been no reaction on this, I would like to bring this > issue up again (I sadly don't have the expertise to investigate this > further...). The issue is not limited to cryptodev, but seems to be > either a problem with commit f8b63c1 or a problem in mv_cesa that was > uncovered by this commit. In the past, I also had massive problems > compiling on an NFS mounted file system when not reverting f8b63c1. I > currently can't reproduce this anymore under 3.4-rc5. > > However, the following still happens on a 3.4-rc5 preempt kernel on arm > kirkwood (VIVT cache): > > root@ww1:~# cryptsetup luksOpen /dev/sda2 c_sda2 > Enter passphrase for /dev/sda2: > root@ww1:~# vgchange -a y ww1_1 > Volume group "ww1_1" not found > root@ww1:~# vgchange -a y ww1_1 > Segmentation fault > > > Thus, the behavior of vgchange is unpredictable on a dm-crypt device > when using mv_cesa (btw. the machine needs to have no load to show this > behavior. I assume that the cache flushes caused by task switches make > it work under load). > > Using the generic crypto modules, it works as expected: > > root@ww1:~# cryptsetup luksClose c_sda2 > root@ww1:~# rmmod mv_cesa > root@ww1:~# cryptsetup luksOpen /dev/sda2 c_sda2 > Enter passphrase for /dev/sda2: > root@ww1:~# vgchange -a y ww1_1 > 1 logical volume(s) in volume group "ww1_1" now active > > > After reverting f8b63c1, it works as expected using mv_cesa as well. > > > - Simon I'm not sure if this is related, but I do see a kernel oops (on kernel 3.2.15) when using mv_cesa in the situation where clients connect to a L2TP/IPSEC VPN and use eap-tls authentication for the ppp link: [ 495.526702] Unable to handle kernel paging request at virtual address 03205d58 [ 495.533964] pgd = c0004000 [ 495.536697] [03205d58] *pgd=00000000 [ 495.540298] Internal error: Oops: 5 [#1] [ 495.544236] Modules linked in: mv_cesa ppp_async crc_ccitt ppp_generic slhc authenc xfrm4_mode_transport tcm_loop tcm_fc libfc scsi_transport_fc scsi_tgt iscsi_target_mod target_core_pscsi target_core_file target_core_iblock target_core_mod configfs xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 ctr twofish_generic twofish_common camellia serpent blowfish_generic blowfish_common cast5 des_generic cbc aes_generic xcbc rmd160 sha512_generic sha256_generic sha1_generic hmac crypto_null af_key ipv6 ext3 jbd ext2 loop evdev snd_usb_audio snd_usbmidi_lib snd_hwdep snd_seq_midi snd_seq_midi_event snd_rawmidi snd_pcm snd_page_alloc snd_seq snd_seq_device snd_timer snd soundcore gpio_keys ext4 jbd2 mbcache sd_mod crc_t10dif usb_storage uas sata_mv libata ehci_hcd scsi_mod usbcore usb_common mv643xx_eth inet_lro libphy [last unloaded: l2tp_core] [ 495.620303] CPU: 0 Not tainted (3.2.0-2-kirkwood #1) [ 495.625645] PC is at memcpy+0x94/0x3a4 [ 495.629415] LR is at copy_src_to_buf+0x68/0x94 [mv_cesa] [ 495.634754] pc : [<c01929d4>] lr : [<bf530c3c>] psr: 20000013 [ 495.634759] sp : de989f24 ip : 00000008 fp : de988000 [ 495.646295] r10: 00000608 r9 : de5cd868 r8 : 00000000 [ 495.651545] r7 : e0e6e648 r6 : 00000040 r5 : 00000040 r4 : c01929cc [ 495.658104] r3 : 00000018 r2 : 00000008 r1 : 03205d58 r0 : e0e6e648 [ 495.664661] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 495.672003] Control: 0005397f Table: 1e564000 DAC: 00000017 [ 495.677775] Process mv_crypto (pid: 2484, stack limit = 0xde988270) [ 495.684071] Stack: (0xde989f24 to 0xde98a000) [ 495.688454] 9f20: 00000040 00000040 e0e6e648 00000000 e0e6e648 ded7e1ac bf530c3c [ 495.696668] 9f40: 00000080 ded7e180 00000608 ded7e180 ded7e100 bf530ca8 06080080 de5cd8e8 [ 495.704882] 9f60: 00000001 bf530e3c 00000070 00000000 00000000 00000000 00000000 06080080 [ 495.713097] 9f80: 00000000 00000000 00000004 de5cd8e8 bf531f38 ded7e180 ded7e1ac bf5312e0 [ 495.721312] 9fa0: ded7e180 ded7e1ac de989f30 ddccbdf0 ded7e180 bf530f70 00000013 00000000 [ 495.729533] 9fc0: 00000000 00000000 00000000 c003dc68 00000000 00000000 ded7e180 00000000 [ 495.737748] 9fe0: de989fe0 de989fe0 ddccbdf0 c003dbec c000edf8 c000edf8 00000000 00000000 [ 495.745964] Code: 108ff00c ea000012 e1a00000 e4913004 (e4914004) [ 495.752389] ---[ end trace 0054294d538730e7 ]--- Here's the patch for Debian Squeeze/Wheezy to allow ppp authentication against a RADIUS server in ppp: http://debian-nas.org/files/ppp-2.4.5-heiart-radius-eaptls-debian.patch Here are instructions on how to set it up: http://debian-nas.org/files/ppp-radius-eaptls-debian-howto.txt I haven't tested (yet) if reverting f8b63c1 fixes this issue for me. Regards, Frank -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
