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

[Hans Verkuil]

On 31/08/2023 14:10, Linux regression tracking (Thorsten Leemhuis) wrote:
> 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?

Ah, I interpreted "#regzbot introduced" as "this issue was seen in these
kernels", instead of: "it was introduced in one of these kernels".

With that it matches perfectly.

Regards,

	Hans

> 
> 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