All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Haller <thaller@redhat.com>
To: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Jiri Pirko <jiri@resnulli.us>,
	netdev@vger.kernel.org, stephen@networkplumber.org,
	dcbw@redhat.com
Subject: Re: [PATCH v2 2/2] ipv6 addrconf: don't cleanup route prefix for IFA_F_NOPREFIXROUTE
Date: Tue, 07 Jan 2014 23:54:22 +0100	[thread overview]
Message-ID: <1389135262.2248.42.camel@weing> (raw)
In-Reply-To: <20140107190148.GD30393@order.stressinduktion.org>

[-- Attachment #1: Type: text/plain, Size: 2956 bytes --]

On Tue, 2014-01-07 at 20:01 +0100, Hannes Frederic Sowa wrote:
> On Tue, Jan 07, 2014 at 07:32:57PM +0100, Thomas Haller wrote:
> > On Tue, 2014-01-07 at 17:28 +0100, Hannes Frederic Sowa wrote:
> > > On Tue, Jan 07, 2014 at 03:39:13PM +0100, Thomas Haller wrote:
> > > > Also, when adding the NOPREFIXROUTE flag to an already existing address,
> > > > check if there there is a prefix that was likly added by the kernel
> > > > and delete it.
> > > 
> > > Hmm, could you give a bit more details why you have done this? I find
> > > that a bit counterintuitive. Maybe it has a reason?
> > > 
> > 
> > You find the behavior or the commit message counterintuitive? Didn't you
> > suggest this behavior in your email from "7 Jan 2014 13:01:11 +0100"?
> 
> I guess I was a bit confused, sorry. I think I confused the deleted and modify
> case. However:
> 
> So we have the following changes on addresses:
> 
> add is simple: just as in the first patch
> 
> modify: is a bit hairy. To be extremly exact, we would have to recreate the
> 	route with proper metrics etc. so delete in any case and reinsert.
> 	I really dislike removing a route someone else might have inserted
> 	manually, and this is a likely scenario.
> 
> 	Somehow I tend to just don't allow NOPREFIXROUTE on modify at all and
> 	just return a proper error value. What do you think? What would be the
> 	best behavior for NM?
> 
> delete: if IFA_F_NOPREFIXROUTE is set, we don't care about removing a prefix
> 	route, it must be set by user space and should get cleaned up by user
> 	space
> 
> > 
> > 
> > For v3 I will reword the commit message. How about the following:
> > ...
> 
> If we want go with the current modify behavior this sounds good.


Hi,


I think, the modify case is not that hairy and the patch does IMO the
sensible thing:

case 1) "change NOPREFIXROUTE -> !NOPREFIXROUTE":
    update or add prefix route (as before);;
case 2) "change !NOPREFIXROUTE -> !NOPREFIXROUTE":
    update or add prefix route (as before);;
case 3) "change NOPREFIXROUTE -> NOPREFIXROUTE":
    ;;
case 4) "change !NOPREFIXROUTE -> NOPREFIXROUTE":
    cleanup prefix route;;

where "cleanup" means the same as done in ipv6_del_addr(), as determined
by check_cleanup_prefix_routes().


Allowing modify with case 2) and 3) is important. But for case 4) (and
possibly 1)), we could also fail with error. I tend to the scheme above
though because it makes it easier for userspace and is likely what it
wants.



The problem of deleting a route created by somebody else is already
present without this patch in ipv6_del_addr. This is indeed a bit shaky,
but I guess it's good enough in practice. Do I understand correctly,
that you think about to use the information from ifp->rt to ensure, that
what we really cleanup the correct route? If that's what you intend, can
you elaborate a bit on how to do that?


ciao,
Thomas


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2014-01-07 22:54 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-02 15:34 [patch iproute2 v2 0/2] add support for IFA_F_MANAGETEMPADDR Jiri Pirko
2014-01-02 15:34 ` [patch iproute2 v2 1/2] add support for extended ifa_flags Jiri Pirko
2014-01-02 15:34 ` [patch iproute2 v2 2/2] add support for IFA_F_MANAGETEMPADDR Jiri Pirko
2014-01-02 15:50   ` [PATCH 1/1] fixup! " Thomas Haller
2014-01-04 10:44     ` Jiri Pirko
2014-01-02 17:29 ` [patch iproute2 v2 0/2] " Hannes Frederic Sowa
2014-01-04 10:43   ` Jiri Pirko
2014-01-04 10:55     ` Hannes Frederic Sowa
2014-01-04 11:05       ` Jiri Pirko
2014-01-04 11:15         ` Hannes Frederic Sowa
2014-01-04 11:21           ` Thomas Haller
2014-01-04 11:35             ` Hannes Frederic Sowa
2014-01-06 15:41               ` Thomas Haller
2014-01-06 16:01                 ` Hannes Frederic Sowa
2014-01-06 17:29                   ` [PATCH 1/1] ipv6 addrconf: add IFA_F_NOPREFIXROUTE flag to suppress creation of IP6 routes Thomas Haller
2014-01-06 17:38                     ` Jiri Pirko
2014-01-07  9:39                       ` Hannes Frederic Sowa
2014-01-07 12:01                     ` Hannes Frederic Sowa
2014-01-07 12:14                       ` Thomas Haller
2014-01-07 12:22                         ` Hannes Frederic Sowa
2014-01-07 14:39                     ` [PATCH v2 0/2] " Thomas Haller
2014-01-07 14:39                       ` [PATCH v2 1/2] " Thomas Haller
2014-01-07 14:39                       ` [PATCH v2 2/2] ipv6 addrconf: don't cleanup route prefix for IFA_F_NOPREFIXROUTE Thomas Haller
2014-01-07 16:28                         ` Hannes Frederic Sowa
2014-01-07 18:32                           ` Thomas Haller
2014-01-07 19:01                             ` Hannes Frederic Sowa
2014-01-07 22:54                               ` Thomas Haller [this message]
2014-01-07 23:09                                 ` Hannes Frederic Sowa
2014-01-07 16:03                       ` [PATCH v2 0/2] ipv6 addrconf: add IFA_F_NOPREFIXROUTE flag to suppress creation of IP6 routes Hannes Frederic Sowa
2014-01-07 21:42                         ` Thomas Haller

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=1389135262.2248.42.camel@weing \
    --to=thaller@redhat.com \
    --cc=dcbw@redhat.com \
    --cc=hannes@stressinduktion.org \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.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.