Kernel hangs after DVB patch from July 2021 with Hauppauge WinTV dualHD

Kernel hangs after DVB patch from July 2021 with Hauppauge WinTV dualHD

[Maximilian Böhm]

Hello Paul and the other people involved,

I’m a user of a Hauppauge WinTV dualHD DVB-T2 USB card and experiencing a bug since Linux 5.15.3 of which kernel bisecting brought me to a commit by you from Juli 29: "media: em28xx: add missing em28xx_close_extension".
My problem: This TV stick doesn’t work for me after a wake up from a system standby, so I have to use the little helper tool usbreset to reset its USB connection. But if I try this after Linux 5.15.3, I get a severe kernel error in dmesg, system hangs and I’m unable to proper reboot or shutdown. I have reported this on the kernel Bugzilla, including a dmesg log: https://bugzilla.kernel.org/show_bug.cgi?id=215241

I hope you have an idea about how to stop this problem from occurring and I‘m willing to help testing a fix.
Another thinkable fix would be to directly fix this TV stick’s standby-wake-up problem but I’m not savvy enough to determine if this would be the better option than to fix this hanging issue.

Best regards

Maximilian Böhm

Re: Kernel hangs after DVB patch from July 2021 with Hauppauge WinTV dualHD

[Mauro Carvalho Chehab]

Em Sat, 18 Dec 2021 02:09:46 +0100
Maximilian Böhm <maximilian.boehm@elbmurf.de> escreveu:

> Hello Paul and the other people involved,
> 
> I’m a user of a Hauppauge WinTV dualHD DVB-T2 USB card and experiencing a bug since Linux 5.15.3 of which kernel bisecting brought me to a commit by you from Juli 29: "media: em28xx: add missing em28xx_close_extension".


So, basically this changeset: 2c98b8a3458d ("media: em28xx: add missing em28xx_close_extension")

> My problem: This TV stick doesn’t work for me after a wake up from a system standby, so I have to use the little helper tool usbreset to reset its USB connection.

What such patch should be doing is to ensure that the drivers will
do the right thing when the device is removed (or unbound).

It shouldn't have been called during suspend/resume. While this bug
should be fixed, the issue with suspend/resume callbacks also seem
to require additional work.

Now, I dunno what a "usbreset" tool would be doing, but I'm assuming
that it will be doing a unbind/bind sequence.

> But if I try this after Linux 5.15.3, I get a severe kernel error in dmesg, system hangs and I’m unable to proper reboot or shutdown. I have reported this on the kernel Bugzilla, including a dmesg log: https://bugzilla.kernel.org/show_bug.cgi?id=215241

Such patch should actually be fixing a use-after-free on disconnect.

Anyway, could you please try the enclosed patch?

> I hope you have an idea about how to stop this problem from occurring and I‘m willing to help testing a fix.
> Another thinkable fix would be to directly fix this TV stick’s standby-wake-up problem but I’m not savvy enough to determine if this would be the better option than to fix this hanging issue.

Yeah, that would be the best. Unfortunately, right now, I don't have 
any dual DVB-T em28xx-based board to test.

Thanks,
Mauro

[PATCH] media: em28xx: close exension first at dev_next

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c b/drivers/media/usb/em28xx/em28xx-cards.c
index b451ce3cb169..08f34a8aab5e 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -4148,13 +4148,12 @@ static void em28xx_usb_disconnect(struct usb_interface *intf)
 
        flush_request_modules(dev);
 
-       em28xx_close_extension(dev);
-
        if (dev->dev_next) {
                em28xx_close_extension(dev->dev_next);
                em28xx_release_resources(dev->dev_next);
        }
 
+       em28xx_close_extension(dev);
        em28xx_release_resources(dev);
 
        if (dev->dev_next) {

Re: Kernel hangs after DVB patch from July 2021 with Hauppauge WinTV dualHD

[Pavel Skripkin]

On 12/18/21 12:15, Mauro Carvalho Chehab wrote:
> Em Sat, 18 Dec 2021 02:09:46 +0100
> Maximilian Böhm <maximilian.boehm@elbmurf.de> escreveu:
> 
>> Hello Paul and the other people involved,
>> 
>> I’m a user of a Hauppauge WinTV dualHD DVB-T2 USB card and experiencing a bug since Linux 5.15.3 of which kernel bisecting brought me to a commit by you from Juli 29: "media: em28xx: add missing em28xx_close_extension".
> 
> 
> So, basically this changeset: 2c98b8a3458d ("media: em28xx: add missing em28xx_close_extension")
> 
>> My problem: This TV stick doesn’t work for me after a wake up from a system standby, so I have to use the little helper tool usbreset to reset its USB connection.
> 
> What such patch should be doing is to ensure that the drivers will
> do the right thing when the device is removed (or unbound).
> 
> It shouldn't have been called during suspend/resume. While this bug
> should be fixed, the issue with suspend/resume callbacks also seem
> to require additional work.
> 
> Now, I dunno what a "usbreset" tool would be doing, but I'm assuming
> that it will be doing a unbind/bind sequence.
> 

First of all I want to apologize for introducing this bug. I don't have 
any em28xx devices and I've only tested with syzbot reproducer.

I can't say much about task hung bug, because I am not an expert in 
em28xx driver, but I have an idea about NULL deref (which is in attached 
dmesg on bugzilla page)

> [  108.755526] BUG: kernel NULL pointer dereference, address: 0000000000000000
> [  108.755529] #PF: supervisor read access in kernel mode
> [  108.755530] #PF: error_code(0x0000) - not-present page
> [  108.755532] PGD 0 P4D 0  
> [  108.755534] Oops: 0000 [#1] PREEMPT SMP NOPTI
> [  108.755535] CPU: 12 PID: 28104 Comm: usbreset Not tainted 5.16.0-rc3-1-mainline #1 5300773575872a1d8fb5e17c51f4b15320e5794c
> [  108.755538] Hardware name: System manufacturer System Product Name/ROG STRIX X570-E GAMING, BIOS 1407 02/24/2020
> [  108.755539] RIP: 0010:__list_del_entry_valid+0x25/0xc0
> [  108.755545] RSP: 0018:ffffb26a8b67bc70 EFLAGS: 00010217
> [  108.755547] RAX: dead000000000122 RBX: ffffffffc11ea000 RCX: 0000000000000000
> [  108.755548] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff92c9d82081e8
> [  108.755549] RBP: ffff92c9d8208000 R08: 0000000000000000 R09: 0000000000000000
> [  108.755550] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffc11ea0d0
> [  108.755551] R13: ffff92c9d50ea400 R14: ffff92c9d50ea430 R15: ffff92c9d50ea400
> [  108.755552] FS:  00007f9ce9bd4580(0000) GS:ffff92d0bed00000(0000) knlGS:0000000000000000
> [  108.755553] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [  108.755555] CR2: 0000000000000000 CR3: 00000003cc740000 CR4: 0000000000350ee0
> [  108.755556] Call Trace:
> [  108.755558]  <TASK>
> [  108.755561]  em28xx_close_extension+0x64/0xb0 [em28xx e547aa2f945c8b78712225f6e5e1ca6a1015473f]
> [  108.755569]  em28xx_usb_disconnect.cold+0x82/0xbb [em28xx e547aa2f945c8b78712225f6e5e1ca6a1015473f]
> [  108.755574]  usb_unbind_interface+0x87/0x280


Looks like missing INIT_LIST_HEAD() somewhere, because all devices are 
kzalloced.

Something like this may work

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
b/drivers/media/usb/em28xx/em28xx-cards.c
index b207f34af5c6..c303a95e845a 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -3936,6 +3936,7 @@ static int em28xx_usb_probe(struct usb_interface 
*intf,
  	dev->is_audio_only = has_vendor_audio && !(has_video || has_dvb);
  	dev->has_video = has_video;
  	dev->ifnum = ifnum;
+	INIT_LIST_HEAD(&dev->devlist);

  	dev->ts = PRIMARY_TS;
  	snprintf(dev->name, 28, "em28xx");




With regards,
Pavel Skripkin

Re: Kernel hangs after DVB patch from July 2021 with Hauppauge WinTV dualHD

[Robert Schlabbach]

> Such patch should actually be fixing a use-after-free on disconnect.

I wonder if it's the right thing to do, though, because if you look into the em28xx_close_extension() function in em28xx-core.c:

		if (ops->fini) {
			if (dev->dev_next)
				ops->fini(dev->dev_next);
			ops->fini(dev);
		}

So doing this in em28xx_cards.c:

	em28xx_close_extension(dev);

	if (dev->dev_next) {
		em28xx_close_extension(dev->dev_next);
		em28xx_release_resources(dev->dev_next);
	}

will end up calling ops->fini() twice on dev->dev_next, no matter in which order you put the calls.

So it looks prone to double-free, but at least em28xx_dvb_fini() in em28xx_dvb.c guards against that by NULLing the dev->dvb pointer after free and checking the pointer at entry.

Still, there are redundant calls here. I think a decision should be made whether dev->dev_next is taken care of in em28xx-core.c or in em28xx-cards.c, and the code then be made consistent accordingly.

Best Regards,
-Robert Schlabbach

Re: Kernel hangs after DVB patch from July 2021 with Hauppauge WinTV dualHD

[Pavel Skripkin]

On 12/18/21 23:33, Robert Schlabbach wrote:
>> Such patch should actually be fixing a use-after-free on disconnect.
> 
> I wonder if it's the right thing to do, though, because if you look into the em28xx_close_extension() function in em28xx-core.c:
> 
> 		if (ops->fini) {
> 			if (dev->dev_next)
> 				ops->fini(dev->dev_next);
> 			ops->fini(dev);
> 		}
> 
> So doing this in em28xx_cards.c:
> 
> 	em28xx_close_extension(dev);
> 
> 	if (dev->dev_next) {
> 		em28xx_close_extension(dev->dev_next);
> 		em28xx_release_resources(dev->dev_next);
> 	}
> 
> will end up calling ops->fini() twice on dev->dev_next, no matter in which order you put the calls.
> 

I don't see any problem in calling ->fini() twice. I see only 4 ->fini() 
variants and of them have guards against double free.

I've checked out if there possible kref unbalance, but ->init() is also 
called 2 times: em28xx_register_extension() and em28xx_init_extension().


> So it looks prone to double-free, but at least em28xx_dvb_fini() in em28xx_dvb.c guards against that by NULLing the dev->dvb pointer after free and checking the pointer at entry.
> 
> Still, there are redundant calls here. I think a decision should be made whether dev->dev_next is taken care of in em28xx-core.c or in em28xx-cards.c, and the code then be made consistent accordingly.
> 

Agree. Some kind of refactoring should be done :)


With regards,
Pavel Skripkin

Re: Kernel hangs after DVB patch from July 2021 with Hauppauge WinTV dualHD

[Maximilian Böhm]

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

Thanks Pavel (not Paul, I‘m sorry!),

we might be on the right track here. This patch does still trigger a kernel tracing event with usbreset after a resume from standby (and usbreset is hanging for about 2 mins), but afterwards the system is still running fine, the DVB card works again and I can reboot the machine without hangs. I’ve tried this with two reboots and attached a dmesg log.
But this only works one time, a second try with usbreset in the same uptame seems to trigger the old total block, the adapter doesn’t get alive again and a proper reboot is impossible.

Best regards
Maximilian Böhm

Am 18.12.21 um 15:23 schrieb Pavel Skripkin:
> On 12/18/21 12:15, Mauro Carvalho Chehab wrote:
>> Em Sat, 18 Dec 2021 02:09:46 +0100
>> Maximilian Böhm <maximilian.boehm@elbmurf.de> escreveu:
>>
>>> Hello Paul and the other people involved,
>>>
>>> I’m a user of a Hauppauge WinTV dualHD DVB-T2 USB card and experiencing a bug since Linux 5.15.3 of which kernel bisecting brought me to a commit by you from Juli 29: "media: em28xx: add missing em28xx_close_extension".
>>
>> So, basically this changeset: 2c98b8a3458d ("media: em28xx: add missing em28xx_close_extension")
>>
>>> My problem: This TV stick doesn’t work for me after a wake up from a system standby, so I have to use the little helper tool usbreset to reset its USB connection.
>> What such patch should be doing is to ensure that the drivers will
>> do the right thing when the device is removed (or unbound).
>>
>> It shouldn't have been called during suspend/resume. While this bug
>> should be fixed, the issue with suspend/resume callbacks also seem
>> to require additional work.
>>
>> Now, I dunno what a "usbreset" tool would be doing, but I'm assuming
>> that it will be doing a unbind/bind sequence.
>>
> First of all I want to apologize for introducing this bug. I don't have
> any em28xx devices and I've only tested with syzbot reproducer.
>
> I can't say much about task hung bug, because I am not an expert in
> em28xx driver, but I have an idea about NULL deref (which is in attached
> dmesg on bugzilla page)
>
>> [  108.755526] BUG: kernel NULL pointer dereference, address: 0000000000000000
>> [  108.755529] #PF: supervisor read access in kernel mode
>> [  108.755530] #PF: error_code(0x0000) - not-present page
>> [  108.755532] PGD 0 P4D 0
>> [  108.755534] Oops: 0000 [#1] PREEMPT SMP NOPTI
>> [  108.755535] CPU: 12 PID: 28104 Comm: usbreset Not tainted 5.16.0-rc3-1-mainline #1 5300773575872a1d8fb5e17c51f4b15320e5794c
>> [  108.755538] Hardware name: System manufacturer System Product Name/ROG STRIX X570-E GAMING, BIOS 1407 02/24/2020
>> [  108.755539] RIP: 0010:__list_del_entry_valid+0x25/0xc0
>> [  108.755545] RSP: 0018:ffffb26a8b67bc70 EFLAGS: 00010217
>> [  108.755547] RAX: dead000000000122 RBX: ffffffffc11ea000 RCX: 0000000000000000
>> [  108.755548] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff92c9d82081e8
>> [  108.755549] RBP: ffff92c9d8208000 R08: 0000000000000000 R09: 0000000000000000
>> [  108.755550] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffc11ea0d0
>> [  108.755551] R13: ffff92c9d50ea400 R14: ffff92c9d50ea430 R15: ffff92c9d50ea400
>> [  108.755552] FS:  00007f9ce9bd4580(0000) GS:ffff92d0bed00000(0000) knlGS:0000000000000000
>> [  108.755553] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [  108.755555] CR2: 0000000000000000 CR3: 00000003cc740000 CR4: 0000000000350ee0
>> [  108.755556] Call Trace:
>> [  108.755558]  <TASK>
>> [  108.755561]  em28xx_close_extension+0x64/0xb0 [em28xx e547aa2f945c8b78712225f6e5e1ca6a1015473f]
>> [  108.755569]  em28xx_usb_disconnect.cold+0x82/0xbb [em28xx e547aa2f945c8b78712225f6e5e1ca6a1015473f]
>> [  108.755574]  usb_unbind_interface+0x87/0x280
>
> Looks like missing INIT_LIST_HEAD() somewhere, because all devices are
> kzalloced.
>
> Something like this may work
>
> diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
> b/drivers/media/usb/em28xx/em28xx-cards.c
> index b207f34af5c6..c303a95e845a 100644
> --- a/drivers/media/usb/em28xx/em28xx-cards.c
> +++ b/drivers/media/usb/em28xx/em28xx-cards.c
> @@ -3936,6 +3936,7 @@ static int em28xx_usb_probe(struct usb_interface
> *intf,
>    	dev->is_audio_only = has_vendor_audio && !(has_video || has_dvb);
>    	dev->has_video = has_video;
>    	dev->ifnum = ifnum;
> +	INIT_LIST_HEAD(&dev->devlist);
>
>    	dev->ts = PRIMARY_TS;
>    	snprintf(dev->name, 28, "em28xx");
>
>
>
>
> With regards,
> Pavel Skripkin

[-- Attachment #2: dmesg.log --]
[-- Type: text/x-log, Size: 12604 bytes --]

[   48.714086] em28xx 3-6:1.0: Disconnecting em28xx #1
[   48.714091] em28xx 3-6:1.0: Disconnecting em28xx
[   48.714094] em28xx 3-6:1.0: Closing DVB extension
[   48.714727] em28xx 3-6:1.0: Closing DVB extension

$ sudo /usr/bin/usbreset /dev/bus/usb/003/004

[  245.359654] INFO: task usbreset:6276 blocked for more than 124 seconds.
[  245.359657]       Not tainted 5.15.2-1-git-00372-g2899243f272f-dirty #15
[  245.359658] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  245.359659] task:usbreset        state:D stack:    0 pid: 6276 ppid:  6264 flags:0x00004000
[  245.359662] Call Trace:
[  245.359663]  <TASK>
[  245.359666]  __schedule+0x331/0x1540
[  245.359671]  ? dvb_unregister_device+0x1c/0x30 [dvb_core 15d9351e0e083271bc0a59b86ef1b0878266ca75]
[  245.359678]  ? dvb_net_ts_callback+0x42/0x50 [dvb_core 15d9351e0e083271bc0a59b86ef1b0878266ca75]
[  245.359686]  schedule+0x5d/0xd0
[  245.359687]  dvb_dmxdev_release+0x101/0x1a0 [dvb_core 15d9351e0e083271bc0a59b86ef1b0878266ca75]
[  245.359694]  ? do_wait_intr_irq+0xb0/0xb0
[  245.359698]  em28xx_dvb_fini.cold+0xf5/0x1ad [em28xx_dvb ba7eab8f286c229b453c3fdf88d20fdfca469b4b]
[  245.359701]  em28xx_close_extension+0x49/0xb0 [em28xx 8fe644becc0cde0cc81250fd6ae4d56311d50962]
[  245.359706]  em28xx_usb_disconnect.cold+0x71/0xbb [em28xx 8fe644becc0cde0cc81250fd6ae4d56311d50962]
[  245.359711]  usb_unbind_interface+0x87/0x280
[  245.359713]  ? kernfs_find_ns+0x35/0xe0
[  245.359716]  __device_release_driver+0x232/0x240
[  245.359719]  device_release_driver+0x24/0x30
[  245.359721]  usb_forced_unbind_intf+0x75/0xb0
[  245.359723]  usb_reset_device+0xc9/0x250
[  245.359725]  usbdev_ioctl+0xac3/0x1370
[  245.359728]  ? ksys_write+0x67/0xf0
[  245.359730]  ? syscall_exit_to_user_mode+0x23/0x50
[  245.359732]  ? do_syscall_64+0x69/0x90
[  245.359734]  __x64_sys_ioctl+0x8b/0xd0
[  245.359737]  do_syscall_64+0x59/0x90
[  245.359739]  ? exc_page_fault+0x72/0x180
[  245.359740]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[  245.359743] RIP: 0033:0x7fc75d04359b
[  245.359744] RSP: 002b:00007ffe0e41dc88 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
[  245.359746] RAX: ffffffffffffffda RBX: 0000556dd748c290 RCX: 00007fc75d04359b
[  245.359747] RDX: 0000000000000000 RSI: 0000000000005514 RDI: 0000000000000003
[  245.359748] RBP: 00007ffe0e41dcb0 R08: 0000000000000000 R09: 00007fc75d0d34e0
[  245.359749] R10: 00007fc75cf5df78 R11: 0000000000000206 R12: 0000556dd748c0a0
[  245.359749] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[  245.359751]  </TASK>
[  368.248457] INFO: task usbreset:6276 blocked for more than 247 seconds.
[  368.248461]       Not tainted 5.15.2-1-git-00372-g2899243f272f-dirty #15
[  368.248462] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  368.248463] task:usbreset        state:D stack:    0 pid: 6276 ppid:  6264 flags:0x00004000
[  368.248466] Call Trace:
[  368.248468]  <TASK>
[  368.248471]  __schedule+0x331/0x1540
[  368.248477]  ? dvb_unregister_device+0x1c/0x30 [dvb_core 15d9351e0e083271bc0a59b86ef1b0878266ca75]
[  368.248485]  ? dvb_net_ts_callback+0x42/0x50 [dvb_core 15d9351e0e083271bc0a59b86ef1b0878266ca75]
[  368.248493]  schedule+0x5d/0xd0
[  368.248494]  dvb_dmxdev_release+0x101/0x1a0 [dvb_core 15d9351e0e083271bc0a59b86ef1b0878266ca75]
[  368.248501]  ? do_wait_intr_irq+0xb0/0xb0
[  368.248505]  em28xx_dvb_fini.cold+0xf5/0x1ad [em28xx_dvb ba7eab8f286c229b453c3fdf88d20fdfca469b4b]
[  368.248509]  em28xx_close_extension+0x49/0xb0 [em28xx 8fe644becc0cde0cc81250fd6ae4d56311d50962]
[  368.248514]  em28xx_usb_disconnect.cold+0x71/0xbb [em28xx 8fe644becc0cde0cc81250fd6ae4d56311d50962]
[  368.248518]  usb_unbind_interface+0x87/0x280
[  368.248521]  ? kernfs_find_ns+0x35/0xe0
[  368.248524]  __device_release_driver+0x232/0x240
[  368.248527]  device_release_driver+0x24/0x30
[  368.248529]  usb_forced_unbind_intf+0x75/0xb0
[  368.248530]  usb_reset_device+0xc9/0x250
[  368.248533]  usbdev_ioctl+0xac3/0x1370
[  368.248535]  ? ksys_write+0x67/0xf0
[  368.248538]  ? syscall_exit_to_user_mode+0x23/0x50
[  368.248540]  ? do_syscall_64+0x69/0x90
[  368.248542]  __x64_sys_ioctl+0x8b/0xd0
[  368.248545]  do_syscall_64+0x59/0x90
[  368.248547]  ? exc_page_fault+0x72/0x180
[  368.248548]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[  368.248550] RIP: 0033:0x7fc75d04359b
[  368.248552] RSP: 002b:00007ffe0e41dc88 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
[  368.248554] RAX: ffffffffffffffda RBX: 0000556dd748c290 RCX: 00007fc75d04359b
[  368.248555] RDX: 0000000000000000 RSI: 0000000000005514 RDI: 0000000000000003
[  368.248556] RBP: 00007ffe0e41dcb0 R08: 0000000000000000 R09: 00007fc75d0d34e0
[  368.248557] R10: 00007fc75cf5df78 R11: 0000000000000206 R12: 0000556dd748c0a0
[  368.248558] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[  368.248559]  </TASK>
[  491.128613] INFO: task usbreset:6276 blocked for more than 370 seconds.
[  491.128617]       Not tainted 5.15.2-1-git-00372-g2899243f272f-dirty #15
[  491.128618] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  491.128619] task:usbreset        state:D stack:    0 pid: 6276 ppid:  6264 flags:0x00004000
[  491.128622] Call Trace:
[  491.128623]  <TASK>
[  491.128626]  __schedule+0x331/0x1540
[  491.128632]  ? dvb_unregister_device+0x1c/0x30 [dvb_core 15d9351e0e083271bc0a59b86ef1b0878266ca75]
[  491.128640]  ? dvb_net_ts_callback+0x42/0x50 [dvb_core 15d9351e0e083271bc0a59b86ef1b0878266ca75]
[  491.128647]  schedule+0x5d/0xd0
[  491.128648]  dvb_dmxdev_release+0x101/0x1a0 [dvb_core 15d9351e0e083271bc0a59b86ef1b0878266ca75]
[  491.128655]  ? do_wait_intr_irq+0xb0/0xb0
[  491.128659]  em28xx_dvb_fini.cold+0xf5/0x1ad [em28xx_dvb ba7eab8f286c229b453c3fdf88d20fdfca469b4b]
[  491.128663]  em28xx_close_extension+0x49/0xb0 [em28xx 8fe644becc0cde0cc81250fd6ae4d56311d50962]
[  491.128668]  em28xx_usb_disconnect.cold+0x71/0xbb [em28xx 8fe644becc0cde0cc81250fd6ae4d56311d50962]
[  491.128673]  usb_unbind_interface+0x87/0x280
[  491.128675]  ? kernfs_find_ns+0x35/0xe0
[  491.128678]  __device_release_driver+0x232/0x240
[  491.128681]  device_release_driver+0x24/0x30
[  491.128683]  usb_forced_unbind_intf+0x75/0xb0
[  491.128685]  usb_reset_device+0xc9/0x250
[  491.128687]  usbdev_ioctl+0xac3/0x1370
[  491.128690]  ? ksys_write+0x67/0xf0
[  491.128692]  ? syscall_exit_to_user_mode+0x23/0x50
[  491.128693]  ? do_syscall_64+0x69/0x90
[  491.128696]  __x64_sys_ioctl+0x8b/0xd0
[  491.128698]  do_syscall_64+0x59/0x90
[  491.128700]  ? exc_page_fault+0x72/0x180
[  491.128702]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[  491.128704] RIP: 0033:0x7fc75d04359b
[  491.128706] RSP: 002b:00007ffe0e41dc88 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
[  491.128708] RAX: ffffffffffffffda RBX: 0000556dd748c290 RCX: 00007fc75d04359b
[  491.128708] RDX: 0000000000000000 RSI: 0000000000005514 RDI: 0000000000000003
[  491.128709] RBP: 00007ffe0e41dcb0 R08: 0000000000000000 R09: 00007fc75d0d34e0
[  491.128710] R10: 00007fc75cf5df78 R11: 0000000000000206 R12: 0000556dd748c0a0
[  491.128711] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[  491.128712]  </TASK>
[  525.619615] em28xx 3-6:1.0: Freeing device
[  525.749282] usb 3-6: reset high-speed USB device number 4 using xhci_hcd
[  525.894041] em28xx 3-6:1.0: New device HCW dualHD @ 480 Mbps (2040:8265, interface 0, class 0)
[  525.894048] em28xx 3-6:1.0: DVB interface 0 found: bulk
[  525.949524] em28xx 3-6:1.0: chip ID is em28174
[  527.158662] em28xx 3-6:1.0: EEPROM ID = 26 00 01 00, EEPROM hash = 0xc4ecc94c
[  527.158667] em28xx 3-6:1.0: EEPROM info:
[  527.158668] em28xx 3-6:1.0:  microcode start address = 0x0004, boot configuration = 0x01
[  527.168914] em28xx 3-6:1.0:  AC97 audio (5 sample rates)
[  527.168917] em28xx 3-6:1.0:  500mA max power
[  527.168918] em28xx 3-6:1.0:  Table at offset 0x27, strings=0x0e6a, 0x1888, 0x087e
[  527.229270] em28xx 3-6:1.0: Identified as Hauppauge WinTV-dualHD DVB (card=99)
[  527.229872] tveeprom: Hauppauge model 204209, rev C2I6, serial# 14109692
[  527.229874] tveeprom: tuner model is SiLabs Si2157 (idx 186, type 4)
[  527.229875] tveeprom: TV standards PAL(B/G) NTSC(M) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xfc)
[  527.229876] tveeprom: audio processor is None (idx 0)
[  527.229877] tveeprom: has no radio, has IR receiver, has no IR transmitter
[  527.229879] em28xx 3-6:1.0: dvb set to bulk mode.
[  527.286170] em28xx 3-6:1.0: chip ID is em28174
[  528.488683] em28xx 3-6:1.0: EEPROM ID = 26 00 01 00, EEPROM hash = 0xc4ecc94c
[  528.488686] em28xx 3-6:1.0: EEPROM info:
[  528.488687] em28xx 3-6:1.0:  microcode start address = 0x0004, boot configuration = 0x01
[  528.498932] em28xx 3-6:1.0:  AC97 audio (5 sample rates)
[  528.498934] em28xx 3-6:1.0:  500mA max power
[  528.498935] em28xx 3-6:1.0:  Table at offset 0x27, strings=0x0e6a, 0x1888, 0x087e
[  528.555960] em28xx 3-6:1.0: Identified as Hauppauge WinTV-dualHD DVB (card=99)
[  528.557089] tveeprom: Hauppauge model 204209, rev C2I6, serial# 14109692
[  528.557091] tveeprom: tuner model is SiLabs Si2157 (idx 186, type 4)
[  528.557092] tveeprom: TV standards PAL(B/G) NTSC(M) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xfc)
[  528.557094] tveeprom: audio processor is None (idx 0)
[  528.557095] tveeprom: has no radio, has IR receiver, has no IR transmitter
[  528.557097] em28xx 3-6:1.0: dvb ts2 set to bulk mode.
[  528.757617] em28xx 3-6:1.0: Binding DVB extension
[  528.765833] i2c i2c-12: Added multiplexed i2c bus 15
[  528.765836] si2168 12-0064: Silicon Labs Si2168-B40 successfully identified
[  528.765837] si2168 12-0064: firmware version: B 4.0.2
[  528.769063] si2157 15-0060: Silicon Labs Si2147/2148/2157/2158 successfully attached
[  528.769072] dvbdev: DVB: registering new adapter (3-6:1.0)
[  528.769074] em28xx 3-6:1.0: DVB: registering adapter 0 frontend 0 (Silicon Labs Si2168)...
[  528.769075] dvbdev: dvb_create_media_entity: media entity 'Silicon Labs Si2168' registered.
[  528.769332] dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
[  528.769811] em28xx 3-6:1.0: DVB extension successfully initialized
[  528.769814] em28xx 3-6:1.0: Binding DVB extension
[  528.778583] i2c i2c-14: Added multiplexed i2c bus 16
[  528.778587] si2168 14-0067: Silicon Labs Si2168-B40 successfully identified
[  528.778588] si2168 14-0067: firmware version: B 4.0.2
[  528.782185] si2157 16-0063: Silicon Labs Si2147/2148/2157/2158 successfully attached
[  528.782192] dvbdev: DVB: registering new adapter (3-6:1.0)
[  528.782194] em28xx 3-6:1.0: DVB: registering adapter 1 frontend 0 (Silicon Labs Si2168)...
[  528.782196] dvbdev: dvb_create_media_entity: media entity 'Silicon Labs Si2168' registered.
[  528.782426] dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
[  528.782860] em28xx 3-6:1.0: DVB extension successfully initialized
[  528.782863] em28xx 3-6:1.0: Registering input extension
[  528.783935] Registered IR keymap rc-hauppauge
[  528.785070] rc rc0: Hauppauge WinTV-dualHD DVB as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:06:00.3/usb3/3-6/3-6:1.0/rc/rc0
[  528.785092] rc rc0: lirc_dev: driver em28xx registered at minor = 0, scancode receiver, no transmitter
[  528.785115] input: Hauppauge WinTV-dualHD DVB as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:06:00.3/usb3/3-6/3-6:1.0/rc/rc0/input24
[  528.785134] em28xx 3-6:1.0: Input extension successfully initialized
[  528.785135] em28xx 3-6:1.0: Remote control support is not available for this card.
[  528.872451] si2168 12-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw'
[  529.579701] si2168 12-0064: firmware version: B 4.0.11
[  529.595321] si2157 15-0060: found a 'Silicon Labs Si2157-A30'
[  529.625072] si2157 15-0060: firmware version: 3.0.5
[  529.638970] em28xx 3-6:1.0: DVB: adapter 0 frontend 0 frequency 0 out of range (48000000..870000000)
[  529.652594] si2168 14-0067: downloading firmware from file 'dvb-demod-si2168-b40-01.fw'
[  529.682950] si2157 15-0060: found a 'Silicon Labs Si2157-A30'
[  529.720323] si2157 15-0060: firmware version: 3.0.5
[  530.394083] si2168 14-0067: firmware version: B 4.0.11
[  530.409962] si2157 16-0063: found a 'Silicon Labs Si2157-A30'
[  530.438837] si2157 16-0063: firmware version: 3.0.5
[  530.452720] em28xx 3-6:1.0: DVB: adapter 1 frontend 0 frequency 0 out of range (48000000..870000000)
[  530.478835] si2157 16-0063: found a 'Silicon Labs Si2157-A30'
[  530.508209] si2157 16-0063: firmware version: 3.0.5
 

[-- Attachment #3: dmesg after second usbreset.log --]
[-- Type: text/x-log, Size: 5010 bytes --]

[ 1351.282178] INFO: task usbreset:531202 blocked for more than 491 seconds.
[ 1351.282181]       Tainted: G        W         5.15.2-1-git-00372-g2899243f272f-dirty #15
[ 1351.282182] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1351.282182] task:usbreset        state:D stack:    0 pid:531202 ppid:531194 flags:0x00004000
[ 1351.282185] Call Trace:
[ 1351.282187]  <TASK>
[ 1351.282189]  __schedule+0x331/0x1540
[ 1351.282195]  ? dvb_unregister_device+0x1c/0x30 [dvb_core 15d9351e0e083271bc0a59b86ef1b0878266ca75]
[ 1351.282202]  ? dvb_net_ts_callback+0x42/0x50 [dvb_core 15d9351e0e083271bc0a59b86ef1b0878266ca75]
[ 1351.282210]  schedule+0x5d/0xd0
[ 1351.282211]  dvb_dmxdev_release+0x101/0x1a0 [dvb_core 15d9351e0e083271bc0a59b86ef1b0878266ca75]
[ 1351.282218]  ? do_wait_intr_irq+0xb0/0xb0
[ 1351.282221]  em28xx_dvb_fini.cold+0xf5/0x1ad [em28xx_dvb ba7eab8f286c229b453c3fdf88d20fdfca469b4b]
[ 1351.282225]  em28xx_close_extension+0x49/0xb0 [em28xx 8fe644becc0cde0cc81250fd6ae4d56311d50962]
[ 1351.282230]  em28xx_usb_disconnect.cold+0x71/0xbb [em28xx 8fe644becc0cde0cc81250fd6ae4d56311d50962]
[ 1351.282235]  usb_unbind_interface+0x87/0x280
[ 1351.282238]  ? kernfs_find_ns+0x35/0xe0
[ 1351.282241]  __device_release_driver+0x232/0x240
[ 1351.282244]  device_release_driver+0x24/0x30
[ 1351.282246]  usb_forced_unbind_intf+0x75/0xb0
[ 1351.282247]  usb_reset_device+0xc9/0x250
[ 1351.282250]  usbdev_ioctl+0xac3/0x1370
[ 1351.282252]  ? new_sync_write+0x159/0x200
[ 1351.282255]  __x64_sys_ioctl+0x8b/0xd0
[ 1351.282257]  do_syscall_64+0x59/0x90
[ 1351.282260]  ? vfs_write+0x203/0x2a0
[ 1351.282261]  ? ksys_write+0x67/0xf0
[ 1351.282263]  ? syscall_exit_to_user_mode+0x23/0x50
[ 1351.282265]  ? do_syscall_64+0x69/0x90
[ 1351.282266]  ? do_user_addr_fault+0x20b/0x6b0
[ 1351.282269]  ? do_syscall_64+0x69/0x90
[ 1351.282271]  ? exc_page_fault+0x72/0x180
[ 1351.282272]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 1351.282274] RIP: 0033:0x7f80f597259b
[ 1351.282276] RSP: 002b:00007ffeee9548c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000010
[ 1351.282278] RAX: ffffffffffffffda RBX: 00005638a2368290 RCX: 00007f80f597259b
[ 1351.282279] RDX: 0000000000000000 RSI: 0000000000005514 RDI: 0000000000000003
[ 1351.282280] RBP: 00007ffeee9548f0 R08: 0000000000000000 R09: 00007f80f5a024e0
[ 1351.282281] R10: 00007f80f588cf78 R11: 0000000000000202 R12: 00005638a23680a0
[ 1351.282281] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 1351.282283]  </TASK>
[ 1474.162912] INFO: task usbreset:531202 blocked for more than 614 seconds.
[ 1474.162916]       Tainted: G        W         5.15.2-1-git-00372-g2899243f272f-dirty #15
[ 1474.162917] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1474.162918] task:usbreset        state:D stack:    0 pid:531202 ppid:531194 flags:0x00004000
[ 1474.162921] Call Trace:
[ 1474.162922]  <TASK>
[ 1474.162925]  __schedule+0x331/0x1540
[ 1474.162931]  ? dvb_unregister_device+0x1c/0x30 [dvb_core 15d9351e0e083271bc0a59b86ef1b0878266ca75]
[ 1474.162939]  ? dvb_net_ts_callback+0x42/0x50 [dvb_core 15d9351e0e083271bc0a59b86ef1b0878266ca75]
[ 1474.162947]  schedule+0x5d/0xd0
[ 1474.162948]  dvb_dmxdev_release+0x101/0x1a0 [dvb_core 15d9351e0e083271bc0a59b86ef1b0878266ca75]
[ 1474.162955]  ? do_wait_intr_irq+0xb0/0xb0
[ 1474.162959]  em28xx_dvb_fini.cold+0xf5/0x1ad [em28xx_dvb ba7eab8f286c229b453c3fdf88d20fdfca469b4b]
[ 1474.162963]  em28xx_close_extension+0x49/0xb0 [em28xx 8fe644becc0cde0cc81250fd6ae4d56311d50962]
[ 1474.162968]  em28xx_usb_disconnect.cold+0x71/0xbb [em28xx 8fe644becc0cde0cc81250fd6ae4d56311d50962]
[ 1474.162973]  usb_unbind_interface+0x87/0x280
[ 1474.162975]  ? kernfs_find_ns+0x35/0xe0
[ 1474.162979]  __device_release_driver+0x232/0x240
[ 1474.162982]  device_release_driver+0x24/0x30
[ 1474.162984]  usb_forced_unbind_intf+0x75/0xb0
[ 1474.162985]  usb_reset_device+0xc9/0x250
[ 1474.162988]  usbdev_ioctl+0xac3/0x1370
[ 1474.162991]  ? new_sync_write+0x159/0x200
[ 1474.162993]  __x64_sys_ioctl+0x8b/0xd0
[ 1474.162996]  do_syscall_64+0x59/0x90
[ 1474.162998]  ? vfs_write+0x203/0x2a0
[ 1474.163000]  ? ksys_write+0x67/0xf0
[ 1474.163001]  ? syscall_exit_to_user_mode+0x23/0x50
[ 1474.163002]  ? do_syscall_64+0x69/0x90
[ 1474.163004]  ? do_user_addr_fault+0x20b/0x6b0
[ 1474.163007]  ? do_syscall_64+0x69/0x90
[ 1474.163009]  ? exc_page_fault+0x72/0x180
[ 1474.163010]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 1474.163012] RIP: 0033:0x7f80f597259b
[ 1474.163014] RSP: 002b:00007ffeee9548c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000010
[ 1474.163015] RAX: ffffffffffffffda RBX: 00005638a2368290 RCX: 00007f80f597259b
[ 1474.163016] RDX: 0000000000000000 RSI: 0000000000005514 RDI: 0000000000000003
[ 1474.163017] RBP: 00007ffeee9548f0 R08: 0000000000000000 R09: 00007f80f5a024e0
[ 1474.163018] R10: 00007f80f588cf78 R11: 0000000000000202 R12: 00005638a23680a0
[ 1474.163019] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 1474.163021]  </TASK>
 

Re: Kernel hangs after DVB patch from July 2021 with Hauppauge WinTV dualHD

[Maximilian Böhm]

Hi Mauro,

I’m sorry but I cannot get this patch to compile up to the end.

Best regards
Maximilian

Am 18.12.21 um 10:15 schrieb Mauro Carvalho Chehab:
> Em Sat, 18 Dec 2021 02:09:46 +0100
> Maximilian Böhm <maximilian.boehm@elbmurf.de> escreveu:
>
>> Hello Paul and the other people involved,
>>
>> I’m a user of a Hauppauge WinTV dualHD DVB-T2 USB card and experiencing a bug since Linux 5.15.3 of which kernel bisecting brought me to a commit by you from Juli 29: "media: em28xx: add missing em28xx_close_extension".
>
> So, basically this changeset: 2c98b8a3458d ("media: em28xx: add missing em28xx_close_extension")
>
>> My problem: This TV stick doesn’t work for me after a wake up from a system standby, so I have to use the little helper tool usbreset to reset its USB connection.
> What such patch should be doing is to ensure that the drivers will
> do the right thing when the device is removed (or unbound).
>
> It shouldn't have been called during suspend/resume. While this bug
> should be fixed, the issue with suspend/resume callbacks also seem
> to require additional work.
>
> Now, I dunno what a "usbreset" tool would be doing, but I'm assuming
> that it will be doing a unbind/bind sequence.
>
>> But if I try this after Linux 5.15.3, I get a severe kernel error in dmesg, system hangs and I’m unable to proper reboot or shutdown. I have reported this on the kernel Bugzilla, including a dmesg log: https://bugzilla.kernel.org/show_bug.cgi?id=215241
> Such patch should actually be fixing a use-after-free on disconnect.
>
> Anyway, could you please try the enclosed patch?
>
>> I hope you have an idea about how to stop this problem from occurring and I‘m willing to help testing a fix.
>> Another thinkable fix would be to directly fix this TV stick’s standby-wake-up problem but I’m not savvy enough to determine if this would be the better option than to fix this hanging issue.
> Yeah, that would be the best. Unfortunately, right now, I don't have
> any dual DVB-T em28xx-based board to test.
>
> Thanks,
> Mauro
>
> [PATCH] media: em28xx: close exension first at dev_next
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
>
> diff --git a/drivers/media/usb/em28xx/em28xx-cards.c b/drivers/media/usb/em28xx/em28xx-cards.c
> index b451ce3cb169..08f34a8aab5e 100644
> --- a/drivers/media/usb/em28xx/em28xx-cards.c
> +++ b/drivers/media/usb/em28xx/em28xx-cards.c
> @@ -4148,13 +4148,12 @@ static void em28xx_usb_disconnect(struct usb_interface *intf)
>   
>          flush_request_modules(dev);
>   
> -       em28xx_close_extension(dev);
> -
>          if (dev->dev_next) {
>                  em28xx_close_extension(dev->dev_next);
>                  em28xx_release_resources(dev->dev_next);
>          }
>   
> +       em28xx_close_extension(dev);
>          em28xx_release_resources(dev);
>   
>          if (dev->dev_next) {
>

Re: Kernel hangs after DVB patch from July 2021 with Hauppauge WinTV dualHD

[Pavel Skripkin]

On 12/19/21 01:50, Maximilian Böhm wrote:
> Thanks Pavel (not Paul, I‘m sorry!),
> 
> we might be on the right track here. This patch does still trigger a kernel tracing event with usbreset after a resume from standby (and usbreset is hanging for about 2 mins), but afterwards the system is still running fine, the DVB card works again and I can reboot the machine without hangs. I’ve tried this with two reboots and attached a dmesg log.
> But this only works one time, a second try with usbreset in the same uptame seems to trigger the old total block, the adapter doesn’t get alive again and a proper reboot is impossible.
> 

Hi, Maximilian!

Ok, one down :) I will look at the second one today later or tomorrow. 
It looks like missing dvb_dmxdev_release() somewhere at first glance, 
but for now I have no idea where...




With regards,
Pavel Skripkin

Re: Kernel hangs after DVB patch from July 2021 with Hauppauge WinTV dualHD

[Maximilian Böhm]

Hey Pavel,

did you have time to look into this issue further?

Regards
Maximilian Böhm

Am 20.12.21 um 15:39 schrieb Pavel Skripkin:
> On 12/19/21 01:50, Maximilian Böhm wrote:
>> Thanks Pavel (not Paul, I‘m sorry!),
>>
>> we might be on the right track here. This patch does still trigger a kernel tracing event with usbreset after a resume from standby (and usbreset is hanging for about 2 mins), but afterwards the system is still running fine, the DVB card works again and I can reboot the machine without hangs. I’ve tried this with two reboots and attached a dmesg log.
>> But this only works one time, a second try with usbreset in the same uptame seems to trigger the old total block, the adapter doesn’t get alive again and a proper reboot is impossible.
>>
> Hi, Maximilian!
>
> Ok, one down :) I will look at the second one today later or tomorrow.
> It looks like missing dvb_dmxdev_release() somewhere at first glance,
> but for now I have no idea where...
>
>
>
>
> With regards,
> Pavel Skripkin

Re: Kernel hangs after DVB patch from July 2021 with Hauppauge WinTV dualHD

[Pavel Skripkin]

On 1/4/22 20:22, Maximilian Böhm wrote:
> Hey Pavel,
> 
> did you have time to look into this issue further?
> 

Hi Maximilian,

I did give it a try, but looking at the code didn't give any results :(

It's a bit hard to debug without reproducer or real hw piece



With regards,
Pavel Skripkin

Re: Kernel hangs after DVB patch from July 2021 with Hauppauge WinTV dualHD

[Maximilian Böhm]

How can I help? I’m totally not a kernel developer but maybe you could SSH to my machine or something? Should we text in private outside the mailing list? What about reverting the kernel commit until this issue gets somehow solved?

Am 04.01.22 um 18:31 schrieb Pavel Skripkin:
> On 1/4/22 20:22, Maximilian Böhm wrote:
>> Hey Pavel,
>>
>> did you have time to look into this issue further?
>>
> Hi Maximilian,
>
> I did give it a try, but looking at the code didn't give any results :(
>
> It's a bit hard to debug without reproducer or real hw piece
>
>
>
> With regards,
> Pavel Skripkin

Re: Kernel hangs after DVB patch from July 2021 with Hauppauge WinTV dualHD

[Pavel Skripkin]

Hi Maximilian,

On 1/4/22 20:58, Maximilian Böhm wrote:
> How can I help? I’m totally not a kernel developer but maybe you could SSH to my machine or something? Should we text in private outside the mailing list? What about reverting the kernel commit until this issue gets somehow solved?
> 

I can't say what is better in this case. My patch fixed a use-after-free 
on disconnect path, but seems like it broke something else.

I am not against reverting, but I don't know what is bigger problem in 
general: UAF or usbreset tool hang. I guess, Mauro can help us here to 
decide what to do about this.

Anyway, you can revert my patch locally and use your device. I 
understand, that this approach is the best one, but anyway revert will 
come to Linus' tree in 2-3 weeks, since v5.16 will be released in couple 
of days.



With regards,
Pavel Skripkin

Re: Kernel hangs after DVB patch from July 2021 with Hauppauge WinTV dualHD

[Pavel Skripkin]

> Anyway, you can revert my patch locally and use your device. I
> understand, that this approach is the best one, but anyway revert will
				
				 ^^^^

I've missed "not". Please, don't get me wrong :) Reverting something 
locally to work with upstream device is never a good thing.



With regards,
Pavel Skripkin

Re: Kernel hangs after DVB patch from July 2021 with Hauppauge WinTV dualHD

[Maximilian Böhm]

Hey Pavel,

I would prefer reverting your use-after-free change. I’m still on Linux 5.15.2 to avoid this issue. I’m not sure if I understand your last mails correctly, did you already revert the change or did you just offer to do it? Anyway, reverting locally wouldn’t be feasible long-term.
If I could help eliminating this bug, I would gladly offer my system for a remote hacking session via ssh or Teamviewer or try other patch ideas.

Btw, found this forum thread describing the same original problem (which is forcing me to use usbreset after standby) on Windows, so this probably is a bug in the tuner hardware, not in the Linux driver: https://www.dvbviewer.tv/forum/topic/63002-hauppauge-wintv-dualhd-stick-geht-oft-nicht-nach-standby/

If I were to submit an official "device quirk" for the Linux kernel, would it be affected of your use-after-free change too? Nobody knows, I guess?

Regards
Maximilian Böhm

Am 06.01.22 um 12:57 schrieb Pavel Skripkin:
>> Anyway, you can revert my patch locally and use your device. I
>> understand, that this approach is the best one, but anyway revert will
> 				
> 				 ^^^^
>
> I've missed "not". Please, don't get me wrong :) Reverting something
> locally to work with upstream device is never a good thing.
>
>
>
> With regards,
> Pavel Skripkin

[PATCH] Revert "media: em28xx: add missing em28xx_close_extension"

[Pavel Skripkin]

This reverts commit 2c98b8a3458df03abdc6945bbef67ef91d181938.

Reverted patch causes problems with Hauppauge WinTV dualHD as Maximilian
reported [1]. Since quick solution didn't come up let's just revert it
to make this device work with upstream kernels.

Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://lore.kernel.org/all/6a72a37b-e972-187d-0322-16336e12bdc5@elbmurf.de/ [1]
Reported-by: Maximilian Böhm <maximilian.boehm@elbmurf.de>
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
---
 drivers/media/usb/em28xx/em28xx-cards.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c b/drivers/media/usb/em28xx/em28xx-cards.c
index b451ce3cb169..4a46ef50baf9 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -4150,11 +4150,8 @@ static void em28xx_usb_disconnect(struct usb_interface *intf)
 
 	em28xx_close_extension(dev);
 
-	if (dev->dev_next) {
-		em28xx_close_extension(dev->dev_next);
+	if (dev->dev_next)
 		em28xx_release_resources(dev->dev_next);
-	}
-
 	em28xx_release_resources(dev);
 
 	if (dev->dev_next) {
-- 
2.34.1

Re: Kernel hangs after DVB patch from July 2021 with Hauppauge WinTV dualHD

[Pavel Skripkin]

Hi Maximilian,

On 1/20/22 22:29, Maximilian Böhm wrote:
> Hey Pavel,
> 
> I would prefer reverting your use-after-free change. I’m still on Linux 5.15.2 to avoid this issue. I’m not sure if I understand your last mails correctly, did you already revert the change or did you just offer to do it? Anyway, reverting locally wouldn’t be feasible long-term.
> If I could help eliminating this bug, I would gladly offer my system for a remote hacking session via ssh or Teamviewer or try other patch ideas.
> 

Since I don't have enough time to look into this, I've just sent a 
revert. I've looked couple of times at the code, but unfortunately 
solution didn't come up

You should be in CC list, can you also test and reply to patch with 
Tested-by: tag, which will indicate, that revert actually works for you

Thanks

> Btw, found this forum thread describing the same original problem (which is forcing me to use usbreset after standby) on Windows, so this probably is a bug in the tuner hardware, not in the Linux driver: https://www.dvbviewer.tv/forum/topic/63002-hauppauge-wintv-dualhd-stick-geht-oft-nicht-nach-standby/
> 
> If I were to submit an official "device quirk" for the Linux kernel, would it be affected of your use-after-free change too? Nobody knows, I guess?
> 




With regards,
Pavel Skripkin

Re: [PATCH] Revert "media: em28xx: add missing em28xx_close_extension"

[Maximilian Böhm]

Tested-by: Maximilian Böhm, kernelml@elbmurf.de

Am 20.01.22 um 20:37 schrieb Pavel Skripkin:
> This reverts commit 2c98b8a3458df03abdc6945bbef67ef91d181938.
>
> Reverted patch causes problems with Hauppauge WinTV dualHD as Maximilian
> reported [1]. Since quick solution didn't come up let's just revert it
> to make this device work with upstream kernels.
>
> Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl>
> Link: https://lore.kernel.org/all/6a72a37b-e972-187d-0322-16336e12bdc5@elbmurf.de/ [1]
> Reported-by: Maximilian Böhm <maximilian.boehm@elbmurf.de>
> Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
> ---
>   drivers/media/usb/em28xx/em28xx-cards.c | 5 +----
>   1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/media/usb/em28xx/em28xx-cards.c b/drivers/media/usb/em28xx/em28xx-cards.c
> index b451ce3cb169..4a46ef50baf9 100644
> --- a/drivers/media/usb/em28xx/em28xx-cards.c
> +++ b/drivers/media/usb/em28xx/em28xx-cards.c
> @@ -4150,11 +4150,8 @@ static void em28xx_usb_disconnect(struct usb_interface *intf)
>   
>   	em28xx_close_extension(dev);
>   
> -	if (dev->dev_next) {
> -		em28xx_close_extension(dev->dev_next);
> +	if (dev->dev_next)
>   		em28xx_release_resources(dev->dev_next);
> -	}
> -
>   	em28xx_release_resources(dev);
>   
>   	if (dev->dev_next) {

Re: Kernel hangs after DVB patch from July 2021 with Hauppauge WinTV dualHD

[Hans Verkuil]

Hi Maximilian,

On 20/01/2022 20:29, Maximilian Böhm wrote:
> Hey Pavel,
> 
> I would prefer reverting your use-after-free change. I’m still on Linux 5.15.2 to avoid this issue. I’m not sure if I understand your last mails correctly, did you already revert the change or did you
> just offer to do it? Anyway, reverting locally wouldn’t be feasible long-term.
> If I could help eliminating this bug, I would gladly offer my system for a remote hacking session via ssh or Teamviewer or try other patch ideas.

I wonder if this patch:

https://patchwork.linuxtv.org/project/linux-media/patch/20220122074500.429184-1-dzm91@hust.edu.cn/

is perhaps related to this issue? Can you test if this patch solves your issue?

If not, then I'll apply Pavel's revert patch for 5.18.

Regards,

	Hans

> 
> Btw, found this forum thread describing the same original problem (which is forcing me to use usbreset after standby) on Windows, so this probably is a bug in the tuner hardware, not in the Linux
> driver: https://www.dvbviewer.tv/forum/topic/63002-hauppauge-wintv-dualhd-stick-geht-oft-nicht-nach-standby/
> 
> If I were to submit an official "device quirk" for the Linux kernel, would it be affected of your use-after-free change too? Nobody knows, I guess?
> 
> Regards
> Maximilian Böhm
> 
> Am 06.01.22 um 12:57 schrieb Pavel Skripkin:
>>> Anyway, you can revert my patch locally and use your device. I
>>> understand, that this approach is the best one, but anyway revert will
>>                
>>                  ^^^^
>>
>> I've missed "not". Please, don't get me wrong :) Reverting something
>> locally to work with upstream device is never a good thing.
>>
>>
>>
>> With regards,
>> Pavel Skripkin

Re: Kernel hangs after DVB patch from July 2021 with Hauppauge WinTV dualHD

[Maximilian Böhm]

Hi Hans,

thanks for reaching out. I’ve applied this patch on top of Linux 5.15.3 (with Pavel’s former patch) and I’m still experiencing this system hangs, effectively kernel panics after resume from standby + usbreset of my Hauppauge WinTV DualHD. So, it’s not solving my issue, but perhaps another one, I don’t know.

Regards
Maximilian

Am 17.02.22 um 12:14 schrieb Hans Verkuil:
> Hi Maximilian,
>
> On 20/01/2022 20:29, Maximilian Böhm wrote:
>> Hey Pavel,
>>
>> I would prefer reverting your use-after-free change. I’m still on Linux 5.15.2 to avoid this issue. I’m not sure if I understand your last mails correctly, did you already revert the change or did you
>> just offer to do it? Anyway, reverting locally wouldn’t be feasible long-term.
>> If I could help eliminating this bug, I would gladly offer my system for a remote hacking session via ssh or Teamviewer or try other patch ideas.
> I wonder if this patch:
>
> https://patchwork.linuxtv.org/project/linux-media/patch/20220122074500.429184-1-dzm91@hust.edu.cn/
>
> is perhaps related to this issue? Can you test if this patch solves your issue?
>
> If not, then I'll apply Pavel's revert patch for 5.18.
>
> Regards,
>
> 	Hans
>
>> Btw, found this forum thread describing the same original problem (which is forcing me to use usbreset after standby) on Windows, so this probably is a bug in the tuner hardware, not in the Linux
>> driver: https://www.dvbviewer.tv/forum/topic/63002-hauppauge-wintv-dualhd-stick-geht-oft-nicht-nach-standby/
>>
>> If I were to submit an official "device quirk" for the Linux kernel, would it be affected of your use-after-free change too? Nobody knows, I guess?
>>
>> Regards
>> Maximilian Böhm
>>
>> Am 06.01.22 um 12:57 schrieb Pavel Skripkin:
>>>> Anyway, you can revert my patch locally and use your device. I
>>>> understand, that this approach is the best one, but anyway revert will
>>>                 
>>>                   ^^^^
>>>
>>> I've missed "not". Please, don't get me wrong :) Reverting something
>>> locally to work with upstream device is never a good thing.
>>>
>>>
>>>
>>> With regards,
>>> Pavel Skripkin

Re: Kernel hangs after DVB patch from July 2021 with Hauppauge WinTV dualHD

[Hans Verkuil]

Hi Maximilian,

On 18/02/2022 01:16, Maximilian Böhm wrote:
> Hi Hans,
> 
> thanks for reaching out. I’ve applied this patch on top of Linux 5.15.3 (with Pavel’s former patch) and I’m still experiencing this system hangs, effectively kernel panics after resume from standby +
> usbreset of my Hauppauge WinTV DualHD. So, it’s not solving my issue, but perhaps another one, I don’t know.

Thank you for the quick test, it was worth a shot.

I'll take the revert patch for 5.18.

Regards,

	Hans

> 
> Regards
> Maximilian
> 
> Am 17.02.22 um 12:14 schrieb Hans Verkuil:
>> Hi Maximilian,
>>
>> On 20/01/2022 20:29, Maximilian Böhm wrote:
>>> Hey Pavel,
>>>
>>> I would prefer reverting your use-after-free change. I’m still on Linux 5.15.2 to avoid this issue. I’m not sure if I understand your last mails correctly, did you already revert the change or did you
>>> just offer to do it? Anyway, reverting locally wouldn’t be feasible long-term.
>>> If I could help eliminating this bug, I would gladly offer my system for a remote hacking session via ssh or Teamviewer or try other patch ideas.
>> I wonder if this patch:
>>
>> https://patchwork.linuxtv.org/project/linux-media/patch/20220122074500.429184-1-dzm91@hust.edu.cn/
>>
>> is perhaps related to this issue? Can you test if this patch solves your issue?
>>
>> If not, then I'll apply Pavel's revert patch for 5.18.
>>
>> Regards,
>>
>>     Hans
>>
>>> Btw, found this forum thread describing the same original problem (which is forcing me to use usbreset after standby) on Windows, so this probably is a bug in the tuner hardware, not in the Linux
>>> driver: https://www.dvbviewer.tv/forum/topic/63002-hauppauge-wintv-dualhd-stick-geht-oft-nicht-nach-standby/
>>>
>>> If I were to submit an official "device quirk" for the Linux kernel, would it be affected of your use-after-free change too? Nobody knows, I guess?
>>>
>>> Regards
>>> Maximilian Böhm
>>>
>>> Am 06.01.22 um 12:57 schrieb Pavel Skripkin:
>>>>> Anyway, you can revert my patch locally and use your device. I
>>>>> understand, that this approach is the best one, but anyway revert will
>>>>                                   ^^^^
>>>>
>>>> I've missed "not". Please, don't get me wrong :) Reverting something
>>>> locally to work with upstream device is never a good thing.
>>>>
>>>>
>>>>
>>>> With regards,
>>>> Pavel Skripkin