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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Fri, 14 Feb 2020 10:03:18 +0100
From:   Arnd Bergmann <>
To:     Merlijn Wajer <>
Cc:     linux-scsi <>,
        Jens Axboe <>,
        "James E.J. Bottomley" <>,
        "Martin K. Petersen" <>,
        "" <>
Subject: Re: [RFC PATCH] scsi: sr: get rid of sr global mutex

On Wed, Feb 12, 2020 at 5:45 PM Merlijn Wajer <> wrote:
> 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:
> Also see
> Signed-off-by: Merlijn Wajer <>

This all looks reasonable to me. The conversion from BKL to a per-driver
mutex was done in a mostly automated way, and I did not attempt to make
it more fine-grained then.

I don't see any global state accessed in the open/close/ioctl functions,
so this is probably completely safe. It may even be possible to avoid
that mutex completely, but that is harder to prove.

Acked-by: Arnd Bergmann <>

Powered by blists - more mailing lists