similar to: ssh client is setting O_NONBLOCK on a pipe shared with other processes

> So the make process gets an EAGAIN on the write syscall and doesn't > retry? That sounds like a bug in whatever make you're using, since > that could potentially occur in other circumstances too. What other circumstances? EAGAIN means that something put the device into non-blocking mode, and normally, that should only happen if the program calling write had itself previously

> Case in point; EAGAIN can come if you give your fd to another process > and continue using it yourself. > Short counts; It is documented behavior that read() and write() may > return short counts. It is not documented why, so you can not make > any assumptions. You might be right about short counts but if you're right about EAGAIN, there are bugs everywhere. My first

> ssh has to set NONBLOCK otherwise it can, well, block - there's > no way for ssh to know a priori how much data it can write to a fd. I don't know anything about how ssh is structured, but I think it must be a bit more complicated than that. Ssh only sets O_NONBLOCK on an fd if isatty(fd) returns false, so it's able to function with blocking input and output if the relevant

On 11/08/2020 16:28, mwilck at suse.com wrote: > From: Martin Wilck <mwilck at suse.com> > > If a program opens /dev/hwrng with O_NONBLOCK and uses poll() and > non-blocking read() to retrieve random data, it ends up in a tight > loop with poll() always returning POLLIN and read() returning EAGAIN. > This repeats forever until some process makes a blocking read() call.

On 11/08/2020 16:28, mwilck at suse.com wrote: > From: Martin Wilck <mwilck at suse.com> > > If a program opens /dev/hwrng with O_NONBLOCK and uses poll() and > non-blocking read() to retrieve random data, it ends up in a tight > loop with poll() always returning POLLIN and read() returning EAGAIN. > This repeats forever until some process makes a blocking read() call.

I noted a possible problem restoring a machine. In xc_domain_restore (xc_domain_restore.c) if it''s not the last checkpoint we set O_NONBLOCK flag (search for fcntl) that we can call pagebuf_get or just load other pages (see following "goto loadpages;" line). Now we could ending up calling xc_tmem_restore/xc_tmem_restore_extra (xc_tmem.c) which call read_extract (xc_private.c)

https://bugzilla.mindrot.org/show_bug.cgi?id=1467 Summary: SFTP stalls Classification: Unclassified Product: Portable OpenSSH Version: 5.0p1 Platform: Other OS/Version: Other Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: bitbucket at mindrot.org ReportedBy: sconeu

As the start of work to add remote support, I'm taking a close look at the protocol layer in the library. These are some small cleanups. Rich.

I've been taking a long hard look at the protocol layer. It has evolved over a long time without any particular direction, and the result is, to say the least, not very organized. These patches take a first step at cleaning up the mess by abstracting out socket operations from the rest of the code. The purpose of this is to allow us to slot in a different connection layer under the

Hi, I attached the changes I made to a vanilla libguestfs-1.22.6 in order to make it work in mingw/win32. Added is also the patch required to make QEMU compatible (add a command to QMP that lists the supported devices (the regilat way you do it print it to stderr, which is difficult to redirect in win32)). This is done on behalf of Intel Corp. Thanks, Or (oberon in irc)

FYI in order to get 2.1.1p2 to work on my HP-UX 11.0 systems I had to patch atomicio.c for EWOULDBLOCK (HP read() does not give the POSIX return code). The new atomicio() is a clean fix for this timing problem; all it needs now is this one little tweak. Also had the "General Commercial Security" error (PAM_TERM_ERROR from pam_acct_mgmt()) which I have very crudely addressed for now by

I also made the code a bit more robust about closing the socket along error paths. --- generator/states-connect.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/generator/states-connect.c b/generator/states-connect.c index ba8b240..a69b70f 100644 --- a/generator/states-connect.c +++ b/generator/states-connect.c @@ -27,6 +27,7 @@ #include

We recently tried upgrading openssh from 2.5.2p2 to 2.9p1 and discovered that it no longer worked to feed the output from a remote command into a pipe, unless the output was short and the pipe was very fast at processing its input. Example 1: ssh remote_machine some_command | less (where "some_command" generates a lot of output) now fails after the first screenful, with a

http://bugzilla.mindrot.org/show_bug.cgi?id=26 ------- Additional Comments From markus at openbsd.org 2002-08-23 08:21 ------- hm, what do you suggest? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

On 11/08/2020 15:14, Michael S. Tsirkin wrote: > On Tue, Aug 11, 2020 at 03:00:14PM +0200, Laurent Vivier wrote: >> No problem. This code is tricky and it took me several months to really >> start to understand it ... > > Oh great, we actually have someone who understands the code! > Maybe you can help me understand: virtio_read > takes the buf pointer and puts it in

On 11/08/2020 15:14, Michael S. Tsirkin wrote: > On Tue, Aug 11, 2020 at 03:00:14PM +0200, Laurent Vivier wrote: >> No problem. This code is tricky and it took me several months to really >> start to understand it ... > > Oh great, we actually have someone who understands the code! > Maybe you can help me understand: virtio_read > takes the buf pointer and puts it in

On 5/25/19 3:22 PM, Eric Blake wrote: > On 5/25/19 1:33 PM, Richard W.M. Jones wrote: >> I also made the code a bit more robust about closing the socket along >> error paths. >> --- >> generator/states-connect.c | 21 ++++++++++++++++++--- >> 1 file changed, 18 insertions(+), 3 deletions(-) >> > >> assert (!h->sock); >> assert

On 11/08/2020 14:53, Martin Wilck wrote: > On Tue, 2020-08-11 at 14:39 +0200, Laurent Vivier wrote: >> On 11/08/2020 14:22, Martin Wilck wrote: >>> On Tue, 2020-08-11 at 14:02 +0200, Laurent Vivier wrote: >>>>>> drivers/char/hw_random/virtio-rng.c | 14 ++++++++++++++ >>>>>> 1 file changed, 14 insertions(+) >>>>>>

On 11/08/2020 14:53, Martin Wilck wrote: > On Tue, 2020-08-11 at 14:39 +0200, Laurent Vivier wrote: >> On 11/08/2020 14:22, Martin Wilck wrote: >>> On Tue, 2020-08-11 at 14:02 +0200, Laurent Vivier wrote: >>>>>> drivers/char/hw_random/virtio-rng.c | 14 ++++++++++++++ >>>>>> 1 file changed, 14 insertions(+) >>>>>>

http://bugzilla.mindrot.org/show_bug.cgi?id=26 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From djm at mindrot.org 2003-01-07 15:03