2020-02-14 14:05:50

by Merlijn Wajer

[permalink] [raw]
Subject: [PATCH] scsi: sr: get rid of sr global mutex

From: Merlijn Wajer <[email protected]>

When replacing the Big Kernel Lock in commit
2a48fc0ab24241755dc93bfd4f01d68efab47f5a ("block: autoconvert trivial
BKL users to private mutex"), the lock was replaced with a sr-wide lock.

This causes very poor performance when using multiple sr devices, as the
sr driver was not able to execute more than one command to one drive at
any given time, even when there were many CD drives available.

Replace the global mutex with per-sr-device mutex.

Someone tried this patch at the time, but it never made it
upstream, due to possible concerns with race conditions, but it's not
clear the patch actually caused those:

https://www.spinics.net/lists/linux-scsi/msg63706.html
https://www.spinics.net/lists/linux-scsi/msg63750.html

Also see

http://lists.xiph.org/pipermail/paranoia/2019-December/001647.html

Signed-off-by: Merlijn Wajer <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
---
drivers/scsi/sr.c | 16 +++++++++-------
drivers/scsi/sr.h | 2 ++
2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index 38ddbbfe5..6809fdcfd 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -77,7 +77,6 @@ MODULE_ALIAS_SCSI_DEVICE(TYPE_WORM);
CDC_CD_R|CDC_CD_RW|CDC_DVD|CDC_DVD_R|CDC_DVD_RAM|CDC_GENERIC_PACKET| \
CDC_MRW|CDC_MRW_W|CDC_RAM)

-static DEFINE_MUTEX(sr_mutex);
static int sr_probe(struct device *);
static int sr_remove(struct device *);
static blk_status_t sr_init_command(struct scsi_cmnd *SCpnt);
@@ -535,9 +534,9 @@ static int sr_block_open(struct block_device *bdev, fmode_t mode)
scsi_autopm_get_device(sdev);
check_disk_change(bdev);

- mutex_lock(&sr_mutex);
+ mutex_lock(&cd->lock);
ret = cdrom_open(&cd->cdi, bdev, mode);
- mutex_unlock(&sr_mutex);
+ mutex_unlock(&cd->lock);

scsi_autopm_put_device(sdev);
if (ret)
@@ -550,10 +549,10 @@ static int sr_block_open(struct block_device *bdev, fmode_t mode)
static void sr_block_release(struct gendisk *disk, fmode_t mode)
{
struct scsi_cd *cd = scsi_cd(disk);
- mutex_lock(&sr_mutex);
+ mutex_lock(&cd->lock);
cdrom_release(&cd->cdi, mode);
scsi_cd_put(cd);
- mutex_unlock(&sr_mutex);
+ mutex_unlock(&cd->lock);
}

static int sr_block_ioctl(struct block_device *bdev, fmode_t mode, unsigned cmd,
@@ -564,7 +563,7 @@ static int sr_block_ioctl(struct block_device *bdev, fmode_t mode, unsigned cmd,
void __user *argp = (void __user *)arg;
int ret;

- mutex_lock(&sr_mutex);
+ mutex_lock(&cd->lock);

ret = scsi_ioctl_block_when_processing_errors(sdev, cmd,
(mode & FMODE_NDELAY) != 0);
@@ -594,7 +593,7 @@ static int sr_block_ioctl(struct block_device *bdev, fmode_t mode, unsigned cmd,
scsi_autopm_put_device(sdev);

out:
- mutex_unlock(&sr_mutex);
+ mutex_unlock(&cd->lock);
return ret;
}

@@ -700,6 +699,7 @@ static int sr_probe(struct device *dev)
disk = alloc_disk(1);
if (!disk)
goto fail_free;
+ mutex_init(&cd->lock);

spin_lock(&sr_index_lock);
minor = find_first_zero_bit(sr_index_bits, SR_DISKS);
@@ -1009,6 +1009,8 @@ static void sr_kref_release(struct kref *kref)

put_disk(disk);

+ mutex_destroy(&cd->lock);
+
kfree(cd);
}

diff --git a/drivers/scsi/sr.h b/drivers/scsi/sr.h
index a2bb7b8ba..339c624e0 100644
--- a/drivers/scsi/sr.h
+++ b/drivers/scsi/sr.h
@@ -20,6 +20,7 @@

#include <linux/genhd.h>
#include <linux/kref.h>
+#include <linux/mutex.h>

#define MAX_RETRIES 3
#define SR_TIMEOUT (30 * HZ)
@@ -51,6 +52,7 @@ typedef struct scsi_cd {
bool ignore_get_event:1; /* GET_EVENT is unreliable, use TUR */

struct cdrom_device_info cdi;
+ struct mutex lock;
/* We hold gendisk and scsi_device references on probe and use
* the refs on this kref to decide when to release them */
struct kref kref;
--
2.17.1


2020-02-18 05:24:24

by Martin K. Petersen

[permalink] [raw]
Subject: Re: [PATCH] scsi: sr: get rid of sr global mutex


Merlijn,

> When replacing the Big Kernel Lock in commit
> 2a48fc0ab24241755dc93bfd4f01d68efab47f5a ("block: autoconvert trivial
> BKL users to private mutex"), the lock was replaced with a sr-wide
> lock.

Applied to 5.7/scsi-queue, thanks!

--
Martin K. Petersen Oracle Linux Engineering

2020-02-18 05:40:08

by Martin K. Petersen

[permalink] [raw]
Subject: Re: [PATCH] scsi: sr: get rid of sr global mutex


Merlijn,

>> When replacing the Big Kernel Lock in commit
>> 2a48fc0ab24241755dc93bfd4f01d68efab47f5a ("block: autoconvert trivial
>> BKL users to private mutex"), the lock was replaced with a sr-wide
>> lock.
>
> Applied to 5.7/scsi-queue, thanks!

Doesn't build. Please rebase on top of 5.7/scsi-queue and
resubmit. Thanks!

--
Martin K. Petersen Oracle Linux Engineering

2020-02-18 11:17:19

by Merlijn Wajer

[permalink] [raw]
Subject: Re: [PATCH] scsi: sr: get rid of sr global mutex

Hi Martin,

On 18/02/2020 06:39, Martin K. Petersen wrote:
>
> Merlijn,
>
>>> When replacing the Big Kernel Lock in commit
>>> 2a48fc0ab24241755dc93bfd4f01d68efab47f5a ("block: autoconvert trivial
>>> BKL users to private mutex"), the lock was replaced with a sr-wide
>>> lock.
>>
>> Applied to 5.7/scsi-queue, thanks!
>
> Doesn't build. Please rebase on top of 5.7/scsi-queue and
> resubmit. Thanks!
>

Odd, I will take a look.

Cheers,
Merlijn


Attachments:
signature.asc (235.00 B)
OpenPGP digital signature

2020-02-18 14:40:32

by Merlijn Wajer

[permalink] [raw]
Subject: Re: [PATCH] scsi: sr: get rid of sr global mutex

Hi Martin,

On 18/02/2020 06:39, Martin K. Petersen wrote:
>
> Merlijn,
>
>>> When replacing the Big Kernel Lock in commit
>>> 2a48fc0ab24241755dc93bfd4f01d68efab47f5a ("block: autoconvert trivial
>>> BKL users to private mutex"), the lock was replaced with a sr-wide
>>> lock.
>>
>> Applied to 5.7/scsi-queue, thanks!
>
> Doesn't build. Please rebase on top of 5.7/scsi-queue and
> resubmit. Thanks!

I've sent out a new (v2) patch, based on `5.7/scsi-queue`. I've sent it
out using my work-email for proper attribution, and now it also matches
the Signed-off-by.

Sorry for the hassle.

One question -- I would like to put in some extra work to get this patch
(or some version of it) sent out to stable trees as well. Is there any
additional work I can do to get that going, or is it a matter of
emailing the right person/list?

Thanks,
Cheers,
Merlijn


Attachments:
signature.asc (235.00 B)
OpenPGP digital signature