netdev - Re: [PATCH] net: Fragment large datagrams even when IP

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 for Android: free password hash cracker in your pocket

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

Message-ID: <797d729c-093c-4317-c371-5f64c8a3a2f3@gmail.com>
Date:   Tue, 14 Dec 2021 17:33:37 +0530
From:   Senthil Kumar Nagappan <nagappanksenthil@...il.com>
To:     David Miller <davem@...emloft.net>, Alan.Davey@...aswitch.com
Cc:     paul@...ma.org, netdev@...r.kernel.org, kuznet@....inr.ac.ru,
        jmorris@...ei.org, yoshfuji@...ux-ipv6.org, kaber@...sh.net
Subject: Re: [PATCH] net: Fragment large datagrams even when IP_HDRINCL is
 set.


On 7/12/2016 11:41 PM, David Miller wrote:
> From: Alan Davey <Alan.Davey@...aswitch.com>
> Date: Tue, 12 Jul 2016 12:34:07 +0000
>
>> -  all future applications have to continue to implement their own fragmentation code, duplicating that which already exists in the kernel
> They have to do this anyways, don't you see this?
>
> Otherwise they don't support %99 of the kernels out there.
>
> Even if I put this change in now, it would take years for it to
> propagate to even a moderate percentage of Linux machines out there.
>
> And applications doing a "we only support kernels > version x.y.z" is
> a situation I don't want to promote if you think that's a reasonable
> way to handle this.
>
> Dave patch functionality is good to have in the kernel.
> The reason David says it not convincing,  since its there for decades and "we only support kernels > version x.y.z", As Paul suggested we could have a socket option to avoid compatibility issues.
>
> Dave patch has minimal changes, but i see some downsides to it and suggestion to do this differently.
> 1. We will not be able to support MSG_MORE if we take this path.
> 2. we will try to allocate one big skb based on the user data size and kmalloc might fail to allocate a big contiguous buffer, which is not better as compared to the path taken using ip_append_data where we will take care allocating skb's based on the mtu.
> 3. other suggestion is, may be we can take the ip_append_data path, some were down the line we can use the user provided header.