Re: [net-next-2.6 PATCH RFC] TCPCT part 1d: generate Responder Cookie

[Eric Dumazet <eric.dumazet@gmail.com>]

William Allen Simpson a écrit :
> William Allen Simpson wrote:
>> Yes.  Just shuffling the pointers without ever freeing anything.  So,
>> there's nothing for call_rcu() to do, and nothing else to synchronize
>> (only the pointers).  This assumes that after _unlock_ any CPU cache
>> with an old pointer->expires will hit the _lock_ code, and that will
>> update *both* ->expires and the other array elements concurrently?
>>
> Reiterating, I've not found Documentation showing that this code works:
> 
> +    unsigned long jiffy = jiffies;
> +
> +    if (unlikely(time_after(jiffy, tcp_secret_generating->expires))) {
> +        spin_lock_bh(&tcp_secret_locker);
> +        if (!time_after(jiffy, tcp_secret_generating->expires)) {
> +            /* refreshed by another */
> +            spin_unlock_bh(&tcp_secret_locker);
> +            memcpy(&xvp->cookie_bakery[0],
> +                   &tcp_secret_generating->secrets[0],
> +                   sizeof(tcp_secret_generating->secrets));
> +        } else {
> 
> How is it ensured that an old tcp_secret_generating or an old ->expires,
> followed by a spin_lock, has updated both?
> 
> And even when both are updated, then every word of the ->secrets array has
> also been updated in the local cache?
> 
> Is this a property of spin_lock()?  Or spin_unlock()?

Yes,  

$ vi +1121 Documentation/memory-barriers.txt

 (1) LOCK operation implication:

     Memory operations issued after the LOCK will be completed after the LOCK
     operation has completed.

     Memory operations issued before the LOCK may be completed after the LOCK
     operation has completed.

 (2) UNLOCK operation implication:

     Memory operations issued before the UNLOCK will be completed before the
     UNLOCK operation has completed.

     Memory operations issued after the UNLOCK may be completed before the
     UNLOCK operation has completed.