SMP: protocol control block protection for a multithreaded
process (ex: udp).
vasanth rao naik sabavat
vasanth.raonaik at gmail.com
Tue May 29 22:06:16 UTC 2012
My main concern is about the protocol control block "inp", a reference in
the socket structure. the udp_detach() free'es the inp but there is a
potential for other thread running udp_* functions to get hold of the
reference? Also, sofree() calls SOCK_UNLOCK() which potentially may allow
other thread of the same process to enter into the udp_* functions? I am
not sure if that is ever possible.
On Tue, May 29, 2012 at 5:06 PM, Robert Watson <rwatson at freebsd.org> wrote:
> 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
>> On Tue, May 29, 2012 at 10:53 AM, vasanth rao naik sabavat <
>> vasanth.raonaik at gmail.com> wrote:
>>> In case of a Multicore cpu system running a multithreaded process.
>>> For protocol control blocks there is no protection provided in the
>>> 9. For example, udp_close() and udp_send() access the inp before taking
>>> lock. Couldn't this cause the inp inconsistency on a multithreaded
>>> 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?
>> freebsd-hackers at freebsd.org mailing list
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@**
>> freebsd.org <freebsd-hackers-unsubscribe at freebsd.org>"
More information about the freebsd-hackers