From: Maxim Devaev <mdevaev@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb@vger.kernel.org, Felipe Balbi <balbi@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Cai Huoqing <caihuoqing@baidu.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: gadget: f_mass_storage: break IO operations via configfs
Date: Wed, 6 Apr 2022 19:52:34 +0300 [thread overview]
Message-ID: <20220406195234.4f63cb4a@reki> (raw)
In-Reply-To: <Yk2wvhSTMKTLFK6c@rowland.harvard.edu>
> 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.
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".
Will masking the curlun->prevent_medium_removal flag be enough?
> 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.
next prev parent reply other threads:[~2022-04-06 18:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-06 9:24 [PATCH] usb: gadget: f_mass_storage: break IO operations via configfs Maxim Devaev
2022-04-06 15:24 ` Alan Stern
2022-04-06 16:52 ` Maxim Devaev [this message]
2022-04-06 17:51 ` Alan Stern
2022-04-06 18:36 ` Maxim Devaev
2022-04-07 16:06 ` Alan Stern
2022-04-07 17:47 ` Maxim Devaev
2022-04-08 14:59 ` Alan Stern
2022-04-09 8:57 ` Maxim Devaev
2022-04-09 13:46 ` Alan Stern
2022-04-09 14:08 ` Maxim Devaev
2022-04-09 20:22 ` Alan Stern
2022-04-09 22:42 ` Maxim Devaev
2022-04-10 1:57 ` Alan Stern
2022-04-10 2:18 ` Maxim Devaev
2022-04-10 15:21 ` Alan Stern
2022-04-10 16:14 ` Maxim Devaev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220406195234.4f63cb4a@reki \
--to=mdevaev@gmail.com \
--cc=balbi@kernel.org \
--cc=caihuoqing@baidu.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox