netdev - Re: [PATCH net-next 2/8] i40e: change Rx buffer size for legacy-rx to support XDP multi-buffer

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] [day] [month] [year] [list]

Message-ID: <20230308182808.60e4af6c@kernel.org>
Date:   Wed, 8 Mar 2023 18:28:08 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     "Sarkar, Tirthendu" <tirthendu.sarkar@...el.com>
Cc:     "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Fijalkowski, Maciej" <maciej.fijalkowski@...el.com>,
        "Karlsson, Magnus" <magnus.karlsson@...el.com>,
        "ast@...nel.org" <ast@...nel.org>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        "hawk@...nel.org" <hawk@...nel.org>,
        "john.fastabend@...il.com" <john.fastabend@...il.com>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        "Rout, ChandanX" <chandanx.rout@...el.com>
Subject: Re: [PATCH net-next 2/8] i40e: change Rx buffer size for legacy-rx
 to support XDP multi-buffer

On Wed, 8 Mar 2023 12:22:13 +0000 Sarkar, Tirthendu wrote:
> > On Mon,  6 Mar 2023 13:08:16 -0800 Tony Nguyen wrote:  
> > > In the legacy-rx mode, driver can only configure up to 2k sized Rx buffers
> > > and with the current configuration of 2k sized Rx buffers there is no way
> > > to do tailroom reservation for skb_shared_info. Hence size of Rx buffers
> > > is now lowered to 1664 (2k - sizeof(skb_shared_info)). Also, driver can  
> > 
> > skb_shared_info is not fixed size, the number of fragments can
> > be changed in the future. What will happen to the driver and
> > this assumption, then?
> >   
> 
> This is for the non-default path in legacy mode. If for some reason number of 
> fragments increase in future, we may have to think of other options like using
> page pools.

Is it possible to add runtime checks so that in configurations where
the shinfo geometry does not match expectations we'd cleanly error out?
Better to be too careful than risk silent memory corruptions..