Linux SCSI subsystem development
 help / color / mirror / Atom feed
From: Wakko Warner <wakko@animx.eu.org>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Otto Meta <otto.kernel.02e4af24@sister-shadow.de>,
	linux-scsi@vger.kernel.org
Subject: Re: [PATCH] [SCSI] sr: Fix multi-drive performance by using per-device mutexes
Date: Fri, 4 Jan 2013 16:26:46 -0500	[thread overview]
Message-ID: <20130104212646.GA18875@animx.eu.org> (raw)
In-Reply-To: <20130104205027.062c808a@stein>

Stefan Richter wrote:
> 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.

I myself have not tried this specific test.  I do not have any systems with
2 PATA DVDroms on the same cable.  The only system I have that has PATA, the
drives are on seperate cables with nothing else on the cable.  My other
system is all SATA.  I have no other systems with more than 1 CD/DVD drive.

  reply	other threads:[~2013-01-04 21:46 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
2013-01-04 21:26     ` Wakko Warner [this message]
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=20130104212646.GA18875@animx.eu.org \
    --to=wakko@animx.eu.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=otto.kernel.02e4af24@sister-shadow.de \
    --cc=stefanr@s5r6.in-berlin.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox