Bug 204243

Summary: WARNING: possible circular locking dependency detected [sr_mod]
Product: IO/Storage Reporter: Erhard F. (erhard_f)
Component: SCSIAssignee: linux-scsi (linux-scsi)
Status: NEW ---    
Severity: normal CC: scdbackup
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 5.2.1 Subsystem:
Regression: No Bisected commit-id:
Attachments: dmesg output
kernel .config (5.2.1)

Description Erhard F. 2019-07-20 10:43:36 UTC
Created attachment 283867 [details]
dmesg output

Encountered this during writing an .iso to a DVD-RW media:

[...]
[ 6908.678745] ======================================================
[ 6908.678746] WARNING: possible circular locking dependency detected
[ 6908.678749] 5.2.1-gentoo #1 Not tainted
[ 6908.678750] ------------------------------------------------------
[ 6908.678752] brasero/1066 is trying to acquire lock:
[ 6908.678754] 0000000087aec994 (&mm->mmap_sem#2){++++}, at: __do_page_fault+0x387/0x420
[ 6908.678761] 
               but task is already holding lock:
[ 6908.678762] 0000000056293ac4 (sr_mutex){+.+.}, at: sr_block_ioctl+0x3a/0xc0 [sr_mod]
[ 6908.678768] 
               which lock already depends on the new lock.

[ 6908.678769] 
               the existing dependency chain (in reverse order) is:
[ 6908.678770] 
               -> #6 (sr_mutex){+.+.}:
[ 6908.678773] 
               -> #5 (&bdev->bd_mutex){+.+.}:
[ 6908.678775] 
               -> #4 (&fs_devs->device_list_mutex){+.+.}:
[ 6908.678777] 
               -> #3 (&fs_info->tree_log_mutex){+.+.}:
[ 6908.678780] 
               -> #2 (&fs_info->reloc_mutex){+.+.}:
[ 6908.678782] 
               -> #1 (sb_pagefaults){.+.+}:
[ 6908.678784] 
               -> #0 (&mm->mmap_sem#2){++++}:
[ 6908.678786] 
               other info that might help us debug this:

[ 6908.678787] Chain exists of:
                 &mm->mmap_sem#2 --> &bdev->bd_mutex --> sr_mutex

[ 6908.678790]  Possible unsafe locking scenario:

[ 6908.678791]        CPU0                    CPU1
[ 6908.678793]        ----                    ----
[ 6908.678794]   lock(sr_mutex);
[ 6908.678795]                                lock(&bdev->bd_mutex);
[ 6908.678797]                                lock(sr_mutex);
[ 6908.678798]   lock(&mm->mmap_sem#2);
[ 6908.678800] 
                *** DEADLOCK ***

[ 6908.678801] 1 lock held by brasero/1066:
[ 6908.678802]  #0: 0000000056293ac4 (sr_mutex){+.+.}, at: sr_block_ioctl+0x3a/0xc0 [sr_mod]
[ 6908.678806] 
               stack backtrace:
[ 6908.678809] CPU: 1 PID: 1066 Comm: brasero Not tainted 5.2.1-gentoo #1
[ 6908.678810] Hardware name: System manufacturer System Product Name/M5A78L-M LX3, BIOS 1401    05/05/2016
[ 6908.678812] Call Trace:
[ 6908.678816]  dump_stack+0x67/0x98
[ 6908.678820]  print_circular_bug.cold.60+0x15c/0x195
[ 6908.678823]  __lock_acquire+0x17c0/0x1d18
[ 6908.678826]  lock_acquire+0xaa/0x168
[ 6908.678828]  ? __do_page_fault+0x387/0x420
[ 6908.678831]  ? copy_user_generic_string+0x29/0x40
[ 6908.678833]  down_read+0x28/0xc0
[ 6908.678836]  ? __do_page_fault+0x387/0x420
[ 6908.678838]  __do_page_fault+0x387/0x420
[ 6908.678841]  ? page_fault+0x1b/0x20
[ 6908.678843]  ? copy_user_generic_string+0x29/0x40
[ 6908.678846]  ? copyout+0x25/0x30
[ 6908.678847]  ? copy_page_to_iter+0xd0/0x330
[ 6908.678850]  ? bio_uncopy_user+0x124/0x168
[ 6908.678852]  ? blk_rq_unmap_user+0x22/0x60
[ 6908.678855]  ? sg_io+0x268/0x440
[ 6908.678857]  ? scsi_cmd_ioctl+0x2b2/0x498
[ 6908.678861]  ? cdrom_ioctl+0x36/0xde4 [cdrom]
[ 6908.678864]  ? _raw_spin_unlock_irqrestore+0x37/0x40
[ 6908.678866]  ? __pm_runtime_resume+0x4f/0x70
[ 6908.678869]  ? sr_block_ioctl+0x9d/0xc0 [sr_mod]
[ 6908.678872]  ? blkdev_ioctl+0x52e/0xa80
[ 6908.678874]  ? find_held_lock+0x2d/0x90
[ 6908.678876]  ? block_ioctl+0x2d/0x38
[ 6908.678879]  ? do_vfs_ioctl+0xa8/0x718
[ 6908.678881]  ? __fget+0x101/0x1e0
[ 6908.678883]  ? ksys_ioctl+0x35/0x70
[ 6908.678884]  ? __x64_sys_ioctl+0x11/0x18
[ 6908.678887]  ? do_syscall_64+0x4b/0x198
[ 6908.678889]  ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 6984.804171] capability: warning: `growisofs' uses 32-bit capabilities (legacy support in use)
Comment 1 Erhard F. 2019-07-20 10:45:28 UTC
Created attachment 283869 [details]
kernel .config (5.2.1)
Comment 2 Thomas Schmitt 2019-07-21 07:26:19 UTC
Hi,

the lock in sr_block_open() is a nuisance since it was introduced by
a daring mass change nine years ago:
  https://lkml.org/lkml/2010/9/14/338
It has a history of complaints about slowing down concurrent use of
ioctl(SG_IO) on different sr drives:
  https://marc.info/?l=linux-scsi&m=135705061804384&w=2
As developer of libburn i had to develop workarounds in userspace:
  http://libburnia-project.org/wiki/ConcurrentLinuxSr
None of them is really satisfying.

Since 3 years i use /dev/sg* instead of /dev/sr* for burning. The older
readers will remember the relief when we could use hd and sr and thus
had proper coordination with mount(8). This is gone, at least for systems
where more than one optical drive shall be used concurrently.

So, as did others before, i propose to remove the mutex_lock()/mutex_unlock()
pair in sr_block_ioctl().

(Actually the other mutex_lock()/mutex_unlock() pairs introduced by
   https://lkml.org/lkml/2010/9/14/338
 should be examined whether they are appropriate replacements of the
 previously existing BKLs. They don't have this long lasting impact on
 multi-drive operation, though.)

Have a nice day :)

Thomas
Comment 3 Thomas Schmitt 2019-07-21 07:28:15 UTC
Sorry, i wrote "sr_block_open()" where i meant "sr_block_ioctl()".