Re: [PATCH 6.6 000/530] 6.6.3-rc1 review

[Greg Kroah-Hartman]

On Sat, Nov 25, 2023 at 12:35:47AM +0530, Naresh Kamboju wrote:
> On Fri, 24 Nov 2023 at 23:34, Greg Kroah-Hartman
> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > This is the start of the stable review cycle for the 6.6.3 release.
> > There are 530 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun, 26 Nov 2023 17:19:17 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> >         https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.3-rc1.gz
> > or in the git tree and branch at:
> >         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.6.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> 
> 
> 
> > Zhen Lei <thunder.leizhen@xxxxxxxxxx>
> >     rcu: Dump memory object info if callback function is invalid
> 
> 
> Following build warnings / errors noticed while building the
> arm64 tinyconfig on stable-rc linux-6.6.y.
> 
> 
> kernel/rcu/update.c:49:
> kernel/rcu/rcu.h: In function 'debug_rcu_head_callback':
> kernel/rcu/rcu.h:255:17: error: implicit declaration of function
> 'kmem_dump_obj'; did you mean 'mem_dump_obj'?
> [-Werror=implicit-function-declaration]
>   255 |                 kmem_dump_obj(rhp);
>       |                 ^~~~~~~~~~~~~
>       |                 mem_dump_obj
> cc1: some warnings being treated as errors
> 
> 
> rcu: Dump memory object info if callback function is invalid
> [ Upstream commit 2cbc482d325ee58001472c4359b311958c4efdd1 ]
> 
> Steps to reproduce:
> $ tuxmake --runtime podman --target-arch arm64 --toolchain gcc-11
> --kconfig tinyconfig config debugkernel dtbs kernel modules xipkernel
> 
> Reported-by: Linux Kernel Functional Testing <lkft@xxxxxxxxxx>
> 
> Links:
>  - https://storage.tuxsuite.com/public/linaro/lkft/builds/2YdN5Tb5NAFPo7H9WWQd0APrWu1/

Should now be fixed, I'll push out a -rc2 soon to verify.

thanks,

greg k-h