All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Otto Meta <otto.kernel.02e4af24@sister-shadow.de>
Cc: linux-scsi@vger.kernel.org, Wakko Warner <wakko@animx.eu.org>
Subject: Re: [PATCH] [SCSI] sr: Fix multi-drive performance by using per-device mutexes
Date: Fri, 4 Jan 2013 20:50:27 +0100	[thread overview]
Message-ID: <20130104205027.062c808a@stein> (raw)
In-Reply-To: <50E61021.20709@sister-shadow.de>

On Jan 04 Otto Meta wrote:
> Otto Meta wrote:
> > The single mutex for the sr module, introduced as a BKL replacement,
> > globally serialises all sr ioctls, which hurts multi-drive performance.
> > 
> > This patch replaces sr_mutex with per-device mutexes in struct scsi_cd,
> > allowing concurrent ioctls on different sr devices.
> 
> Unfortunately it wasn't as easy as that. The patch seems to introduce
> a race condition that corrupts a drive's state under certain circumstances.
> 
> When two drives (e.g. sr0 and sr1) are attached to the same IDE cable, one
> drive has its door locked, which will usually be the case after any operation
> on the drive with inserted media (and whenever it feels like it, even with
> dev.cdrom.lock=0), and the other drive is unlocked, then executing
> 
>   $ eject sr0 & eject sr1
> 
> will eject the unlocked drive and the locked drive will return
> 
>   eject: unable to eject, last error: Inappropriate ioctl for device
> 
> 
> Other drivers down the road probably don't expect concurrent ioctls, so this
> patch cannot be applied safely at this time. Sorry about the noise.
> 
> For the record: Tested with kernels 3.2.35 and 3.8.0-rc1, using IDE CD/DVD
> drives connected via the drivers ata_piix and pata_pdc202xx_old.

As yo may have seen in the mailinglist archive, when Wakko and I tested
with sr_mutex removed without any replacement, we were not able to trigger
any race condition.  However, we certainly did not attempt this very
particular test (two drives on the same PATA cable, one locked and one
unlocked, and "eject" called on both of them at the same time).  I wonder
if this is a PATA idiosyncrasy.

I will see whether I can do some tests tomorrow.  I can easily test master
and slave PATA drives on a single cable behind a PATA-to-1394 bridge; but
testing two drives on a single cable behind a PATA-to-PCI controller would
be a bit more involved because the case of my PATA-equipped Linux PC is
rather cramped.
-- 
Stefan Richter
-=====-===-= ---= --=--
http://arcgraph.de/sr/

  reply	other threads:[~2013-01-04 19:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-01 14:20 [PATCH] [SCSI] sr: Fix multi-drive performance by using per-device mutexes Otto Meta
2013-01-03 23:11 ` Otto Meta
2013-01-04 19:50   ` Stefan Richter [this message]
2013-01-04 21:26     ` Wakko Warner
2013-01-04 23:05     ` Otto Meta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130104205027.062c808a@stein \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=linux-scsi@vger.kernel.org \
    --cc=otto.kernel.02e4af24@sister-shadow.de \
    --cc=wakko@animx.eu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.