netdev - Re: [PATCH] net: take care of bonding in build_skb_flow

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <568CC3B2.9020106@gmail.com>
Date:	Wed, 6 Jan 2016 15:35:14 +0800
From:	zhuyj <zyjzyj2000@...il.com>
To:	Wengang Wang <wen.gang.wang@...cle.com>, netdev@...r.kernel.org
Subject: Re: [PATCH] net: take care of bonding in build_skb_flow_key

IMHO, "The path MTU is set to the active slave device, not the bonding 
master."
Can we set PMTU to bonding master when path MTU is set to the active 
slave device?

If not appropriate, you can ignore it.

Best Regards!
Zhu Yanjun

On 01/06/2016 03:06 PM, Wengang Wang wrote:
> Hi Yanjun,
>
> Thanks for your review.
> Master MTU is same as that for slaves.
> Maybe fixing in bonding driver is a good idea, but I don't find a good 
> place to do that.
> Let's go through the simplified follow:
>
> ...
> 1) Fragmentation.
>    --This is is done is against the bonding master device(device MTU 
> and path MTU)
> 2) bond_start_xmit
> 3) ipoib_start_xmit(slaves are IPoIB interfaces)
>
> For the first send
> 1) fragment size is 7000(in my case)
> 2) bond_start_xmit its self is fine
> 3) ipoib_start_xmit sees the packet size 7000 is larger than the 
> internal limit 2044, drops the packet and try to update PMTU.
>     without the patch, it tried update PMTU on slave device(no changes 
> to master).
>
> the seconds send comes, since no changes happen on bonding 
> master(PMTU), the fragment size is still 7000 and the behavior is just 
> the same as the first send.
>
> With the patch, the bonding master PMTU is changed to 2044 after the 
> first send(hopefully), for the seconds send the fragment size is set 
> to 2044.
>
> To fix in bonding code, I don't find where we can.
>
> thanks,
> wengang
>
> 在 2016年01月06日 14:19, zhuyj 写道:
>>
>> IMHO, this should fix in bonding driver because the active slave mtu 
>> should be the same with the master.
>> bonding master's mtu is changed to path MTU, then slave dev's MTU 
>> should be changed, too.
>>
>> Zhu Yanjun
>> On 01/06/2016 01:49 PM, Wengang Wang wrote:
>>> A problem is found that we are looking for route basing a bonding 
>>> device and
>>> deal with path MTU there: The path MTU is set to the active slave 
>>> device, not
>>> the bonding master.
>>>
>>> The patch tries to fix the issue by letting build_skb_flow_key() 
>>> take care
>>> of the transition of device index from bonding slave to the master.
>>>
>>> Signed-off-by: Wengang Wang <wen.gang.wang@...cle.com>
>>> ---
>>>   net/ipv4/route.c | 11 ++++++++++-
>>>   1 file changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
>>> index 85f184e..3053f10 100644
>>> --- a/net/ipv4/route.c
>>> +++ b/net/ipv4/route.c
>>> @@ -523,11 +523,20 @@ static void build_skb_flow_key(struct flowi4 
>>> *fl4, const struct sk_buff *skb,
>>>                      const struct sock *sk)
>>>   {
>>>       const struct iphdr *iph = ip_hdr(skb);
>>> -    int oif = skb->dev->ifindex;
>>> +    int oif;
>>> +    struct net_device *master = NULL;
>>> +
>>>       u8 tos = RT_TOS(iph->tos);
>>>       u8 prot = iph->protocol;
>>>       u32 mark = skb->mark;
>>>   +    if (skb->dev->flags & IFF_SLAVE)
>>> +        master = netdev_master_upper_dev_get(skb->dev);
>>> +    if (master)
>>> +        oif = master->ifindex;
>>> +    else
>>> +        oif = skb->dev->ifindex;
>>> +
>>>       __build_flow_key(fl4, sk, iph, oif, tos, prot, mark, 0);
>>>   }
>>
>

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html