# 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 <torvalds@linux-foundation.org>
# 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 <oliver.sang@intel.com>
#     Reported-by: John Hubbard <jhubbard@nvidia.com>
#     Reported-by: syzbot+6cf44e127903fdf9d929@syzkaller.appspotmail.com
#     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
# < /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