[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <02ebed305b6bb50f272c7f3decfa204dc72311f0.camel@mellanox.com>
Date: Fri, 9 Aug 2019 18:49:50 +0000
From: Saeed Mahameed <saeedm@...lanox.com>
To: "jakub.kicinski@...ronome.com" <jakub.kicinski@...ronome.com>
CC: "davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Tariq Toukan <tariqt@...lanox.com>,
Maxim Mikityanskiy <maximmi@...lanox.com>
Subject: Re: [net 01/12] net/mlx5e: Use flow keys dissector to parse packets
for ARFS
On Thu, 2019-08-08 at 18:15 -0700, Jakub Kicinski wrote:
> On Thu, 8 Aug 2019 20:22:00 +0000, Saeed Mahameed wrote:
> > From: Maxim Mikityanskiy <maximmi@...lanox.com>
> >
> > The current ARFS code relies on certain fields to be set in the SKB
> > (e.g. transport_header) and extracts IP addresses and ports by
> > custom
> > code that parses the packet. The necessary SKB fields, however, are
> > not
> > always set at that point, which leads to an out-of-bounds access.
> > Use
> > skb_flow_dissect_flow_keys() to get the necessary information
> > reliably,
> > fix the out-of-bounds access and reuse the code.
>
> The whole series LGTM, FWIW.
>
> I'd be curious to hear which path does not have the skb fully
> set up, could you elaborate? (I'm certainly no aRFC expert this
> is pure curiosity).
In our regression we found two use cases that might lead aRFS using un-
initialized values.
1) GRO Disabled, Usually GRO fills the necessary fields.
2) Raw socket type of tests.
And i am sure there are many other use cases. So drivers must use
skb_flow_dissect_flow_keys() for aRFS parsing and eliminate all
uncertainties.
Powered by blists - more mailing lists