Re: [PATCH 1/1] net/wireless/ibss.c: replace memcpy by ether_addr_copy

[Johannes Berg]

On Mon, 2014-05-12 at 12:17 -0700, Joe Perches wrote:

> > I certainly don't see the benefit in changing all those other files,
> > particularly since it's not just that we have to verify alignment *now*,
> > we also have to add alignment attributes so that we don't break
> > alignment in the future.
> 
> The same alignment requirements exist in quite a
> lot of the code so I don't see that as much of a
> continuing problem.

I disagree. This may be true for some of the cases we're discussing,
e.g. the change in net/wireless/util.c which has the assumption based on
frame alignment assumptions etc.

However, for things like the mac80211/mlme.c change we're operating
entirely on internal structures that are purely in software and don't
belong to any network frames or similar structs that already have
alignment guarantees.

As a consequence, something like this simple patch:

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 5c7169b0ac57..fccbba2f4fe1 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1529,7 +1529,7 @@ struct cfg80211_bss {
 
 	u16 beacon_interval;
 	u16 capability;
-
+	u8 my_new_field;
 	u8 bssid[ETH_ALEN];
 
 	u8 priv[0] __aligned(sizeof(void *));

would already break at least one of the patches. The change looks
innocent enough, and is modifying a purely internal struct that doesn't
get used anywhere but the wireless stack (neither wire frame nor
userspace) so this is a perfectly valid change.

Therefore, the patch should mark the bssid with __aligned(2) or such, to
avoid having simple patches like that introduce problems.



> > Additionally doesn't even really save much typing:
> > 
> > memcpy(x, y, ETH_ALEN);
> > ether_addr_copy(x, y);
> 
> To me the general benefit isn't in the reduced
> source code size, but small improvements for
> ARM both in code size and execution speed.

Well, yes, but if it's in a configuration path, which you invoke maybe a
few times an hour, it doesn't seem worth it at all.

If it's in a frame/data hotpath, like the util.c change that already has
other alignment guarantees, it does seem somewhat worthwhile, but beyond
that I'm not so sure.

johannes

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/