Re: CVS commit: src/sys/kern

[Andrew Doran <ad%netbsd.org@localhost>]

On Thu, Oct 16, 2008 at 11:46:51AM +0100, Iain Hibbert wrote:

> On Thu, 16 Oct 2008, Andrew Doran wrote:
> 
> > On Sun, Oct 12, 2008 at 09:26:50AM +0000, Iain Hibbert wrote:
> >
> > > fix problem pointed out by ad where sockopt may end up sleeping
> > > inappropriately with the socket lock held.
> >
> > Are you sure that enough space is always be available for sockopt_set()?
> > If not, legitimate operations will be failed if the system is paging.
> 
> I'm not sure if I understand the question (context) exactly, but I think
> the answer is that yes, sockopt_set() may fail due to lack of memory (uses
> KM_NOSLEEP if allocation is required) but ENOMEM will be returned in that
> case. It is of course up to the caller to make sure the return code is
> checked and handle it properly (I believe all instances do)
> 
> If you need to use sockopt_set() in a context where memory allocation may
> be required and you don't want to consider failure, then the sockopt
> structure can be initialised in a better context with an appropriate
> memory buffer using sockopt_init() which may sleep.
> 
> does this need clarifying in sockopt(9) ?
> 
> If you are referring to userland, then it is true that getsockopt(2) can
> fail for lack of memory but it always could, if mbufs were somehow
> exhausted

My question is, is there an instance where an operation on a socket can now
fail with ENOMEM, where it would not have failed when we were passing data
around in mbufs?

Andrew