Bug 214611 - UM: stdout output ceases under certain conditions

Bug 214611 - UM: stdout output ceases under certain conditions

[Glenn Washburn]

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.

Separately, I noticed that the bugzilla told me that an email was being
sent to inout@users.sourceforge.net and jdike@karaya.com. My
understanding is that the Source Forge list is in active and that Jeff
Dike seems to not be an active maintainer. Regardless, I believe this
list should be on the list of recipients for created bug reports for
the UM architecture. Perhaps a maintainer can contact the buzilla team.

Glenn

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

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

Re: 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.


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

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

[Glenn Washburn]

On Mon, 04 Oct 2021 14:48:34 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:

> 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?

This was just a way to trigger the issue I was seeing. 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

I was confused why running this script caused UML to lose output always
when mounting the ubd in the UML mount script. And it didn't happen
when I ran "run_some_script_which_eventually_runs_uml" alone. Since the
amount of data returned by the grep was small, this issue was triggered
all the time. If the output were a lot of data, I might have noticed
that early runs of run_some_script_which_eventually_runs_uml would not
have output disappear after mounting. Thanks for debugging this.

> 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.

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.

> 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.

> 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.

Ok, I've confirmed that. I think that's another reason to fix this in
a manner that doesn't tie stdin to stdout, just hitting enter can make
outut disappear (non-intuitive). In my case, stdout was going to a file.
So my intuition would say that stdin (from a pipe) and stdout (to a
file) shouldn't be connected (yes a program can create any kind of
connection it wants, but it's not intuitive). It would be like rsync
-av dir1 dir2 < <(cat /dev/null) having its output disappear if you
pressed enter in the middle of the run.

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

Thanks, got a chuckle out of that.

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

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

[Johannes Berg]

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

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


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

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

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

[Johannes Berg]

On Mon, 2021-10-04 at 21:14 +0100, Anton Ivanov wrote:
> > 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.

He was running on 5.14.8, but I did all my experiments now with this on
5.15-rc, so master should be fine.

johannes


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

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

[Anton Ivanov]

On 04/10/2021 17:54, Glenn Washburn wrote:
> On Mon, 04 Oct 2021 14:48:34 +0200
> Johannes Berg <johannes@sipsolutions.net> wrote:
> 
>> 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?
> 
> This was just a way to trigger the issue I was seeing. 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
> 
> I was confused why running this script caused UML to lose output always
> when mounting the ubd in the UML mount script. And it didn't happen
> when I ran "run_some_script_which_eventually_runs_uml" alone. Since the
> amount of data returned by the grep was small, this issue was triggered
> all the time. If the output were a lot of data, I might have noticed
> that early runs of run_some_script_which_eventually_runs_uml would not
> have output disappear after mounting. Thanks for debugging this.
> 
>> 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.
> 
> 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.

There is an even more convoluted case where the stdin is a socket (which
is possible - you pass it to UML as a fd:N). That can be half-closed.

Looking at it at the moment, but to be honest, separating the logic for in
and out if the fd is the same is going to be quite difficult (if at all
possible). It all ends as EPOLL events at the bottom. Even if you handle IN
and OUT separately in the upper layers, the kernel will handle them as the
same fd and any event (f.e. closure) will show up on both.

A.

> 
>> 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.
> 
>> 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.
> 
> Ok, I've confirmed that. I think that's another reason to fix this in
> a manner that doesn't tie stdin to stdout, just hitting enter can make
> outut disappear (non-intuitive). In my case, stdout was going to a file.
> So my intuition would say that stdin (from a pipe) and stdout (to a
> file) shouldn't be connected (yes a program can create any kind of
> connection it wants, but it's not intuitive). It would be like rsync
> -av dir1 dir2 < <(cat /dev/null) having its output disappear if you
> pressed enter in the middle of the run.
> 
>>
>>
>> johannes
>>
>> [1] did I really just write that? heh.
> 
> Thanks, got a chuckle out of that.
> 
> _______________________________________________
> linux-um mailing list
> linux-um@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-um
> 

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

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

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

[Anton Ivanov]

On 06/10/2021 16:57, Anton Ivanov wrote:
> 
> 
> On 04/10/2021 17:54, Glenn Washburn wrote:
>> On Mon, 04 Oct 2021 14:48:34 +0200
>> Johannes Berg <johannes@sipsolutions.net> wrote:
>>
>>> 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?
>>
>> This was just a way to trigger the issue I was seeing. 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
>>
>> I was confused why running this script caused UML to lose output always
>> when mounting the ubd in the UML mount script. And it didn't happen
>> when I ran "run_some_script_which_eventually_runs_uml" alone. Since the
>> amount of data returned by the grep was small, this issue was triggered
>> all the time. If the output were a lot of data, I might have noticed
>> that early runs of run_some_script_which_eventually_runs_uml would not
>> have output disappear after mounting. Thanks for debugging this.
>>
>>> 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.
>>
>> 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.
> 
> There is an even more convoluted case where the stdin is a socket (which
> is possible - you pass it to UML as a fd:N). That can be half-closed.
> 
> Looking at it at the moment, but to be honest, separating the logic for in
> and out if the fd is the same is going to be quite difficult (if at all
> possible). It all ends as EPOLL events at the bottom. Even if you handle IN
> and OUT separately in the upper layers, the kernel will handle them as the
> same fd and any event (f.e. closure) will show up on both.

Further to this, the same holds even if we start playing games with multiple
EPOLL descriptors, dup-ing fds, etc, the event will still show up on all of
them.

I frankly do not have any ideas at present to solve this. This is just
the way it is - a file close event for one fd will show up on all instances
where it is mentioned.

A.

> 
> A.
> 
>>
>>> 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.
>>
>>> 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.
>>
>> Ok, I've confirmed that. I think that's another reason to fix this in
>> a manner that doesn't tie stdin to stdout, just hitting enter can make
>> outut disappear (non-intuitive). In my case, stdout was going to a file.
>> So my intuition would say that stdin (from a pipe) and stdout (to a
>> file) shouldn't be connected (yes a program can create any kind of
>> connection it wants, but it's not intuitive). It would be like rsync
>> -av dir1 dir2 < <(cat /dev/null) having its output disappear if you
>> pressed enter in the middle of the run.
>>
>>>
>>>
>>> johannes
>>>
>>> [1] did I really just write that? heh.
>>
>> Thanks, got a chuckle out of that.
>>
>> _______________________________________________
>> linux-um mailing list
>> linux-um@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-um
>>
> 

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

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

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

[Glenn Washburn]

On Wed, 6 Oct 2021 17:44:14 +0100
Anton Ivanov <anton.ivanov@kot-begemot.co.uk> wrote:

> 
> 
> On 06/10/2021 16:57, Anton Ivanov wrote:
> > 
> > 
> > On 04/10/2021 17:54, Glenn Washburn wrote:
> >> On Mon, 04 Oct 2021 14:48:34 +0200
> >> Johannes Berg <johannes@sipsolutions.net> wrote:
> >>
> >>> 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?
> >>
> >> This was just a way to trigger the issue I was seeing. 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
> >>
> >> I was confused why running this script caused UML to lose output always
> >> when mounting the ubd in the UML mount script. And it didn't happen
> >> when I ran "run_some_script_which_eventually_runs_uml" alone. Since the
> >> amount of data returned by the grep was small, this issue was triggered
> >> all the time. If the output were a lot of data, I might have noticed
> >> that early runs of run_some_script_which_eventually_runs_uml would not
> >> have output disappear after mounting. Thanks for debugging this.
> >>
> >>> 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.
> >>
> >> 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.
> > 
> > There is an even more convoluted case where the stdin is a socket (which
> > is possible - you pass it to UML as a fd:N). That can be half-closed.
> > 
> > Looking at it at the moment, but to be honest, separating the logic for in
> > and out if the fd is the same is going to be quite difficult (if at all
> > possible). It all ends as EPOLL events at the bottom. Even if you handle IN
> > and OUT separately in the upper layers, the kernel will handle them as the
> > same fd and any event (f.e. closure) will show up on both.
> 
> Further to this, the same holds even if we start playing games with multiple
> EPOLL descriptors, dup-ing fds, etc, the event will still show up on all of
> them.

Thanks for looking into this. If I'm understanding correctly, you're
looking at the case where the UML process has STDIN and STDOUT to the
same file descriptor. However, the situation is when STDIN is to a pipe
that gets closed and STDOUT is to something else (pty, tty, file,
different pipe, etc..). Does your logic still hold true in this case?

Glenn

> 
> I frankly do not have any ideas at present to solve this. This is just
> the way it is - a file close event for one fd will show up on all instances
> where it is mentioned.
> 
> A.
> 
> > 
> > A.
> > 
> >>
> >>> 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.
> >>
> >>> 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.
> >>
> >> Ok, I've confirmed that. I think that's another reason to fix this in
> >> a manner that doesn't tie stdin to stdout, just hitting enter can make
> >> outut disappear (non-intuitive). In my case, stdout was going to a file.
> >> So my intuition would say that stdin (from a pipe) and stdout (to a
> >> file) shouldn't be connected (yes a program can create any kind of
> >> connection it wants, but it's not intuitive). It would be like rsync
> >> -av dir1 dir2 < <(cat /dev/null) having its output disappear if you
> >> pressed enter in the middle of the run.
> >>
> >>>
> >>>
> >>> johannes
> >>>
> >>> [1] did I really just write that? heh.
> >>
> >> Thanks, got a chuckle out of that.
> >>
> >> _______________________________________________
> >> linux-um mailing list
> >> linux-um@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-um
> >>
> > 
> 

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

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

[Anton Ivanov]

On 06/10/2021 19:05, Glenn Washburn wrote:
> On Wed, 6 Oct 2021 17:44:14 +0100
> Anton Ivanov <anton.ivanov@kot-begemot.co.uk> wrote:
>
>>
>> On 06/10/2021 16:57, Anton Ivanov wrote:
>>>
>>> On 04/10/2021 17:54, Glenn Washburn wrote:
>>>> On Mon, 04 Oct 2021 14:48:34 +0200
>>>> Johannes Berg <johannes@sipsolutions.net> wrote:
>>>>
>>>>> 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?
>>>> This was just a way to trigger the issue I was seeing. 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
>>>>
>>>> I was confused why running this script caused UML to lose output always
>>>> when mounting the ubd in the UML mount script. And it didn't happen
>>>> when I ran "run_some_script_which_eventually_runs_uml" alone. Since the
>>>> amount of data returned by the grep was small, this issue was triggered
>>>> all the time. If the output were a lot of data, I might have noticed
>>>> that early runs of run_some_script_which_eventually_runs_uml would not
>>>> have output disappear after mounting. Thanks for debugging this.
>>>>
>>>>> 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.
>>>> 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.
>>> There is an even more convoluted case where the stdin is a socket (which
>>> is possible - you pass it to UML as a fd:N). That can be half-closed.
>>>
>>> Looking at it at the moment, but to be honest, separating the logic for in
>>> and out if the fd is the same is going to be quite difficult (if at all
>>> possible). It all ends as EPOLL events at the bottom. Even if you handle IN
>>> and OUT separately in the upper layers, the kernel will handle them as the
>>> same fd and any event (f.e. closure) will show up on both.
>> Further to this, the same holds even if we start playing games with multiple
>> EPOLL descriptors, dup-ing fds, etc, the event will still show up on all of
>> them.
> Thanks for looking into this. If I'm understanding correctly, you're
> looking at the case where the UML process has STDIN and STDOUT to the
> same file descriptor. However, the situation is when STDIN is to a pipe
> that gets closed and STDOUT is to something else (pty, tty, file,
> different pipe, etc..). Does your logic still hold true in this case?

No. They should be on different IRQs.

Question:

Have you tried using con0=null,fd:1 ?

Assign null explicitly to the input instead of a fd which is closed?

A


>
> Glenn
>
>> I frankly do not have any ideas at present to solve this. This is just
>> the way it is - a file close event for one fd will show up on all instances
>> where it is mentioned.
>>
>> A.
>>
>>> A.
>>>
>>>>> 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.
>>>>
>>>>> 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.
>>>> Ok, I've confirmed that. I think that's another reason to fix this in
>>>> a manner that doesn't tie stdin to stdout, just hitting enter can make
>>>> outut disappear (non-intuitive). In my case, stdout was going to a file.
>>>> So my intuition would say that stdin (from a pipe) and stdout (to a
>>>> file) shouldn't be connected (yes a program can create any kind of
>>>> connection it wants, but it's not intuitive). It would be like rsync
>>>> -av dir1 dir2 < <(cat /dev/null) having its output disappear if you
>>>> pressed enter in the middle of the run.
>>>>
>>>>>
>>>>> johannes
>>>>>
>>>>> [1] did I really just write that? heh.
>>>> Thanks, got a chuckle out of that.
>>>>
>>>> _______________________________________________
>>>> linux-um mailing list
>>>> linux-um@lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-um
>>>>

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


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

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

[Glenn Washburn]

On Wed, 6 Oct 2021 19:53:48 +0100
Anton Ivanov <anton.ivanov@kot-begemot.co.uk> wrote:

> On 06/10/2021 19:05, Glenn Washburn wrote:
> > On Wed, 6 Oct 2021 17:44:14 +0100
> > Anton Ivanov <anton.ivanov@kot-begemot.co.uk> wrote:
> >
> >>
> >> On 06/10/2021 16:57, Anton Ivanov wrote:
> >>>
> >>> On 04/10/2021 17:54, Glenn Washburn wrote:
> >>>> On Mon, 04 Oct 2021 14:48:34 +0200
> >>>> Johannes Berg <johannes@sipsolutions.net> wrote:
> >>>>
> >>>>> 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?
> >>>> This was just a way to trigger the issue I was seeing. 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
> >>>>
> >>>> I was confused why running this script caused UML to lose output always
> >>>> when mounting the ubd in the UML mount script. And it didn't happen
> >>>> when I ran "run_some_script_which_eventually_runs_uml" alone. Since the
> >>>> amount of data returned by the grep was small, this issue was triggered
> >>>> all the time. If the output were a lot of data, I might have noticed
> >>>> that early runs of run_some_script_which_eventually_runs_uml would not
> >>>> have output disappear after mounting. Thanks for debugging this.
> >>>>
> >>>>> 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.
> >>>> 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.
> >>> There is an even more convoluted case where the stdin is a socket (which
> >>> is possible - you pass it to UML as a fd:N). That can be half-closed.
> >>>
> >>> Looking at it at the moment, but to be honest, separating the logic for in
> >>> and out if the fd is the same is going to be quite difficult (if at all
> >>> possible). It all ends as EPOLL events at the bottom. Even if you handle IN
> >>> and OUT separately in the upper layers, the kernel will handle them as the
> >>> same fd and any event (f.e. closure) will show up on both.
> >> Further to this, the same holds even if we start playing games with multiple
> >> EPOLL descriptors, dup-ing fds, etc, the event will still show up on all of
> >> them.
> > Thanks for looking into this. If I'm understanding correctly, you're
> > looking at the case where the UML process has STDIN and STDOUT to the
> > same file descriptor. However, the situation is when STDIN is to a pipe
> > that gets closed and STDOUT is to something else (pty, tty, file,
> > different pipe, etc..). Does your logic still hold true in this case?
> 
> No. They should be on different IRQs.
> 
> Question:
> 
> Have you tried using con0=null,fd:1 ?
> 
> Assign null explicitly to the input instead of a fd which is closed?
> 
> A

I just tried that and it does not trigger the bug, which I'd expect.
This would be another work around, but I think it would be good to fix
the bug. What if you want to pipe some data to stdin? Then when program
on the write side of the pipe exits because its done sending data, the
UML will stop sending data to stdout because the pipe gets closed.  How
hard do you think this would be to fix?

Glenn

> 
> >
> > Glenn
> >
> >> I frankly do not have any ideas at present to solve this. This is just
> >> the way it is - a file close event for one fd will show up on all instances
> >> where it is mentioned.
> >>
> >> A.
> >>
> >>> A.
> >>>
> >>>>> 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.
> >>>>
> >>>>> 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.
> >>>> Ok, I've confirmed that. I think that's another reason to fix this in
> >>>> a manner that doesn't tie stdin to stdout, just hitting enter can make
> >>>> outut disappear (non-intuitive). In my case, stdout was going to a file.
> >>>> So my intuition would say that stdin (from a pipe) and stdout (to a
> >>>> file) shouldn't be connected (yes a program can create any kind of
> >>>> connection it wants, but it's not intuitive). It would be like rsync
> >>>> -av dir1 dir2 < <(cat /dev/null) having its output disappear if you
> >>>> pressed enter in the middle of the run.
> >>>>
> >>>>>
> >>>>> johannes
> >>>>>
> >>>>> [1] did I really just write that? heh.
> >>>> Thanks, got a chuckle out of that.
> >>>>
> >>>> _______________________________________________
> >>>> linux-um mailing list
> >>>> linux-um@lists.infradead.org
> >>>> http://lists.infradead.org/mailman/listinfo/linux-um
> >>>>
> 

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

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

[Anton Ivanov]

On 06/10/2021 20:48, Glenn Washburn wrote:
> On Wed, 6 Oct 2021 19:53:48 +0100
> Anton Ivanov <anton.ivanov@kot-begemot.co.uk> wrote:
>
>> On 06/10/2021 19:05, Glenn Washburn wrote:
>>> On Wed, 6 Oct 2021 17:44:14 +0100
>>> Anton Ivanov <anton.ivanov@kot-begemot.co.uk> wrote:
>>>
>>>> On 06/10/2021 16:57, Anton Ivanov wrote:
>>>>> On 04/10/2021 17:54, Glenn Washburn wrote:
>>>>>> On Mon, 04 Oct 2021 14:48:34 +0200
>>>>>> Johannes Berg <johannes@sipsolutions.net> wrote:
>>>>>>
>>>>>>> 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?
>>>>>> This was just a way to trigger the issue I was seeing. 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
>>>>>>
>>>>>> I was confused why running this script caused UML to lose output always
>>>>>> when mounting the ubd in the UML mount script. And it didn't happen
>>>>>> when I ran "run_some_script_which_eventually_runs_uml" alone. Since the
>>>>>> amount of data returned by the grep was small, this issue was triggered
>>>>>> all the time. If the output were a lot of data, I might have noticed
>>>>>> that early runs of run_some_script_which_eventually_runs_uml would not
>>>>>> have output disappear after mounting. Thanks for debugging this.
>>>>>>
>>>>>>> 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.
>>>>>> 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.
>>>>> There is an even more convoluted case where the stdin is a socket (which
>>>>> is possible - you pass it to UML as a fd:N). That can be half-closed.
>>>>>
>>>>> Looking at it at the moment, but to be honest, separating the logic for in
>>>>> and out if the fd is the same is going to be quite difficult (if at all
>>>>> possible). It all ends as EPOLL events at the bottom. Even if you handle IN
>>>>> and OUT separately in the upper layers, the kernel will handle them as the
>>>>> same fd and any event (f.e. closure) will show up on both.
>>>> Further to this, the same holds even if we start playing games with multiple
>>>> EPOLL descriptors, dup-ing fds, etc, the event will still show up on all of
>>>> them.
>>> Thanks for looking into this. If I'm understanding correctly, you're
>>> looking at the case where the UML process has STDIN and STDOUT to the
>>> same file descriptor. However, the situation is when STDIN is to a pipe
>>> that gets closed and STDOUT is to something else (pty, tty, file,
>>> different pipe, etc..). Does your logic still hold true in this case?
>> No. They should be on different IRQs.
>>
>> Question:
>>
>> Have you tried using con0=null,fd:1 ?
>>
>> Assign null explicitly to the input instead of a fd which is closed?
>>
>> A
> I just tried that and it does not trigger the bug, which I'd expect.
> This would be another work around, but I think it would be good to fix
> the bug. What if you want to pipe some data to stdin? Then when program
> on the write side of the pipe exits because its done sending data, the
> UML will stop sending data to stdout because the pipe gets closed.  How
> hard do you think this would be to fix?

I will see if we can do something about it.

I'd rather have this as an option instead of always enabled, because 
having it always on will break error handling elsewhere.

>
> Glenn
>
>>> Glenn
>>>
>>>> I frankly do not have any ideas at present to solve this. This is just
>>>> the way it is - a file close event for one fd will show up on all instances
>>>> where it is mentioned.
>>>>
>>>> A.
>>>>
>>>>> A.
>>>>>
>>>>>>> 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.
>>>>>>
>>>>>>> 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.
>>>>>> Ok, I've confirmed that. I think that's another reason to fix this in
>>>>>> a manner that doesn't tie stdin to stdout, just hitting enter can make
>>>>>> outut disappear (non-intuitive). In my case, stdout was going to a file.
>>>>>> So my intuition would say that stdin (from a pipe) and stdout (to a
>>>>>> file) shouldn't be connected (yes a program can create any kind of
>>>>>> connection it wants, but it's not intuitive). It would be like rsync
>>>>>> -av dir1 dir2 < <(cat /dev/null) having its output disappear if you
>>>>>> pressed enter in the middle of the run.
>>>>>>
>>>>>>> johannes
>>>>>>>
>>>>>>> [1] did I really just write that? heh.
>>>>>> Thanks, got a chuckle out of that.
>>>>>>
>>>>>> _______________________________________________
>>>>>> linux-um mailing list
>>>>>> linux-um@lists.infradead.org
>>>>>> http://lists.infradead.org/mailman/listinfo/linux-um
>>>>>>
> _______________________________________________
> linux-um mailing list
> linux-um@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-um


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


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

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

[Glenn Washburn]

On Wed, 6 Oct 2021 20:52:40 +0100
Anton Ivanov <anton.ivanov@kot-begemot.co.uk> wrote:

> On 06/10/2021 20:48, Glenn Washburn wrote:
> > On Wed, 6 Oct 2021 19:53:48 +0100
> > Anton Ivanov <anton.ivanov@kot-begemot.co.uk> wrote:
> >
> >> On 06/10/2021 19:05, Glenn Washburn wrote:
> >>> On Wed, 6 Oct 2021 17:44:14 +0100
> >>> Anton Ivanov <anton.ivanov@kot-begemot.co.uk> wrote:
> >>>
> >>>> On 06/10/2021 16:57, Anton Ivanov wrote:
> >>>>> On 04/10/2021 17:54, Glenn Washburn wrote:
> >>>>>> On Mon, 04 Oct 2021 14:48:34 +0200
> >>>>>> Johannes Berg <johannes@sipsolutions.net> wrote:
> >>>>>>
> >>>>>>> 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?
> >>>>>> This was just a way to trigger the issue I was seeing. 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
> >>>>>>
> >>>>>> I was confused why running this script caused UML to lose output always
> >>>>>> when mounting the ubd in the UML mount script. And it didn't happen
> >>>>>> when I ran "run_some_script_which_eventually_runs_uml" alone. Since the
> >>>>>> amount of data returned by the grep was small, this issue was triggered
> >>>>>> all the time. If the output were a lot of data, I might have noticed
> >>>>>> that early runs of run_some_script_which_eventually_runs_uml would not
> >>>>>> have output disappear after mounting. Thanks for debugging this.
> >>>>>>
> >>>>>>> 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.
> >>>>>> 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.
> >>>>> There is an even more convoluted case where the stdin is a socket (which
> >>>>> is possible - you pass it to UML as a fd:N). That can be half-closed.
> >>>>>
> >>>>> Looking at it at the moment, but to be honest, separating the logic for in
> >>>>> and out if the fd is the same is going to be quite difficult (if at all
> >>>>> possible). It all ends as EPOLL events at the bottom. Even if you handle IN
> >>>>> and OUT separately in the upper layers, the kernel will handle them as the
> >>>>> same fd and any event (f.e. closure) will show up on both.
> >>>> Further to this, the same holds even if we start playing games with multiple
> >>>> EPOLL descriptors, dup-ing fds, etc, the event will still show up on all of
> >>>> them.
> >>> Thanks for looking into this. If I'm understanding correctly, you're
> >>> looking at the case where the UML process has STDIN and STDOUT to the
> >>> same file descriptor. However, the situation is when STDIN is to a pipe
> >>> that gets closed and STDOUT is to something else (pty, tty, file,
> >>> different pipe, etc..). Does your logic still hold true in this case?
> >> No. They should be on different IRQs.
> >>
> >> Question:
> >>
> >> Have you tried using con0=null,fd:1 ?
> >>
> >> Assign null explicitly to the input instead of a fd which is closed?
> >>
> >> A
> > I just tried that and it does not trigger the bug, which I'd expect.
> > This would be another work around, but I think it would be good to fix
> > the bug. What if you want to pipe some data to stdin? Then when program
> > on the write side of the pipe exits because its done sending data, the
> > UML will stop sending data to stdout because the pipe gets closed.  How
> > hard do you think this would be to fix?
> 
> I will see if we can do something about it.
> 
> I'd rather have this as an option instead of always enabled, because 
> having it always on will break error handling elsewhere.

Interesting, for posterity, specifically what error handling would be
broken by this?

Glenn

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

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

[Anton Ivanov]

On 06/10/2021 22:28, Glenn Washburn wrote:
> On Wed, 6 Oct 2021 20:52:40 +0100
> Anton Ivanov <anton.ivanov@kot-begemot.co.uk> wrote:
>
>> On 06/10/2021 20:48, Glenn Washburn wrote:
>>> On Wed, 6 Oct 2021 19:53:48 +0100
>>> Anton Ivanov <anton.ivanov@kot-begemot.co.uk> wrote:
>>>
>>>> On 06/10/2021 19:05, Glenn Washburn wrote:
>>>>> On Wed, 6 Oct 2021 17:44:14 +0100
>>>>> Anton Ivanov <anton.ivanov@kot-begemot.co.uk> wrote:
>>>>>
>>>>>> On 06/10/2021 16:57, Anton Ivanov wrote:
>>>>>>> On 04/10/2021 17:54, Glenn Washburn wrote:
>>>>>>>> On Mon, 04 Oct 2021 14:48:34 +0200
>>>>>>>> Johannes Berg <johannes@sipsolutions.net> wrote:
>>>>>>>>
>>>>>>>>> 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?
>>>>>>>> This was just a way to trigger the issue I was seeing. 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
>>>>>>>>
>>>>>>>> I was confused why running this script caused UML to lose output always
>>>>>>>> when mounting the ubd in the UML mount script. And it didn't happen
>>>>>>>> when I ran "run_some_script_which_eventually_runs_uml" alone. Since the
>>>>>>>> amount of data returned by the grep was small, this issue was triggered
>>>>>>>> all the time. If the output were a lot of data, I might have noticed
>>>>>>>> that early runs of run_some_script_which_eventually_runs_uml would not
>>>>>>>> have output disappear after mounting. Thanks for debugging this.
>>>>>>>>
>>>>>>>>> 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.
>>>>>>>> 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.
>>>>>>> There is an even more convoluted case where the stdin is a socket (which
>>>>>>> is possible - you pass it to UML as a fd:N). That can be half-closed.
>>>>>>>
>>>>>>> Looking at it at the moment, but to be honest, separating the logic for in
>>>>>>> and out if the fd is the same is going to be quite difficult (if at all
>>>>>>> possible). It all ends as EPOLL events at the bottom. Even if you handle IN
>>>>>>> and OUT separately in the upper layers, the kernel will handle them as the
>>>>>>> same fd and any event (f.e. closure) will show up on both.
>>>>>> Further to this, the same holds even if we start playing games with multiple
>>>>>> EPOLL descriptors, dup-ing fds, etc, the event will still show up on all of
>>>>>> them.
>>>>> Thanks for looking into this. If I'm understanding correctly, you're
>>>>> looking at the case where the UML process has STDIN and STDOUT to the
>>>>> same file descriptor. However, the situation is when STDIN is to a pipe
>>>>> that gets closed and STDOUT is to something else (pty, tty, file,
>>>>> different pipe, etc..). Does your logic still hold true in this case?
>>>> No. They should be on different IRQs.
>>>>
>>>> Question:
>>>>
>>>> Have you tried using con0=null,fd:1 ?
>>>>
>>>> Assign null explicitly to the input instead of a fd which is closed?
>>>>
>>>> A
>>> I just tried that and it does not trigger the bug, which I'd expect.
>>> This would be another work around, but I think it would be good to fix
>>> the bug. What if you want to pipe some data to stdin? Then when program
>>> on the write side of the pipe exits because its done sending data, the
>>> UML will stop sending data to stdout because the pipe gets closed.  How
>>> hard do you think this would be to fix?
>> I will see if we can do something about it.
>>
>> I'd rather have this as an option instead of always enabled, because
>> having it always on will break error handling elsewhere.
> Interesting, for posterity, specifically what error handling would be
> broken by this?

The detection that a file "behind" a device is closed at present 
presently happens in the interrupt controller - it maps EPOLL events on 
the fds to IRQs. All file IO gets multiplexed through there.

Alternatively, we can try playing with this in the upper layer - the tty 
system channels. Some of them use external helpers and correct handling 
of file close is essential for them to work properly. We had bugs along 
these lines and had to fix them. F.E. commits 
9b1c0c0e25dcccafd30e7d4c150c249cc65550eb and 
9b1c0c0e25dcccafd30e7d4c150c249cc65550eb in the kernel tree fixed an 
actual tty handling bug.

All in all, if we add this functionality to the console/tty channels it 
should be an extra option, because it is opposite to existing behavior.

Brgds,

>
> Glenn
>

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


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

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

[Johannes Berg]

On Thu, 2021-10-07 at 08:00 +0100, Anton Ivanov wrote:
> 
> The detection that a file "behind" a device is closed at present 
> presently happens in the interrupt controller - it maps EPOLL events on 
> the fds to IRQs. All file IO gets multiplexed through there.

True. But it really just causes an IRQ event to be reported, the upper
layer is still responsible for reading and then handling the error on
the FD.

> All in all, if we add this functionality to the console/tty channels it 
> should be an extra option, because it is opposite to existing behavior.

As I pointed out earlier in the thread, somehow providing a way to get
chan->primary be not set would already provide the necessary behaviour.
I believe even when the FDs are identical (e.g. a socket), because we
separate read/write epoll and error handling.

johannes


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

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

[Anton Ivanov]

On 07/10/2021 08:03, Johannes Berg wrote:
> On Thu, 2021-10-07 at 08:00 +0100, Anton Ivanov wrote:
>> The detection that a file "behind" a device is closed at present
>> presently happens in the interrupt controller - it maps EPOLL events on
>> the fds to IRQs. All file IO gets multiplexed through there.
> True. But it really just causes an IRQ event to be reported, the upper
> layer is still responsible for reading and then handling the error on
> the FD.
>
>> All in all, if we add this functionality to the console/tty channels it
>> should be an extra option, because it is opposite to existing behavior.
> As I pointed out earlier in the thread, somehow providing a way to get
> chan->primary be not set would already provide the necessary behaviour.
> I believe even when the FDs are identical (e.g. a socket), because we
> separate read/write epoll and error handling.

The easiest way to provide this behavior is to add an option to the tty 
command line args and parse it. An optional extra "[,options]" after the 
fds will do the job.

>
> johannes
>
>

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


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