netdev - Re: [PATCH net-next] net: mhi-net: Add de-aggeration support

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

Message-ID: <CAF=yD-KT0nPEV4CphRH3xVJhXqpK=FQHM-3TkK+88ZqA9afeFw@mail.gmail.com>
Date:   Mon, 1 Feb 2021 13:33:05 -0500
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Loic Poulain <loic.poulain@...aro.org>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        David Miller <davem@...emloft.net>,
        Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] net: mhi-net: Add de-aggeration support

On Mon, Feb 1, 2021 at 11:41 AM Loic Poulain <loic.poulain@...aro.org> wrote:
>
> On Mon, 1 Feb 2021 at 15:24, Willem de Bruijn
> <willemdebruijn.kernel@...il.com> wrote:
> >
> > On Mon, Feb 1, 2021 at 3:08 AM Loic Poulain <loic.poulain@...aro.org> wrote:
> > >
> > > Hi Jakub, Willem,
> > >
> > > On Sat, 30 Jan 2021 at 02:01, Jakub Kicinski <kuba@...nel.org> wrote:
> > > >
> > > > On Mon, 25 Jan 2021 16:45:57 +0100 Loic Poulain wrote:
> > > > > When device side MTU is larger than host side MRU, the packets
> > > > > (typically rmnet packets) are split over multiple MHI transfers.
> > > > > In that case, fragments must be re-aggregated to recover the packet
> > > > > before forwarding to upper layer.
> > > > >
> > > > > A fragmented packet result in -EOVERFLOW MHI transaction status for
> > > > > each of its fragments, except the final one. Such transfer was
> > > > > previoulsy considered as error and fragments were simply dropped.
> > > > >
> > > > > This patch implements the aggregation mechanism allowing to recover
> > > > > the initial packet. It also prints a warning (once) since this behavior
> > > > > usually comes from a misconfiguration of the device (modem).
> > > > >
> > > > > Signed-off-by: Loic Poulain <loic.poulain@...aro.org>
> > > >
> > > > > +static struct sk_buff *mhi_net_skb_append(struct mhi_device *mhi_dev,
> > > > > +                                       struct sk_buff *skb1,
> > > > > +                                       struct sk_buff *skb2)
> > > > > +{
> > > > > +     struct sk_buff *new_skb;
> > > > > +
> > > > > +     /* This is the first fragment */
> > > > > +     if (!skb1)
> > > > > +             return skb2;
> > > > > +
> > > > > +     /* Expand packet */
> > > > > +     new_skb = skb_copy_expand(skb1, 0, skb2->len, GFP_ATOMIC);
> > > > > +     dev_kfree_skb_any(skb1);
> > > > > +     if (!new_skb)
> > > > > +             return skb2;
> > > >
> > > > I don't get it, if you failed to grow the skb you'll return the next
> > > > fragment to the caller? So the frame just lost all of its data up to
> > > > where skb2 started? The entire fragment "train" should probably be
> > > > dropped at this point.
> > >
> > > Right, there is no point in keeping the partial packet in that case.
> > >
> > > >
> > > > I think you can just hang the skbs off skb_shinfo(p)->frag_list.
> > > >
> > > > Willem - is it legal to feed frag_listed skbs into netif_rx()?
> > >
> > > In QMAP case, the packets will be forwarded to rmnet link, which works
> > > with linear skb (no NETIF_F_SG), does the linearization will be
> > > properly performed by the net core, in the same way as for xmit path?
> >
> > What is this path to rmnet, if not the usual xmit path / validate_xmit_skb?
>
> I mean, not sure what to do exactly here, instead of using
> skb_copy_expand to re-aggregate data from the different skbs, Jakub
> suggests chaining the skbs instead (via 'frag_list' and 'next' pointer
> I assume), and to push this chained skb to net core via netif_rx. In
> that case, I assume the de-fragmentation/linearization will happen in
> the net core, right? If the transported protocol is rmnet, the packet
> is supposed to reach the rmnet_rx_handler at some point, but rmnet
> only works with standard/linear skbs.

If it has that limitation, the rx_handler should have a check and linearize.

That is simpler than this skb_copy_expand, and as far as I can see no
more expensive.