public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
* Behavior for hot-plugging SD card in USB SD card reader
@ 2016-05-12 14:02 Frkuska, Joshua
  2016-06-08  5:24 ` Frkuska, Joshua
  0 siblings, 1 reply; 2+ messages in thread
From: Frkuska, Joshua @ 2016-05-12 14:02 UTC (permalink / raw)
  To: linux-scsi

Hello,

I have two questions regarding the behavior for hot-plugging SD card in 
USB SD card reader relating to the scsi sub system.

Before the questions, the background and my understanding:

On the 3.14.y branch and later (not sure about 4.2+), when using a USB 
SD card reader with sd card inserted and filesystem mounted, there are 4 
possible cases for physical removal of the sd card. The first is when 
the card (not usb reader) is removed and the scsi device is not busy 
(being accessed). The second is with the sd card busy (being accessed) 
and then the sd card is removed. The 3rd and 4th are the similar but 
with the usb reader itself being removed with the sd card inserted. This 
mail focuses on the behavior of the second case where the sd card is 
busy and then removed.

If my understanding is correct, in the scenario above, access of the 
scsi disk block device keeps the reference count positive. This is 
followed by the removal of the sd card which in the non-busy case would 
make the reference count zero and allow the disk partitions to be 
unmounted. However in the busy case any new sd card inserted into the 
card reader should recalculate the geometry and allow the disk 
partitions to be discovered and be auto-mounted. However, it seems that 
the scsi disk reference count does not go to zero and we are unable to 
unmount the partition. A lazy unmount appears to occur leaving a stale 
device node. Similar behavior can be seen on inserting a USB flash based 
storage device and executing the same problem case. In the case of a USB 
flash drive, after hotplug and re-insertion, a new block device node 
gets assigned as the previous one is still busy. In the case of the SD 
card, a new block device node does not get created.

A simple recreation case is to use 'tail -f' on any file on the 
auto-mounted sd card file system, then remove the SD card and then 
insert a second different SD card. The second SD card does not 
auto-mount as one would first think. The device is not listed in MP 
shadow fblock nor mounted at all.

In the case of the USB flash drive, the host adapter is created, scsi 
bus scanned, finding the scsi device controller on the bus. The device 
controller responds to the scan and the scsi disk is populated with 
appropriate geometry sizes. This is provided to the block layer, then to 
the vfs which the auto-mounter picks up on and mounts the partitions. In 
the case of the USB SD card reader, when the card reader is plugged in 
without SD card populated, the scsi device controller is still found, 
root scsi disk node still created, but its geometry is 0 and the device 
is put in a NO_MEDIUM_INSERTED state. Any open attempts on the device 
node will fail with a NOMEDIUM error. Insertion of an SD card changes 
the reported geometry of the SCSI disk during a periodic scan, the 
NOMEDIUM state removed and disk information updated. As far as kernel 
events go, a 'change' and 'add' events are provided to up to userland.

When a USB flash drive is busy (being accessed) when hotplugged 
(removed), the partition remains mounted and root and subsequent 
re-insertion creates a new root scsi device node in sequential 
alphabetical order (e.g. /dev/sdb). The reason re-population of the scsi 
disk works in the USB case is due to the entire virtual host being 
destroyed and repopulated. This repopulates the parent device node after 
the device controller is scanned and found on the virtual scsi bus. In 
the case of the sd card, removal of the SD card only changes the medium 
inserted state and does not result in a scsi disk root node re-population.

I have two questions.

1. In the case of a USB card reader sd card being hotplugged while busy, 
is the current behavior desired? If so, why? An embedded system where 
the sd card reader is physically locked/mounted to the usb hub could see 
such a scenario if the sd card is being accessed during removal from the 
user. Such a usecase is possible on PC as well.
2. If this behavior should be more similar to a USB flash drive during 
hotplug what layer modifications would be necessary? (mass storage 
driver, scsi disk, scsi layer, block, etc)

I have a few ideas how this could be done but I would appreciate any 
additional thoughts or feedback regarding creating similar behavior to a 
usb hotplug.

The current thoughts I have are:

a.) change the behavior of the scsi disk layer in the case when the 
media is ejected with its user count not equal zero. The idea is to 
force drop (up and down the layer stack) the existing references to the 
disk so that it can be properly cleaned up and removed. This is a little 
different than the usb case above as the scsi device node will be re-used.
b.) Use a notifier chain to notify the usb mass storage driver to reset 
and re-instantiate the virtual host adapter. This would be the 
equivalent to what usb is doing at hotplug.
c.) let userspace handle the change events and handle it accordingly. (a 
number of ways, re-enumerate the hub, terminate offending apps using 
node and force unmount, etc.)

Thank you in advance


^ permalink raw reply	[flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-06-08  5:24 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-05-12 14:02 Behavior for hot-plugging SD card in USB SD card reader Frkuska, Joshua
2016-06-08  5:24 ` Frkuska, Joshua

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox