On Thu, 5 Sep 2019 17:51:20 -0400
Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote:
> On Thu, Sep 5, 2019 at 2:36 PM Shmulik Ladkani <shmu...@metanetworks.com>
> wrote:
> >
> > + if (mss != GSO_BY_FRAGS &&
> > + (skb_shinfo(head_skb)->gso_type & SKB_GSO_DODGY)) {
> > + /* gso_size is untrusted.
> > + *
> > + * If head_skb has a frag_list with a linear non head_frag
> > + * item, and head_skb's headlen does not fit requested
> > + * gso_size, fall back to copying the skbs - by disabling
> > sg.
> > + *
> > + * We assume checking the first frag suffices, i.e if
> > either of
> > + * the frags have non head_frag data, then the first frag is
> > + * too.
> > + */
> > + if (list_skb && skb_headlen(list_skb) &&
> > !list_skb->head_frag &&
> > + (mss != skb_headlen(head_skb) - doffset)) {
>
> I thought the idea was to check skb_headlen(list_skb), as that is the
> cause of the problem. Is skb_headlen(head_skb) a good predictor of
> that? I can certainly imagine that it is, just not sure.
Yes, 'mss != skb_headlen(HEAD_SKB)' seems to be a very good predictor,
both for the test reproducer, and what's observered on a live system.
We *CANNOT* use 'mss != skb_headlen(LIST_SKB)' as the test condition.
The packet could have just a SINGLE frag_list member, and that member could
be a "small remainder" not reaching the full mss size - so we could hit
the test condition EVEN FOR NON gso_size mangled frag_list skbs -
which is not desired.
Also, is we test 'mss != skb_headlen(list_skb)' and execute 'sg=false'
ONLY IF 'list_skb' is *NOT* the last item, this is still bogus.
Imagine a gso_size mangled packet having just head_skb and a single
"small remainder" frag. This packet will hit the BUG_ON, as the
'sg=false' solution is now skipped according to the revised condition.
> Thanks for preparing the patch, and explaining the problem and
> solution clearly in the commit message. I'm pretty sure I'll have
> forgotten the finer details next time we have to look at this
> function again.
Indeed. Apparently I've been there myself few years back and forgot all
the gritty details :) see [0]
[0] https://patchwork.ozlabs.org/patch/661419/
