Build failure in v5.15.133

Build failure in v5.15.133

[Guenter Roeck]

Hi,

I see the following build failure with v5.15.133.

Build reference: v5.15.133
Compiler version: aarch64-linux-gcc (GCC) 11.4.0
Assembler version: GNU assembler (GNU Binutils) 2.40

Building arm64:allnoconfig ... passed
Building arm64:tinyconfig ... passed
Building arm64:defconfig ... failed
--------------
Error log:
drivers/interconnect/core.c: In function 'icc_init':
drivers/interconnect/core.c:1148:9: error: implicit declaration of function 'fs_reclaim_acquire' [-Werror=implicit-function-declaration]
 1148 |         fs_reclaim_acquire(GFP_KERNEL);
      |         ^~~~~~~~~~~~~~~~~~
drivers/interconnect/core.c:1150:9: error: implicit declaration of function 'fs_reclaim_release' [-Werror=implicit-function-declaration]
 1150 |         fs_reclaim_release(GFP_KERNEL);
      |         ^~~~~~~~~~~~~~~~~~

This also affects alpha:allmodconfig and m68k:allmodconfig. The problem
was introduced with 'interconnect: Teach lockdep about icc_bw_lock order'.

#include <linux/sched/mm.h> is missing. Presumably that is included
indirectly in the upstream kernel, but I wasn't able to determine which
commit added it.

Guenter

Re: Build failure in v5.15.133

[Sasha Levin]

On Wed, Sep 27, 2023 at 06:37:10AM -0700, Guenter Roeck wrote:
>Hi,
>
>I see the following build failure with v5.15.133.
>
>Build reference: v5.15.133
>Compiler version: aarch64-linux-gcc (GCC) 11.4.0
>Assembler version: GNU assembler (GNU Binutils) 2.40
>
>Building arm64:allnoconfig ... passed
>Building arm64:tinyconfig ... passed
>Building arm64:defconfig ... failed
>--------------
>Error log:
>drivers/interconnect/core.c: In function 'icc_init':
>drivers/interconnect/core.c:1148:9: error: implicit declaration of function 'fs_reclaim_acquire' [-Werror=implicit-function-declaration]
> 1148 |         fs_reclaim_acquire(GFP_KERNEL);
>      |         ^~~~~~~~~~~~~~~~~~
>drivers/interconnect/core.c:1150:9: error: implicit declaration of function 'fs_reclaim_release' [-Werror=implicit-function-declaration]
> 1150 |         fs_reclaim_release(GFP_KERNEL);
>      |         ^~~~~~~~~~~~~~~~~~
>
>This also affects alpha:allmodconfig and m68k:allmodconfig. The problem
>was introduced with 'interconnect: Teach lockdep about icc_bw_lock order'.
>
>#include <linux/sched/mm.h> is missing. Presumably that is included
>indirectly in the upstream kernel, but I wasn't able to determine which
>commit added it.

Yeah, I added a fixup commit for the next release to address that issue,
thanks for the report!


-- 
Thanks,
Sasha

Re: Build failure in v5.15.133

[Nick Desaulniers]

On Wed, Sep 27, 2023 at 06:37:10AM -0700, Guenter Roeck wrote:
> Hi,
> 
> I see the following build failure with v5.15.133.
> 
> Build reference: v5.15.133
> Compiler version: aarch64-linux-gcc (GCC) 11.4.0
> Assembler version: GNU assembler (GNU Binutils) 2.40
> 
> Building arm64:allnoconfig ... passed
> Building arm64:tinyconfig ... passed
> Building arm64:defconfig ... failed
> --------------
> Error log:
> drivers/interconnect/core.c: In function 'icc_init':
> drivers/interconnect/core.c:1148:9: error: implicit declaration of function 'fs_reclaim_acquire' [-Werror=implicit-function-declaration]
>  1148 |         fs_reclaim_acquire(GFP_KERNEL);
>       |         ^~~~~~~~~~~~~~~~~~
> drivers/interconnect/core.c:1150:9: error: implicit declaration of function 'fs_reclaim_release' [-Werror=implicit-function-declaration]
>  1150 |         fs_reclaim_release(GFP_KERNEL);
>       |         ^~~~~~~~~~~~~~~~~~
> 
> This also affects alpha:allmodconfig and m68k:allmodconfig. The problem
> was introduced with 'interconnect: Teach lockdep about icc_bw_lock order'.
> 
> #include <linux/sched/mm.h> is missing. Presumably that is included
> indirectly in the upstream kernel, but I wasn't able to determine which
> commit added it.
> 
> Guenter

Thanks for the report, our CI is also pretty red for ARCH=arm64
linux-5.15.y builds. Also one ARCH=arm build we have that's using
Alpine's config is hitting the same issue.  Making note of this with our
ML CC'ed so that other folks don't potentially re-triage. Happy to hear
there's already a fix inbound.