Re: mainline build failure due to 9c66dc94b62a ("bpf: Introduce css_task open-coded iterator kfuncs")

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 02.11.23 17:04, Sudip Mukherjee wrote:
> On Thu, 2 Nov 2023 at 09:13, Linux regression tracking (Thorsten
> Leemhuis) <regressions@xxxxxxxxxxxxx> wrote:
>> On 02.11.23 09:53, Chuyi Zhou wrote:
>>> 在 2023/11/2 16:50, Sudip Mukherjee (Codethink) 写道:
>>>> The latest mainline kernel branch fails to build mips
>>>> decstation_64_defconfig,
>>>> decstation_defconfig and decstation_r4k_defconfig with the error:
>>>>
>>>> kernel/bpf/task_iter.c: In function 'bpf_iter_css_task_new':
>>>> kernel/bpf/task_iter.c:917:14: error: 'CSS_TASK_ITER_PROCS' undeclared
>>>> (first use in this function)
>>>>    917 |         case CSS_TASK_ITER_PROCS | CSS_TASK_ITER_THREADED:
>>>>        |              ^~~~~~~~~~~~~~~~~~~
>>> [...]
>>>> git bisect pointed to 9c66dc94b62a ("bpf: Introduce css_task
>>>> open-coded iterator kfuncs")
>>>
>>> Thanks for the report! This issue has been solved by Jiri.[1]
>>>
>>> [1]:https://lore.kernel.org/all/169890482505.9002.10852784674164703819.git-patchwork-notify@xxxxxxxxxx/
>>
>> Thx, I was just about to reply something similar. :-D
>>
>> Sudip, maybe you know about this already, but in case you don't, here is
>> a quick tip that might be useful for you: in cases like this it's often
>> wise to search for earlier reports on lore using an even more
>> abbreviated commit-id followed by a wildcard (e.g. "9c66dc94*"). That at
>> least was how I found the fix quickly.
> 
> Yes, but the failure is still in the mainline. And it has happened in
> the past that the fix has been submitted and taken by the maintainer
> but was not sent to Linus.
> In the last release cycle I had to send a reminder around the time of
> -rc3 and in that case also the fix was submitted when I sent the build
> failure mail.

Yes, that can happen, I have an eye on such situations as well, but I
don't add all those cases to rezgbot, as some of them get quickly
resolved in a day or two. But you are totally free to get regzbot
involved if you want!

> But  like you said I will search and will not add Cc to rezbot in
> cases where a fix has been submitted.

No, sorry, please don't read my reply like that. Feel free to tell
regzbot about such cases. But you could do me a favor in cases that are
similar like this: when adding the issue to the tracking use "#regzbot
monitor <url>" to point to the fix and "#regzbot fix <subject>" to
mention its subject, as that makes it clear that a fix is under review
and/or incoming; and when it landed regzbot will automatically consider
the regressions resolved, too.

> Also if Linus wants then I will
> not even send mails in these cases.

That's up to Linus, but I guess he and others that got your report all
receive enough mail already; so if you ask me, for issues that are known
and handled already I'd say its best to send them just to the regression
list while making it obvious that a fix is in the works (see above); if
things are not resolved more people can be brought in later. But that's
just how I would handle it.

Ciao, Thorsten




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux