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)
Created attachment 283869 [details] kernel .config (5.2.1)
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
Sorry, i wrote "sr_block_open()" where i meant "sr_block_ioctl()".