Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754082AbcKPBQm (ORCPT ); Tue, 15 Nov 2016 20:16:42 -0500 Received: from Chamillionaire.breakpoint.cc ([146.0.238.67]:46036 "EHLO Chamillionaire.breakpoint.cc" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751481AbcKPBQj (ORCPT ); Tue, 15 Nov 2016 20:16:39 -0500 Date: Wed, 16 Nov 2016 02:14:04 +0100 From: Florian Westphal To: Vicente =?iso-8859-15?Q?Jim=E9nez?= Cc: Florian Westphal , David Miller , Alexey Kuznetsov , James Morris , Hideaki YOSHIFUJI , Patrick McHardy , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] icmp: Restore resistence to abnormal messages Message-ID: <20161116011404.GF30581@breakpoint.cc> References: <20161111202018.13795-1-googuy@gmail.com> <20161114.133646.1687576478968660327.davem@davemloft.net> <20161115.115657.798577230951109692.davem@redhat.com> <20161115173024.GD30581@breakpoint.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1598 Lines: 36 Vicente Jim?nez wrote: > I agree that both patches try to solve the same problem in a very similar way. > Florian Westphal's patch do two more things: > 1- add warning with pr_warn_ratelimited. I like this idea. I also > though about adding some message but I have no kernel experience and I > preferred to have just a working solution. I added this only to show whats happening. I don't like such printks because end users can't do anything about it. > 2- Check if the packet size is lower than (536 + 8). I think this is > not necessary because low values (even the zero case) is already > handled by the protocol. Also I don't understand why you choose this > value, it seems to be related to TCP MSS and the compared value is IP > packet size. Right, no need for this check. > Finally, both patches decrement current packet by a value: Mine by 2 > and Florian's by 8 bytes. Both arbitrary values. Personally I prefer > to go by small steps. If the small step fails, it just iterate again > and with 4 iterations, my patch also decrement the original value by 8 > bytes (4x2). > Basically they are the same but my patch take smaller steps and miss > the warning message. IIRC I chose 8 because connection recovered faster in my case. I have not experienced this issue again (I dropped the patch from my kernel at some point and the connection stalls did not reappear so this got fixed elsewhere). I'd just apply your patch, possibly with an additional comment that says that we're grasping at straws because some middlebox is evidently feeding bogus pmtu information.