# git rev-parse -q --verify 6cd06ab12d1afdab3847e7981f301bd0404aaa5c^{commit} 6cd06ab12d1afdab3847e7981f301bd0404aaa5c already have revision, skipping fetch # git checkout -q -f -B kisskb 6cd06ab12d1afdab3847e7981f301bd0404aaa5c # git clean -qxdf # < git log -1 # commit 6cd06ab12d1afdab3847e7981f301bd0404aaa5c # Author: Linus Torvalds # Date: Wed Jul 5 09:33:31 2023 -0700 # # gup: make the stack expansion warning a bit more targeted # # I added a warning about about GUP no longer expanding the stack in # commit a425ac5365f6 ("gup: add warning if some caller would seem to want # stack expansion"), but didn't really expect anybody to hit it. # # And it's true that nobody seems to have hit a _real_ case yet, but we # certainly have a number of reports of false positives. Which not only # causes extra noise in itself, but might also end up hiding any real # cases if they do exist. # # So let's tighten up the warning condition, and replace the simplistic # # vma = find_vma(mm, start); # if (vma && (start < vma->vm_start)) { # WARN_ON_ONCE(vma->vm_flags & VM_GROWSDOWN); # # with a # # vma = gup_vma_lookup(mm, start); # # helper function which works otherwise like just "vma_lookup()", but with # some heuristics for when to warn about gup no longer causing stack # expansion. # # In particular, don't just warn for "below the stack", but warn if it's # _just_ below the stack (with "just below" arbitrarily defined as 64kB, # because why not?). And rate-limit it to at most once per hour, which # means that any false positives shouldn't completely hide subsequent # reports, but we won't be flooding the logs about it either. # # The previous code triggered when some GUP user (chromium crashpad) # accessing past the end of the previous vma, for example. That has never # expanded the stack, it just causes GUP to return early, and as such we # shouldn't be warning about it. # # This is still going trigger the randomized testers, but to mitigate the # noise from that, use "dump_stack()" instead of "WARN_ON_ONCE()" to get # the kernel call chain. We'll get the relevant information, but syzbot # shouldn't get too upset about it. # # Also, don't even bother with the GROWSUP case, which would be using # different heuristics entirely, but only happens on parisc. # # Reported-by: kernel test robot # Reported-by: John Hubbard # Reported-by: syzbot+6cf44e127903fdf9d929@syzkaller.appspotmail.com # Signed-off-by: Linus Torvalds # < /opt/cross/kisskb/korg/gcc-5.5.0-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc --version # < /opt/cross/kisskb/korg/gcc-5.5.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld --version # < git log --format=%s --max-count=1 6cd06ab12d1afdab3847e7981f301bd0404aaa5c # make -s -j 160 ARCH=powerpc O=/kisskb/build/linus_ppc40x_defconfig_powerpc-gcc5 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-5.5.0-nolibc/powerpc64-linux/bin/powerpc64-linux- ppc40x_defconfig # < make -s -j 160 ARCH=powerpc O=/kisskb/build/linus_ppc40x_defconfig_powerpc-gcc5 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-5.5.0-nolibc/powerpc64-linux/bin/powerpc64-linux- help # make -s -j 160 ARCH=powerpc O=/kisskb/build/linus_ppc40x_defconfig_powerpc-gcc5 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-5.5.0-nolibc/powerpc64-linux/bin/powerpc64-linux- olddefconfig # make -s -j 160 ARCH=powerpc O=/kisskb/build/linus_ppc40x_defconfig_powerpc-gcc5 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-5.5.0-nolibc/powerpc64-linux/bin/powerpc64-linux- Completed OK # rm -rf /kisskb/build/linus_ppc40x_defconfig_powerpc-gcc5 # Build took: 0:00:52.813412