Buildresult: linus/mips-allnoconfig/mips-gcc4.9 built on Aug 26 2021, 05:13

kisskb

Revisions | Branches | Compilers | Configs | Build Results | Build Failures |

Status:	OK
Date/Time:	Aug 26 2021, 05:13
Duration:	0:00:45.689919
Builder:	blade46
Revision:	pipe: do FASYNC notifications for every pipe IO, not just state changes (`fe67f4dd8daa252eb9aa7acb61555f3cc3c1ce4c)`
Target:	linus/mips-allnoconfig/mips-gcc4.9
Branch:	linus
Compiler:	mips-gcc4.9 (mips-linux-gcc (GCC) 4.9.4 / GNU ld (GNU Binutils) 2.29.1.20170915)
Config:	allnoconfig (download)
Log:	Download original Possible warnings (2) warning: The last gc run reported the following. Please correct the root cause warning: There are too many unreachable loose objects; run 'git prune' to remove them. Full Log # git rev-parse -q --verify fe67f4dd8daa252eb9aa7acb61555f3cc3c1ce4c^{commit} # git fetch -q -n -f git://fs.ozlabs.ibm.com/kernel/linus master warning: The last gc run reported the following. Please correct the root cause and remove .git/gc.log. Automatic cleanup will not be performed until the file is removed. warning: There are too many unreachable loose objects; run 'git prune' to remove them. # git rev-parse -q --verify fe67f4dd8daa252eb9aa7acb61555f3cc3c1ce4c^{commit} fe67f4dd8daa252eb9aa7acb61555f3cc3c1ce4c # git checkout -q -f -B kisskb fe67f4dd8daa252eb9aa7acb61555f3cc3c1ce4c # git clean -qxdf # < git log -1 # commit fe67f4dd8daa252eb9aa7acb61555f3cc3c1ce4c # Author: Linus Torvalds <torvalds@linux-foundation.org> # Date: Tue Aug 24 10:39:25 2021 -0700 # # pipe: do FASYNC notifications for every pipe IO, not just state changes # # It turns out that the SIGIO/FASYNC situation is almost exactly the same # as the EPOLLET case was: user space really wants to be notified after # every operation. # # Now, in a perfect world it should be sufficient to only notify user # space on "state transitions" when the IO state changes (ie when a pipe # goes from unreadable to readable, or from unwritable to writable). User # space should then do as much as possible - fully emptying the buffer or # what not - and we'll notify it again the next time the state changes. # # But as with EPOLLET, we have at least one case (stress-ng) where the # kernel sent SIGIO due to the pipe being marked for asynchronous # notification, but the user space signal handler then didn't actually # necessarily read it all before returning (it read more than what was # written, but since there could be multiple writes, it could leave data # pending). # # The user space code then expected to get another SIGIO for subsequent # writes - even though the pipe had been readable the whole time - and # would only then read more. # # This is arguably a user space bug - and Colin King already fixed the # stress-ng code in question - but the kernel regression rules are clear: # it doesn't matter if kernel people think that user space did something # silly and wrong. What matters is that it used to work. # # So if user space depends on specific historical kernel behavior, it's a # regression when that behavior changes. It's on us: we were silly to # have that non-optimal historical behavior, and our old kernel behavior # was what user space was tested against. # # Because of how the FASYNC notification was tied to wakeup behavior, this # was first broken by commits f467a6a66419 and 1b6b26ae7053 ("pipe: fix # and clarify pipe read/write wakeup logic"), but at the time it seems # nobody noticed. Probably because the stress-ng problem case ends up # being timing-dependent too. # # It was then unwittingly fixed by commit 3a34b13a88ca ("pipe: make pipe # writes always wake up readers") only to be broken again when by commit # 3b844826b6c6 ("pipe: avoid unnecessary EPOLLET wakeups under normal # loads"). # # And at that point the kernel test robot noticed the performance # refression in the stress-ng.sigio.ops_per_sec case. So the "Fixes" tag # below is somewhat ad hoc, but it matches when the issue was noticed. # # Fix it for good (knock wood) by simply making the kill_fasync() case # separate from the wakeup case. FASYNC is quite rare, and we clearly # shouldn't even try to use the "avoid unnecessary wakeups" logic for it. # # Link: https://lore.kernel.org/lkml/20210824151337.GC27667@xsang-OptiPlex-9020/ # Fixes: 3b844826b6c6 ("pipe: avoid unnecessary EPOLLET wakeups under normal loads") # Reported-by: kernel test robot <oliver.sang@intel.com> # Tested-by: Oliver Sang <oliver.sang@intel.com> # Cc: Eric Biederman <ebiederm@xmission.com> # Cc: Colin Ian King <colin.king@canonical.com> # Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> # < /opt/cross/kisskb/korg/gcc-4.9.4-nolibc/mips-linux/bin/mips-linux-gcc --version # < /opt/cross/kisskb/korg/gcc-4.9.4-nolibc/mips-linux/bin/mips-linux-ld --version # < git log --format=%s --max-count=1 fe67f4dd8daa252eb9aa7acb61555f3cc3c1ce4c # < make -s -j 32 ARCH=mips O=/kisskb/build/linus_mips-allnoconfig_mips-gcc4.9 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-4.9.4-nolibc/mips-linux/bin/mips-linux- allnoconfig # < make -s -j 32 ARCH=mips O=/kisskb/build/linus_mips-allnoconfig_mips-gcc4.9 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-4.9.4-nolibc/mips-linux/bin/mips-linux- help # make -s -j 32 ARCH=mips O=/kisskb/build/linus_mips-allnoconfig_mips-gcc4.9 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-4.9.4-nolibc/mips-linux/bin/mips-linux- olddefconfig # make -s -j 32 ARCH=mips O=/kisskb/build/linus_mips-allnoconfig_mips-gcc4.9 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-4.9.4-nolibc/mips-linux/bin/mips-linux- Completed OK # rm -rf /kisskb/build/linus_mips-allnoconfig_mips-gcc4.9 # Build took: 0:00:45.689919

© Michael Ellerman 2006-2018.