linux-kernel - Re: [REGRESSION] cdrom drive doesn't detect removal

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: <20100930083020.62b56218@schatten.dmk.lab>
Date:	Thu, 30 Sep 2010 08:30:20 +0200
From:	Florian Mickler <florian@...kler.org>
To:	linux-kernel@...r.kernel.org
Cc:	Kay Sievers <kay.sievers@...y.org>, Tejun Heo <tj@...nel.org>,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jens Axboe <axboe@...nel.dk>
Subject: Re: [REGRESSION] cdrom drive doesn't detect removal

On Thu, 23 Sep 2010 11:21:08 +0200
Kay Sievers <kay.sievers@...y.org> wrote:

> On Thu, Sep 23, 2010 at 10:47, Tejun Heo <tj@...nel.org> wrote:
> 
> > Yeah, what I'm curious about is why hal behaves differently with
> > claiming block patch.  Exclusive open still fails with EBUSY with or
> > without the patch, right?  So, why does hal behave differently?
> 
> We don't support unlocked cd doors. Currently eject/umount of optical
> media has to be initiated by the user.
> 
> HAL checked if the device was mounted, and if it was, it dropped the
> O_EXCL. This was to support polling of the eject-button state, which
> worked on a few drives. That's no longer cecked with udisks, it does
> O_EXCL only for optical media.
> 
> >> Look if it fails. sure the device is open, but if doesn't fail, nothing
> >> prevents a bit less honest clients (that don't use exclusive open) to
> >> open the device. How exclusive such an open is then?
> 
> >> So I mean exclusive open should really block _all_ following opens of
> >> the device, exclusive or not.
> >
> > That will probably break a lot of stuff.
> 
> That would surely need a new flag like O_REALLYEXCL. :)
> 
> > I'm currently working on in-kernel media presence polling to handle
> > the open and polling command sequence issues.  That said, it's not
> > entirely clear how the mount case should be handled.  If a media is
> > mounted, the device is exclusively open and media presence polling
> > shouldn't be inserting commands in the middle but then how can it
> > detect the media has been ejected by the user?  Kay, can you please
> > enlighten me on how it's supposed to work?
> 
> Non-optical devices should not be a problem, and can be always polled,
> as it seems. We do this without O_EXCL since forever.
> 
> For optical drives I would never ever bypass O_EXCL, like udisks is
> doing it. There are far too many problems with burning, which never
> got really solved.
> 
> Force-removed media (not recommended unlocked doors) might not be
> detected until the filesystem is cleaned-up/umounted, but that's
> probably the better compromise than fiddling with the broken drives
> during burning sessions.
> 
> Kay

So, is the $subject problem solved now? Normally, we shouldn't break
stuff with new kernels... If this is only a temporary breakage on
the other hand, we should keep track of it... 
I ask, because this is listed as https://bugzilla.kernel.org/show_bug.cgi?id=18522.
If it should stay listed, we may need an ETA for the fix... 

Regards,
Flo




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