Netdev List
 help / color / mirror / Atom feed
From: jamal <hadi@cyberus.ca>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Patrick McHardy <kaber@trash.net>,
	Masahide NAKAMURA <nakam@linux-ipv6.org>,
	"David S. Miller" <davem@davemloft.net>,
	netdev <netdev@oss.sgi.com>
Subject: Re: take 2  WAS(Re: PATCH: IPSEC xfrm events
Date: 03 Apr 2005 21:56:01 -0400	[thread overview]
Message-ID: <1112579761.1096.412.camel@jzny.localdomain> (raw)
In-Reply-To: <20050404005805.GA16543@gondor.apana.org.au>

Herbert,
Now that you are picking on whitespaces i think we are almost there ;->
Comments below

On Sun, 2005-04-03 at 20:58, Herbert Xu wrote:

> On Sun, Apr 03, 2005 at 10:31:58AM -0400, jamal wrote:
[.. ..]

> > +
> > +EXPORT_SYMBOL(km_policy_notify);
> > +EXPORT_SYMBOL(km_state_notify);
> 
> Can we perhaps move these lines next to the other km functions
> further down? They look rather lonely here.
> 

Sure. 

> > +	/* XXX: Do we wanna do this right at the top??
> > +	 * if the state is dead we dont want to announce 
> > +	 * the expire - a delete may already have announced
> > +	 * it 
> > +	*/
> 
> Please code this check differently so that it isn't racy.
> 
> One way to do it is to change xfrm_timer_handler to do:
> 
> 	if (__xfrm_state_delete(x) && x->id.spi)
> 		km_state_expired(x, 1);
> 
> > +	/* XXX: Do we still wanna wakeup km_waitq?
> > +	 * if the policy is dead we dont want to announce 
> > +	 * the expire - a delete may already have announced
> > +	 * it 
> > +	*/
> 
> Ditto.
> 

I think i am gonna take out any attempts to address this race above.
It's a bug thats there already - a separate patch after this will be
better.

> > --- a/net/xfrm/xfrm_policy.c	2005-03-25 22:28:21.000000000 -0500
> > +++ b/net/xfrm/xfrm_policy.c	2005-04-02 12:16:30.000000000 -0500
> > @@ -298,7 +298,7 @@
> >   * entry dead. The rule must be unlinked from lists to the moment.
> >   */
> >  
> > -static void xfrm_policy_kill(struct xfrm_policy *policy)
> > +static void xfrm_policy_kill(struct xfrm_policy *policy, int dir)
> 
> What's this for?
>   

Good catch - gunk from previous patch.

> > +	c.seq = nlh->nlmsg_seq;
> > +	c.pid = nlh->nlmsg_pid;
> > +	if (nlh->nlmsg_type == XFRM_MSG_NEWSA)
> > +		c.event = XFRM_SAP_ADDED;
> > +	else
> > +		c.event = XFRM_SAP_UPDATED;
> > +
> > +	km_state_notify(x, &c);
> 
> You need to hold onto x here.  So do a hold before you call xfrm_state_*
> and then drop the reference after km_state_notify.

Good point.

>   
> >  static int xfrm_del_sa(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma)
>   
> > -	xfrm_state_delete(x);
> > +	err = xfrm_state_delete(x);
> > +	if (err < 0) {
> > +		x->km.state = XFRM_STATE_DEAD;
> > +		xfrm_state_put(x);
> > +		return err;
> 
> If the xfrm_state_delete fails then it's already dead.  So kill
> the line that modifies its state.
> 

Good point.

> > +static int xfrm_notify_sa( struct xfrm_state *x, struct km_event *c)
> 
> Extra space after the paren.
> 
> > +	int len = NLMSG_LENGTH(sizeof(struct xfrm_usersa_info));
> 
> Please add the additional payloads for NAT-T and the keys.
> 

I dont think we should broadcast out keys. 
NAT-T - where do i look at to see what to send?

> > +static int xfrm_notify_policy( struct xfrm_policy *xp, int dir, struct km_event *c)
> > +{
> > +	struct xfrm_userpolicy_info *p;
> > +	struct nlmsghdr *nlh;
> > +	struct sk_buff *skb;
> > +	u32 nlt = 0 ;
> > +	unsigned char *b;
> > +	int len = NLMSG_LENGTH(sizeof(struct xfrm_userpolicy_info));
> 
> Please attach the templates.
> 

What is not being attached right now?

> > @@ -1256,7 +1328,7 @@
> >  
> >  	if (hdr->sadb_msg_type == SADB_ADD)
> >  		err = xfrm_state_add(x);
> > -	else
> > +	else 
> 
> A better editor that doesn't leave trailing spaces is needed here :)

you insulting vi? ;->

>   	
> > -	xfrm_state_delete(x);
> > -	xfrm_state_put(x);
> > +	err = xfrm_state_delete(x);
> > +	if (err < 0) {
> > +		x->km.state = XFRM_STATE_DEAD;
> 
> Please remove this line as it's already dead if the delete fails.
>   
> > +static int key_notify_sa_flush(struct km_event *c)
> > +{
> > +	struct sk_buff *skb;
> > +	struct sadb_msg *hdr;
> > +
> > +	skb = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_ATOMIC);
> > +	if (!skb)
> > +		return -ENOBUFS;
> > +	hdr = (struct sadb_msg *) skb_put(skb, sizeof(struct sadb_msg));
> > +	// XXX:do we have to pass proto as well?
> 
> I think so.  A flush of all IPCOMP states is certainly quite different
> from a flush of all states.  It's just a matter of calling satype2proto.
> 

Looks doable.


> > -	pfkey_xfrm_policy2msg(out_skb, xp, pol->sadb_x_policy_dir-1);
> > -
> > -	out_hdr = (struct sadb_msg *) out_skb->data;
> > -	out_hdr->sadb_msg_version = hdr->sadb_msg_version;
> > -	out_hdr->sadb_msg_type = hdr->sadb_msg_type;
> > -	out_hdr->sadb_msg_satype = 0;
> > -	out_hdr->sadb_msg_errno = 0;
> > -	out_hdr->sadb_msg_seq = hdr->sadb_msg_seq;
> > -	out_hdr->sadb_msg_pid = hdr->sadb_msg_pid;
> > -	pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk);
> > -	err = 0;
> 
> However, you do need to keep this code for the real GET case.
> 

Get seems to a separate entry point - pfkey_get() which i didnt touch.

cheers,
jamal

  reply	other threads:[~2005-04-04  1:56 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-01  1:37 PATCH: IPSEC xfrm events jamal
2005-04-01  4:21 ` Herbert Xu
2005-04-01 11:03   ` jamal
2005-04-01 11:42     ` Herbert Xu
2005-04-01 12:24       ` jamal
2005-04-01 12:35         ` Herbert Xu
2005-04-01 12:59           ` jamal
2005-04-01 13:18             ` jamal
2005-04-01 14:19             ` Masahide NAKAMURA
2005-04-02  1:04           ` jamal
2005-04-02  1:28             ` Herbert Xu
2005-04-02  1:42               ` jamal
2005-04-02  1:45                 ` Herbert Xu
2005-04-02  1:46                 ` Herbert Xu
2005-04-02 19:20                   ` take 2 WAS(Re: " jamal
2005-04-03 14:31                     ` jamal
2005-04-03 15:47                       ` Patrick McHardy
2005-04-03 16:29                         ` jamal
2005-04-03 16:36                         ` jamal
2005-04-04  0:58                       ` Herbert Xu
2005-04-04  1:56                         ` jamal [this message]
2005-04-04  2:26                           ` Herbert Xu
2005-04-04  2:39                             ` jamal
2005-04-04  2:46                               ` Herbert Xu
2005-04-04  3:05                                 ` jamal
2005-04-04  2:34                         ` jamal
2005-04-04  2:52                           ` Herbert Xu
2005-04-04  3:07                             ` jamal
2005-04-04 11:38                         ` take 2-2 " jamal
2005-04-04 12:16                           ` Herbert Xu
2005-04-04 12:51                             ` jamal
2005-04-04 13:02                               ` Herbert Xu
2005-04-04 13:16                                 ` jamal
2005-04-04 21:31                                   ` Herbert Xu
2005-04-04 22:20                                     ` jamal
2005-04-04 22:25                                       ` David S. Miller
2005-04-04 22:42                                         ` jamal
2005-04-05  7:35                                           ` Masahide NAKAMURA
2005-04-05 10:18                                             ` jamal
2005-04-05 10:22                                               ` Herbert Xu
2005-04-05 10:35                                                 ` jamal
2005-04-05 11:58                                                 ` jamal
2005-04-05 17:46                                                   ` David S. Miller
2005-04-05 18:05                                                     ` jamal
2005-04-04  1:01                     ` take 2 " Herbert Xu
2005-04-04  1:58                       ` jamal
2005-04-04  2:27                         ` Herbert Xu
2005-04-01 17:28 ` Masahide NAKAMURA

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=1112579761.1096.412.camel@jzny.localdomain \
    --to=hadi@cyberus.ca \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=kaber@trash.net \
    --cc=nakam@linux-ipv6.org \
    --cc=netdev@oss.sgi.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox