Bug 214611 - UM: stdout output ceases under certain conditions

[Anton Ivanov]

On 04/10/2021 21:10, Johannes Berg wrote:
> 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.
>

I will have a look at it tomorrow. I remember fixing a similar bug 
around 5.4-ish which was in the tree since the time of the dinosaurs.

I assume Glenn is running master, right? If not, what version.

Brgds,


> 
>>> 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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-um
> 


-- 
Anton R. Ivanov
https://www.kot-begemot.co.uk/