(This is a repost of a message I originally sent to lkml, which seems a better fit there). Hello. I'm currently playing with hardware-encrypted Imation defender USB devices, which are USB keys/drives, using password and/or fingerprint sensors for unlocking content: http://www.imation.com/en-us/Imation-Products/ The main issue is that they are automatically mounted under gnome (and I guess all other modern desktop) before being unlocked, and the VFS doesn't likes the behind-the-scene changes very much. Here the syslog trace when plugging (the normal partition is seen as a CD-ROM, the encrypted one as a standard removal drive): Jan 3 15:14:07 beria kernel: : usb 2-1: new high speed USB device using ehci_hcd and address 8 Jan 3 15:14:08 beria kernel: : usb 2-1: New USB device found, idVendor=0718, idProduct=0682 Jan 3 15:14:08 beria kernel: : usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jan 3 15:14:08 beria kernel: : usb 2-1: Product: Defender F200 Jan 3 15:14:08 beria kernel: : usb 2-1: Manufacturer: Imation Jan 3 15:14:08 beria kernel: : usb 2-1: SerialNumber: F5121031F003008E Jan 3 15:14:08 beria kernel: : scsi10 : usb-storage 2-1:1.0 Jan 3 15:14:09 beria kernel: : scsi 10:0:0:0: CD-ROM Defender F200 Application 0001 PQ: 0 ANSI: 2 Jan 3 15:14:09 beria kernel: : sr0: scsi-1 drive Jan 3 15:14:09 beria kernel: : sr 10:0:0:0: Attached scsi generic sg1 type 5 Jan 3 15:14:09 beria kernel: : scsi 10:0:0:1: Direct-Access Defender F200 Private 0001 PQ: 0 ANSI: 2 Jan 3 15:14:09 beria kernel: : sd 10:0:0:1: Attached scsi generic sg2 type 0 Jan 3 15:14:09 beria kernel: : sd 10:0:0:1: [sdb] 18434 512-byte logical blocks: (9.43 MB/9.00 MiB) Jan 3 15:14:09 beria kernel: : sd 10:0:0:1: [sdb] Write Protect is off Jan 3 15:14:09 beria kernel: : sd 10:0:0:1: [sdb] Assuming drive cache: write through Jan 3 15:14:09 beria kernel: : sd 10:0:0:1: [sdb] Assuming drive cache: write through Jan 3 15:14:09 beria kernel: : sdb: Jan 3 15:14:09 beria kernel: : sd 10:0:0:1: [sdb] Assuming drive cache: write through Jan 3 15:14:09 beria kernel: : sd 10:0:0:1: [sdb] Attached SCSI removable disk Then unlocking is performed, by sweeping fingerprint sensor, and the hardware change, triggering issues: Jan 3 15:14:21 beria kernel: : VFS: busy inodes on changed media or resized disk sdb Jan 3 15:14:21 beria kernel: : sd 10:0:0:1: [sdb] 3393536 512-byte logical blocks: (1.73 GB/1.61 GiB) Jan 3 15:14:21 beria kernel: : sd 10:0:0:1: [sdb] Assuming drive cache: write through Jan 3 15:14:40 beria kernel: : FAT: Filesystem error (dev sdb) Jan 3 15:14:40 beria kernel: : fat_get_cluster: invalid cluster chain (i_pos 262) Jan 3 15:14:40 beria kernel: : FAT: Filesystem has been set read-only Jan 3 15:14:40 beria kernel: : FAT: Filesystem error (dev sdb) If I'm quick enough at jumping on sensor to unlock at mount time, everything works fine, meaning the real issue is changing partition status when already mounted. I don't know how this issue should be properly handled. Should the VFS be aware than some kind of exotic hardware are able to perform this kind of tricks ? Should the automounter be able to manage those kind of device by not mouting them automatically, at least until they reach proper state ? -- BOFH excuse #31: cellular telephone interference -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
