Hello Roland, [adding upstream to Cc: so adding some context first:]
In Debian bug #1107479 you report that inserting a DVD-RAM reliably
makes blkid (which is triggered by udev) result in a process hang.
On Thu, Jun 19, 2025 at 05:05:07PM +0200, Roland Sommer wrote:
> > Can you easily tell if this happens for several DVD-RAMs or just a
> > single one? (That might affect how good this is reproducible for
> > upstream.)
>
> I've tested 3 different DVD-RAMs, thus, 3 traces below.
>
> > Usually only the first one is interesting. After that the state of the
> > system is broken and the info from later traces is unreliable.
> >
> > So yes, please provide (at least) the first trace output.
>
> [ 330.049632] pktcdvd: pktcdvd0: writer mapped to sr0
> [...]
> [ 484.389280] </TASK>
Translating the addresses here to line numbers yields:
[ 330.049632] pktcdvd: pktcdvd0: writer mapped to sr0
[ 330.074390] sr0: detected capacity change from 8946816 to 8946812
[ 484.388532] INFO: task blkid:1979 blocked for more than 120 seconds.
[ 484.388562] Tainted: G I 6.1.0-37-amd64 #1 Debian
6.1.140-1
[ 484.388577] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 484.388585] task:blkid state:D stack:0 pid:1979 ppid:1768
flags:0x00004002
[ 484.388610] Call Trace:
[ 484.388618] <TASK>
[ 484.388634] __schedule (kernel/sched/core.c:5244 kernel/sched/core.c:6561)
[ 484.388682] schedule (arch/x86/include/asm/bitops.h:207 (discriminator 1)
arch/x86/include/asm/bitops.h:239 (discriminator 1)
include/asm-generic/bitops/instrumented-non-atomic.h:142 (discriminator 1)
include/linux/thread_info.h:118 (discriminator 1) include/linux/sched.h:2230
(discriminator 1) kernel/sched/core.c:6639 (discriminator 1))
[ 484.388706] schedule_preempt_disabled (arch/x86/include/asm/preempt.h:80
kernel/sched/core.c:6697)
[ 484.388728] __mutex_lock.constprop.0 (kernel/locking/mutex.c:197
kernel/locking/mutex.c:681 kernel/locking/mutex.c:747)
[ 484.388761] pkt_ioctl (drivers/block/pktcdvd.c:2590) pktcdvd
[ 484.388813] pkt_ioctl (drivers/block/pktcdvd.c:2610) pktcdvd
[ 484.388853] ? tomoyo_init_request_info (security/tomoyo/util.c:1026)
[ 484.388876] blkdev_ioctl (block/ioctl.c:620)
[ 484.388896] __x64_sys_ioctl (fs/ioctl.c:51 fs/ioctl.c:870 fs/ioctl.c:856
fs/ioctl.c:856)
[ 484.388920] do_syscall_64 (arch/x86/entry/common.c:51
arch/x86/entry/common.c:81)
[ 484.388947] ? mutex_lock (arch/x86/include/asm/atomic64_64.h:190
include/linux/atomic/atomic-long.h:443
include/linux/atomic/atomic-instrumented.h:1781 kernel/locking/mutex.c:171
kernel/locking/mutex.c:285)
[ 484.388969] ? pkt_ioctl (drivers/block/pktcdvd.c:2619) pktcdvd
[ 484.389013] ? blkdev_ioctl (block/ioctl.c:620)
[ 484.389030] ? exit_to_user_mode_prepare
(arch/x86/include/asm/entry-common.h:57 kernel/entry/common.c:212)
[ 484.389053] ? syscall_exit_to_user_mode (kernel/entry/common.c:306)
[ 484.389067] ? do_syscall_64 (arch/x86/entry/common.c:88)
[ 484.389089] ? handle_mm_fault (mm/memory.c:5295)
[ 484.389117] ? do_user_addr_fault (arch/x86/mm/fault.c:1369)
[ 484.389141] ? exit_to_user_mode_prepare
(arch/x86/include/asm/entry-common.h:57 kernel/entry/common.c:212)
[ 484.389161] entry_SYSCALL_64_after_hwframe
(/build/reproducible-path/linux-6.1.140/arch/x86/entry/entry_64.S:121)
[ 484.389181] RIP: 0033:0x7fce32c8ed1b
[ 484.389196] RSP: 002b:00007ffd2857ee10 EFLAGS: 00000246 ORIG_RAX:
0000000000000010
[ 484.389215] RAX: ffffffffffffffda RBX: 0000557da4646b40 RCX: 00007fce32c8ed1b
[ 484.389226] RDX: 00007ffd2857ee90 RSI: 0000000000005395 RDI: 0000000000000006
[ 484.389235] RBP: 0000000000000006 R08: 0000000000000007 R09: 0000557da4646a50
[ 484.389245] R10: 525ee8f48e4e6f05 R11: 0000000000000246 R12: 0000000000000000
[ 484.389255] R13: 0000000000000000 R14: 0000000000000000 R15: 8000000068541db5
[ 484.389280] </TASK>
blkdev_ioctl calls:
bdev->bd_disk->fops->ioctl(bdev, mode, cmd, arg);
Obviously we have bdev->bd_disk->fops->ioctl == pkt_ioctl and this
function then calls itself in line 2610 with:
ret = bdev->bd_disk->fops->ioctl(bdev, mode, cmd, arg);
So this explains the hang as the second instance of pkt_ioctl wants to
grab the mutex that the first is already holding.
A quick look over the commits since 6.1 to current mainline shows no
change that looks relevant.
In current linus/master (5c8013ae2e86) both functions still have these
calls, so I assume newer kernels are affected in the same way.
Best regards
Uwe
signature.asc
Description: PGP signature
