linux-kernel - Re: [PATCH RESEND 2/2] Mass storage gadget: Handle eject request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <g2lfb5cec441004230805m8fc1251ekeb936837349b6e16@mail.gmail.com>
Date:	Fri, 23 Apr 2010 17:05:49 +0200
From:	Chouteau Fabien <fabien.chouteau@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	linux-usb@...r.kernel.org,
	David Brownell <dbrownell@...rs.sourceforge.net>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Michal Nazarewicz <m.nazarewicz@...sung.com>,
	Peter Korsgaard <jacmet@...site.dk>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND 2/2] Mass storage gadget: Handle eject request

On Fri, Apr 23, 2010 at 4:23 PM, Alan Stern <stern@...land.harvard.edu> wrote:
>
> On Fri, 23 Apr 2010 fabien.chouteau@...il.com wrote:
>
> > From: Fabien Chouteau <fabien.chouteau@...co.com>
> >
> > This patch adds handling of the "Start/Stop Unit" SCSI request to simulate media
> > ejection. A sysfs entry to get the "eject" state of a LUN is also added.
>
> Sorry I didn't notice this earlier...
>
> > --- a/drivers/usb/gadget/f_mass_storage.c
> > +++ b/drivers/usb/gadget/f_mass_storage.c
> > @@ -163,6 +163,13 @@
> >   * ro setting are not allowed when the medium is loaded or if CD-ROM
> >   * emulation is being used.
> >   *
> > + * When a LUN receive an "eject" SCSI request (Start/Stop Unit),
> > + * if the LUN is removable, the backing file is released to simulate
> > + * ejection.
> > + * The "eject" state of a LUN is available in the "ejected" file of the
> > + * LUN's sysfs directory (see above). The "eject" state is only updated
> > + * by SCSI request, not by user ejection.
>
> What's the reason for that?  With a real removable device, like a CD
> player, it doesn't make any difference whether the medium was ejected
> because of a SCSI command or because I pressed the "eject" button.
>
> I just don't see any point in keeping track of the two actions
> separately, since they end up having the same final result.
>

By user ejection, I mean send an empty line in the "file" sysfs entry.
The Start/Stop request is an action from the USB host side, user
ejection is from the USB device side, for me it's two different
events.
Maybe my comment is not clear about this point.

I use a FAT disk image as LUN file, users can put some files in the
"fake" disk and then eject it. When I get the ejected signal, I mount
the disk image on loop device and perform operations on the user's
files.
So I want to know when users eject the disk and only when users do.

I still can use the LUN ejection from device side to disable the mass
storage device, and in this case I don't want to mount the disk and
search for user's files.

--
Fabien Chouteau
EPITA GISTR 2010
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/