Buildresult: linus/um-defconfig/um-x86_64 built on Aug 26 2021, 06:04

kisskb

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

Status:	OK
Date/Time:	Aug 26 2021, 06:04
Duration:	0:00:45.914845
Builder:	ka1
Revision:	pipe: do FASYNC notifications for every pipe IO, not just state changes (`fe67f4dd8daa252eb9aa7acb61555f3cc3c1ce4c)`
Target:	linus/um-defconfig/um-x86_64
Branch:	linus
Compiler:	um-x86_64 (x86_64-linux-gcc.br_real (Buildroot 2017.05) 5.4.0 / GNU ld (GNU Binutils) 2.27)
Config:	defconfig (download)
Log:	Download original No warnings found in log. Full Log # git rev-parse -q --verify fe67f4dd8daa252eb9aa7acb61555f3cc3c1ce4c^{commit} fe67f4dd8daa252eb9aa7acb61555f3cc3c1ce4c already have revision, skipping fetch # 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/fe-x86-64-core-i7-2017.05/bin/x86_64-linux-gcc --version # < /opt/cross/kisskb/fe-x86-64-core-i7-2017.05/bin/x86_64-linux-ld --version # < git log --format=%s --max-count=1 fe67f4dd8daa252eb9aa7acb61555f3cc3c1ce4c # < make -s -j 48 ARCH=um O=/kisskb/build/linus_um-defconfig_um-x86_64 CROSS_COMPILE=/opt/cross/kisskb/fe-x86-64-core-i7-2017.05/bin/x86_64-linux- SUBARCH=x86_64 defconfig # < make -s -j 48 ARCH=um O=/kisskb/build/linus_um-defconfig_um-x86_64 CROSS_COMPILE=/opt/cross/kisskb/fe-x86-64-core-i7-2017.05/bin/x86_64-linux- SUBARCH=x86_64 help # make -s -j 48 ARCH=um O=/kisskb/build/linus_um-defconfig_um-x86_64 CROSS_COMPILE=/opt/cross/kisskb/fe-x86-64-core-i7-2017.05/bin/x86_64-linux- SUBARCH=x86_64 olddefconfig # make -s -j 48 ARCH=um O=/kisskb/build/linus_um-defconfig_um-x86_64 CROSS_COMPILE=/opt/cross/kisskb/fe-x86-64-core-i7-2017.05/bin/x86_64-linux- SUBARCH=x86_64 LINK linux Completed OK # rm -rf /kisskb/build/linus_um-defconfig_um-x86_64 # Build took: 0:00:45.914845

© Michael Ellerman 2006-2018.