[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1389021522.12212.174.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Mon, 06 Jan 2014 07:18:42 -0800
From: Eric Dumazet <eric.dumazet@...il.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Emmanuel Grumbach <egrumbach@...il.com>,
Johannes Berg <johannes@...solutions.net>,
Henrique de Moraes Holschuh <hmh@....eng.br>,
Julia Lawall <julia.lawall@...6.fr>,
"kernel-janitors@...r.kernel.org" <kernel-janitors@...r.kernel.org>,
Emmanuel Grumbach <emmanuel.grumbach@...el.com>,
Intel Linux Wireless <ilw@...ux.intel.com>,
"John W. Linville" <linville@...driver.com>,
linux-wireless <linux-wireless@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/11] use ether_addr_equal_64bits
On Mon, 2014-01-06 at 10:24 +0100, Geert Uytterhoeven wrote:
> Thanks to this discussion, my eye fell on:
>
> static inline unsigned compare_ether_addr(const u8 *addr1, const u8 *addr2)
> {
> const u16 *a = (const u16 *) addr1;
> const u16 *b = (const u16 *) addr2;
>
> BUILD_BUG_ON(ETH_ALEN != 6);
> return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) != 0;
> }
>
> What if addr1 or addr2 are odd, and this is running on an architecture that
> doesn't support unaligned accesses at all?? Have we been lucky forever?
This function always had the guarantee of u16 alignment.
No protocol ever included an ether address at an odd alignment, and
drivers always make sure a frame is at least 2-byte aligned.
Its kind of obvious for networking people, Stephen did not mention this
property in commit 360ac8e2f1a38c34
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists