[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200507.173004.1881498730999455740.davem@davemloft.net>
Date: Thu, 07 May 2020 17:30:04 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: zenczykowski@...il.com
Cc: maze@...gle.com, netdev@...r.kernel.org, edumazet@...gle.com,
willemb@...gle.com, lucien.xin@...il.com,
hannes@...essinduktion.org
Subject: Re: [PATCH] Revert "ipv6: add mtu lock check in
__ip6_rt_update_pmtu"
From: Maciej Żenczykowski <zenczykowski@...il.com>
Date: Tue, 5 May 2020 11:57:23 -0700
> From: Maciej Żenczykowski <maze@...gle.com>
>
> This reverts commit 19bda36c4299ce3d7e5bce10bebe01764a655a6d:
>
> | ipv6: add mtu lock check in __ip6_rt_update_pmtu
> |
> | Prior to this patch, ipv6 didn't do mtu lock check in ip6_update_pmtu.
> | It leaded to that mtu lock doesn't really work when receiving the pkt
> | of ICMPV6_PKT_TOOBIG.
> |
> | This patch is to add mtu lock check in __ip6_rt_update_pmtu just as ipv4
> | did in __ip_rt_update_pmtu.
>
> The above reasoning is incorrect. IPv6 *requires* icmp based pmtu to work.
> There's already a comment to this effect elsewhere in the kernel:
>
> $ git grep -p -B1 -A3 'RTAX_MTU lock'
> net/ipv6/route.c=4813=
>
> static int rt6_mtu_change_route(struct fib6_info *f6i, void *p_arg)
> ...
> /* In IPv6 pmtu discovery is not optional,
> so that RTAX_MTU lock cannot disable it.
> We still use this lock to block changes
> caused by addrconf/ndisc.
> */
>
> This reverts to the pre-4.9 behaviour.
>
> Signed-off-by: Maciej Żenczykowski <maze@...gle.com>
> Fixes: 19bda36c4299 ("ipv6: add mtu lock check in __ip6_rt_update_pmtu")
I've thought about this some more and decided to apply this and
queue it up for -stable, thank you.
Powered by blists - more mailing lists