All of lore.kernel.org
 help / color / mirror / Atom feed
From: jamal <hadi@cyberus.ca>
To: "Timo Teräs" <timo.teras@iki.fi>
Cc: netdev@vger.kernel.org
Subject: Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
Date: Wed, 16 Jan 2008 20:25:57 -0500	[thread overview]
Message-ID: <1200533157.4451.86.camel@localhost> (raw)
In-Reply-To: <478E1479.3020204@iki.fi>

On Wed, 2008-16-01 at 16:28 +0200, Timo Teräs wrote:
[..]
> Creating a separate af_key patch would not be a big problem. I was
> just hoping avoiding it as the xfrm_state / xfrm_policy changes
> modify the API and requires changing af_key also.

The way dumping is done by xfrm_user is consistent across all netlink
not just ipsec. Thats why i said it had broader implications. 
OTOH, theres a clear issue with pf_key.

> No. I'm not creating second copies of the SADB/SPD entries. The entries
> are just added to one more list.

Ah, sorry - yes, that sounds reasonable.
So what happens if i delete an entry; does it get removed from the list?
Also what happens on modification?

> If more entries are added, you can get notifications of them.

how would a user app (example racoon) appropriately deal with it?
Example an entry sits in the dump-list, it gets deleted - an event gets
generated user-space and later that entry shows up in user space dump.

cheers,
jamal


  reply	other threads:[~2008-01-17  1:26 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-13 12:26 [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key Timo Teräs
2008-01-16 13:52 ` jamal
2008-01-16 14:28   ` Timo Teräs
2008-01-17  1:25     ` jamal [this message]
2008-01-16 22:58   ` Herbert Xu
2008-01-17  1:39     ` jamal
2008-01-17  2:17       ` Herbert Xu
2008-01-17  5:54         ` Timo Teräs
2008-01-17 11:11           ` Herbert Xu
2008-01-17 12:21             ` Timo Teräs
2008-01-17 12:26             ` jamal
2008-01-17 12:42           ` jamal
2008-01-17 12:50             ` Herbert Xu
2008-01-17 13:18               ` jamal
2008-01-17 13:31               ` Timo Teräs
2008-01-17 21:34                 ` Herbert Xu
2008-01-18  6:45                   ` Timo Teräs
2008-01-18 14:08                     ` jamal
2008-01-17  6:27     ` Timo Teräs
2008-01-17  7:16       ` David Miller
2008-01-17  7:38         ` Timo Teräs
2008-01-17  7:59           ` David Miller
2008-01-17  8:11             ` Timo Teräs
2008-01-17  8:49               ` David Miller
2008-01-17  9:20                 ` Timo Teräs
2008-01-17  9:31                   ` David Miller
2008-01-17  9:38                     ` Timo Teräs
2008-01-17  9:44                       ` David Miller
2008-01-17 10:01                         ` Timo Teräs
2008-01-17 10:06                           ` David Miller
2008-01-17 11:00                             ` Timo Teräs
2008-01-17 11:08                               ` David Miller
2008-01-17 12:37                                 ` Timo Teräs

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=1200533157.4451.86.camel@localhost \
    --to=hadi@cyberus.ca \
    --cc=netdev@vger.kernel.org \
    --cc=timo.teras@iki.fi \
    /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.