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: <Pine.LNX.4.44L0.1004231129530.1777-100000@iolanthe.rowland.org>
Date:	Fri, 23 Apr 2010 11:36:46 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Chouteau Fabien <fabien.chouteau@...il.com>
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, 23 Apr 2010, Chouteau Fabien wrote:

> > > + * 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.

No; it's clear enough and I understood what you meant.  It's true that 
they are two different events, but they have the same end result.

> 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.

Why not?  Isn't it possible that the user put some files there before 
the device-side eject happened?

What happens if the user and the device both try to eject the medium at
approximately the same time?  Which event occurs first will be purely
random chance.  That means there's a 50% probability you will end up
doing the wrong thing.

No, I think you need to do the same thing whenever an eject occurs, or
else find a better criterion for deciding what to do.

Alan Stern

--
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/