From 09e95577b8b69bdd440ad9cdcfb72bde7b1c6eb6 Mon Sep 17 00:00:00 2001
From: Thomas Schmitt <scdbackup@gmx.net>
Date: Fri, 31 Jul 2020 11:05:18 +0000
Subject: [PATCH]

---
 ConcurrentLinuxSr.md | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/ConcurrentLinuxSr.md b/ConcurrentLinuxSr.md
index d0ff447..6d12339 100644
--- a/ConcurrentLinuxSr.md
+++ b/ConcurrentLinuxSr.md
@@ -86,8 +86,26 @@ the translation from `/dev/sr` to `/dev/sg` is not guaranteed to work in future,
 and `/dev/sr*` is better coordinated with `mount(8)` and `open(2)` for
 `read(2)`.
 
-So long lasting SCSI transactions via `/dev/sr*` cause long
-delays of communication with the other drives. Some of these delays
+If you are able to compile an own Linux kernel, then the remedy is quite
+simple. In the source code of kernel 4.19 i edited `drivers/scsi/sr.c`,
+included `<scsi/sg.h>` which defines SG_IO, and skipped the mutex calls in
+function `sr_block_ioctl()` in case of SG_IO:
+```
+static int sr_block_ioctl(struct block_device *bdev, fmode_t mode, unsigned cmd,
+                          unsigned long arg)
+{
+       ...
+       if (cmd != SG_IO)
+               mutex_lock(&sr_mutex);
+       ...
+       if (cmd != SG_IO)
+               mutex_unlock(&sr_mutex);
+       ...
+}
+```
+
+Without such a code change, long lasting SCSI transactions via `/dev/sr*`
+cause long delays of communication with the other drives. Some of these delays
 cannot be avoided.
 E.g. the SCSI command to eject the tray needs several seconds to be 
 completed.