VFS issue with hardware-encrypted usb devices

[Guillaume Rousse <guillomovitch@gmail.com>]

(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\a18, idProduct\x0682
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