netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>,
	Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: gre: minor cleanups in netlink interface
Date: Sat, 11 Oct 2008 17:15:40 +0200	[thread overview]
Message-ID: <48F0C31C.8080501@trash.net> (raw)
In-Reply-To: <20081011150340.GA7520@gondor.apana.org.au>

Herbert Xu wrote:
> On Sat, Oct 11, 2008 at 04:43:03PM +0200, Patrick McHardy wrote:
>> We don't have much precedent for rtnl_link besides VLAN (which
>> does support incremental changes), but actually all other route
>> netlink interfaces do support incremental changes by sending only
>> a subset of the attributes. A reason for supporting this in the
>> interface is that incremental userspace changes will always be
>> racy because you need two seperate operations.
> 
> It is true that it is going to be racy when done in user-space,
> however that's easily solved with locking.  Even if we did the
> incremental change in the kernel it only helps certain kinds of
> usage scenarios.  For instance, if the race is between two updates
> to the local address you're still going to need synchronisation
> in user-space.

Thats true.

> Having said that, I'm certainly not against changing the interface
> since you do have precedence with the other two :)
> 
> Do be warned that doing this for GRE is going to be less trivial
> than the existing rtnl link interfaces.  For example, we'll need
> to break down the iflags/oflags into individual bits as otherwise
> you'll be back in the same situation.  It's a good thing that
> there aren't too many bits in use :)

We usually use two values (value + mask) for flags.

> Also, for ikey/okey we'll need to introduce another attribute to
> indicate their presence as well as their value.

The flags already indicate whether keys should be used, don't
they? So if you want to unset them, you can simply unset the
GRE_KEY flag.

I'll give it a shot and will post a patch, probably tommorrow.

> Hmm, it seems that there is a bug in how we treat a zero key.
> You can't have a tunnel with a zero key and one with no key at
> the same time.
> 
> In fact my latest iproute patch has a similar problem.  You
> can't unset the ikey/okey except by deleting the tunnel.  On
> the other hand the old ip tunnel interface has the same bug :)

I can't find it :)

  reply	other threads:[~2008-10-11 15:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-10 16:04 gre: minor cleanups in netlink interface Patrick McHardy
2008-10-10 19:11 ` David Miller
2008-10-11 10:39 ` Herbert Xu
2008-10-11 12:43   ` Herbert Xu
2008-10-11 19:20     ` David Miller
2008-10-11 14:43   ` Patrick McHardy
2008-10-11 14:45     ` Patrick McHardy
2008-10-11 15:18       ` Herbert Xu
2008-10-11 15:39         ` Patrick McHardy
2008-10-11 15:03     ` Herbert Xu
2008-10-11 15:15       ` Patrick McHardy [this message]
2008-10-11 15:26         ` Herbert Xu

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=48F0C31C.8080501@trash.net \
    --to=kaber@trash.net \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).