[syzbot] [mm?] WARNING in __gup_longterm_locked

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: f8566aa4f176 Merge tag 'x86-urgent-2023-07-01' of git://gi..
git tree: upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=15ebe50b280000
kernel config: https://syzkaller.appspot.com/x/.config?x=7406f415f386e786
dashboard link: https://syzkaller.appspot.com/bug?extid=6cf44e127903fdf9d929
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12e5b04f280000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=102dff80a80000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/08033ccab6ef/disk-f8566aa4.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/04c5c8c7e53a/vmlinux-f8566aa4.xz
kernel image: https://storage.googleapis.com/syzbot-assets/942a1c157a92/bzImage-f8566aa4.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+6cf44e...@syzkaller.appspotmail.com

------------[ cut here ]------------
WARNING: CPU: 1 PID: 5001 at mm/gup.c:1173 __get_user_pages+0xd49/0x1080 mm/gup.c:1173
Modules linked in:
CPU: 1 PID: 5001 Comm: syz-executor229 Not tainted 6.4.0-syzkaller-10062-gf8566aa4f176 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
RIP: 0010:__get_user_pages+0xd49/0x1080 mm/gup.c:1173
Code: 89 f8 48 c1 e8 03 80 3c 08 00 0f 85 bc 02 00 00 48 8b 44 24 20 48 8b 80 c0 00 00 00 48 8d 1c e8 e9 ad f7 ff ff e8 37 19 c3 ff <0f> 0b e9 32 f6 ff ff e8 2b 19 c3 ff 0f 0b e8 24 19 c3 ff 44 89 ed
RSP: 0018:ffffc90003a3f558 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000100 RCX: 0000000000000000
RDX: ffff888020630000 RSI: ffffffff81c1b599 RDI: 0000000000000007
RBP: 0000000020006000 R08: 0000000000000007 R09: 0000000000000000
R10: 0000000000000100 R11: 0000000000000001 R12: ffff888018796100
R13: 0000000000210002 R14: ffff888076f55580 R15: 0000000000000000
FS: 0000555556272300(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000664740 CR3: 0000000029be1000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
__get_user_pages_locked mm/gup.c:1456 [inline]
__gup_longterm_locked+0x6f9/0x23e0 mm/gup.c:2150
internal_get_user_pages_fast+0x16e6/0x32f0 mm/gup.c:3148
get_user_pages_fast+0xa8/0xf0 mm/gup.c:3226
__iov_iter_get_pages_alloc+0x28c/0x1950 lib/iov_iter.c:1111
iov_iter_get_pages2+0xa8/0x100 lib/iov_iter.c:1151
iter_to_pipe fs/splice.c:1402 [inline]
vmsplice_to_pipe fs/splice.c:1492 [inline]
__do_sys_vmsplice+0x50c/0xaa0 fs/splice.c:1556
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f2a6e4e4b69
Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 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 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffdb0cc72d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000116
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f2a6e4e4b69
RDX: 0000000000000001 RSI: 00000000200000c0 RDI: 0000000000000004
RBP: 00007f2a6e4a8d10 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000246 R12: 00007f2a6e4a8da0
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
</TASK>


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the bug is already fixed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to change bug's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the bug is a duplicate of another bug, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[Andrew Morton]

On Tue, 04 Jul 2023 02:37:56 -0700 syzbot <syzbot+6cf44e...@syzkaller.appspotmail.com> wrote:

> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: f8566aa4f176 Merge tag 'x86-urgent-2023-07-01' of git://gi..
> git tree: upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=15ebe50b280000
> kernel config: https://syzkaller.appspot.com/x/.config?x=7406f415f386e786
> dashboard link: https://syzkaller.appspot.com/bug?extid=6cf44e127903fdf9d929
> compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12e5b04f280000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=102dff80a80000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/08033ccab6ef/disk-f8566aa4.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/04c5c8c7e53a/vmlinux-f8566aa4.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/942a1c157a92/bzImage-f8566aa4.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+6cf44e...@syzkaller.appspotmail.com
>
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 5001 at mm/gup.c:1173 __get_user_pages+0xd49/0x1080 mm/gup.c:1173

Thanks. This is the temporary warning which was added by Linus's
a425ac5365f6cb3cc4 ("gup: add warning if some caller would seem to want
stack expansion").

[Linus Torvalds]

On Tue, 4 Jul 2023 at 09:24, Andrew Morton <ak...@linux-foundation.org> wrote:
>
> Thanks. This is the temporary warning which was added by Linus's
> a425ac5365f6cb3cc4 ("gup: add warning if some caller would seem to want
> stack expansion").

Yes, and the randomizer system calls aren't very interesting for that warning.

I don't have any good idea for how to distinguish "this is a
randomizer that is just doing crazy things by its very nature and is
passing in nonsensical system call arguments" from "this is a real
application that is doing crazy things that we will sadly have to try
to be backwards compatible with".

And at the same time, I _really_ don't want that warning to then
perhaps hide some *other* more real warning from the test automation.

End result: I'd love for that warning to trigger on real applications
(including ones run by any cloud test infrastructure, although I doubt
that infrastructure necessarily runs very interesting loads), but not
on things like syzbot and trinity that just randomize system calls.

Does anybody have any ideas how to tell them apart? Maybe syzbot
already sets some flag for this purpose that I just haven't thought
of?

Linus

[Eric Biggers]

syzkaller just makes system calls.

Unless you want to do the crazy thing of checking if current->comm begins with
"syz", I don't think there is a way to distinguish.

In the past there's been some discussion of adding a kconfig option like
CONFIG_FUZZ_TESTING that would be expected to be enabled in order to run a
kernel fuzzer, and changing behavior in certain cases based on that. Changing
behavior in production vs. test is problematic, though...

- Eric

[Linus Torvalds]

On Tue, 4 Jul 2023 at 10:01, Eric Biggers <ebig...@kernel.org> wrote:
>
> syzkaller just makes system calls.
>
> Unless you want to do the crazy thing of checking if current->comm begins with
> "syz", I don't think there is a way to distinguish.

Yeah, that's what I thought.

> In the past there's been some discussion of adding a kconfig option like
> CONFIG_FUZZ_TESTING that would be expected to be enabled in order to run a
> kernel fuzzer, and changing behavior in certain cases based on that. Changing
> behavior in production vs. test is problematic, though...

Agreed. The whole point of a fuzzer is to check the real thing. This
test for GUP expansion really is a pretty specialized thing.

Maybe the WARN_ON_ONCE() could have been just a "pr_warn_once()", but
at the same time, *if* that condition ever happens in some real
situation, I'd really want to know just exactly *what* the app in
question is doing.

Linus