Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 29 May 2012 22:06:10 +0100 (BST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        vasanth rao naik sabavat <vasanth.raonaik@gmail.com>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: SMP: protocol control block protection for a multithreaded process (ex: udp).
Message-ID:  <alpine.BSF.2.00.1205292204590.15505@fledge.watson.org>
In-Reply-To: <CAAuizBhn_QT4WCh1ZRyc%2BHBkOYGaGivsVGm4oLj-i9VY7a5wxw@mail.gmail.com>
References:  <CAAuizBjhGUUH3D3XN1t7WMnOPTq0vZjnV1QXGrR99qBOD34rGQ@mail.gmail.com> <CAAuizBhn_QT4WCh1ZRyc%2BHBkOYGaGivsVGm4oLj-i9VY7a5wxw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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@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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1205292204590.15505>