> Sure but syncache_expand() is entered with the tcbinfo already write locked
> which also protects the unlocking of the listening connection and the
> locking of the newly created socket. Around this part:
>
> /*
> * Socket is created in state SYN_RECEIVED.
>
On 19/12/2012 4:01 PM, Vijay Singh wrote:
Holding the pcbinfo lock prevents races between syncache_socket() and
accept(). See rwatson's comment just above tcp_usr_accept. I noted
this too (the comment above tod->tod_offload_socket() in tcp_syncache.c)
back when I updated the TOE code in the ker
>> Holding the pcbinfo lock prevents races between syncache_socket() and
>> accept(). See rwatson's comment just above tcp_usr_accept. I noted
>> this too (the comment above tod->tod_offload_socket() in tcp_syncache.c)
>> back when I updated the TOE code in the kernel.
>
> er, I think I told you
On 12/19/12 11:42, Navdeep Parhar wrote:
> On 12/19/12 11:31, Vijay Singh wrote:
>> As it is today, a socket upcall on a listener socket is made with the
>> V_tcbinfo lock held. [tcp_input -> syncache_socket -> sonewconn ->
>> sowakeup].
>>
>> I feel that the use of the V_tcbinfo is not consistent
On 19/12/2012 2:31 PM, Vijay Singh wrote:
As it is today, a socket upcall on a listener socket is made with the
V_tcbinfo lock held. [tcp_input -> syncache_socket -> sonewconn ->
sowakeup].
I feel that the use of the V_tcbinfo is not consistent in the syncache code.
In syncache_add(), we drop t
On 12/19/12 11:31, Vijay Singh wrote:
> As it is today, a socket upcall on a listener socket is made with the
> V_tcbinfo lock held. [tcp_input -> syncache_socket -> sonewconn ->
> sowakeup].
>
> I feel that the use of the V_tcbinfo is not consistent in the syncache code.
>
> In syncache_add(), w
As it is today, a socket upcall on a listener socket is made with the
V_tcbinfo lock held. [tcp_input -> syncache_socket -> sonewconn ->
sowakeup].
I feel that the use of the V_tcbinfo is not consistent in the syncache code.
In syncache_add(), we drop the lock before doing the lookup:
IN
schrieb Alexander V. Chernikov am 08.05.2011 15:09 (localtime):
> At the moment the only possible way to set packet fib from userland is
> ipfw(8) setfib rule. Since no 'setfib tablearg' exists ruleset grows
> with every fib.
> Additionally, there is no way to set packet fib before netgraph
> proc
