[PATCH] net/iavf: fix checksum offloading

David Marchand david.marchand at redhat.com
Tue Aug 22 09:39:45 CEST 2023


On Tue, Aug 22, 2023 at 9:33 AM Zhang, Qi Z <qi.z.zhang at intel.com> wrote:
> > If the driver reads l2_len or l3_len, this is an undefined behavior:
> > for example, OVS might have been using l2_len or l3_len for its internal uses
> > (though I agree it would be risky for an application to do so).
> >
> > We probably need to fix access to l2_len a few lines before my patch.
> >
> >         if (m->ol_flags & RTE_MBUF_F_TX_TUNNEL_MASK &&
> >                         !(m->ol_flags & RTE_MBUF_F_TX_SEC_OFFLOAD))
> >                 offset |= (m->outer_l2_len >> 1)
> >                         << IAVF_TX_DESC_LENGTH_MACLEN_SHIFT;
> >         else
> >                 offset |= (m->l2_len >> 1)
> >                         << IAVF_TX_DESC_LENGTH_MACLEN_SHIFT;
> >
> >
> > But to be clear, no I don't think looking at l3_len value is better:
> > it should not be read at all.
>
> Yes, you may be correct; it appears that this issue is unrelated to l3_len. The primary concern is to prevent the configuration of Tx descriptors with incorrect values.
>
> Based on your description, it seems the problem arises when the PMD sets MACLEN to 0 and also configures IIPT as 01b, Is this correct?
>
> To prevent this issue, we could implement a check where, if l2_len is 0, we simply ignore the IIPT configuration and keep it at 0. (which leads to same configure with your patch)

The driver is _not_ supposed to read l2_len or l3_len if no valid
ol_flags is set.
I will reject any suggestion where you consider their values.


-- 
David Marchand



More information about the stable mailing list