Re: Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM

Re: Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 4599 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 1291 bytes --]

Hello Roland,

On Fri, Jun 20, 2025 at 01:26:31AM +0200, Uwe Kleine-König wrote:
> 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>

The pktcdvd driver is essentially unmaintained and there is a chance
that you don't need it. 

Can you please try:

	echo > /etc/modprobe.d/debian-bug1107479.conf blacklist pktcdvd

reboot and then test again? Please report back if any functionallity
related to the DVD-RAM is missing without that module.

My guess is that it's fine and the resolution is to stop building that
module for Debian.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM

[Roland Sommer]

Hello Uwe,

> The pktcdvd driver is essentially unmaintained and there is a chance
> that you don't need it. 
> 
> Can you please try:
> 
> 	echo > /etc/modprobe.d/debian-bug1107479.conf blacklist
> pktcdvd
> 
> reboot and then test again? Please report back if any functionallity
> related to the DVD-RAM is missing without that module.

With that blacklist entry everthing works as expected, even blkid.

> My guess is that it's fine and the resolution is to stop building that
> module for Debian.

Hmm, it's still loaded and I'd assume DVD-RAM will not be accessible
without it:

[  168.063968] pktcdvd: pktcdvd0: writer mapped to sr0
[  168.091270] sr0: detected capacity change from 8946816 to 8946812

lsmod | grep pkt
pktcdvd                49152  1
cdrom                  81920  3 udf,pktcdvd,sr_mod
scsi_mod              286720  5 sd_mod,pktcdvd,libata,sg,sr_mod
scsi_common            16384  5 scsi_mod,pktcdvd,libata,sg,sr_mod

systemd-analyze cat-config modprobe.d | grep pkt
blacklist pktcdvd

Best regards,
Roland

Re: Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]

Hello Roland,

On Fri, Jun 27, 2025 at 12:32:33PM +0200, Roland Sommer wrote:
> > The pktcdvd driver is essentially unmaintained and there is a chance
> > that you don't need it. 
> > 
> > Can you please try:
> > 
> > 	echo > /etc/modprobe.d/debian-bug1107479.conf blacklist
> > pktcdvd
> > 
> > reboot and then test again? Please report back if any functionallity
> > related to the DVD-RAM is missing without that module.
> 
> With that blacklist entry everthing works as expected, even blkid.
> 
> > My guess is that it's fine and the resolution is to stop building that
> > module for Debian.
> 
> Hmm, it's still loaded

That is surprising. I would have expected that the only effect of that
blacklist entry is that the module is not loaded. I don't understand how
that entry makes a difference if it doesn't prevent the module being
loaded.

You can try

	update-initramfs -u -k all

maybe then the module isn't loaded any more on the next boot.

> and I'd assume DVD-RAM will not be accessible
> without it:
> 
> [  168.063968] pktcdvd: pktcdvd0: writer mapped to sr0
> [  168.091270] sr0: detected capacity change from 8946816 to 8946812

The sr module might be enough to handle a DVD-RAM.
 
> lsmod | grep pkt
> pktcdvd                49152  1
> cdrom                  81920  3 udf,pktcdvd,sr_mod
> scsi_mod              286720  5 sd_mod,pktcdvd,libata,sg,sr_mod
> scsi_common            16384  5 scsi_mod,pktcdvd,libata,sg,sr_mod

Puzzled!
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM

[Roland Sommer]

Hello Uwe,

> That is surprising. I would have expected that the only effect of that
> blacklist entry is that the module is not loaded. I don't understand
> how that entry makes a difference if it doesn't prevent the module
> being loaded.
> 
> You can try
> 
> 	update-initramfs -u -k all
> 
> maybe then the module isn't loaded any more on the next boot.

I'm sorry, it is.

> The sr module might be enough to handle a DVD-RAM.

Ok, then lets try it the hard way: rename
/usr/lib/modules/6.1.0-37-amd64/kernel/drivers/block/pktcdvd.ko and
reboot.

-> dmesg reports

Jun 28 10:38:06 nb06 (udev-worker)[2081]: sr0: Process '/usr/sbin/pktsetup -i 11:0' failed with exit code 1.

-> lsmod reports pktcdvd not loaded

-> And most important: DVD-RAM fully operational

> Puzzled!

And now? ;-)

Best regards,
Roland

Re: Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]

On Sat, Jun 28, 2025 at 10:52:26AM +0200, Roland Sommer wrote:
> Hello Uwe,
> 
> > That is surprising. I would have expected that the only effect of that
> > blacklist entry is that the module is not loaded. I don't understand
> > how that entry makes a difference if it doesn't prevent the module
> > being loaded.
> > 
> > You can try
> > 
> > 	update-initramfs -u -k all
> > 
> > maybe then the module isn't loaded any more on the next boot.
> 
> I'm sorry, it is.
> 
> > The sr module might be enough to handle a DVD-RAM.
> 
> Ok, then lets try it the hard way: rename
> /usr/lib/modules/6.1.0-37-amd64/kernel/drivers/block/pktcdvd.ko and
> reboot.
> 
> -> dmesg reports
> 
> Jun 28 10:38:06 nb06 (udev-worker)[2081]: sr0: Process '/usr/sbin/pktsetup -i 11:0' failed with exit code 1.

Ahh, now that makes sense. pktsetup calls `/sbin/modprobe pktcdvd`
explicitly, the blacklist entry doesn't help for that. Without the
kernel module renamed, does the 2nd DVD-RAM result in the blocking
behaviour?

> -> lsmod reports pktcdvd not loaded
> 
> -> And most important: DVD-RAM fully operational
> 
> > Puzzled!
> 
> And now? ;-)

It's a tad better now :-)

Given the lack of upstream response, the driver being orphaned, a
working setup even without the module I think we'll go with disabling
that module.

Thanks for your report and helpful testing,
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM

[Roland Sommer]

Hello Uwe,

[correcting CC recipients]

> Ahh, now that makes sense. pktsetup calls `/sbin/modprobe pktcdvd`
> explicitly, the blacklist entry doesn't help for that. Without the
> kernel module renamed, does the 2nd DVD-RAM result in the blocking
> behaviour?

Yes.

> Thanks for your report and helpful testing,

You're welcome. This is the way how OSS should be treated (at least in
my opinion).

Best regards,
Roland

Re: Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]

Hello Roland,

On Sun, Jun 29, 2025 at 11:46:00AM +0200, Roland Sommer wrote:
> [correcting CC recipients]

Huh, how did I manage that (rhetorical question)? Thanks

> > Ahh, now that makes sense. pktsetup calls `/sbin/modprobe pktcdvd`
> > explicitly, the blacklist entry doesn't help for that. Without the
> > kernel module renamed, does the 2nd DVD-RAM result in the blocking
> > behaviour?
> 
> Yes.

OK, that makes sense. So udev does in this order:

 - auto-load the module (which is suppressed with the backlist entry)
 - call blkid (which blocks if the module is loaded)
 - call pktsetup (which loads the module even in presence of the
   blacklist entry).

> > Thanks for your report and helpful testing,
> 
> You're welcome. This is the way how OSS should be treated (at least in
> my opinion).

I fully agree, still this looks different in practise more often that
not :-\

I created
https://salsa.debian.org/kernel-team/linux/-/merge_requests/1564 now.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM

[Jens Axboe]

On 6/29/25 4:26 AM, Uwe Kleine-K?nig wrote:
> Hello Roland,
> 
> On Sun, Jun 29, 2025 at 11:46:00AM +0200, Roland Sommer wrote:
>> [correcting CC recipients]
> 
> Huh, how did I manage that (rhetorical question)? Thanks
> 
>>> Ahh, now that makes sense. pktsetup calls `/sbin/modprobe pktcdvd`
>>> explicitly, the blacklist entry doesn't help for that. Without the
>>> kernel module renamed, does the 2nd DVD-RAM result in the blocking
>>> behaviour?
>>
>> Yes.
> 
> OK, that makes sense. So udev does in this order:
> 
>  - auto-load the module (which is suppressed with the backlist entry)
>  - call blkid (which blocks if the module is loaded)
>  - call pktsetup (which loads the module even in presence of the
>    blacklist entry).
> 
>>> Thanks for your report and helpful testing,
>>
>> You're welcome. This is the way how OSS should be treated (at least in
>> my opinion).
> 
> I fully agree, still this looks different in practise more often that
> not :-\
> 
> I created
> https://salsa.debian.org/kernel-team/linux/-/merge_requests/1564 now.

I tried removing pktcdvd not that long ago, but someone claimed they
used it still... I haven't worked on it in decades. The original intent
of it was to support the 32k packet writing devices. DVD-RAM doesn't
need it, it was for cd-rw devices.

IMHO it should just be killed with fire.

-- 
Jens Axboe

Re: Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]

On Sun, 2025-06-29 at 12:26 +0200, Uwe Kleine-König wrote:
> Hello Roland,
> 
> On Sun, Jun 29, 2025 at 11:46:00AM +0200, Roland Sommer wrote:
> > [correcting CC recipients]
> 
> Huh, how did I manage that (rhetorical question)? Thanks
> 
> > > Ahh, now that makes sense. pktsetup calls `/sbin/modprobe pktcdvd`
> > > explicitly, the blacklist entry doesn't help for that. Without the
> > > kernel module renamed, does the 2nd DVD-RAM result in the blocking
> > > behaviour?
> > 
> > Yes.
> 
> OK, that makes sense. So udev does in this order:
> 
>  - auto-load the module (which is suppressed with the backlist entry)
>  - call blkid (which blocks if the module is loaded)
>  - call pktsetup (which loads the module even in presence of the
>    blacklist entry).
[...]

I tested with a CD-RW, and the behaviour was slightly different:

- Nothing automtically created a pktcdvd device, so blkid initially
worked with a CD-RW inserted and the pktcdvd modules loaded.
- After running pktsetup to create the block device /dev/pktcdvd/0,
blkid and any other program attempting to open that device hung.

My conslusion is that pktcdvd is eqaully broken for CD-RWs.

Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM

[Jens Axboe]

On 7/2/25 5:08 PM, Ben Hutchings wrote:
> On Sun, 2025-06-29 at 12:26 +0200, Uwe Kleine-König wrote:
>> Hello Roland,
>>
>> On Sun, Jun 29, 2025 at 11:46:00AM +0200, Roland Sommer wrote:
>>> [correcting CC recipients]
>>
>> Huh, how did I manage that (rhetorical question)? Thanks
>>
>>>> Ahh, now that makes sense. pktsetup calls `/sbin/modprobe pktcdvd`
>>>> explicitly, the blacklist entry doesn't help for that. Without the
>>>> kernel module renamed, does the 2nd DVD-RAM result in the blocking
>>>> behaviour?
>>>
>>> Yes.
>>
>> OK, that makes sense. So udev does in this order:
>>
>>  - auto-load the module (which is suppressed with the backlist entry)
>>  - call blkid (which blocks if the module is loaded)
>>  - call pktsetup (which loads the module even in presence of the
>>    blacklist entry).
> [...]
> 
> I tested with a CD-RW, and the behaviour was slightly different:
> 
> - Nothing automtically created a pktcdvd device, so blkid initially
> worked with a CD-RW inserted and the pktcdvd modules loaded.
> - After running pktsetup to create the block device /dev/pktcdvd/0,
> blkid and any other program attempting to open that device hung.
> 
> My conslusion is that pktcdvd is eqaully broken for CD-RWs.

Not surprising. Maybe we should take another stab at killing it
from the kernel.

-- 
Jens Axboe

Re: Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

Hello,

On Wed, Jul 02, 2025 at 05:13:45PM -0600, Jens Axboe wrote:
> On 7/2/25 5:08 PM, Ben Hutchings wrote:
> > My conslusion is that pktcdvd is eqaully broken for CD-RWs.
> 
> Not surprising. Maybe we should take another stab at killing it
> from the kernel.

Sounds reasonable. With Ben's and Roland's user experience it seems
there can be noone left who has a benefit from that module.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM

[Christoph Hellwig]

On Wed, Jul 02, 2025 at 05:13:45PM -0600, Jens Axboe wrote:
> > My conslusion is that pktcdvd is eqaully broken for CD-RWs.
> 
> Not surprising. Maybe we should take another stab at killing it
> from the kernel.

Yes, please.  I don't mind having this support, but it needs an
active maintainer.  And even if it was actively maintained it'd
probably do better by being integrated into sr and the generic
cdrom layer than this stacked design.

Re: Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM

[Andy Shevchenko]

On Wed, Jul 02, 2025 at 05:13:45PM -0600, Jens Axboe wrote:
> On 7/2/25 5:08 PM, Ben Hutchings wrote:
> > On Sun, 2025-06-29 at 12:26 +0200, Uwe Kleine-König wrote:
> >> On Sun, Jun 29, 2025 at 11:46:00AM +0200, Roland Sommer wrote:
> >>
> >> Huh, how did I manage that (rhetorical question)? Thanks
> >>
> >>>> Ahh, now that makes sense. pktsetup calls `/sbin/modprobe pktcdvd`
> >>>> explicitly, the blacklist entry doesn't help for that. Without the
> >>>> kernel module renamed, does the 2nd DVD-RAM result in the blocking
> >>>> behaviour?
> >>>
> >>> Yes.
> >>
> >> OK, that makes sense. So udev does in this order:
> >>
> >>  - auto-load the module (which is suppressed with the backlist entry)
> >>  - call blkid (which blocks if the module is loaded)
> >>  - call pktsetup (which loads the module even in presence of the
> >>    blacklist entry).
> > [...]
> > 
> > I tested with a CD-RW, and the behaviour was slightly different:
> > 
> > - Nothing automtically created a pktcdvd device, so blkid initially
> > worked with a CD-RW inserted and the pktcdvd modules loaded.
> > - After running pktsetup to create the block device /dev/pktcdvd/0,
> > blkid and any other program attempting to open that device hung.
> > 
> > My conslusion is that pktcdvd is eqaully broken for CD-RWs.
> 
> Not surprising. Maybe we should take another stab at killing it
> from the kernel.

In the commit 4b83e99ee709 ("Revert "pktcdvd: remove driver."") you wrote
that we would wait for better user space solution is developed. Any news there?

Just asking (I'm in favour to kill the old fart) as you haven't mentioned that
in a new attempt.

-- 
With Best Regards,
Andy Shevchenko

Re: Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM

[Jens Axboe]

On 7/8/25 5:35 AM, Andy Shevchenko wrote:
> On Wed, Jul 02, 2025 at 05:13:45PM -0600, Jens Axboe wrote:
>> On 7/2/25 5:08 PM, Ben Hutchings wrote:
>>> On Sun, 2025-06-29 at 12:26 +0200, Uwe Kleine-K?nig wrote:
>>>> On Sun, Jun 29, 2025 at 11:46:00AM +0200, Roland Sommer wrote:
>>>>
>>>> Huh, how did I manage that (rhetorical question)? Thanks
>>>>
>>>>>> Ahh, now that makes sense. pktsetup calls `/sbin/modprobe pktcdvd`
>>>>>> explicitly, the blacklist entry doesn't help for that. Without the
>>>>>> kernel module renamed, does the 2nd DVD-RAM result in the blocking
>>>>>> behaviour?
>>>>>
>>>>> Yes.
>>>>
>>>> OK, that makes sense. So udev does in this order:
>>>>
>>>>  - auto-load the module (which is suppressed with the backlist entry)
>>>>  - call blkid (which blocks if the module is loaded)
>>>>  - call pktsetup (which loads the module even in presence of the
>>>>    blacklist entry).
>>> [...]
>>>
>>> I tested with a CD-RW, and the behaviour was slightly different:
>>>
>>> - Nothing automtically created a pktcdvd device, so blkid initially
>>> worked with a CD-RW inserted and the pktcdvd modules loaded.
>>> - After running pktsetup to create the block device /dev/pktcdvd/0,
>>> blkid and any other program attempting to open that device hung.
>>>
>>> My conslusion is that pktcdvd is eqaully broken for CD-RWs.
>>
>> Not surprising. Maybe we should take another stab at killing it
>> from the kernel.
> 
> In the commit 4b83e99ee709 ("Revert "pktcdvd: remove driver."") you
> wrote that we would wait for better user space solution is developed.
> Any news there?
> 
> Just asking (I'm in favour to kill the old fart) as you haven't
> mentioned that in a new attempt.

No work has been done there, to my knowledge. But as the current driver
is totally broken and people aren't even complaining about that (outside
of running into that for unrelated reasons), I don't think there's any
reason for keeping the driver in-tree.

-- 
Jens Axboe

Re: Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM

[Andy Shevchenko]

On Tue, Jul 08, 2025 at 09:32:19AM -0600, Jens Axboe wrote:
> On 7/8/25 5:35 AM, Andy Shevchenko wrote:
> > On Wed, Jul 02, 2025 at 05:13:45PM -0600, Jens Axboe wrote:
> >> On 7/2/25 5:08 PM, Ben Hutchings wrote:
> >>> On Sun, 2025-06-29 at 12:26 +0200, Uwe Kleine-K?nig wrote:
> >>>> On Sun, Jun 29, 2025 at 11:46:00AM +0200, Roland Sommer wrote:
> >>>>
> >>>> Huh, how did I manage that (rhetorical question)? Thanks
> >>>>
> >>>>>> Ahh, now that makes sense. pktsetup calls `/sbin/modprobe pktcdvd`
> >>>>>> explicitly, the blacklist entry doesn't help for that. Without the
> >>>>>> kernel module renamed, does the 2nd DVD-RAM result in the blocking
> >>>>>> behaviour?
> >>>>>
> >>>>> Yes.
> >>>>
> >>>> OK, that makes sense. So udev does in this order:
> >>>>
> >>>>  - auto-load the module (which is suppressed with the backlist entry)
> >>>>  - call blkid (which blocks if the module is loaded)
> >>>>  - call pktsetup (which loads the module even in presence of the
> >>>>    blacklist entry).
> >>> [...]
> >>>
> >>> I tested with a CD-RW, and the behaviour was slightly different:
> >>>
> >>> - Nothing automtically created a pktcdvd device, so blkid initially
> >>> worked with a CD-RW inserted and the pktcdvd modules loaded.
> >>> - After running pktsetup to create the block device /dev/pktcdvd/0,
> >>> blkid and any other program attempting to open that device hung.
> >>>
> >>> My conslusion is that pktcdvd is eqaully broken for CD-RWs.
> >>
> >> Not surprising. Maybe we should take another stab at killing it
> >> from the kernel.
> > 
> > In the commit 4b83e99ee709 ("Revert "pktcdvd: remove driver."") you
> > wrote that we would wait for better user space solution is developed.
> > Any news there?
> > 
> > Just asking (I'm in favour to kill the old fart) as you haven't
> > mentioned that in a new attempt.
> 
> No work has been done there, to my knowledge. But as the current driver
> is totally broken and people aren't even complaining about that (outside
> of running into that for unrelated reasons), I don't think there's any
> reason for keeping the driver in-tree.

Sure, thanks for clarifications!

-- 
With Best Regards,
Andy Shevchenko