On Wed, Jan 13, 2021 at 3:28 PM Yonghong Song <yhs@xxxxxx> wrote:
>
>
>
> On 1/13/21 1:48 PM, Song Liu wrote:
> >
> >
> >> On Jan 12, 2021, at 9:17 PM, Yonghong Song <yhs@xxxxxx> wrote:
> >>
> >>
> >>
> >> On 1/12/21 3:42 PM, Song Liu wrote:
> >>> syzbot reported a WARNING for allocating too big memory:
> >>> WARNING: CPU: 1 PID: 8484 at mm/page_alloc.c:4976 __alloc_pages_nodemask+0x5f8/0x730 mm/page_alloc.c:5011
> >>> Modules linked in:
> >>> CPU: 1 PID: 8484 Comm: syz-executor862 Not tainted 5.11.0-rc2-syzkaller #0
> >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> >>> RIP: 0010:__alloc_pages_nodemask+0x5f8/0x730 mm/page_alloc.c:4976
> >>> Code: 00 00 0c 00 0f 85 a7 00 00 00 8b 3c 24 4c 89 f2 44 89 e6 c6 44 24 70 00 48 89 6c 24 58 e8 d0 d7 ff ff 49 89 c5 e9 ea fc ff ff <0f> 0b e9 b5 fd ff ff 89 74 24 14 4c 89 4c 24 08 4c 89 74 24 18 e8
> >>> RSP: 0018:ffffc900012efb10 EFLAGS: 00010246
> >>> RAX: 0000000000000000 RBX: 1ffff9200025df66 RCX: 0000000000000000
> >>> RDX: 0000000000000000 RSI: dffffc0000000000 RDI: 0000000000140dc0
> >>> RBP: 0000000000140dc0 R08: 0000000000000000 R09: 0000000000000000
> >>> R10: ffffffff81b1f7e1 R11: 0000000000000000 R12: 0000000000000014
> >>> R13: 0000000000000014 R14: 0000000000000000 R15: 0000000000000000
> >>> FS: 000000000190c880(0000) GS:ffff8880b9e00000(0000) knlGS:0000000000000000
> >>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >>> CR2: 00007f08b7f316c0 CR3: 0000000012073000 CR4: 00000000001506f0
> >>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> >>> Call Trace:
> >>> alloc_pages_current+0x18c/0x2a0 mm/mempolicy.c:2267
> >>> alloc_pages include/linux/gfp.h:547 [inline]
> >>> kmalloc_order+0x2e/0xb0 mm/slab_common.c:837
> >>> kmalloc_order_trace+0x14/0x120 mm/slab_common.c:853
> >>> kmalloc include/linux/slab.h:557 [inline]
> >>> kzalloc include/linux/slab.h:682 [inline]
> >>> bpf_prog_test_run_raw_tp+0x4b5/0x670 net/bpf/test_run.c:282
> >>> bpf_prog_test_run kernel/bpf/syscall.c:3120 [inline]
> >>> __do_sys_bpf+0x1ea9/0x4f10 kernel/bpf/syscall.c:4398
> >>> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> >>> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >>> RIP: 0033:0x440499
> >>> Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
> >>> RSP: 002b:00007ffe1f3bfb18 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
> >>> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440499
> >>> RDX: 0000000000000048 RSI: 0000000020000600 RDI: 000000000000000a
> >>> RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
> >>> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401ca0
> >>> R13: 0000000000401d30 R14: 0000000000000000 R15: 0000000000000000
> >>> This is because we didn't filter out too big ctx_size_in. Fix it by
> >>> rejecting ctx_size_in that are bigger than MAX_BPF_FUNC_ARGS (12) u64
> >>> numbers.
> >>> Reported-by: syzbot+4f98876664c7337a4ae6@xxxxxxxxxxxxxxxxxxxxxxxxx
> >>> Fixes: 1b4d60ec162f ("bpf: Enable BPF_PROG_TEST_RUN for raw_tracepoint")
> >>> Cc: stable@xxxxxxxxxxxxxxx # v5.10+
> >>> Signed-off-by: Song Liu <songliubraving@xxxxxx>
> >>
> >> Maybe this should target to bpf tree?
> >
> > IIRC, we direct fixes to current release under rc (5.11) to bpf tree. This
> > one is for 5.10 and 5.11, so should go bpf-next, no?
>
> I don't know where it should go first. Maintainers know better. But it
> should go to 5.10, 5.11 (currently rc4) and bpf-next.
Not sure what is the disagreement here.
It's clearly a fix. Hence it was applied to bpf tree.
Song, please mark subj as [PATCH bpf] not to confuse CI,
since it's using this tag to test patches against appropriate tree.
