* Bug 214611 - UM: stdout output ceases under certain conditions @ 2021-10-03 2:00 Glenn Washburn 2021-10-04 12:48 ` Johannes Berg 0 siblings, 1 reply; 16+ messages in thread From: Glenn Washburn @ 2021-10-03 2:00 UTC (permalink / raw) To: linux-um 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug 214611 - UM: stdout output ceases under certain conditions 2021-10-03 2:00 Bug 214611 - UM: stdout output ceases under certain conditions Glenn Washburn @ 2021-10-04 12:48 ` Johannes Berg 2021-10-04 16:54 ` Glenn Washburn 0 siblings, 1 reply; 16+ messages in thread From: Johannes Berg @ 2021-10-04 12:48 UTC (permalink / raw) To: development, linux-um 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug 214611 - UM: stdout output ceases under certain conditions 2021-10-04 12:48 ` Johannes Berg @ 2021-10-04 16:54 ` Glenn Washburn 2021-10-04 20:10 ` Johannes Berg 2021-10-06 15:57 ` Anton Ivanov 0 siblings, 2 replies; 16+ messages in thread From: Glenn Washburn @ 2021-10-04 16:54 UTC (permalink / raw) To: Johannes Berg; +Cc: linux-um 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug 214611 - UM: stdout output ceases under certain conditions 2021-10-04 16:54 ` Glenn Washburn @ 2021-10-04 20:10 ` Johannes Berg 2021-10-04 20:14 ` Anton Ivanov 2021-10-06 15:57 ` Anton Ivanov 1 sibling, 1 reply; 16+ messages in thread From: Johannes Berg @ 2021-10-04 20:10 UTC (permalink / raw) To: development; +Cc: linux-um 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug 214611 - UM: stdout output ceases under certain conditions 2021-10-04 20:10 ` Johannes Berg @ 2021-10-04 20:14 ` Anton Ivanov 2021-10-04 20:15 ` Johannes Berg 0 siblings, 1 reply; 16+ messages in thread From: Anton Ivanov @ 2021-10-04 20:14 UTC (permalink / raw) To: Johannes Berg, development; +Cc: linux-um 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug 214611 - UM: stdout output ceases under certain conditions 2021-10-04 20:14 ` Anton Ivanov @ 2021-10-04 20:15 ` Johannes Berg 0 siblings, 0 replies; 16+ messages in thread From: Johannes Berg @ 2021-10-04 20:15 UTC (permalink / raw) To: Anton Ivanov, development; +Cc: linux-um 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug 214611 - UM: stdout output ceases under certain conditions 2021-10-04 16:54 ` Glenn Washburn 2021-10-04 20:10 ` Johannes Berg @ 2021-10-06 15:57 ` Anton Ivanov 2021-10-06 16:44 ` Anton Ivanov 1 sibling, 1 reply; 16+ messages in thread From: Anton Ivanov @ 2021-10-06 15:57 UTC (permalink / raw) To: development, Johannes Berg; +Cc: linux-um 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug 214611 - UM: stdout output ceases under certain conditions 2021-10-06 15:57 ` Anton Ivanov @ 2021-10-06 16:44 ` Anton Ivanov 2021-10-06 18:05 ` Glenn Washburn 0 siblings, 1 reply; 16+ messages in thread From: Anton Ivanov @ 2021-10-06 16:44 UTC (permalink / raw) To: development, Johannes Berg; +Cc: linux-um 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug 214611 - UM: stdout output ceases under certain conditions 2021-10-06 16:44 ` Anton Ivanov @ 2021-10-06 18:05 ` Glenn Washburn 2021-10-06 18:53 ` Anton Ivanov 0 siblings, 1 reply; 16+ messages in thread From: Glenn Washburn @ 2021-10-06 18:05 UTC (permalink / raw) To: Anton Ivanov; +Cc: Johannes Berg, linux-um 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug 214611 - UM: stdout output ceases under certain conditions 2021-10-06 18:05 ` Glenn Washburn @ 2021-10-06 18:53 ` Anton Ivanov 2021-10-06 19:48 ` Glenn Washburn 0 siblings, 1 reply; 16+ messages in thread From: Anton Ivanov @ 2021-10-06 18:53 UTC (permalink / raw) To: development; +Cc: Johannes Berg, linux-um 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug 214611 - UM: stdout output ceases under certain conditions 2021-10-06 18:53 ` Anton Ivanov @ 2021-10-06 19:48 ` Glenn Washburn 2021-10-06 19:52 ` Anton Ivanov 0 siblings, 1 reply; 16+ messages in thread From: Glenn Washburn @ 2021-10-06 19:48 UTC (permalink / raw) To: Anton Ivanov; +Cc: Johannes Berg, linux-um 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug 214611 - UM: stdout output ceases under certain conditions 2021-10-06 19:48 ` Glenn Washburn @ 2021-10-06 19:52 ` Anton Ivanov 2021-10-06 21:28 ` Glenn Washburn 0 siblings, 1 reply; 16+ messages in thread From: Anton Ivanov @ 2021-10-06 19:52 UTC (permalink / raw) To: development; +Cc: Johannes Berg, linux-um 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug 214611 - UM: stdout output ceases under certain conditions 2021-10-06 19:52 ` Anton Ivanov @ 2021-10-06 21:28 ` Glenn Washburn 2021-10-07 7:00 ` Anton Ivanov 0 siblings, 1 reply; 16+ messages in thread From: Glenn Washburn @ 2021-10-06 21:28 UTC (permalink / raw) To: Anton Ivanov; +Cc: Johannes Berg, linux-um 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug 214611 - UM: stdout output ceases under certain conditions 2021-10-06 21:28 ` Glenn Washburn @ 2021-10-07 7:00 ` Anton Ivanov 2021-10-07 7:03 ` Johannes Berg 0 siblings, 1 reply; 16+ messages in thread From: Anton Ivanov @ 2021-10-07 7:00 UTC (permalink / raw) To: development; +Cc: Johannes Berg, linux-um 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug 214611 - UM: stdout output ceases under certain conditions 2021-10-07 7:00 ` Anton Ivanov @ 2021-10-07 7:03 ` Johannes Berg 2021-10-07 7:10 ` Anton Ivanov 0 siblings, 1 reply; 16+ messages in thread From: Johannes Berg @ 2021-10-07 7:03 UTC (permalink / raw) To: Anton Ivanov, development; +Cc: linux-um 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug 214611 - UM: stdout output ceases under certain conditions 2021-10-07 7:03 ` Johannes Berg @ 2021-10-07 7:10 ` Anton Ivanov 0 siblings, 0 replies; 16+ messages in thread From: Anton Ivanov @ 2021-10-07 7:10 UTC (permalink / raw) To: Johannes Berg, development; +Cc: linux-um 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2021-10-07 7:10 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-10-03 2:00 Bug 214611 - UM: stdout output ceases under certain conditions Glenn Washburn 2021-10-04 12:48 ` Johannes Berg 2021-10-04 16:54 ` Glenn Washburn 2021-10-04 20:10 ` Johannes Berg 2021-10-04 20:14 ` Anton Ivanov 2021-10-04 20:15 ` Johannes Berg 2021-10-06 15:57 ` Anton Ivanov 2021-10-06 16:44 ` Anton Ivanov 2021-10-06 18:05 ` Glenn Washburn 2021-10-06 18:53 ` Anton Ivanov 2021-10-06 19:48 ` Glenn Washburn 2021-10-06 19:52 ` Anton Ivanov 2021-10-06 21:28 ` Glenn Washburn 2021-10-07 7:00 ` Anton Ivanov 2021-10-07 7:03 ` Johannes Berg 2021-10-07 7:10 ` Anton Ivanov
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.