Re: Fwd: in linux 6.3.7-200.fc38.x86_64 goes vlc in time to switch tv channels to zombie-process

[Linux regression tracking (Thorsten Leemhuis)]

On 31.08.23 13:47, Hans Verkuil wrote:
> On 31/08/2023 13:00, Thorsten Leemhuis wrote:
>> On 31.08.23 12:35, Hans Verkuil wrote:
>>> On 31/08/2023 11:26, Linux regression tracking #update (Thorsten Leemhuis) wrote:
>>>> [TLDR: This mail in primarily relevant for Linux kernel regression
>>>> tracking. See link in footer if these mails annoy you.]
>>>>
>>>> On 19.06.23 02:24, Bagas Sanjaya wrote:
>>>>>
>>>>> I notice a regression report on Bugzilla [1]. Quoting from it:
>>>>> [...]
>>>>>
>>>>> #regzbot introduced: v6.3.5..v6.3.7 https://bugzilla.kernel.org/show_bug.cgi?id=217566
>>>>> #regzbot title: switching TV channel causes VLC and firmware loading hang
>>>>
>>>> #regzbot fix: 7cfab4c9dc09ca3a9d57c187894055a22bdcd
>>>> #regzbot ignore-activity
>>>>
>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>>>> --
>>>> Everything you wanna know about Linux kernel regression tracking:
>>>> https://linux-regtracking.leemhuis.info/about/#tldr
>>>> That page also explains what to do if mails like this annoy you.
>>>
>>> >From what I can gather from the bugzilla report, whatever the issue was appears
>>> to be resolved or at least improved in later kernels.
>>
>> I'm pretty (but not 100%) sure the initial report in that ticket were
>> issues caused by a backport of a patch that was reverted later:
>> https://lore.kernel.org/all/20230609082238.3671398-1-mchehab@xxxxxxxxxx/
> 
> Ah, you have a better memory than I have. That might well be the culprit.
> I didn't check for changes in the dvb core, I should have done that.
> 
> That patch was introduced in 6.3.7 and reverted in 6.3.9.
> 
> That doesn't quite match the "#regzbot introduced: v6.3.5..v6.3.7" report,
> though. I wonder if fedora backported that problematic patch to their v6.3.5
> release?

Nope, as it matches (I'd say). The reporter never bisected this and just
claimed that 6.3.5 was fine and 6.3.7 was broken (and 6.3.6 iirc was
never tested). In that case we tell regzbot that the culprit is
somewhere in that range (which is was[1]), as that's the important thing
to know in the context of the 6.3.y regression (that it also happened in
mainline is a different story).

Is this too confusing? Would it be better to handle things differently
somehow?

Ciao, Thorsten

[1] $ git rev-list v6.3.5..v6.3.7 --oneline | grep "Fix use-after-free
on race condition at dvb_frontend"
8994830135b3 media: dvb-core: Fix use-after-free on race condition at
dvb_frontend