Messages in this thread | | | Date | Thu, 05 Nov 2009 07:45:24 -0500 | From | William Allen Simpson <> | Subject | Re: [net-next-2.6 PATCH RFC] TCPCT part 1d: generate Responder Cookie |
| |
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()?
| |