Bug 214611 - UM: stdout output ceases under certain conditions

[Johannes Berg]

On Sat, 2021-10-02 at 21:00 -0500, Glenn Washburn wrote:
> Hi list,
> 
> I'm notifying the list of a bug report[1] I created in the kernel
> bugzilla. I'm not subscribed to this list, so please add this my email
> in any replies to this email.


> [1] https://bugzilla.kernel.org/show_bug.cgi?id=214611

This really has nothing to do with UBD or something. What's happening is
that you're using the command line badly.

What do you expect this:

  ... < <(cat /dev/null)

to do?

What happens is that the shell creates a pipe. This pipe is connected on
the one side to fd:1 in UML (stdin) and on the other to stdout of 'cat'.

Now this is all fine, but 'cat' will *quit immediately* since it cannot
read anything from /dev/null (it's write-only!).

Therefore, the fd:1 in UML will be invalidated pretty much immediately,
receiving EPOLLHUP.

This is detected by the epoll code, raising an interrupt into the line
level code, and the line code then closes the stdio console channel
entirely, including stdout.


If anything, the bug is that when you're not causing enough interrupts
by using ubd, somehow this situation doesn't get detected, and the
console remains open, so you still see the output... I think this might
be if closing the FD didn't generate a SIGIO?

In fact, if you generate SIGIO in *any* other way, including pressing
enter while the script is running even if stdin is redirected from your
dead cat [1], you still get the same behaviour of the channel getting
closed.


johannes

[1] did I really just write that? heh.