Closing a socket.

[Till Straumann]

Chris Johns wrote:

> Joel Sherrill <joel at OARcorp.com> wrote:
>
>>
>> But if the socket is closed, then shouldn't there be a path from the
>> blocking object going away which indicates an error occurred so
>> future references to freed resources can be avoided.
>>
>
> I have been looking into the code and making progress but see a 
> potential problem I would like feedback on.
>
> Some of system calls in rtems_syscalls.c need to pass parameters to 
> the BSD code in an mbuf. This is a source of socket close problems as 
> the mbuf request is WAIT. If the mbufs are gone the network semaphore 
> is released a close could proceed and free the socket struct which the 
> system call has a pointer to and using.
>
> This is simple to fix by reordering the system calls to get the mbuf 
> before the socket struct is obtained from the fd. If the socket closes 
> while waiting the socket struct will not be found and call will fail 
> with an error.
>
> The problem how-ever is the lack of mbufs could hold the system call 
> for an unknown period of time and a close would not have any effect. 
> If a thread is to delete itself which is what we seem to agree on, the 
> thread will also be blocked.
>
> Should the m_get call be changed to no wait and ENOBUFS returned in 
> errno ?


Probably. If the system is so loaded that there are not enough buffers 
you are likely
to have problems anyways. 'no wait' backs off from trying to get 
resources more
aggressively and is IMO preferrable to 'wait'.

-- Till

>
>