Bug 18522

Summary: cdrom drive doesn't detect removal
Product: IO/Storage Reporter: Maciej Rutecki (maciej.rutecki)
Component: Serial ATAAssignee: Jeff Garzik (jgarzik)
Severity: normal CC: florian, maciej.rutecki, rjw, tj
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.35-rc1 Subsystem:
Regression: Yes Bisected commit-id:
Bug Depends on:    
Bug Blocks: 16055    

Description Maciej Rutecki 2010-09-14 19:36:40 UTC
Subject    : [REGRESSION] cdrom drive doesn't detect removal
Submitter  : Maxim Levitsky <maximlevitsky@gmail.com>
Date       : 2010-09-12 9:49
Message-ID : 1284284969.2928.18.camel@maxim-laptop
References : http://marc.info/?l=linux-kernel&m=128428499013930&w=2

This entry is being used for tracking a regression from 2.6.34. Please don't
close it until the problem is fixed in the mainline.

Caused by:

commit 6b4517a7913a09d3259bb1d21c9cb300f12294bd
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Apr 7 18:53:59 2010 +0900

    block: implement bd_claiming and claiming block
    Currently, device claiming for exclusive open is done after low level
    open - disk->fops->open() - has completed successfully.  This means
    that exclusive open attempts while a device is already exclusively
    open will fail only after disk->fops->open() is called.
    cdrom driver issues commands during open() which means that O_EXCL
    open attempt can unintentionally inject commands to in-progress
    command stream for burning thus disturbing burning process.  In most
    cases, this doesn't cause problems because the first command to be
    issued is TUR which most devices can process in the middle of burning.
    However, depending on how a device replies to TUR during burning,
    cdrom driver may end up issuing further commands.
    This can't be resolved trivially by moving bd_claim() before doing
    actual open() because that means an open attempt which will end up
    failing could interfere other legit O_EXCL open attempts.
    ie. unconfirmed open attempts can fail others.
    This patch resolves the problem by introducing claiming block which is
    started by bd_start_claiming() and terminated either by bd_claim() or
    bd_abort_claiming().  bd_claim() from inside a claiming block is
    guaranteed to succeed and once a claiming block is started, other
    bd_start_claiming() or bd_claim() attempts block till the current
    claiming block is terminated.
    bd_claim() can still be used standalone although now it always
    synchronizes against claiming blocks, so the existing users will keep
    working without any change.
    blkdev_open() and open_bdev_exclusive() are converted to use claiming
    blocks so that exclusive open attempts from these functions don't
    interfere with the existing exclusive open.
    This problem was discovered while investigating bko#15403.
    The burning problem itself can be resolved by updating userspace
    probing tools to always open w/ O_EXCL.
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Matthias-Christian Ott <ott@mirix.org>
    Cc: Kay Sievers <kay.sievers@vrfy.org>
    Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

First-Bad-Commit : 6b4517a7913a09d3259bb1d21c9cb300f12294bd
Comment 1 Florian Mickler 2010-09-30 11:43:48 UTC
On Thu, 30 Sep 2010 09:48:50 +0200
Kay Sievers <kay.sievers@vrfy.org> wrote:

> Hmm, I still don't think that's a bug or regression.
> Optical drives are not supposed to report media changes without
> constantly being polled. Why Tejun's seems to have an influence in
> Maxim's setup, is likely more a timing-related issue, or some other
> thing, we never really got an idea why it could change anything.
> The current behavior is the expected and correct behavior, and for me
> also the older kernels behave like this.
> Kay
Comment 2 Florian Mickler 2010-10-01 07:35:57 UTC
On Fri, 01 Oct 2010 07:55:44 +0200
Tejun Heo <tj@kernel.org> wrote:

> Hello,
> I just started working on in-kernel media presence polling and it
> shouldn't be too hard to distinguish ro-mount and burning cases and it
> should be possible to keep polling for ro mounts.  I think it's
> already a bit too late for the next merge window but the one after
> that would be a reasonable target.
> Thanks.
Comment 3 Florian Mickler 2010-12-18 02:07:51 UTC
References: http://www.spinics.net/lists/linux-ide/msg39585.html
Comment 4 Florian Mickler 2011-03-30 22:17:06 UTC
This landed, IIRC ...