From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: The list for a Better Approach To Mobile Ad-hoc Networking
<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] [PATCH v4] batman-adv: Snoop DHCPACKs for DAT
Date: Mon, 21 May 2018 13:04:40 +0200 [thread overview]
Message-ID: <20180521110440.GJ7162@otheros> (raw)
In-Reply-To: <1526683397.ZIjaEm5zIv@sven-edge>
On Sat, May 19, 2018 at 12:08:57AM +0200, Sven Eckelmann wrote:
> On Dienstag, 15. Mai 2018 17:59:08 CEST Linus Lüssing wrote:
> > + magic = skb_header_pointer(skb, offset, sizeof(_magic), &_magic);
> > + if (!magic || *magic != htonl(BATADV_DHCP_MAGIC))
> > + return -EINVAL;
>
> I just hear a neoraider cry [1] in the background because you've added a new
> potentially unaligned 4 byte access in the network packet parsing code.
>
>
> [...]
> > +static __be32 *batadv_dat_dhcp_get_yiaddr(struct sk_buff *skb, __be32 *buffer)
> > +{
> > + unsigned int offset = skb_transport_offset(skb) + sizeof(struct udphdr);
> > + unsigned int len = sizeof(((struct batadv_dhcp_packet *)0)->yiaddr);
> > +
> > + offset += offsetof(struct batadv_dhcp_packet, yiaddr);
> > +
> > + return skb_header_pointer(skb, offset, len, buffer);
> > +}
>
> Same here
Hm, I guess there's nothing I could do about that unaligned
access other than suppressing any potential warnings? I guess
since DHCP ACKs are relatively rare compared to other traffic in
fast path I think the performance impact should be negligible.
What was the magic command to check unaligned accesses during
runtime again?
With the preceding "#pragma pack(2)" any warnings should be
suppressed already, shouldn't they?
Regards, Linus
prev parent reply other threads:[~2018-05-21 11:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-15 15:59 [B.A.T.M.A.N.] [PATCH v4] batman-adv: Snoop DHCPACKs for DAT Linus Lüssing
2018-05-18 21:46 ` Sven Eckelmann
2018-05-21 10:49 ` Linus Lüssing
2018-05-21 14:32 ` Sven Eckelmann
2018-05-18 22:08 ` Sven Eckelmann
2018-05-21 11:04 ` Linus Lüssing [this message]
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=20180521110440.GJ7162@otheros \
--to=linus.luessing@c0d3.blue \
--cc=b.a.t.m.a.n@lists.open-mesh.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.