linux-kernel - perf top --stdio, glibc 2.28, stdio EOF sticky

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Thu, 6 Jun 2019 06:55:48 +0000
From:   "Rantala, Tommi T. (Nokia - FI/Espoo)" <tommi.t.rantala@...ia.com>
To:     "peterz@...radead.org" <peterz@...radead.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "acme@...nel.org" <acme@...nel.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: perf top --stdio, glibc 2.28, stdio EOF sticky

Hello,

"perf top --stdio" (or perf kvm top --stdio) keyboard handling does not
work properly for me. Instead of accepting key presses, it just
displays the "Mapped keys:" help output always.

Seems to be related to this glibc 2.28 stdio change:

https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS

* All stdio functions now treat end-of-file as a sticky condition.  If
you
 read from a file until EOF, and then the file is enlarged by another
 process, you must call clearerr or another function with the same
effect
 (e.g. fseek, rewind) before you can read the additional data.  This
 corrects a longstanding C99 conformance bug.  It is most likely to
affect
 programs that use stdio to read interactive input from a terminal.
 (Bug #1190.)

Also "perf top </dev/null" with or without --stdio does not behave very
well either...

-Tommi