Re: Documenting writev(2) ENOBUFS error
Nik Clayton wrote: > > On Sat, Jul 31, 1999 at 06:50:09PM -0600, Wes Peters wrote: > > So, do you want to enumerate the cases in which this error can occur in the > > man page? This is not generally done, now that we have verified it is > > possible for the system to generate ENOBUFS on a writev. I think the text > > stands as it is. > > FWIW, I committed: > > [ENOBUFS]The mbuf pool has been completely exhausted when writing to > a socket Mmmm. Yummy. Do we want to mention that one or more of the vectors may have been written before the failure occurred, or is that OTTMCO? ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Documenting writev(2) ENOBUFS error
Nik Clayton wrote: > > On Sat, Jul 31, 1999 at 06:50:09PM -0600, Wes Peters wrote: > > So, do you want to enumerate the cases in which this error can occur in the > > man page? This is not generally done, now that we have verified it is > > possible for the system to generate ENOBUFS on a writev. I think the text > > stands as it is. > > FWIW, I committed: > > [ENOBUFS]The mbuf pool has been completely exhausted when writing to > a socket Mmmm. Yummy. Do we want to mention that one or more of the vectors may have been written before the failure occurred, or is that OTTMCO? ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Documenting writev(2) ENOBUFS error
On Sat, Jul 31, 1999 at 06:50:09PM -0600, Wes Peters wrote: > So, do you want to enumerate the cases in which this error can occur in the > man page? This is not generally done, now that we have verified it is > possible for the system to generate ENOBUFS on a writev. I think the text > stands as it is. FWIW, I committed: [ENOBUFS]The mbuf pool has been completely exhausted when writing to a socket ... N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <37514...@cs.colorado.edu> To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Documenting writev(2) ENOBUFS error
On Sat, Jul 31, 1999 at 06:50:09PM -0600, Wes Peters wrote: > So, do you want to enumerate the cases in which this error can occur in the > man page? This is not generally done, now that we have verified it is > possible for the system to generate ENOBUFS on a writev. I think the text > stands as it is. FWIW, I committed: [ENOBUFS]The mbuf pool has been completely exhausted when writing to a socket ... N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Documenting writev(2) ENOBUFS error
> > > :> [ENOBUFS] Insufficient system buffer space exists to complete > > > the op- > > > :>eration. > > > : > > > :Do you know what kind of circumstances that error *really* occurs > > > :under? > > > > So you can get ENOBUFS not related to mbufs for UDP/local datagram > > sockets, but you should never get ENOBUFS from write for TCP sockets > > or local stream sockets. > > So, do you want to enumerate the cases in which this error can occur in the > man page? This is not generally done, now that we have verified it is > possible for the system to generate ENOBUFS on a writev. I think the text > stands as it is. It should probably mention that it doesn't occur for most files (or that it only occurs for datagram sockets - although it probably applies to some types of raw sockets, too, and possibly non-PF_INET/PF_UNIX sockets) to avoid people doing unnecessary checking or implementing kernel code that bails out when it shouldn't. It should be a fair requirement that the kernel continue to never fail with ENOBUFS for a write to a reliable stream (local file, fifo, pipe or stream socket) and that such cases be treated as bugs. I would assume that this corresponds to how other systems operate, as well. Of course I'm no authority on this, and I'm not sure about NFS writes. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Documenting writev(2) ENOBUFS error
> > > :> [ENOBUFS] Insufficient system buffer space exists to complete the op- > > > :>eration. > > > : > > > :Do you know what kind of circumstances that error *really* occurs > > > :under? > > > > So you can get ENOBUFS not related to mbufs for UDP/local datagram > > sockets, but you should never get ENOBUFS from write for TCP sockets > > or local stream sockets. > > So, do you want to enumerate the cases in which this error can occur in the > man page? This is not generally done, now that we have verified it is > possible for the system to generate ENOBUFS on a writev. I think the text > stands as it is. It should probably mention that it doesn't occur for most files (or that it only occurs for datagram sockets - although it probably applies to some types of raw sockets, too, and possibly non-PF_INET/PF_UNIX sockets) to avoid people doing unnecessary checking or implementing kernel code that bails out when it shouldn't. It should be a fair requirement that the kernel continue to never fail with ENOBUFS for a write to a reliable stream (local file, fifo, pipe or stream socket) and that such cases be treated as bugs. I would assume that this corresponds to how other systems operate, as well. Of course I'm no authority on this, and I'm not sure about NFS writes. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Documenting writev(2) ENOBUFS error
Ville-Pertti Keinonen wrote: > > > :w...@softweyr.com (Wes Peters) writes: > > : > > :> [ENOBUFS] Insufficient system buffer space exists to complete > > the op- > > :>eration. > > : > > :Do you know what kind of circumstances that error *really* occurs > > :under? > > So you can get ENOBUFS not related to mbufs for UDP/local datagram > sockets, but you should never get ENOBUFS from write for TCP sockets > or local stream sockets. So, do you want to enumerate the cases in which this error can occur in the man page? This is not generally done, now that we have verified it is possible for the system to generate ENOBUFS on a writev. I think the text stands as it is. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Documenting writev(2) ENOBUFS error
Ville-Pertti Keinonen wrote: > > > :[EMAIL PROTECTED] (Wes Peters) writes: > > : > > :> [ENOBUFS] Insufficient system buffer space exists to complete the op- > > :>eration. > > : > > :Do you know what kind of circumstances that error *really* occurs > > :under? > > So you can get ENOBUFS not related to mbufs for UDP/local datagram > sockets, but you should never get ENOBUFS from write for TCP sockets > or local stream sockets. So, do you want to enumerate the cases in which this error can occur in the man page? This is not generally done, now that we have verified it is possible for the system to generate ENOBUFS on a writev. I think the text stands as it is. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Documenting writev(2) ENOBUFS error
> :w...@softweyr.com (Wes Peters) writes: > : > :> [ENOBUFS] Insufficient system buffer space exists to complete the > op- > :>eration. > : > :Do you know what kind of circumstances that error *really* occurs > :under? > : > :If it happened with files, that would be a bug and should be fixed. > :The call is supposed to block to wait for writes to be possible. This > > I am almost certain that this error can only occur when writing to > sockets, and only then of the network mbuf pool is completely exhausted. > UDP is probably the most vulernable. It looks to me like it can't happen to stream sockets using write/writev. As far as I can tell, the ENOBUFS error can occur internally for sends if: - There is a shortage of mbufs at a low level (at higher levels, code either blocks or panics) - A network interface has a lot of packets queued (this is done at an IP level) - The socket buffer of a local datagram socket is full (the receiving socket, not the one the send occurred on) The TCP layer doesn't let ENOBUFS from low-level calls get through, but returns success. A TCP socket is prepared to resend the data at a higher level, anyhow, so the data is not lost and an error doesn't need to be returned. OOB data or implicit connections can return ENOBUFS for TCP sends, but they are activated by parameters only available through the send/sendto API. So you can get ENOBUFS not related to mbufs for UDP/local datagram sockets, but you should never get ENOBUFS from write for TCP sockets or local stream sockets. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Documenting writev(2) ENOBUFS error
> :[EMAIL PROTECTED] (Wes Peters) writes: > : > :> [ENOBUFS] Insufficient system buffer space exists to complete the op- > :>eration. > : > :Do you know what kind of circumstances that error *really* occurs > :under? > : > :If it happened with files, that would be a bug and should be fixed. > :The call is supposed to block to wait for writes to be possible. This > > I am almost certain that this error can only occur when writing to > sockets, and only then of the network mbuf pool is completely exhausted. > UDP is probably the most vulernable. It looks to me like it can't happen to stream sockets using write/writev. As far as I can tell, the ENOBUFS error can occur internally for sends if: - There is a shortage of mbufs at a low level (at higher levels, code either blocks or panics) - A network interface has a lot of packets queued (this is done at an IP level) - The socket buffer of a local datagram socket is full (the receiving socket, not the one the send occurred on) The TCP layer doesn't let ENOBUFS from low-level calls get through, but returns success. A TCP socket is prepared to resend the data at a higher level, anyhow, so the data is not lost and an error doesn't need to be returned. OOB data or implicit connections can return ENOBUFS for TCP sends, but they are activated by parameters only available through the send/sendto API. So you can get ENOBUFS not related to mbufs for UDP/local datagram sockets, but you should never get ENOBUFS from write for TCP sockets or local stream sockets. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Documenting writev(2) ENOBUFS error
:w...@softweyr.com (Wes Peters) writes: : :> [ENOBUFS] Insufficient system buffer space exists to complete the op- :>eration. : :Do you know what kind of circumstances that error *really* occurs :under? : :If it happened with files, that would be a bug and should be fixed. :The call is supposed to block to wait for writes to be possible. This I am almost certain that this error can only occur when writing to sockets, and only then of the network mbuf pool is completely exhausted. UDP is probably the most vulernable. -Matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Documenting writev(2) ENOBUFS error
Ville-Pertti Keinonen wrote: > > w...@softweyr.com (Wes Peters) writes: > > > [ENOBUFS] Insufficient system buffer space exists to complete the > > op- > >eration. > > Do you know what kind of circumstances that error *really* occurs > under? > > If it happened with files, that would be a bug and should be fixed. > The call is supposed to block to wait for writes to be possible. This > applies to stream sockets in most cases, as well. Based on a quick > look at the code, out-of-band TCP data seems to be the only case where > ENOBUFS might be returned for streams, and that obviously doesn't > apply to write/writev. The only way writev can pick up an ENOBUFS error is in the call to (*fp->f_ops->fo_write)(fp, &auio, fp->f_cred, 0) on line 447 (in -CURRENT). ENOBUFS can happen on any network object if the system is completely out of mbufs, right? So it could return ENOBUFS for any connected socket specified as the fd in a write or writev operation. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Documenting writev(2) ENOBUFS error
:[EMAIL PROTECTED] (Wes Peters) writes: : :> [ENOBUFS] Insufficient system buffer space exists to complete the op- :>eration. : :Do you know what kind of circumstances that error *really* occurs :under? : :If it happened with files, that would be a bug and should be fixed. :The call is supposed to block to wait for writes to be possible. This I am almost certain that this error can only occur when writing to sockets, and only then of the network mbuf pool is completely exhausted. UDP is probably the most vulernable. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Documenting writev(2) ENOBUFS error
Ville-Pertti Keinonen wrote: > > [EMAIL PROTECTED] (Wes Peters) writes: > > > [ENOBUFS] Insufficient system buffer space exists to complete the op- > >eration. > > Do you know what kind of circumstances that error *really* occurs > under? > > If it happened with files, that would be a bug and should be fixed. > The call is supposed to block to wait for writes to be possible. This > applies to stream sockets in most cases, as well. Based on a quick > look at the code, out-of-band TCP data seems to be the only case where > ENOBUFS might be returned for streams, and that obviously doesn't > apply to write/writev. The only way writev can pick up an ENOBUFS error is in the call to (*fp->f_ops->fo_write)(fp, &auio, fp->f_cred, 0) on line 447 (in -CURRENT). ENOBUFS can happen on any network object if the system is completely out of mbufs, right? So it could return ENOBUFS for any connected socket specified as the fd in a write or writev operation. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Documenting writev(2) ENOBUFS error
w...@softweyr.com (Wes Peters) writes: > [ENOBUFS] Insufficient system buffer space exists to complete the op- >eration. Do you know what kind of circumstances that error *really* occurs under? If it happened with files, that would be a bug and should be fixed. The call is supposed to block to wait for writes to be possible. This applies to stream sockets in most cases, as well. Based on a quick look at the code, out-of-band TCP data seems to be the only case where ENOBUFS might be returned for streams, and that obviously doesn't apply to write/writev. As I mentioned to Nik in private mail, for datagram sockets, the description in send(2) more or less applies. Programs should generally use send rather than write for such objects, anyhow. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Documenting writev(2) ENOBUFS error
[EMAIL PROTECTED] (Wes Peters) writes: > [ENOBUFS] Insufficient system buffer space exists to complete the op- >eration. Do you know what kind of circumstances that error *really* occurs under? If it happened with files, that would be a bug and should be fixed. The call is supposed to block to wait for writes to be possible. This applies to stream sockets in most cases, as well. Based on a quick look at the code, out-of-band TCP data seems to be the only case where ENOBUFS might be returned for streams, and that obviously doesn't apply to write/writev. As I mentioned to Nik in private mail, for datagram sockets, the description in send(2) more or less applies. Programs should generally use send rather than write for such objects, anyhow. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Documenting writev(2) ENOBUFS error
Nik Clayton wrote: > > -hackers, > > Could someone who knows write/writev(2) take a quick look at docs/10512. > > In essence, writev(2) can fail with ENOBUFS if (and I quote from the PR) > if you "exhaust writev'able buffer space". This doesn't mean a great > deal to me, and I'm hoping one of you can take a look at come up with a > phrasing suitable for a man page. How does this look: [ENOBUFS] Insufficient system buffer space exists to complete the op- eration. Here's the patch against -current: --- write.2 Tue Jul 13 06:53:41 1999 +++ /home/wes/src/write.2 Thu Jul 29 08:49:54 1999 @@ -242,6 +242,8 @@ values in the .Fa iov array overflowed a 32-bit integer. +.It Bq Er ENOBUFS +Insufficient system buffer space exists to complete the operation. .El .Pp The -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Documenting writev(2) ENOBUFS error
Nik Clayton wrote: > > -hackers, > > Could someone who knows write/writev(2) take a quick look at docs/10512. > > In essence, writev(2) can fail with ENOBUFS if (and I quote from the PR) > if you "exhaust writev'able buffer space". This doesn't mean a great > deal to me, and I'm hoping one of you can take a look at come up with a > phrasing suitable for a man page. How does this look: [ENOBUFS] Insufficient system buffer space exists to complete the op- eration. Here's the patch against -current: --- write.2 Tue Jul 13 06:53:41 1999 +++ /home/wes/src/write.2 Thu Jul 29 08:49:54 1999 @@ -242,6 +242,8 @@ values in the .Fa iov array overflowed a 32-bit integer. +.It Bq Er ENOBUFS +Insufficient system buffer space exists to complete the operation. .El .Pp The -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message