All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlad Yasevich <vladislav.yasevich@hp.com>
To: netdev@vger.kernel.org
Cc: lksctp-developers@lists.sourceforge.net
Subject: Re: [RFC v2 PATCH 0/2] Add RCU locking to SCTP address management
Date: Wed, 12 Sep 2007 16:59:48 -0400	[thread overview]
Message-ID: <46E85344.1030402@hp.com> (raw)
In-Reply-To: <11896263983281-git-send-email-vladislav.yasevich@hp.com>

Vlad Yasevich wrote:
> Ok, this is version 2 of the patch that incorporates comments from
> Sridhar Samudrala and Paul McKenney.
> 
> The changes icorporated are:
>  1.  Add locking around the modification of the global sctp_local_addr_list
>  when processing the notifiers.  After looking around, it is possible for
>  the IPv4 and IPv6 notifiers to be called at the same time, which means that
>  we need a spin lock.
> 
>  2.  After the Paul's explanation of why writers would would to call
>  rcu_read_lock, it's apparent that we really don't need that in our usage.
>  I've removed all that I could find and conser safe.
> 
>  3. I took Paul's suggestiong of passing an explicit rcu callback when
>  removing entries from the list since these can be done it different
>  contexts.  This made the removal code rather simple.

Paul Moore just pointed out that using rcu versions of list traversal
macros inside the writer protected sections is just plain silly, so
consider that another change.

I'll update patch 2/2 with that comment.

-vlad

> 
> Things I've left behind:
>  1.  The valid flag remains.  After discussing the virtues with Paul Moore
>  (who used the same functionality in Netlabel code), I think that the
>  valid flag slightly reduces the possibility that the reader will use
>  an entry that's about to be removed.  It's a good thing in our case.
>  It doesn't really harm anything if a reader used a !valid entry, but
>  I'd like to reduce that chance.
> 
> I would appreciate any further comments

  parent reply	other threads:[~2007-09-12 21:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-12 19:46 [RFC v2 PATCH 0/2] Add RCU locking to SCTP address management Vlad Yasevich
2007-09-12 19:46 ` [RFC v2 PATCH 1/2] SCTP: Add RCU synchronization around sctp_localaddr_list Vlad Yasevich
2007-09-12 22:26   ` Paul E. McKenney
2007-09-12 23:03   ` Sridhar Samudrala
2007-09-13 13:46     ` Vlad Yasevich
2007-09-12 19:46 ` [RFC v2 PATCH 2/2] SCTP: Convert bind_addr_list locking to RCU Vlad Yasevich
2007-09-12 20:59 ` Vlad Yasevich [this message]
2007-09-12 21:03   ` [RFC v3 PATCH 2/21] " Vlad Yasevich
2007-09-12 22:33     ` Paul E. McKenney
2007-09-13 17:59       ` Sridhar Samudrala
2007-09-13 18:15         ` Vlad Yasevich
2007-09-13 19:33         ` [Lksctp-developers] " Vlad Yasevich
2007-09-13 19:56           ` Sridhar Samudrala
2007-09-13 20:14             ` Vlad Yasevich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46E85344.1030402@hp.com \
    --to=vladislav.yasevich@hp.com \
    --cc=lksctp-developers@lists.sourceforge.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.