linux-kernel - Re: SCSI sr driver: parallel writes to optical serialized which hurts performance (sr

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: <CAHrxqh3pGJzVoxtgNgmbVSdwXSiH2cLGYpU4R2+eDEEfaHxi7A@mail.gmail.com>
Date:	Sat, 5 Mar 2016 21:15:11 +0100
From:	Johan de Jong <jrdejong@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	Thomas Schmitt <scdbackup@....net>
Subject: Re: SCSI sr driver: parallel writes to optical serialized which hurts
 performance (sr_mutex)

Dear developers,

In the mean time I have applied and tested the 2013 patch by Otto Meta:

http://marc.info/?l=linux-scsi&m=135705061804384&w=2

which, in short, replaces mutex_lock(&sr_mutex) (global mutex), that
was introduced in 2010 to replace lock_kernel(), by per-device mutexes
and allowing concurrent ioctl(SG_IO) in different processes with
different sr devices.

I had to patch some parts by hand as the posted patch did not slide
seamlessly into my more current source tree, but I'm happy to report
that the patch indeed does what it intends and solves the performance
issue with accessing multiple sr devices concurrently. Repeated
concurrent writes to three SATA burners have shown reliable and
performance penalty free runs. In addition, repeated concurrent drive
tray open and close (eject (-t) /dev/sr0 & eject (-t) /dev/sr1 & eject
(-t) /dev/sr2) commands result in simultaneous (as opposed to the
unpatched kernel) and reliable tray movement with no visible
indications of locking problems caused by the patch either physically
or in the kernel logs.

I have been running the patched kernel for a number of days now to
full satisfaction and relief. I would therefore venture to suggest
that mutex_lock(&sr_mutex) is indeed the cause of the severe
performance penalty and that the 2013 Otto Meta patch proposes a
viable remedy that bears nomination for patching into the main kernel
tree.

Sincerely,
Johan de Jong