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: <4C9B141F.3050908@kernel.org>
Date:	Thu, 23 Sep 2010 10:47:27 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Maxim Levitsky <maximlevitsky@...il.com>,
	Kay Sievers <kay.sievers@...y.org>
CC:	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

Hello,

On 09/22/2010 03:58 PM, Maxim Levitsky wrote:
>> 1. Make exclusive opens really exclusive.
>> That is if someone opens a device with exclusive access, no more opens
>> will succeed.
> And as a follow-up, indeed hal first tries exclusive open, and if it
> fails, it retries with non-exclusive open, and it succeeds.
> And that somewhat makes me think that exclusive open is pretty much
> useless.

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?

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

It's cooperative exclusion.  It doesn't assume the presence of hostile
programs having access to the device.

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

> Btw I had few failed dual layer disk burns that failed just after write
> of few MBs. I wouldn't be surprised if this was the cause.

Usually open sequence just inserts TEST UNIT READY which usually is
safe but yeah it's possible that some device might react badly.

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?

Thanks.

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