Buildresult: linus/x86_64-defconfig/x86_64-gcc8 built on Feb 17 2022, 06:29

kisskb

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

Status:	OK
Date/Time:	Feb 17 2022, 06:29
Duration:	0:02:33.277665
Builder:	ka1
Revision:	tty: n_tty: do not look ahead for EOL character past the end of the buffer (`3593030761630e09200072a4bd06468892c27be3)`
Target:	linus/x86_64-defconfig/x86_64-gcc8
Branch:	linus
Compiler:	x86_64-gcc8 (x86_64-linux-gcc (GCC) 8.1.0 / GNU ld (GNU Binutils) 2.30)
Config:	defconfig (download)
Log:	Download original No warnings found in log. Full Log # git rev-parse -q --verify 3593030761630e09200072a4bd06468892c27be3^{commit} # git fetch -q -n -f git://fs.ozlabs.ibm.com/kernel/linus master # git rev-parse -q --verify 3593030761630e09200072a4bd06468892c27be3^{commit} 3593030761630e09200072a4bd06468892c27be3 # git checkout -q -f -B kisskb 3593030761630e09200072a4bd06468892c27be3 # git clean -qxdf # < git log -1 # commit 3593030761630e09200072a4bd06468892c27be3 # Author: Linus Torvalds <torvalds@linux-foundation.org> # Date: Tue Feb 15 15:28:00 2022 -0800 # # tty: n_tty: do not look ahead for EOL character past the end of the buffer # # Daniel Gibson reports that the n_tty code gets line termination wrong in # very specific cases: # # "If you feed a line with exactly 64 chars + terminating newline, and # directly afterwards (without reading) another line into a pseudo # terminal, the the first read() on the other side will return the 64 # char line without terminating newline, and the next read() will # return the missing terminating newline AND the complete next line (if # it fits in the buffer)" # # and bisected the behavior to commit 3b830a9c34d5 ("tty: convert # tty_ldisc_ops 'read()' function to take a kernel pointer"). # # Now, digging deeper, it turns out that the behavior isn't exactly new: # what changed in commit 3b830a9c34d5 was that the tty line discipline # .read() function is now passed an intermediate kernel buffer rather than # the final user space buffer. # # And that intermediate kernel buffer is 64 bytes in size - thus that # special case with exactly 64 bytes plus terminating newline. # # The same problem did exist before, but historically the boundary was not # the 64-byte chunk, but the user-supplied buffer size, which is obviously # generally bigger (and potentially bigger than N_TTY_BUF_SIZE, which # would hide the issue entirely). # # The reason is that the n_tty canon_copy_from_read_buf() code would look # ahead for the EOL character one byte further than it would actually # copy. It would then decide that it had found the terminator, and unmark # it as an EOL character - which in turn explains why the next read # wouldn't then be terminated by it. # # Now, the reason it did all this in the first place is related to some # historical and pretty obscure EOF behavior, see commit ac8f3bf8832a # ("n_tty: Fix poll() after buffer-limited eof push read") and commit # 40d5e0905a03 ("n_tty: Fix EOF push handling"). # # And the reason for the EOL confusion is that we treat EOF as a special # EOL condition, with the EOL character being NUL (aka "__DISABLED_CHAR" # in the kernel sources). # # So that EOF look-ahead also affects the normal EOL handling. # # This patch just removes the look-ahead that causes problems, because EOL # is much more critical than the historical "EOF in the middle of a line # that coincides with the end of the buffer" handling ever was. # # Now, it is possible that we should indeed re-introduce the "look at next # character to see if it's a EOF" behavior, but if so, that should be done # not at the kernel buffer chunk boundary in canon_copy_from_read_buf(), # but at a higher level, when we run out of the user buffer. # # In particular, the place to do that would be at the top of # 'n_tty_read()', where we check if it's a continuation of a previously # started read, and there is no more buffer space left, we could decide to # just eat the __DISABLED_CHAR at that point. # # But that would be a separate patch, because I suspect nobody actually # cares, and I'd like to get a report about it before bothering. # # Fixes: 3b830a9c34d5 ("tty: convert tty_ldisc_ops 'read()' function to take a kernel pointer") # Fixes: ac8f3bf8832a ("n_tty: Fix poll() after buffer-limited eof push read") # Fixes: 40d5e0905a03 ("n_tty: Fix EOF push handling") # Link: https://bugzilla.kernel.org/show_bug.cgi?id=215611 # Reported-and-tested-by: Daniel Gibson <metalcaedes@gmail.com> # Cc: Peter Hurley <peter@hurleysoftware.com> # Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> # Cc: Jiri Slaby <jirislaby@kernel.org> # Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> # < /opt/cross/kisskb/korg/gcc-8.1.0-nolibc/x86_64-linux/bin/x86_64-linux-gcc --version # < /opt/cross/kisskb/korg/gcc-8.1.0-nolibc/x86_64-linux/bin/x86_64-linux-ld --version # < git log --format=%s --max-count=1 3593030761630e09200072a4bd06468892c27be3 # < make -s -j 48 ARCH=x86 O=/kisskb/build/linus_x86_64_defconfig_x86_64-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.1.0-nolibc/x86_64-linux/bin/x86_64-linux- x86_64_defconfig # < make -s -j 48 ARCH=x86 O=/kisskb/build/linus_x86_64_defconfig_x86_64-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.1.0-nolibc/x86_64-linux/bin/x86_64-linux- help # make -s -j 48 ARCH=x86 O=/kisskb/build/linus_x86_64_defconfig_x86_64-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.1.0-nolibc/x86_64-linux/bin/x86_64-linux- olddefconfig # make -s -j 48 ARCH=x86 O=/kisskb/build/linus_x86_64_defconfig_x86_64-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.1.0-nolibc/x86_64-linux/bin/x86_64-linux- Completed OK # rm -rf /kisskb/build/linus_x86_64_defconfig_x86_64-gcc8 # Build took: 0:02:33.277665

© Michael Ellerman 2006-2018.