Hi all,
Changes since 20190915:
The arm64 tree acquired a conflict with the compiler-attributes tree.
The ia64 tree acquired a conflict with the dma-mapping tree.
The vfs tree acquired a conflict with the ubifds tree.
A workaround was applied for a merge issue between the drm and kbuild
trees with a patch sent by Xinpeng Liu, Austin Kim sent a similar fix.
There are further issues with this merge that still need to be resolved.
Non-merge commits (relative to Linus' tree): 11922
11682 files changed, 762897 insertions(+), 376399 deletions(-)
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a defconfig for arm64, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf.
Below is a summary of the state of the merge.
I am currently merging 310 trees (counting Linus' and 77 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
On 9/16/19 3:38 PM, Mark Brown wrote:
> Hi all,
>
> Changes since 20190915:
>
on x86_64:
when CONFIG_CGROUPS is not set:
CC kernel/sched/core.o
../kernel/sched/core.c: In function ?uclamp_update_active_tasks?:
../kernel/sched/core.c:1081:23: error: storage size of ?it? isn?t known
struct css_task_iter it;
^~
CC kernel/printk/printk_safe.o
../kernel/sched/core.c:1084:2: error: implicit declaration of function ?css_task_iter_start?; did you mean ?__sg_page_iter_start?? [-Werror=implicit-function-declaration]
css_task_iter_start(css, 0, &it);
^~~~~~~~~~~~~~~~~~~
__sg_page_iter_start
../kernel/sched/core.c:1085:14: error: implicit declaration of function ?css_task_iter_next?; did you mean ?__sg_page_iter_next?? [-Werror=implicit-function-declaration]
while ((p = css_task_iter_next(&it))) {
^~~~~~~~~~~~~~~~~~
__sg_page_iter_next
../kernel/sched/core.c:1091:2: error: implicit declaration of function ?css_task_iter_end?; did you mean ?get_task_cred?? [-Werror=implicit-function-declaration]
css_task_iter_end(&it);
^~~~~~~~~~~~~~~~~
get_task_cred
../kernel/sched/core.c:1081:23: warning: unused variable ?it? [-Wunused-variable]
struct css_task_iter it;
^~
--
~Randy
* Randy Dunlap <[email protected]> wrote:
> On 9/16/19 3:38 PM, Mark Brown wrote:
> > Hi all,
> >
> > Changes since 20190915:
> >
>
> on x86_64:
>
> when CONFIG_CGROUPS is not set:
>
> CC kernel/sched/core.o
> ../kernel/sched/core.c: In function ‘uclamp_update_active_tasks’:
> ../kernel/sched/core.c:1081:23: error: storage size of ‘it’ isn’t known
> struct css_task_iter it;
> ^~
> CC kernel/printk/printk_safe.o
> ../kernel/sched/core.c:1084:2: error: implicit declaration of function ‘css_task_iter_start’; did you mean ‘__sg_page_iter_start’? [-Werror=implicit-function-declaration]
> css_task_iter_start(css, 0, &it);
> ^~~~~~~~~~~~~~~~~~~
> __sg_page_iter_start
> ../kernel/sched/core.c:1085:14: error: implicit declaration of function ‘css_task_iter_next’; did you mean ‘__sg_page_iter_next’? [-Werror=implicit-function-declaration]
> while ((p = css_task_iter_next(&it))) {
> ^~~~~~~~~~~~~~~~~~
> __sg_page_iter_next
> ../kernel/sched/core.c:1091:2: error: implicit declaration of function ‘css_task_iter_end’; did you mean ‘get_task_cred’? [-Werror=implicit-function-declaration]
> css_task_iter_end(&it);
> ^~~~~~~~~~~~~~~~~
> get_task_cred
> ../kernel/sched/core.c:1081:23: warning: unused variable ‘it’ [-Wunused-variable]
> struct css_task_iter it;
> ^~
>
I cannot reproduce this build failue: I took Linus's latest which has all
the -next scheduler commits included (ad062195731b), and an x86-64 "make
defconfig" and a disabling of CONFIG_CGROUPS still resuls in a kernel
that builds fine.
Thanks,
Ingo
On Tue, Sep 17, 2019 at 08:52:42 +0100, Ingo Molnar wrote...
> * Randy Dunlap <[email protected]> wrote:
>
>> On 9/16/19 3:38 PM, Mark Brown wrote:
>> > Hi all,
>> >
>> > Changes since 20190915:
>> >
>>
>> on x86_64:
>>
>> when CONFIG_CGROUPS is not set:
Hi Randy,
thanks for the report.
>> CC kernel/sched/core.o
>> ../kernel/sched/core.c: In function ‘uclamp_update_active_tasks’:
>> ../kernel/sched/core.c:1081:23: error: storage size of ‘it’ isn’t known
>> struct css_task_iter it;
>> ^~
>> CC kernel/printk/printk_safe.o
>> ../kernel/sched/core.c:1084:2: error: implicit declaration of function ‘css_task_iter_start’; did you mean ‘__sg_page_iter_start’? [-Werror=implicit-function-declaration]
>> css_task_iter_start(css, 0, &it);
>> ^~~~~~~~~~~~~~~~~~~
>> __sg_page_iter_start
>> ../kernel/sched/core.c:1085:14: error: implicit declaration of function ‘css_task_iter_next’; did you mean ‘__sg_page_iter_next’? [-Werror=implicit-function-declaration]
>> while ((p = css_task_iter_next(&it))) {
>> ^~~~~~~~~~~~~~~~~~
>> __sg_page_iter_next
>> ../kernel/sched/core.c:1091:2: error: implicit declaration of function ‘css_task_iter_end’; did you mean ‘get_task_cred’? [-Werror=implicit-function-declaration]
>> css_task_iter_end(&it);
>> ^~~~~~~~~~~~~~~~~
>> get_task_cred
>> ../kernel/sched/core.c:1081:23: warning: unused variable ‘it’ [-Wunused-variable]
>> struct css_task_iter it;
>> ^~
>>
>
> I cannot reproduce this build failue: I took Linus's latest which has all
> the -next scheduler commits included (ad062195731b), and an x86-64 "make
> defconfig" and a disabling of CONFIG_CGROUPS still resuls in a kernel
> that builds fine.
Same here Ingo, I cannot reproduce on arm64 and !CONFIG_CGROUPS and
testing on tip/sched/core.
However, if you like, the following patch can make that code a
bit more "robust".
Best,
Patrick
---8<---
From 7e17b7bb08dd8dfc57e01c2a7b6875439eb47cbe Mon Sep 17 00:00:00 2001
From: Patrick Bellasi <[email protected]>
Date: Tue, 17 Sep 2019 14:12:10 +0100
Subject: [PATCH 1/1] sched/core: uclamp: Fix compile error on !CONFIG_CGROUPS
Randy reported a compiler error on x86_64 and !CONFIG_CGROUPS which is due
to uclamp_update_active_tasks() using the undefined css_task_iter().
Since uclamp_update_active_tasks() is used only when cgroup support is
enabled, fix that by properly guarding that function at compile time.
Signed-off-by: Patrick Bellasi <[email protected]>
Link: https://lore.kernel.org/lkml/[email protected]/
Fixes: commit babbe170e05 ("sched/uclamp: Update CPU's refcount on TG's clamp changes")
---
kernel/sched/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 3c7b90bcbe4e..14873ad4b34a 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1043,6 +1043,7 @@ static inline void uclamp_rq_dec(struct rq *rq, struct task_struct *p)
uclamp_rq_dec_id(rq, p, clamp_id);
}
+#ifdef CONFIG_UCLAMP_TASK_GROUP
static inline void
uclamp_update_active(struct task_struct *p, enum uclamp_id clamp_id)
{
@@ -1091,7 +1092,6 @@ uclamp_update_active_tasks(struct cgroup_subsys_state *css,
css_task_iter_end(&it);
}
-#ifdef CONFIG_UCLAMP_TASK_GROUP
static void cpu_util_update_eff(struct cgroup_subsys_state *css);
static void uclamp_update_root_tg(void)
{
--
2.22.0
---8<---
--
#include <best/regards.h>
Patrick Bellasi
On 9/17/19 6:38 AM, Patrick Bellasi wrote:
>
> On Tue, Sep 17, 2019 at 08:52:42 +0100, Ingo Molnar wrote...
>
>> * Randy Dunlap <[email protected]> wrote:
>>
>>> On 9/16/19 3:38 PM, Mark Brown wrote:
>>>> Hi all,
>>>>
>>>> Changes since 20190915:
>>>>
>>>
>>> on x86_64:
>>>
>>> when CONFIG_CGROUPS is not set:
>
> Hi Randy,
> thanks for the report.
>
>>> CC kernel/sched/core.o
>>> ../kernel/sched/core.c: In function ‘uclamp_update_active_tasks’:
>>> ../kernel/sched/core.c:1081:23: error: storage size of ‘it’ isn’t known
>>> struct css_task_iter it;
>>> ^~
>>> CC kernel/printk/printk_safe.o
>>> ../kernel/sched/core.c:1084:2: error: implicit declaration of function ‘css_task_iter_start’; did you mean ‘__sg_page_iter_start’? [-Werror=implicit-function-declaration]
>>> css_task_iter_start(css, 0, &it);
>>> ^~~~~~~~~~~~~~~~~~~
>>> __sg_page_iter_start
>>> ../kernel/sched/core.c:1085:14: error: implicit declaration of function ‘css_task_iter_next’; did you mean ‘__sg_page_iter_next’? [-Werror=implicit-function-declaration]
>>> while ((p = css_task_iter_next(&it))) {
>>> ^~~~~~~~~~~~~~~~~~
>>> __sg_page_iter_next
>>> ../kernel/sched/core.c:1091:2: error: implicit declaration of function ‘css_task_iter_end’; did you mean ‘get_task_cred’? [-Werror=implicit-function-declaration]
>>> css_task_iter_end(&it);
>>> ^~~~~~~~~~~~~~~~~
>>> get_task_cred
>>> ../kernel/sched/core.c:1081:23: warning: unused variable ‘it’ [-Wunused-variable]
>>> struct css_task_iter it;
>>> ^~
>>>
>>
>> I cannot reproduce this build failue: I took Linus's latest which has all
>> the -next scheduler commits included (ad062195731b), and an x86-64 "make
>> defconfig" and a disabling of CONFIG_CGROUPS still resuls in a kernel
>> that builds fine.
>
> Same here Ingo, I cannot reproduce on arm64 and !CONFIG_CGROUPS and
> testing on tip/sched/core.
>
> However, if you like, the following patch can make that code a
> bit more "robust".
>
> Best,
> Patrick
>
> ---8<---
> From 7e17b7bb08dd8dfc57e01c2a7b6875439eb47cbe Mon Sep 17 00:00:00 2001
> From: Patrick Bellasi <[email protected]>
> Date: Tue, 17 Sep 2019 14:12:10 +0100
> Subject: [PATCH 1/1] sched/core: uclamp: Fix compile error on !CONFIG_CGROUPS
>
> Randy reported a compiler error on x86_64 and !CONFIG_CGROUPS which is due
> to uclamp_update_active_tasks() using the undefined css_task_iter().
>
> Since uclamp_update_active_tasks() is used only when cgroup support is
> enabled, fix that by properly guarding that function at compile time.
>
> Signed-off-by: Patrick Bellasi <[email protected]>
> Link: https://lore.kernel.org/lkml/[email protected]/
> Fixes: commit babbe170e05 ("sched/uclamp: Update CPU's refcount on TG's clamp changes")
Acked-by: Randy Dunlap <[email protected]> # build-tested
Thanks.
> ---
> kernel/sched/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 3c7b90bcbe4e..14873ad4b34a 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1043,6 +1043,7 @@ static inline void uclamp_rq_dec(struct rq *rq, struct task_struct *p)
> uclamp_rq_dec_id(rq, p, clamp_id);
> }
>
> +#ifdef CONFIG_UCLAMP_TASK_GROUP
> static inline void
> uclamp_update_active(struct task_struct *p, enum uclamp_id clamp_id)
> {
> @@ -1091,7 +1092,6 @@ uclamp_update_active_tasks(struct cgroup_subsys_state *css,
> css_task_iter_end(&it);
> }
>
> -#ifdef CONFIG_UCLAMP_TASK_GROUP
> static void cpu_util_update_eff(struct cgroup_subsys_state *css);
> static void uclamp_update_root_tg(void)
> {
>
--
~Randy
* Randy Dunlap <[email protected]> wrote:
> On 9/17/19 6:38 AM, Patrick Bellasi wrote:
> >
> > On Tue, Sep 17, 2019 at 08:52:42 +0100, Ingo Molnar wrote...
> >
> >> * Randy Dunlap <[email protected]> wrote:
> >>
> >>> On 9/16/19 3:38 PM, Mark Brown wrote:
> >>>> Hi all,
> >>>>
> >>>> Changes since 20190915:
> >>>>
> >>>
> >>> on x86_64:
> >>>
> >>> when CONFIG_CGROUPS is not set:
> >
> > Hi Randy,
> > thanks for the report.
> >
> >>> CC kernel/sched/core.o
> >>> ../kernel/sched/core.c: In function ‘uclamp_update_active_tasks’:
> >>> ../kernel/sched/core.c:1081:23: error: storage size of ‘it’ isn’t known
> >>> struct css_task_iter it;
> >>> ^~
> >>> CC kernel/printk/printk_safe.o
> >>> ../kernel/sched/core.c:1084:2: error: implicit declaration of function ‘css_task_iter_start’; did you mean ‘__sg_page_iter_start’? [-Werror=implicit-function-declaration]
> >>> css_task_iter_start(css, 0, &it);
> >>> ^~~~~~~~~~~~~~~~~~~
> >>> __sg_page_iter_start
> >>> ../kernel/sched/core.c:1085:14: error: implicit declaration of function ‘css_task_iter_next’; did you mean ‘__sg_page_iter_next’? [-Werror=implicit-function-declaration]
> >>> while ((p = css_task_iter_next(&it))) {
> >>> ^~~~~~~~~~~~~~~~~~
> >>> __sg_page_iter_next
> >>> ../kernel/sched/core.c:1091:2: error: implicit declaration of function ‘css_task_iter_end’; did you mean ‘get_task_cred’? [-Werror=implicit-function-declaration]
> >>> css_task_iter_end(&it);
> >>> ^~~~~~~~~~~~~~~~~
> >>> get_task_cred
> >>> ../kernel/sched/core.c:1081:23: warning: unused variable ‘it’ [-Wunused-variable]
> >>> struct css_task_iter it;
> >>> ^~
> >>>
> >>
> >> I cannot reproduce this build failue: I took Linus's latest which has all
> >> the -next scheduler commits included (ad062195731b), and an x86-64 "make
> >> defconfig" and a disabling of CONFIG_CGROUPS still resuls in a kernel
> >> that builds fine.
> >
> > Same here Ingo, I cannot reproduce on arm64 and !CONFIG_CGROUPS and
> > testing on tip/sched/core.
> >
> > However, if you like, the following patch can make that code a
> > bit more "robust".
> >
> > Best,
> > Patrick
> >
> > ---8<---
> > From 7e17b7bb08dd8dfc57e01c2a7b6875439eb47cbe Mon Sep 17 00:00:00 2001
> > From: Patrick Bellasi <[email protected]>
> > Date: Tue, 17 Sep 2019 14:12:10 +0100
> > Subject: [PATCH 1/1] sched/core: uclamp: Fix compile error on !CONFIG_CGROUPS
> >
> > Randy reported a compiler error on x86_64 and !CONFIG_CGROUPS which is due
> > to uclamp_update_active_tasks() using the undefined css_task_iter().
> >
> > Since uclamp_update_active_tasks() is used only when cgroup support is
> > enabled, fix that by properly guarding that function at compile time.
> >
> > Signed-off-by: Patrick Bellasi <[email protected]>
> > Link: https://lore.kernel.org/lkml/[email protected]/
> > Fixes: commit babbe170e05 ("sched/uclamp: Update CPU's refcount on TG's clamp changes")
>
> Acked-by: Randy Dunlap <[email protected]> # build-tested
>
> Thanks.
Build failures like this one shouldn't depend on the compiler version -
and it's still a mystery how and why this build bug triggered - we cannot
apply the fix without knowing the answer to those questions.
Can you reproduce the build bug with Linus's latest tree? If not, which
part of -next triggers the build failure?
Thanks,
Ingo
On Wed, Sep 18, 2019 at 07:05:53 +0100, Ingo Molnar wrote...
> * Randy Dunlap <[email protected]> wrote:
>
>> On 9/17/19 6:38 AM, Patrick Bellasi wrote:
>> >
>> > On Tue, Sep 17, 2019 at 08:52:42 +0100, Ingo Molnar wrote...
>> >
>> >> * Randy Dunlap <[email protected]> wrote:
>> >>
>> >>> On 9/16/19 3:38 PM, Mark Brown wrote:
>> >>>> Hi all,
>> >>>>
>> >>>> Changes since 20190915:
>> >>>>
>> >>>
>> >>> on x86_64:
>> >>>
>> >>> when CONFIG_CGROUPS is not set:
>> >
>> > Hi Randy,
>> > thanks for the report.
>> >
>> >>> CC kernel/sched/core.o
>> >>> ../kernel/sched/core.c: In function ‘uclamp_update_active_tasks’:
>> >>> ../kernel/sched/core.c:1081:23: error: storage size of ‘it’ isn’t known
>> >>> struct css_task_iter it;
>> >>> ^~
>> >>> CC kernel/printk/printk_safe.o
>> >>> ../kernel/sched/core.c:1084:2: error: implicit declaration of function ‘css_task_iter_start’; did you mean ‘__sg_page_iter_start’? [-Werror=implicit-function-declaration]
>> >>> css_task_iter_start(css, 0, &it);
>> >>> ^~~~~~~~~~~~~~~~~~~
>> >>> __sg_page_iter_start
>> >>> ../kernel/sched/core.c:1085:14: error: implicit declaration of function ‘css_task_iter_next’; did you mean ‘__sg_page_iter_next’? [-Werror=implicit-function-declaration]
>> >>> while ((p = css_task_iter_next(&it))) {
>> >>> ^~~~~~~~~~~~~~~~~~
>> >>> __sg_page_iter_next
>> >>> ../kernel/sched/core.c:1091:2: error: implicit declaration of function ‘css_task_iter_end’; did you mean ‘get_task_cred’? [-Werror=implicit-function-declaration]
>> >>> css_task_iter_end(&it);
>> >>> ^~~~~~~~~~~~~~~~~
>> >>> get_task_cred
>> >>> ../kernel/sched/core.c:1081:23: warning: unused variable ‘it’ [-Wunused-variable]
>> >>> struct css_task_iter it;
>> >>> ^~
>> >>>
>> >>
>> >> I cannot reproduce this build failue: I took Linus's latest which has all
>> >> the -next scheduler commits included (ad062195731b), and an x86-64 "make
>> >> defconfig" and a disabling of CONFIG_CGROUPS still resuls in a kernel
>> >> that builds fine.
>> >
>> > Same here Ingo, I cannot reproduce on arm64 and !CONFIG_CGROUPS and
>> > testing on tip/sched/core.
>> >
>> > However, if you like, the following patch can make that code a
>> > bit more "robust".
>> >
>> > Best,
>> > Patrick
>> >
>> > ---8<---
>> > From 7e17b7bb08dd8dfc57e01c2a7b6875439eb47cbe Mon Sep 17 00:00:00 2001
>> > From: Patrick Bellasi <[email protected]>
>> > Date: Tue, 17 Sep 2019 14:12:10 +0100
>> > Subject: [PATCH 1/1] sched/core: uclamp: Fix compile error on !CONFIG_CGROUPS
>> >
>> > Randy reported a compiler error on x86_64 and !CONFIG_CGROUPS which is due
>> > to uclamp_update_active_tasks() using the undefined css_task_iter().
>> >
>> > Since uclamp_update_active_tasks() is used only when cgroup support is
>> > enabled, fix that by properly guarding that function at compile time.
>> >
>> > Signed-off-by: Patrick Bellasi <[email protected]>
>> > Link: https://lore.kernel.org/lkml/[email protected]/
>> > Fixes: commit babbe170e05 ("sched/uclamp: Update CPU's refcount on TG's clamp changes")
>>
>> Acked-by: Randy Dunlap <[email protected]> # build-tested
>>
>> Thanks.
>
> Build failures like this one shouldn't depend on the compiler version -
> and it's still a mystery how and why this build bug triggered - we cannot
> apply the fix without knowing the answer to those questions.
Right, but it's also quite strange it's not triggering without the
guarding above. The only definition of struct css_task_iter I can see is
the one
provided in:
include/linux/cgroup.h:50
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/cgroup.h?h=35f7a95266153b1cf0caca3aa9661cb721864527#n50
which is CONFIG_CGROUPS guarded.
> Can you reproduce the build bug with Linus's latest tree? If not, which
> part of -next triggers the build failure?
I tried again using this morning's Linus tree headed at:
commit 35f7a9526615 ("Merge tag 'devprop-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm")
and compilation actually fails for me too.
Everything is fine in v5.3 with !CONFIG_CGROUPS and a git bisect
between v5.3 and Linus master points to:
commit babbe170e053c ("sched/uclamp: Update CPU's refcount on TG's clamp changes")
So, I think it's really my fault not properly testing !CONFIG_CGROUP,
which is enforced by default from CONFIG_SCHED_AUTOGROUP.
The patch above fixes the compilation error, hope this helps.
Cheers,
Patrick
--
#include <best/regards.h>
Patrick Bellasi
On 9/18/19 3:03 AM, Patrick Bellasi wrote:
>
> On Wed, Sep 18, 2019 at 07:05:53 +0100, Ingo Molnar wrote...
>
>> * Randy Dunlap <[email protected]> wrote:
>>
>>> On 9/17/19 6:38 AM, Patrick Bellasi wrote:
>>>>
>>>> On Tue, Sep 17, 2019 at 08:52:42 +0100, Ingo Molnar wrote...
>>>>
>>>>> * Randy Dunlap <[email protected]> wrote:
>>>>>
>>>>>> On 9/16/19 3:38 PM, Mark Brown wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Changes since 20190915:
>>>>>>>
>>>>>>
>>>>>> on x86_64:
>>>>>>
>>>>>> when CONFIG_CGROUPS is not set:
>>>>
>>>> Hi Randy,
>>>> thanks for the report.
>>>>
>>>>>> CC kernel/sched/core.o
>>>>>> ../kernel/sched/core.c: In function ‘uclamp_update_active_tasks’:
>>>>>> ../kernel/sched/core.c:1081:23: error: storage size of ‘it’ isn’t known
>>>>>> struct css_task_iter it;
>>>>>> ^~
>>>>>> CC kernel/printk/printk_safe.o
>>>>>> ../kernel/sched/core.c:1084:2: error: implicit declaration of function ‘css_task_iter_start’; did you mean ‘__sg_page_iter_start’? [-Werror=implicit-function-declaration]
>>>>>> css_task_iter_start(css, 0, &it);
>>>>>> ^~~~~~~~~~~~~~~~~~~
>>>>>> __sg_page_iter_start
>>>>>> ../kernel/sched/core.c:1085:14: error: implicit declaration of function ‘css_task_iter_next’; did you mean ‘__sg_page_iter_next’? [-Werror=implicit-function-declaration]
>>>>>> while ((p = css_task_iter_next(&it))) {
>>>>>> ^~~~~~~~~~~~~~~~~~
>>>>>> __sg_page_iter_next
>>>>>> ../kernel/sched/core.c:1091:2: error: implicit declaration of function ‘css_task_iter_end’; did you mean ‘get_task_cred’? [-Werror=implicit-function-declaration]
>>>>>> css_task_iter_end(&it);
>>>>>> ^~~~~~~~~~~~~~~~~
>>>>>> get_task_cred
>>>>>> ../kernel/sched/core.c:1081:23: warning: unused variable ‘it’ [-Wunused-variable]
>>>>>> struct css_task_iter it;
>>>>>> ^~
>>>>>>
>>>>>
>>>>> I cannot reproduce this build failue: I took Linus's latest which has all
>>>>> the -next scheduler commits included (ad062195731b), and an x86-64 "make
>>>>> defconfig" and a disabling of CONFIG_CGROUPS still resuls in a kernel
>>>>> that builds fine.
>>>>
>>>> Same here Ingo, I cannot reproduce on arm64 and !CONFIG_CGROUPS and
>>>> testing on tip/sched/core.
>>>>
>>>> However, if you like, the following patch can make that code a
>>>> bit more "robust".
>>>>
>>>> Best,
>>>> Patrick
>>>>
>>>> ---8<---
>>>> From 7e17b7bb08dd8dfc57e01c2a7b6875439eb47cbe Mon Sep 17 00:00:00 2001
>>>> From: Patrick Bellasi <[email protected]>
>>>> Date: Tue, 17 Sep 2019 14:12:10 +0100
>>>> Subject: [PATCH 1/1] sched/core: uclamp: Fix compile error on !CONFIG_CGROUPS
>>>>
>>>> Randy reported a compiler error on x86_64 and !CONFIG_CGROUPS which is due
>>>> to uclamp_update_active_tasks() using the undefined css_task_iter().
>>>>
>>>> Since uclamp_update_active_tasks() is used only when cgroup support is
>>>> enabled, fix that by properly guarding that function at compile time.
>>>>
>>>> Signed-off-by: Patrick Bellasi <[email protected]>
>>>> Link: https://lore.kernel.org/lkml/[email protected]/
>>>> Fixes: commit babbe170e05 ("sched/uclamp: Update CPU's refcount on TG's clamp changes")
>>>
>>> Acked-by: Randy Dunlap <[email protected]> # build-tested
>>>
>>> Thanks.
>>
>> Build failures like this one shouldn't depend on the compiler version -
>> and it's still a mystery how and why this build bug triggered - we cannot
>> apply the fix without knowing the answer to those questions.
>
> Right, but it's also quite strange it's not triggering without the
> guarding above. The only definition of struct css_task_iter I can see is
> the one
> provided in:
>
> include/linux/cgroup.h:50
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/cgroup.h?h=35f7a95266153b1cf0caca3aa9661cb721864527#n50
>
> which is CONFIG_CGROUPS guarded.
>
>> Can you reproduce the build bug with Linus's latest tree? If not, which
>> part of -next triggers the build failure?
>
> I tried again using this morning's Linus tree headed at:
>
> commit 35f7a9526615 ("Merge tag 'devprop-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm")
>
> and compilation actually fails for me too.
and linux-next of 20190924 still fails also...
> Everything is fine in v5.3 with !CONFIG_CGROUPS and a git bisect
> between v5.3 and Linus master points to:
>
> commit babbe170e053c ("sched/uclamp: Update CPU's refcount on TG's clamp changes")
>
> So, I think it's really my fault not properly testing !CONFIG_CGROUP,
> which is enforced by default from CONFIG_SCHED_AUTOGROUP.
>
> The patch above fixes the compilation error, hope this helps.
>
> Cheers,
> Patrick
--
~Randy