lkml.org 
[lkml]   [2009]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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()?


    \
     
     \ /
      Last update: 2009-11-05 13:47    [W:3.243 / U:0.096 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site