Re: [PATCH] [SCSI] sr: Fix multi-drive performance by using per-device mutexes

[Otto Meta <otto.kernel.02e4af24@sister-shadow.de>]

On 2013-01-04 Stefan Richter wrote:
> 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.

Reading from two devices connected to different PATA cables or controllers
via ioctl is working quite fine with the patch, so that seems to be in line
with your and Wakko's findings.

Running the eject test on the same device combination seems to be mostly
fine. I'm saying "mostly" because sometimes drives stay locked when I expect
them to be unlocked, but I haven't been able to reproduce that reliably.
A few times drives even stayed locked with the tray ejected(!), i.e. I
couldn't close the drive via its eject button and had to run  eject -t.
As dev.cdrom.lock=0 seems to be ignored even without the patch, I'm not sure
whether the locking issue is caused or just amplified by the patch.

Another note regarding the eject test with two devices connected to the same
PATA cable: If both drives are unlocked, they eject fine, but sequentially.
Something seems to be trying to prevent interference between the two drives,
but it's not working properly once unlocking is involved.

-- 
Otto Meta