Re: [PATCH] usb: gadget: f_mass_storage: break IO operations via configfs

[Alan Stern <stern@rowland.harvard.edu>]

On Wed, Apr 06, 2022 at 07:52:34PM +0300, Maxim Devaev wrote:
> > It's not clear to me how breaking I/O operations allows you to do a 
> > "force eject".  It seems that what you would need is something like 
> > fsg_store_file() that omits the curlun->prevent_medium_removal check.
> > Interrupting a lengthy I/O operation doesn't really have anything to do 
> > with this.
> 
> Perhaps I chose the wrong path, it's just how my userspace code works now.
> If the drive is connected to a Linux host, then in order to clear
> the "file" and extract the image, I sent a SIGUSR1 signal to the "file-storage"
> thread. This interrupted long IO operations, reset curlun->prevent_medium_removal
> and I got the ability to extract.

Oh, I see.  That's kind of an unintended side effect of not calling 
raise_exception().

And while it does interrupt long I/O operations, it does so in 
non-sanctioned way.  To the host it will appear as though the gadget's 
firmware has crashed, since the gadget will stop sending or receiving 
data.  Eventually the host will time out and reset the gadget.

Maybe that's the sort of thing you want, but I rather doubt it.

> It was done in our KVM-over-IP project and worked for several years,
> just now I want to do it without searching for procfs and the need
> to use sudo helpers like this:
> https://github.com/pikvm/kvmd/blob/1b3a2cc/kvmd/helpers/otgmsd/unlock/__init__.py
> 
> Maybe it's worth introducing some option that will allow us to ignore
> curlun->prevent_medium_removal and perform a forced extraction?
> Something like "allow_force_eject" on the same lavel with "stall".

Or have a separate sysfs file where any write at all will be interpreted 
as a forced eject.  Either way would work.

> Will masking the curlun->prevent_medium_removal flag be enough?

I think so.  But it will be blocked to some extent by long-running I/O 
operations, because those operations acquire the filesem rw-semaphore 
for reading.

More precisely, each individual command holds the rw-semaphore.  But the 
semaphore is dropped between commands, and a long-running I/O operation 
typically consists of many separate commands.  So the blocking may be 
acceptable.

> > Or to keep this ability restricted to the superuser, if that is desired.
> 
> Indeed.
> 
> > You should not call send_sig_info() directly; instead call 
> > raise_exception().  It already does the work you need (including some 
> > things you left out).
> 
> raise_exception() assumes the setting of a new state, and I did not want to do this,
> since the same does not happen when throwing a signal from userspace.

Userspace isn't supposed to send the USR1 signal, only the INT, TERM, or 
KILL signals.  USR1 is supposed to be reserved for the driver's internal 
use.  Unfortunately, AFAIK there's no way to allow the driver to send a 
signal to itself without also allowing the signal to be sent by 
userspace.  :-(

And sending the signal _does_ set a new state, whether you intended to 
or not.  Although in this case, the new state is always the same as the 
old state, i.e., FSG_STATE_NORMAL.

Alan Stern