Re: [syzbot] [erofs?] WARNING: CPU: NUM PID: NUM at mm/page_alloc.c:LINE get_page_from_freeli

From: Xiang Gao
Date: Thu Jan 05 2023 - 11:00:00 EST



Hi Aleksandr,

On 2023/1/5 19:14, Aleksandr Nogikh wrote:
Hi,

On Thu, Jan 5, 2023 at 11:54 AM Xiang Gao <hsiangkao@xxxxxxxxxxxxxxxxx> wrote:

I wasn't able to build the kernel with this kernel config, it shows:
"...
FATAL: modpost: vmlinux.o is truncated. sechdrs[i].sh_offset=1399394064 > sizeof(*hrd)=64
make[2]: *** [Module.symvers] Error 1
make[1]: *** [modpost] Error 2
make: *** [__sub-make] Error 2
"

Could you please tell, what exact compiler/linker version did you use?

Thanks for your help.

GCC 9.2.1 on my developping server.




Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/0c8a5f06ceb3/disk-f9ff5644.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/be222e852ae2/vmlinux-f9ff5644.xz
kernel image: https://storage.googleapis.com/syzbot-assets/d9f42a53b05e/bzImage-f9ff5644.xz

Finally I tried the original kernel image, and it printed some other
random bug when booting system and then reboot, like:

[ 36.991123][ T1] ==================================================================
[ 36.991800][ T1] BUG: KASAN: slab-out-of-bounds in copy_array+0x96/0x100
[ 36.992438][ T1] Write of size 32 at addr ffff888018c34640 by task systemd/1
< .. >

Interesting!
I've just tried to boot it with qemu and it was fine.

qemu-system-x86_64 -smp 2,sockets=2,cores=1 -m 4G -drive
file=disk-f9ff5644.raw,format=raw -snapshot -nographic -enable-kvm

So it looks like it's some difference between these VMMs that causes
that bug to fire.

I think the problem is that the rootfs which I used has more complicated
workload than the given one.



May I ask it can be reproducable on the latest -rc kernel?

We can ask syzbot about v6.2-rc2:

#syz test git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
88603b6dc419445847923fcb7fe5080067a30f98

I think I know the root cause: It seems that kvcalloc doesn't support
GFP_NOFAIL, I will use kcalloc directly instead.

Thanks,
Gao Xiang



Thanks,
Gao Xiang


--
Aleksandr