Re: Bug 214611 - UM: stdout output ceases under certain conditions

[Johannes Berg <johannes@sipsolutions.net>]

On Mon, 2021-10-04 at 11:54 -0500, Glenn Washburn wrote:
> 
> This was just a way to trigger the issue I was seeing. 
> 

Hah, ok :)

> I have a bash
> script which was doing something like the following:
> 
> grep "search" /path/to/file |
> while read VAR; do
>   run_some_script_which_eventually_runs_uml $VAR;
> done

Oh. OK, that's fair.

> This seems like it could be a bug. Couldn't the console not be closed,
> but the console handling code internally mark stdin as closed? Perhaps
> there could even be logic to detect if stdin and stdout are from the
> same fd, then close the console, otherwise don't. From a user
> perspective, thinking of UML as a normal process, it doesn't make sense
> that closing stdin would close stdout as well.

Yeah, that's kind of a good point. I had thought about it before, but
only briefly, and sort of discarded that as "clearly behaves as
expected". Though as you point out with the shell pipeline, that makes
it clearer that it would indeed make sense to have this behave
differently.

Detecting stdin==stdout doesn't make much sense, if one is closed the
other will also detect the close condition, and I believe they'll always
be different FDs anyway.

Changing it really shouldn't be hard, but it clearly looks like all of
this is intentional? Looking at arch/um/drivers/chan_kern.c:

void chan_interrupt(struct line *line, int irq)
{
...
        if (err == -EIO) {
                if (chan->primary) {
                        tty_port_tty_hangup(&line->port, false);
                        if (line->chan_out != chan)
                                close_one_chan(line->chan_out, 1);
                }
                close_one_chan(chan, 1);
                if (chan->primary)
                        return;
        }


and chan->primary is set here - though I couldn't figure out if it's
ever *not* set?

So I think we need Richard or somebody to chime in here - I can't really
disagree that the behaviour is strange, but clearly it seems intended,
for whatever reason.


> > 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?
> 
> This leads to strange behavior. But for this issue, I think the
> suggestion above would obviate the need to do anything about this.

Agree.

> Thanks, got a chuckle out of that.

I had to take that even further and ended up telling my kids that I just
told someone to not try talking to a dead cat ;-)

johannes



_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um