* [PATCH net-next] ipv6: recreate ipv6 link-local addresses when increasing MTU over IPV6_MIN_MTU @ 2015-10-26 14:36 Hannes Frederic Sowa 2015-10-26 15:52 ` Alexander Duyck 2015-10-26 18:06 ` [net-next PATCH v2] " Alexander Duyck 0 siblings, 2 replies; 12+ messages in thread From: Hannes Frederic Sowa @ 2015-10-26 14:36 UTC (permalink / raw) To: netdev; +Cc: Hannes Frederic Sowa Take into consideration that the interface might be disabled for IPv6, thus switch event type. Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> --- net/ipv6/addrconf.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index d0c685c..c2dcebe 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -3149,6 +3149,7 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event, case NETDEV_UP: case NETDEV_CHANGE: +netdev_change: if (dev->flags & IFF_SLAVE) break; @@ -3244,8 +3245,10 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event, if (!idev && dev->mtu >= IPV6_MIN_MTU) { idev = ipv6_add_dev(dev); - if (!IS_ERR(idev)) - break; + if (!IS_ERR(idev)) { + event = NETDEV_UP; + goto netdev_change; + } } /* -- 2.5.0 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH net-next] ipv6: recreate ipv6 link-local addresses when increasing MTU over IPV6_MIN_MTU 2015-10-26 14:36 [PATCH net-next] ipv6: recreate ipv6 link-local addresses when increasing MTU over IPV6_MIN_MTU Hannes Frederic Sowa @ 2015-10-26 15:52 ` Alexander Duyck 2015-10-26 16:05 ` Hannes Frederic Sowa 2015-10-26 16:33 ` Hannes Frederic Sowa 2015-10-26 18:06 ` [net-next PATCH v2] " Alexander Duyck 1 sibling, 2 replies; 12+ messages in thread From: Alexander Duyck @ 2015-10-26 15:52 UTC (permalink / raw) To: Hannes Frederic Sowa, netdev On 10/26/2015 07:36 AM, Hannes Frederic Sowa wrote: > Take into consideration that the interface might be disabled for IPv6, > thus switch event type. > > Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> > --- > net/ipv6/addrconf.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c > index d0c685c..c2dcebe 100644 > --- a/net/ipv6/addrconf.c > +++ b/net/ipv6/addrconf.c > @@ -3149,6 +3149,7 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event, > > case NETDEV_UP: > case NETDEV_CHANGE: > +netdev_change: > if (dev->flags & IFF_SLAVE) > break; > > @@ -3244,8 +3245,10 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event, > > if (!idev && dev->mtu >= IPV6_MIN_MTU) { > idev = ipv6_add_dev(dev); > - if (!IS_ERR(idev)) > - break; > + if (!IS_ERR(idev)) { > + event = NETDEV_UP; > + goto netdev_change; > + } > } > > /* Seems like this code isn't quite correct. You are calling ipv6_add_dev for slave devices, and if I understand things correctly I don't believe that was happening before and may be an unintended side effect. You might want to instead just make it so that you only do the jump, and perhaps change the code in the NETDEV_UP/NETDEV_CHANGE section so that you test for NETDEV_CHANGE instead of NETDEV_UP. That should be enough to get the effect you are looking for and I believe there would be no change to behaviour other than adding IPv6 link-local addresses when the MTU is increased. Give me a bit and I can submit an alternative that may actually work out a bit better I think. - Alex ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH net-next] ipv6: recreate ipv6 link-local addresses when increasing MTU over IPV6_MIN_MTU 2015-10-26 15:52 ` Alexander Duyck @ 2015-10-26 16:05 ` Hannes Frederic Sowa 2015-10-26 17:07 ` Alexander Duyck 2015-10-26 16:33 ` Hannes Frederic Sowa 1 sibling, 1 reply; 12+ messages in thread From: Hannes Frederic Sowa @ 2015-10-26 16:05 UTC (permalink / raw) To: Alexander Duyck, netdev Hi Alex, On Mon, Oct 26, 2015, at 16:52, Alexander Duyck wrote: > On 10/26/2015 07:36 AM, Hannes Frederic Sowa wrote: > > Take into consideration that the interface might be disabled for IPv6, > > thus switch event type. > > > > Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> > > --- > > net/ipv6/addrconf.c | 7 +++++-- > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c > > index d0c685c..c2dcebe 100644 > > --- a/net/ipv6/addrconf.c > > +++ b/net/ipv6/addrconf.c > > @@ -3149,6 +3149,7 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event, > > > > case NETDEV_UP: > > case NETDEV_CHANGE: > > +netdev_change: > > if (dev->flags & IFF_SLAVE) > > break; > > > > @@ -3244,8 +3245,10 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event, > > > > if (!idev && dev->mtu >= IPV6_MIN_MTU) { > > idev = ipv6_add_dev(dev); > > - if (!IS_ERR(idev)) > > - break; > > + if (!IS_ERR(idev)) { > > + event = NETDEV_UP; > > + goto netdev_change; > > + } > > } > > > > /* > > Seems like this code isn't quite correct. You are calling ipv6_add_dev > for slave devices, and if I understand things correctly I don't believe > that was happening before and may be an unintended side effect. Hmm, could you quickly help me where I get into this situation? I made sure I enter the NETDEV_UP part before the IFF_SLAVE test and disable_ipv6 test. > You might want to instead just make it so that you only do the jump, and > perhaps change the code in the NETDEV_UP/NETDEV_CHANGE section so that > you test for NETDEV_CHANGE instead of NETDEV_UP. That should be enough > to get the effect you are looking for and I believe there would be no > change to behaviour other than adding IPv6 link-local addresses when the > MTU is increased. > > Give me a bit and I can submit an alternative that may actually work out > a bit better I think. If you go the NETDEV_CHANGE route instead of NETDEV_UP, you end up with the IF_READY flag already set from ipv6_add_dev and thus won't do any initialization of the device. Sure, I wait. Bye, Hannes ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH net-next] ipv6: recreate ipv6 link-local addresses when increasing MTU over IPV6_MIN_MTU 2015-10-26 16:05 ` Hannes Frederic Sowa @ 2015-10-26 17:07 ` Alexander Duyck 2015-10-26 17:21 ` Hannes Frederic Sowa 2015-10-26 19:05 ` Hannes Frederic Sowa 0 siblings, 2 replies; 12+ messages in thread From: Alexander Duyck @ 2015-10-26 17:07 UTC (permalink / raw) To: Hannes Frederic Sowa, netdev On 10/26/2015 09:05 AM, Hannes Frederic Sowa wrote: > Hi Alex, > > On Mon, Oct 26, 2015, at 16:52, Alexander Duyck wrote: >> On 10/26/2015 07:36 AM, Hannes Frederic Sowa wrote: >>> Take into consideration that the interface might be disabled for IPv6, >>> thus switch event type. >>> >>> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> >>> --- >>> net/ipv6/addrconf.c | 7 +++++-- >>> 1 file changed, 5 insertions(+), 2 deletions(-) >>> >>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c >>> index d0c685c..c2dcebe 100644 >>> --- a/net/ipv6/addrconf.c >>> +++ b/net/ipv6/addrconf.c >>> @@ -3149,6 +3149,7 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event, >>> >>> case NETDEV_UP: >>> case NETDEV_CHANGE: >>> +netdev_change: >>> if (dev->flags & IFF_SLAVE) >>> break; >>> >>> @@ -3244,8 +3245,10 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event, >>> >>> if (!idev && dev->mtu >= IPV6_MIN_MTU) { >>> idev = ipv6_add_dev(dev); >>> - if (!IS_ERR(idev)) >>> - break; >>> + if (!IS_ERR(idev)) { >>> + event = NETDEV_UP; >>> + goto netdev_change; >>> + } >>> } >>> >>> /* >> Seems like this code isn't quite correct. You are calling ipv6_add_dev >> for slave devices, and if I understand things correctly I don't believe >> that was happening before and may be an unintended side effect. > Hmm, could you quickly help me where I get into this situation? I made > sure I enter the NETDEV_UP part before the IFF_SLAVE test and > disable_ipv6 te I think I was getting a bit a head of myself. I was looking over the NETDEV_UP code and thinking that we could just fall into that path since it is already calling ipv6_add_dev. However now I am wondering if maybe we need to look at adding an idev allocation somewhere before the disable_ipv6 check. I assume that is why you were allocating the idev before you were getting into NETDEV_UP? >> You might want to instead just make it so that you only do the jump, and >> perhaps change the code in the NETDEV_UP/NETDEV_CHANGE section so that >> you test for NETDEV_CHANGE instead of NETDEV_UP. That should be enough >> to get the effect you are looking for and I believe there would be no >> change to behaviour other than adding IPv6 link-local addresses when the >> MTU is increased. >> >> Give me a bit and I can submit an alternative that may actually work out >> a bit better I think. > If you go the NETDEV_CHANGE route instead of NETDEV_UP, you end up with > the IF_READY flag already set from ipv6_add_dev and thus won't do any > initialization of the device. What I meant was that you don't need to change the event. If you change the check inside the NETDEV_UP/CHANGE code path so that it tests for event != NETDEV_CHANGE instead of event == NETDEV_UP you don't need to change the event type. > Sure, I wait. Might be a bit longer. I just realized that I think there is another bug here where you are going through the NETDEV_UP path even though the interface isn't up. I'll run through some testing this morning to work out the kinks. - Alex ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH net-next] ipv6: recreate ipv6 link-local addresses when increasing MTU over IPV6_MIN_MTU 2015-10-26 17:07 ` Alexander Duyck @ 2015-10-26 17:21 ` Hannes Frederic Sowa 2015-10-26 19:05 ` Hannes Frederic Sowa 1 sibling, 0 replies; 12+ messages in thread From: Hannes Frederic Sowa @ 2015-10-26 17:21 UTC (permalink / raw) To: Alexander Duyck, netdev Hi Alex, On Mon, Oct 26, 2015, at 18:07, Alexander Duyck wrote: > >> Seems like this code isn't quite correct. You are calling ipv6_add_dev > >> for slave devices, and if I understand things correctly I don't believe > >> that was happening before and may be an unintended side effect. > > Hmm, could you quickly help me where I get into this situation? I made > > sure I enter the NETDEV_UP part before the IFF_SLAVE test and > > disable_ipv6 te > > I think I was getting a bit a head of myself. I was looking over the > NETDEV_UP code and thinking that we could just fall into that path since > it is already calling ipv6_add_dev. However now I am wondering if maybe > we need to look at adding an idev allocation somewhere before the > disable_ipv6 check. I assume that is why you were allocating the idev > before you were getting into NETDEV_UP? The original bug report was: If user reduces the MTU below IPV6_MIN_MTU we addrconf_ifdown the interface but don't reinitialize the interface if the MTU is increased later on. > >> You might want to instead just make it so that you only do the jump, and > >> perhaps change the code in the NETDEV_UP/NETDEV_CHANGE section so that > >> you test for NETDEV_CHANGE instead of NETDEV_UP. That should be enough > >> to get the effect you are looking for and I believe there would be no > >> change to behaviour other than adding IPv6 link-local addresses when the > >> MTU is increased. > >> > >> Give me a bit and I can submit an alternative that may actually work out > >> a bit better I think. > > If you go the NETDEV_CHANGE route instead of NETDEV_UP, you end up with > > the IF_READY flag already set from ipv6_add_dev and thus won't do any > > initialization of the device. > > What I meant was that you don't need to change the event. If you change > the check inside the NETDEV_UP/CHANGE code path so that it tests for > event != NETDEV_CHANGE instead of event == NETDEV_UP you don't need to > change the event type. Yeah, that would be possible, too. I just find an equal easier to follow. ;) > > Sure, I wait. > > Might be a bit longer. I just realized that I think there is another > bug here where you are going through the NETDEV_UP path even though the > interface isn't up. I'll run through some testing this morning to work > out the kinks. Ok, cool. I have a look at it again, too. Bye, Hannes ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH net-next] ipv6: recreate ipv6 link-local addresses when increasing MTU over IPV6_MIN_MTU 2015-10-26 17:07 ` Alexander Duyck 2015-10-26 17:21 ` Hannes Frederic Sowa @ 2015-10-26 19:05 ` Hannes Frederic Sowa 1 sibling, 0 replies; 12+ messages in thread From: Hannes Frederic Sowa @ 2015-10-26 19:05 UTC (permalink / raw) To: Alexander Duyck, netdev Hi Alex, On Mon, Oct 26, 2015, at 18:07, Alexander Duyck wrote: > Might be a bit longer. I just realized that I think there is another > bug here where you are going through the NETDEV_UP path even though the > interface isn't up. I'll run through some testing this morning to work > out the kinks. When you wrote this, I noticed that if someone removes the LL addresses to disable the interface and raises the MTU again, we would also start adding link-local addresses. Probably we need to safe the last state of disable_ipv6 somewhere in the parent interface. :( Maybe there is an easier solution for that. Thanks for your patch, it looks cleaner! Bye, Hannes ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH net-next] ipv6: recreate ipv6 link-local addresses when increasing MTU over IPV6_MIN_MTU 2015-10-26 15:52 ` Alexander Duyck 2015-10-26 16:05 ` Hannes Frederic Sowa @ 2015-10-26 16:33 ` Hannes Frederic Sowa 2015-10-26 19:16 ` Jay Vosburgh 1 sibling, 1 reply; 12+ messages in thread From: Hannes Frederic Sowa @ 2015-10-26 16:33 UTC (permalink / raw) To: Alexander Duyck, netdev Hello Alex, On Mon, Oct 26, 2015, at 16:52, Alexander Duyck wrote: > Seems like this code isn't quite correct. You are calling ipv6_add_dev > for slave devices, and if I understand things correctly I don't believe > that was happening before and may be an unintended side effect. Ah, btw., autoconf and ipv6 operation on IFF_SLAVE devices is actually desired nowadays and don't think we can change this. See also: <https://patchwork.ozlabs.org/patch/531196/> Bye, Hannes ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH net-next] ipv6: recreate ipv6 link-local addresses when increasing MTU over IPV6_MIN_MTU 2015-10-26 16:33 ` Hannes Frederic Sowa @ 2015-10-26 19:16 ` Jay Vosburgh 2015-10-26 20:45 ` Hannes Frederic Sowa 0 siblings, 1 reply; 12+ messages in thread From: Jay Vosburgh @ 2015-10-26 19:16 UTC (permalink / raw) To: Hannes Frederic Sowa; +Cc: Alexander Duyck, netdev Hannes Frederic Sowa <hannes@stressinduktion.org> wrote: >Hello Alex, > >On Mon, Oct 26, 2015, at 16:52, Alexander Duyck wrote: >> Seems like this code isn't quite correct. You are calling ipv6_add_dev >> for slave devices, and if I understand things correctly I don't believe >> that was happening before and may be an unintended side effect. > >Ah, btw., autoconf and ipv6 operation on IFF_SLAVE devices is actually >desired nowadays and don't think we can change this. See also: ><https://patchwork.ozlabs.org/patch/531196/> IPv6 addrconf on IFF_SLAVE devices was disabled for bonding slaves in commit c2edacf80e15 because it caused issues with snooping switches. This is also referenced in https://bugzilla.redhat.com/show_bug.cgi?id=236750 Won't re-enabling autoconf on IFF_SLAVE devices cause that issue to return? -J --- -Jay Vosburgh, jay.vosburgh@canonical.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH net-next] ipv6: recreate ipv6 link-local addresses when increasing MTU over IPV6_MIN_MTU 2015-10-26 19:16 ` Jay Vosburgh @ 2015-10-26 20:45 ` Hannes Frederic Sowa 2015-10-26 20:52 ` Alexander Duyck 0 siblings, 1 reply; 12+ messages in thread From: Hannes Frederic Sowa @ 2015-10-26 20:45 UTC (permalink / raw) To: Jay Vosburgh; +Cc: Alexander Duyck, netdev Hi, On Mon, Oct 26, 2015, at 20:16, Jay Vosburgh wrote: > Hannes Frederic Sowa <hannes@stressinduktion.org> wrote: > > >Hello Alex, > > > >On Mon, Oct 26, 2015, at 16:52, Alexander Duyck wrote: > >> Seems like this code isn't quite correct. You are calling ipv6_add_dev > >> for slave devices, and if I understand things correctly I don't believe > >> that was happening before and may be an unintended side effect. > > > >Ah, btw., autoconf and ipv6 operation on IFF_SLAVE devices is actually > >desired nowadays and don't think we can change this. See also: > ><https://patchwork.ozlabs.org/patch/531196/> > > IPv6 addrconf on IFF_SLAVE devices was disabled for bonding > slaves in commit c2edacf80e15 because it caused issues with snooping > switches. > > This is also referenced in > > https://bugzilla.redhat.com/show_bug.cgi?id=236750 > > Won't re-enabling autoconf on IFF_SLAVE devices cause that issue > to return? Both patches don't enable autoconf on IFF_SLAVE devices. Sorry for being imprecise. The referred patch was changing the behavior to whether the device had a master device. @Alex, I will take your patch and submit it with the necessary guards to not enable ipv6 again if we forcefully disable ipv6 and later on shrink and increase the MTU again. I will do so in your name. Thanks again for the patch! Bye, Hannes ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH net-next] ipv6: recreate ipv6 link-local addresses when increasing MTU over IPV6_MIN_MTU 2015-10-26 20:45 ` Hannes Frederic Sowa @ 2015-10-26 20:52 ` Alexander Duyck 0 siblings, 0 replies; 12+ messages in thread From: Alexander Duyck @ 2015-10-26 20:52 UTC (permalink / raw) To: Hannes Frederic Sowa, Jay Vosburgh; +Cc: netdev On 10/26/2015 01:45 PM, Hannes Frederic Sowa wrote: > Hi, > > On Mon, Oct 26, 2015, at 20:16, Jay Vosburgh wrote: >> Hannes Frederic Sowa <hannes@stressinduktion.org> wrote: >> >>> Hello Alex, >>> >>> On Mon, Oct 26, 2015, at 16:52, Alexander Duyck wrote: >>>> Seems like this code isn't quite correct. You are calling ipv6_add_dev >>>> for slave devices, and if I understand things correctly I don't believe >>>> that was happening before and may be an unintended side effect. >>> Ah, btw., autoconf and ipv6 operation on IFF_SLAVE devices is actually >>> desired nowadays and don't think we can change this. See also: >>> <https://patchwork.ozlabs.org/patch/531196/> >> IPv6 addrconf on IFF_SLAVE devices was disabled for bonding >> slaves in commit c2edacf80e15 because it caused issues with snooping >> switches. >> >> This is also referenced in >> >> https://bugzilla.redhat.com/show_bug.cgi?id=236750 >> >> Won't re-enabling autoconf on IFF_SLAVE devices cause that issue >> to return? > Both patches don't enable autoconf on IFF_SLAVE devices. Sorry for being > imprecise. The referred patch was changing the behavior to whether the > device had a master device. Yes, the IFF_SLAVE comment on my part was an error in interpretation of the code. > @Alex, I will take your patch and submit it with the necessary guards to > not enable ipv6 again if we forcefully disable ipv6 and later on shrink > and increase the MTU again. I will do so in your name. Thanks again for > the patch! No problem. If you want to you can take over authorship of the patch and just leave my signed-off-by on there. I'm good either way. - Alex ^ permalink raw reply [flat|nested] 12+ messages in thread
* [net-next PATCH v2] ipv6: recreate ipv6 link-local addresses when increasing MTU over IPV6_MIN_MTU 2015-10-26 14:36 [PATCH net-next] ipv6: recreate ipv6 link-local addresses when increasing MTU over IPV6_MIN_MTU Hannes Frederic Sowa 2015-10-26 15:52 ` Alexander Duyck @ 2015-10-26 18:06 ` Alexander Duyck 2015-10-30 9:11 ` David Miller 1 sibling, 1 reply; 12+ messages in thread From: Alexander Duyck @ 2015-10-26 18:06 UTC (permalink / raw) To: netdev, hannes; +Cc: alexander.duyck This change makes it so that we reinitialize the interface if the MTU is increased back above IPV6_MIN_MTU and the interface is up. Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: Alexander Duyck <aduyck@mirantis.com> --- net/ipv6/addrconf.c | 46 +++++++++++++++++++++++++++------------------- 1 file changed, 27 insertions(+), 19 deletions(-) diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index d0c685cdc345..d72fa90d6feb 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -3147,6 +3147,32 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event, } break; + case NETDEV_CHANGEMTU: + /* if MTU under IPV6_MIN_MTU stop IPv6 on this interface. */ + if (dev->mtu < IPV6_MIN_MTU) { + addrconf_ifdown(dev, 1); + break; + } + + if (idev) { + rt6_mtu_change(dev, dev->mtu); + idev->cnf.mtu6 = dev->mtu; + break; + } + + /* allocate new idev */ + idev = ipv6_add_dev(dev); + if (IS_ERR(idev)) + break; + + /* device is still not ready */ + if (!(idev->if_flags & IF_READY)) + break; + + run_pending = 1; + + /* fall through */ + case NETDEV_UP: case NETDEV_CHANGE: if (dev->flags & IFF_SLAVE) @@ -3170,7 +3196,7 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event, idev->if_flags |= IF_READY; run_pending = 1; } - } else { + } else if (event == NETDEV_CHANGE) { if (!addrconf_qdisc_ok(dev)) { /* device is still not ready. */ break; @@ -3235,24 +3261,6 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event, } break; - case NETDEV_CHANGEMTU: - if (idev && dev->mtu >= IPV6_MIN_MTU) { - rt6_mtu_change(dev, dev->mtu); - idev->cnf.mtu6 = dev->mtu; - break; - } - - if (!idev && dev->mtu >= IPV6_MIN_MTU) { - idev = ipv6_add_dev(dev); - if (!IS_ERR(idev)) - break; - } - - /* - * if MTU under IPV6_MIN_MTU. - * Stop IPv6 on this interface. - */ - case NETDEV_DOWN: case NETDEV_UNREGISTER: /* ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [net-next PATCH v2] ipv6: recreate ipv6 link-local addresses when increasing MTU over IPV6_MIN_MTU 2015-10-26 18:06 ` [net-next PATCH v2] " Alexander Duyck @ 2015-10-30 9:11 ` David Miller 0 siblings, 0 replies; 12+ messages in thread From: David Miller @ 2015-10-30 9:11 UTC (permalink / raw) To: aduyck; +Cc: netdev, hannes, alexander.duyck From: Alexander Duyck <aduyck@mirantis.com> Date: Mon, 26 Oct 2015 11:06:33 -0700 > This change makes it so that we reinitialize the interface if the MTU is > increased back above IPV6_MIN_MTU and the interface is up. > > Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> > Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Applied, thanks. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2015-10-30 9:11 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-10-26 14:36 [PATCH net-next] ipv6: recreate ipv6 link-local addresses when increasing MTU over IPV6_MIN_MTU Hannes Frederic Sowa 2015-10-26 15:52 ` Alexander Duyck 2015-10-26 16:05 ` Hannes Frederic Sowa 2015-10-26 17:07 ` Alexander Duyck 2015-10-26 17:21 ` Hannes Frederic Sowa 2015-10-26 19:05 ` Hannes Frederic Sowa 2015-10-26 16:33 ` Hannes Frederic Sowa 2015-10-26 19:16 ` Jay Vosburgh 2015-10-26 20:45 ` Hannes Frederic Sowa 2015-10-26 20:52 ` Alexander Duyck 2015-10-26 18:06 ` [net-next PATCH v2] " Alexander Duyck 2015-10-30 9:11 ` David Miller
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).