> From: "Shmulik Ladkani"
> To: "Lance Richardson"
> Cc: netdev@vger.kernel.org, f...@strlen.de, jtl...@redhat.com,
> han...@stressinduktion.org
> Sent: Friday, November 4, 2016 5:24:09 AM
> Subject: Re: [PATCH net v3] ipv4: allow local fragmentatio
> From: "Shmulik Ladkani"
> To: "Hannes Frederic Sowa"
> Cc: "Lance Richardson" , f...@strlen.de,
> netdev@vger.kernel.org, jtl...@redhat.com
> Sent: Friday, November 4, 2016 5:40:14 AM
> Subject: Re: [PATCH net v3] ipv4: allow local fragmentation
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 to outer DF being set,
ICMP_
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 ip_finish_output_gso(struc
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 nothing changes.
>
>2)
On 03.11.2016 22:05, Lance Richardson wrote:
>> From: "Shmulik Ladkani"
>> To: "Lance Richardson" , f...@strlen.de,
>> han...@stressinduktion.org
>> Cc: netdev@vger.kernel.org, jtl...@redhat.com
>> Sent: Thursday, November 3, 2016 4:27:51 P
> From: "Shmulik Ladkani"
> To: "Lance Richardson" , f...@strlen.de,
> han...@stressinduktion.org
> Cc: netdev@vger.kernel.org, jtl...@redhat.com
> Sent: Thursday, November 3, 2016 4:27:51 PM
> Subject: Re: [PATCH net v3] ipv4: allow local fragmentatio
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 deserve some more thought to make sure nothing got
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 https://patchwork.ozlabs.org/patch/690594/
B
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.
> - * If skb i
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 considered to be a "bad" co
> From: "Shmulik Ladkani"
> To: "Lance Richardson"
> Cc: netdev@vger.kernel.org, f...@strlen.de, jtl...@redhat.com,
> han...@stressinduktion.org
> Sent: Thursday, November 3, 2016 3:42:39 AM
> Subject: Re: [PATCH net v3] ipv4: allow local fragmentation in
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 (((IPCB(skb)->flags & IPSKB
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) ||
> - skb_gso_validat
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
o
16 matches
Mail list logo