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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.