SMP: protocol control block protection for a multithreaded process (ex: udp).

[Robert Watson]

On Tue, 29 May 2012, vasanth rao naik sabavat wrote:

> Can somebody please reply to this email.
>
> basically, can udp_detach() and udp_send() execute simultaneously for a 
> process with multiple threads? if yes, then inp reference in udp_send() will 
> be stale if udp_detach() free's the inp?

You are confusing application-level close() with an actual close in the socket 
implementation.  The socket will remain allocated as long as there are 
consumers using it, which is ensured through a reference count on the socket, 
regardless of close().  That isn't to say that there aren't bugs -- this stuff 
is pretty complex -- but the life cycle and synchronisation models around 
sockets should prevent the scenario you are describing from occurring.

Robert

>
> Thanks,
> Vasanth
>
>
>
> On Tue, May 29, 2012 at 10:53 AM, vasanth rao naik sabavat <
> vasanth.raonaik at gmail.com> wrote:
>
>> Hi,
>>
>> In case of a Multicore cpu system running a multithreaded process.
>>
>> For protocol control blocks there is no protection provided in the FreeBSD
>> 9. For example, udp_close() and udp_send() access the inp before taking the
>> lock. Couldn't this cause the inp inconsistency on a multithreaded process
>> running on multicore cpu system?
>>
>> Say, If the two threads of a process are concurrently executing socket
>> send and socket close say on a udp connection (this can happen in case of
>> poorly written user code.).
>> udp_close() will access the inp on one cpu and udp_send() will access the
>> inp on another cpu. it is possible that udp_close() gets the locks first
>> and free's the inp before udp_send() has a chance to run?
>>
>> Am I missing anything?
>>
>> Thanks,
>> Vasanth
>>
>>
>>
>>
>>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>