From: Andrew Lunn <andrew@lunn.ch>
To: The list for a Better Approach To Mobile Ad-hoc Networking
<b.a.t.m.a.n@lists.open-mesh.org>
Cc: Sven Eckelmann <sven@narfation.org>, Felix Kaechele <felix@kaechele.ca>
Subject: Re: [PATCH] batman-adv: Don't skb_split skbuffs with frag_list
Date: Sat, 16 Apr 2022 16:21:19 +0200 [thread overview]
Message-ID: <YlrQ306LD4luXaeJ@lunn.ch> (raw)
In-Reply-To: <20220416122434.33061-1-sven@narfation.org>
On Sat, Apr 16, 2022 at 02:24:34PM +0200, Sven Eckelmann wrote:
> The receiving interface might have used GRO to receive more fragments than
> MAX_SKB_FRAGS fragments. In this case, these will not be stored in
> skb_shinfo(skb)->frags but merged into the frag list.
>
> batman-adv relies on the function skb_split to split packets up into
> multiple smaller packets which are not larger than the MTU on the outgoing
> interface. But this function cannot handle frag_list entries and is only
> operating on skb_shinfo(skb)->frags. If it is then still trying to split
> such an skb and xmit'ing it on an interface without support for
> NETIF_F_FRAGLIST then validate_xmit_skb() will try to linearize it. But
> this fails due to inconsistent information and __pskb_pull_tail will
> trigger a BUG_ON after skb_copy_bits() returns an error.
>
> In case of entries in frag_list, just linearize the skb before operating on
> it with skb_split().
Hi Sven
This is not an area of the kernel i'm very familiar with. But i'm
wondering, is this a BATMAN specific problem, or a generic problem?
Should the fix be in BATMAN, or the core?
Andrew
next prev parent reply other threads:[~2022-04-16 14:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-16 12:24 [PATCH] batman-adv: Don't skb_split skbuffs with frag_list Sven Eckelmann
2022-04-16 14:01 ` Felix Kaechele
2022-04-16 14:21 ` Andrew Lunn [this message]
2022-04-16 17:17 ` Sven Eckelmann
2022-04-16 17:26 ` Andrew Lunn
[not found] ` <165011769041.26690.10778801125078465694@diktynna.open-mesh.org>
2022-04-17 16:07 ` Felix Kaechele
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YlrQ306LD4luXaeJ@lunn.ch \
--to=andrew@lunn.ch \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=felix@kaechele.ca \
--cc=sven@narfation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.