From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shards.monkeyblade.net ([184.105.139.130]:35786 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751302AbeCNRiQ (ORCPT ); Wed, 14 Mar 2018 13:38:16 -0400 Date: Wed, 14 Mar 2018 13:38:13 -0400 (EDT) Message-Id: <20180314.133813.351503287022956858.davem@davemloft.net> To: sd@queasysnail.net Cc: netdev@vger.kernel.org, sbrivio@redhat.com Subject: Re: [PATCH net v2] ipv4: lock mtu in fnhe when received PMTU < net.ipv4.route.min_pmtu From: David Miller In-Reply-To: References: Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org List-ID: From: Sabrina Dubroca Date: Wed, 14 Mar 2018 10:21:14 +0100 > Prior to the rework of PMTU information storage in commit > 2c8cec5c10bc ("ipv4: Cache learned PMTU information in inetpeer."), > when a PMTU event advertising a PMTU smaller than > net.ipv4.route.min_pmtu was received, we would disable setting the DF > flag on packets by locking the MTU metric, and set the PMTU to > net.ipv4.route.min_pmtu. > > Since then, we don't disable DF, and set PMTU to > net.ipv4.route.min_pmtu, so the intermediate router that has this link > with a small MTU will have to drop the packets. > > This patch reestablishes pre-2.6.39 behavior by splitting > rtable->rt_pmtu into a bitfield with rt_mtu_locked and rt_pmtu. > rt_mtu_locked indicates that we shouldn't set the DF bit on that path, > and is checked in ip_dont_fragment(). > > One possible workaround is to set net.ipv4.route.min_pmtu to a value low > enough to accommodate the lowest MTU encountered. > > Fixes: 2c8cec5c10bc ("ipv4: Cache learned PMTU information in inetpeer.") > Signed-off-by: Sabrina Dubroca > Reviewed-by: Stefano Brivio > --- > v2: make rt_pmtu a bitfield > fix missing initializations of rt_mtu_locked Applied and queued up for -stable, thanks.