Juergen Keil wrote: > 2009/3/10 Dina <dina.nimeh at sun.com>: >> usr/src/uts/common/io/lofi.c > ... >> line 2236 and following (new file numbering): >> Does anything need to be done about -f(orce) option to lofi? >> I left a note there for the next person, but wouldn't expect >> anything other than a call to lofi_free_comp_cache() for the >> time being. > > > Hmm, ... > > Why exactly do you have to call lofi_free_crypto() during > the forced lofi unmap? I'd expect that the crypto state is freed > via lofi_close() -> lofi_free_handle() -> lofi_free_crypto() when > the last reference to the lofi device is closed... >
To erase the crypto key. The crypto key comes into existence during lofi_map_file, and should go out of existence during lofi_unmap_file. Whether the lofi was unmapped nicely or forcibly, the key should be cleared so it doesn't hang around any longer than it needs to. The problem you found was the crypto mutex was already destroyed in the lofi_unmap_file, and then tried to be destroyed again in the lofi_close. I think the lofi_free_crypto should stay where it is, but the mutex destroy for crypto_lock needs to move out of lofi_free_crypto and into lofi_free_handle. I think ... I need to take a closer look Thanks! D. > > I just tried to run the following shell script: > > ================================= > #!/bin/sh > > set -ex > > lofi=/dev/lofi/99 > rlofi=`echo $lofi|sed s=lofi=rlofi=` > file=/tmp/floppy_crypt.img > size=1440k > crypt_alg=blowfish-cbc > mntpnt=/mnt > > mkfile -n $size $file > lofiadm -c $crypt_alg -a $file $lofi > newfs $rlofi > mount $lofi $mntpnt > cp /etc/passwd $mntpnt > umount $mntpnt > lofiadm -d $lofi > > sync > > lofiadm -c blowfish-cbc -a $file $lofi > mount $lofi $mntpnt > lofiadm -f -d $lofi > umount $mntpnt > =================================== > > > It panics during the last umount, when the last reference to the > encrypted file is released, after the forced unmap: > >> ::status > debugging crash dump vmcore.1 (64-bit) from rosa > operating system: 5.11 snv_111_jk (i86pc) > panic message: > mutex_destroy: bad mutex, lp=ffffff014c0c26c0 owner=ffffff014b9ad080 > thread=ffffff014b9bc1e0 > dump content: kernel pages only >> ::stack > vpanic() > mutex_panic+0x73(fffffffffb92b450, ffffff014c0c26c0) > mutex_destroy+0x127(ffffff014c0c26c0) > lofi_free_crypto+0xda(ffffff014c0c2000) > lofi_free_handle+0x36(9000000063, 63, ffffff014c0c2000, ffffff0153b627a0) > lofi_close+0x93(9000000063, 1, 0, ffffff0153b627a0) > dev_close+0x3d(9000000063, 1, 0, ffffff0153b627a0) > device_close+0x6d(ffffff01548d1080, 1, ffffff0153b627a0) > spec_close+0x163(ffffff01548d1080, 1, 1, 0, ffffff0153b627a0, 0) > fop_close+0x71(ffffff01548d1080, 1, 1, 0, ffffff0153b627a0, 0) > ufs_unmount+0x78d(ffffff0153930768, 0, ffffff0153b627a0) > fsop_unmount+0x22(ffffff0153930768, 0, ffffff0153b627a0) > dounmount+0x5f(ffffff0153930768, 0, ffffff0153b627a0) > umount2_engine+0x5c(ffffff0153930768, 0, ffffff0153b627a0, 1) > umount2+0x142(8066cf0, 0) > _sys_sysenter_post_swapgs+0x14b() > > > I guess the lofi_free_crypto() call should be *removed* at lines > 2236 and following; and the decompress caching changes > don't have to add anything at this place.
