Re: How to fix CDROM/DVD eject mess?

[Kay Sievers]

On Mon, Feb 2, 2015 at 2:20 PM, Takashi Iwai <tiwai@xxxxxxx> wrote:
> we've got a bug report about the mishandling of DVD/CDROM media eject
> button, and it seems indeed broken since some time ago.  In short:
> when the eject button is pressed, the media is forcibly ejected no
> matter whether it's mounted or in use.

Which is the right thing to do for all read-only stuff.

> And, the mount remains even
> after ejecting the media, eventually the kernel spews error messages
> when the further access happens.

This cosmetic issue should be "fixed" if it matters.

> There seem many problems behind the scene.  First of all, udev tries
> to lock the media unconditionally at the media insert.  This seems to
> be a workaround for making DISK_EVENT_EJECT_REQUEST working.

It is no workaround, it's the SCSI spec. You only see events if you
lock the door.

> Then,
> udev unlocks the media and issues the SCSI eject ioctl unconditionally
> when DISK_EVENT_EJECT_REQUEST event is received.  Since SCSI ioctl
> doesn't take the open refcount into account, it results in the
> forcible eject.

Which again is the expected behavior in the user's view.

> (A relevant problem is that CDROM_IOCTL doesn't behave consistently;
>  it checks the open refcount only for IDE.  For SCSI, it bypasses and
>  gives the control directly to SCSI backend.  So, using CDROM_EJECT
>  ioctl won't help as of now.)
>
> I thought that fixing the udev behavior would solve the problem.  But
> it turned out that I was too naive.  A bigger problem is that all
> user-space stuff misinterprets DISK_EVENT_EJECT_REQUEST event: they
> see this as if the disk is *ready* to be ejected.  KDE, for example,
> dismisses the DVD icon when it receives this event even if it's still
> mounted.

It is not really about being "ready to eject", if the user presses the
button, the user does not want to wait for anything else than actually
ejecting the media as fast as possible. It is the same as ripping out
a USB cable. It needs to work, no matter if things are mounted or
busy.

We have to handle "the mess" in our tools, meaning cleaning up the stale
stuff in the kernel or userspace, just like we do with all other
plugable devices when they ripped out by the user.

I'm really not convinced that suppressing events here makes any sense.
It is just a hardware button event which should not be masked out for
rather weird reasons.

Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/