All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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.