Hi All,
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:
| ^~~~~~~~~~~~~~~~~~~
kernel/bpf/task_iter.c:917:14: note: each undeclared identifier is reported only once for each function it appears in
kernel/bpf/task_iter.c:917:36: error: 'CSS_TASK_ITER_THREADED' undeclared (first use in this function)
917 | case CSS_TASK_ITER_PROCS | CSS_TASK_ITER_THREADED:
| ^~~~~~~~~~~~~~~~~~~~~~
kernel/bpf/task_iter.c:925:60: error: invalid application of 'sizeof' to incomplete type 'struct css_task_iter'
925 | kit->css_it = bpf_mem_alloc(&bpf_global_ma, sizeof(struct css_task_iter));
| ^~~~~~
kernel/bpf/task_iter.c:928:9: error: implicit declaration of function 'css_task_iter_start'; did you mean 'task_seq_start'? [-Werror=implicit-function-declaration]
928 | css_task_iter_start(css, flags, kit->css_it);
| ^~~~~~~~~~~~~~~~~~~
| task_seq_start
kernel/bpf/task_iter.c: In function 'bpf_iter_css_task_next':
kernel/bpf/task_iter.c:938:16: error: implicit declaration of function 'css_task_iter_next'; did you mean 'class_dev_iter_next'? [-Werror=implicit-function-declaration]
938 | return css_task_iter_next(kit->css_it);
| ^~~~~~~~~~~~~~~~~~
| class_dev_iter_next
kernel/bpf/task_iter.c:938:16: warning: returning 'int' from a function with return type 'struct task_struct *' makes pointer from integer without a cast [-Wint-conversion]
938 | return css_task_iter_next(kit->css_it);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kernel/bpf/task_iter.c: In function 'bpf_iter_css_task_destroy':
kernel/bpf/task_iter.c:947:9: error: implicit declaration of function 'css_task_iter_end' [-Werror=implicit-function-declaration]
947 | css_task_iter_end(kit->css_it);
| ^~~~~~~~~~~~~~~~~
git bisect pointed to 9c66dc94b62a ("bpf: Introduce css_task open-coded iterator kfuncs")
I will be happy to test any patch or provide any extra log if needed.
#regzbot introduced: 9c66dc94b62aef23300f05f63404afb8990920b4
--
Regards
Sudip
Hello,
在 2023/11/2 16:50, Sudip Mukherjee (Codethink) 写道:
> Hi All,
>
> 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:
> | ^~~~~~~~~~~~~~~~~~~
> kernel/bpf/task_iter.c:917:14: note: each undeclared identifier is reported only once for each function it appears in
> kernel/bpf/task_iter.c:917:36: error: 'CSS_TASK_ITER_THREADED' undeclared (first use in this function)
> 917 | case CSS_TASK_ITER_PROCS | CSS_TASK_ITER_THREADED:
> | ^~~~~~~~~~~~~~~~~~~~~~
> kernel/bpf/task_iter.c:925:60: error: invalid application of 'sizeof' to incomplete type 'struct css_task_iter'
> 925 | kit->css_it = bpf_mem_alloc(&bpf_global_ma, sizeof(struct css_task_iter));
> | ^~~~~~
> kernel/bpf/task_iter.c:928:9: error: implicit declaration of function 'css_task_iter_start'; did you mean 'task_seq_start'? [-Werror=implicit-function-declaration]
> 928 | css_task_iter_start(css, flags, kit->css_it);
> | ^~~~~~~~~~~~~~~~~~~
> | task_seq_start
> kernel/bpf/task_iter.c: In function 'bpf_iter_css_task_next':
> kernel/bpf/task_iter.c:938:16: error: implicit declaration of function 'css_task_iter_next'; did you mean 'class_dev_iter_next'? [-Werror=implicit-function-declaration]
> 938 | return css_task_iter_next(kit->css_it);
> | ^~~~~~~~~~~~~~~~~~
> | class_dev_iter_next
> kernel/bpf/task_iter.c:938:16: warning: returning 'int' from a function with return type 'struct task_struct *' makes pointer from integer without a cast [-Wint-conversion]
> 938 | return css_task_iter_next(kit->css_it);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> kernel/bpf/task_iter.c: In function 'bpf_iter_css_task_destroy':
> kernel/bpf/task_iter.c:947:9: error: implicit declaration of function 'css_task_iter_end' [-Werror=implicit-function-declaration]
> 947 | css_task_iter_end(kit->css_it);
> | ^~~~~~~~~~~~~~~~~
>
> git bisect pointed to 9c66dc94b62a ("bpf: Introduce css_task open-coded iterator kfuncs")
>
> I will be happy to test any patch or provide any extra log if needed.
>
> #regzbot introduced: 9c66dc94b62aef23300f05f63404afb8990920b4
>
Thanks for the report! This issue has been solved by Jiri.[1]
[1]:https://lore.kernel.org/all/169890482505.9002.10852784674164703819.git-patchwork-notify@kernel.org/
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@kernel.org/
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.
Ciao, Thorsten
#regzbot fix: bpf: fix compilation error without CGROUPS
Hi Thorsten,
On Thu, 2 Nov 2023 at 09:13, Linux regression tracking (Thorsten
Leemhuis) <[email protected]> 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@kernel.org/
>
> 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.
But like you said I will search and will not add Cc to rezbot in
cases where a fix has been submitted. Also if Linus wants then I will
not even send mails in these cases.
--
Regards
Sudip
On 02.11.23 17:04, Sudip Mukherjee wrote:
> On Thu, 2 Nov 2023 at 09:13, Linux regression tracking (Thorsten
> Leemhuis) <[email protected]> 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@kernel.org/
>>
>> 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