> From: "Shmulik Ladkani" <shmulik.ladk...@gmail.com>
> To: "Lance Richardson" <lrich...@redhat.com>
> Cc: netdev@vger.kernel.org, f...@strlen.de, jtl...@redhat.com,
> han...@stressinduktion.org
> Sent: Friday, November 4, 2016 5:24:09 AM
riday, November 4, 2016 5:40:14 AM
> Subject: Re: [PATCH net v3] ipv4: allow local fragmentation in
> ip_finish_output_gso()
>
> On Thu, 3 Nov 2016 22:34:34 +0100 Hannes Frederic Sowa
> <han...@stressinduktion.org> wrote:
> > Correct, but we should maybe redefine the code a
On Thu, 3 Nov 2016 22:34:34 +0100 Hannes Frederic Sowa
wrote:
> Correct, but we should maybe redefine the code a bit. From my
> understanding we can now create an ICMP storm in case every fragment gets.
Yes, you are right.
Each segment gets into ip_fragment, and due
Hi,
On Thu, 3 Nov 2016 09:06:27 -0400 (EDT) Lance Richardson
wrote:
> I'm not sure what could be added that would help, was there something
> specific you had in mind?
How about something like this (preliminary, feel free to massage):
@@ -248,10 +248,16 @@ static int
Hi,
On Thu, 3 Nov 2016 17:05:54 -0400 (EDT) Lance Richardson
wrote:
>
> I'm still digesting the patchwork history, but it seems to me:
>
>1) If we call skb_gso_validate_mtu() and it returns true,
> ip_finish_output2() will
> be called, just as before, so
edhat.com
>> Sent: Thursday, November 3, 2016 4:27:51 PM
>> Subject: Re: [PATCH net v3] ipv4: allow local fragmentation in
>> ip_finish_output_gso()
>>
>> Hi Hannes, Lance,
>>
>> On Wed, 2 Nov 2016 16:36:17 -0400 Lance Richardson <lrich...@redhat.com>
&
> From: "Shmulik Ladkani" <shmulik.ladk...@gmail.com>
> To: "Lance Richardson" <lrich...@redhat.com>, f...@strlen.de,
> han...@stressinduktion.org
> Cc: netdev@vger.kernel.org, jtl...@redhat.com
> Sent: Thursday, November 3, 2016 4:27:51 PM
From: Shmulik Ladkani
Date: Thu, 3 Nov 2016 22:40:52 +0200
> On Thu, 03 Nov 2016 16:12:44 -0400 (EDT) David Miller
> wrote:
>> Applied and queued up for -stable.
>
> Dave, my response lagged your "Applied" by few minutes ;)
>
> This seems to
On Thu, 03 Nov 2016 16:12:44 -0400 (EDT) David Miller
wrote:
> Applied and queued up for -stable.
Dave, my response lagged your "Applied" by few minutes ;)
This seems to deserve some more thought to make sure nothing got broken,
as expressed last in
Hi Hannes, Lance,
On Wed, 2 Nov 2016 16:36:17 -0400 Lance Richardson wrote:
>
> - if (skb_iif && !(df & htons(IP_DF))) {
> - /* Arrived from an ingress interface, got encapsulated, with
> - * fragmentation of encapulating frames allowed.
> -
From: Lance Richardson
Date: Wed, 2 Nov 2016 16:36:17 -0400
> Some configurations (e.g. geneve interface with default
> MTU of 1500 over an ethernet interface with 1500 MTU) result
> in the transmission of packets that exceed the configured MTU.
> While this should be
> From: "Shmulik Ladkani" <shmulik.ladk...@gmail.com>
> To: "Lance Richardson" <lrich...@redhat.com>
> Cc: netdev@vger.kernel.org, f...@strlen.de, jtl...@redhat.com,
> han...@stressinduktion.org
> Sent: Thursday, November 3, 2016 3:42:39 AM
On 03.11.2016 08:42, Shmulik Ladkani wrote:
> On Wed, 2 Nov 2016 16:36:17 -0400
> Lance Richardson wrote:
>
>> -/* common case: fragmentation of segments is not allowed,
>> - * or seglen is <= mtu
>> +/* common case: seglen is <= mtu
>> */
>> -if
On 02.11.2016 21:36, Lance Richardson wrote:
> Some configurations (e.g. geneve interface with default
> MTU of 1500 over an ethernet interface with 1500 MTU) result
> in the transmission of packets that exceed the configured MTU.
> While this should be considered to be a "bad" configuration,
> it
On Wed, 2 Nov 2016 16:36:17 -0400
Lance Richardson wrote:
> - /* common case: fragmentation of segments is not allowed,
> - * or seglen is <= mtu
> + /* common case: seglen is <= mtu
>*/
> - if (((IPCB(skb)->flags & IPSKB_FRAG_SEGS) == 0) ||
> -
Some configurations (e.g. geneve interface with default
MTU of 1500 over an ethernet interface with 1500 MTU) result
in the transmission of packets that exceed the configured MTU.
While this should be considered to be a "bad" configuration,
it is still allowed and should not result in the sending
16 matches
Mail list logo