From: Sven Eckelmann <sven@narfation.org>
To: b.a.t.m.a.n@lists.open-mesh.org
Cc: martin@hundeboll.net
Subject: Re: [B.A.T.M.A.N.] [PATCH maint] batman-adv: Fix transmission of final, 16th fragment
Date: Mon, 13 Feb 2017 22:23:52 +0100 [thread overview]
Message-ID: <3594207.H7EOxyrbqM@sven-edge> (raw)
In-Reply-To: <20170213200008.GK29718@otheros>
[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]
On Montag, 13. Februar 2017 21:00:08 CET Linus Lüssing wrote:
[...]
> And one more thing which seems fishy to me in this function:
>
> 526 /* Make room for the fragment header. */
> 527 if (batadv_skb_head_push(skb, header_size) < 0 ||
> 528 pskb_expand_head(skb, header_size + ETH_HLEN, 0, GFP_ATOMIC) < 0) {
> 529 ret = -ENOMEM;
> 530 goto put_primary_if;
> 531 }
> 532
> 533 memcpy(skb->data, &frag_header, header_size);
>
>
> For the pskb_expand_head() case, there is an skb_push(header_size) missing,
> isn't it?
I am a little bit confused about your remark... and about the code.
So let's check what Martin wrote:
* get header_size more room in our data section
* allocate new buffer to get header_size + ETH_HLEN in front (but not part)
of our data section
If one of these two fails then it will get in panic mode and leave the
function.
I agree that the header_size in pskb_expand_head is slightly odd and I don't
see why we would need it. My best guess would be to compensate the extra
header which "stole" some bytes from the headroom which the underlying
interface may need.
But more importantly, I don't understand why an extra skb_push(header_size)
(like you've suggested) would be necessary here. Why would you want to have an
empty header_size region in the fragment between the actual header and the
fragment data?
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2017-02-13 21:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-13 19:44 [B.A.T.M.A.N.] [PATCH maint] batman-adv: Fix transmission of final, 16th fragment Linus Lüssing
2017-02-13 20:00 ` Linus Lüssing
2017-02-13 21:23 ` Sven Eckelmann [this message]
2017-02-14 8:30 ` Linus Lüssing
2017-02-13 20:51 ` Sven Eckelmann
2017-02-21 17:27 ` Sven Eckelmann
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=3594207.H7EOxyrbqM@sven-edge \
--to=sven@narfation.org \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=martin@hundeboll.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox