On Thu, 25 Aug 2016 12:05:33 +0300 Shmulik Ladkani
wrote:
> The BUG occurs when GRO occurs on the ingress, and only if GRO merges
> skbs into the frag_list (OTOH when segments are only placed into frags[]
> of a single skb, skb_segment succeeds even if gso_size was
On Thu, Aug 25, 2016 at 12:05:33PM +0300, Shmulik Ladkani wrote:
>
> We have few alternatives for gso_size clamping:
>
> 1 Fix 'skb_segment' arithmentics to support inputs that do not match
> the "frag_list members terminate on exact MSS" assumption.
>
> 2 Perform gso_size clamping in
Hi,
On Mon, 22 Aug 2016 14:58:42 +0200, f...@strlen.de wrote:
> Shmulik Ladkani wrote:
> > There are cases where gso skbs (which originate from an ingress
> > interface) have a gso_size value that exceeds the output dst mtu:
> >
> > - ipv4 forwarding middlebox having
Shmulik Ladkani wrote:
> > Normal ipv4 routing via vm1, no iptables etc. present, so
> >
> > we have hypervisor 1500 -> 1500 VM1 1280 -> 1280 VM2
> >
> > Turning off gro avoids this problem.
>
> I hit the BUG only when VM2's mtu is not set to 1280 (kept to the 1500
Hi,
On Mon, 22 Aug 2016 14:58:42 +0200, f...@strlen.de wrote:
> > Florian, in fe6cc55f you described a BUG due to gso_size decrease.
> > I've tested both bridged and routed cases, but in my setups failed to
> > hit the issue; Appreciate if you can provide some hints.
>
> Still get the BUG, I
Shmulik Ladkani wrote:
> There are cases where gso skbs (which originate from an ingress
> interface) have a gso_size value that exceeds the output dst mtu:
>
> - ipv4 forwarding middlebox having in/out interfaces with different mtus
>addressed by fe6cc55f3a 'net:
Hi,
On Mon, 22 Aug 2016 14:58:42 +0200, f...@strlen.de wrote:
> >
> > Florian, in fe6cc55f you described a BUG due to gso_size decrease.
> > I've tested both bridged and routed cases, but in my setups failed to
> > hit the issue; Appreciate if you can provide some hints.
>
> Still get the
There are cases where gso skbs (which originate from an ingress
interface) have a gso_size value that exceeds the output dst mtu:
- ipv4 forwarding middlebox having in/out interfaces with different mtus
addressed by fe6cc55f3a 'net: ip, ipv6: handle gso skbs in forwarding path'
- bridge