[PATCH] net: compare_ether_addr[_64bits]() has no ordering

STALE5212d

11 messages, 4 authors, 2012-05-08 · open the first message on its own page

[PATCH] net: compare_ether_addr[_64bits]() has no ordering

From: Johannes Berg <johannes@sipsolutions.net>
Date: 2012-05-07 13:39:08

From: Johannes Berg <redacted>

Neither compare_ether_addr() nor compare_ether_addr_64bits()
(as it can fall back to the former) have comparison semantics
like memcmp() where the sign of the return value indicates sort
order. We had a bug in the wireless code due to a blind memcmp
replacement because of this.

A cursory look suggests that the wireless bug was the only one
due to this semantic difference.

Signed-off-by: Johannes Berg <redacted>
---
 include/linux/etherdevice.h |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)
--- a/include/linux/etherdevice.h	2012-04-12 05:40:35.000000000 +0200
+++ b/include/linux/etherdevice.h	2012-05-07 15:34:28.000000000 +0200
@@ -159,7 +159,8 @@ static inline void eth_hw_addr_random(st
  * @addr1: Pointer to a six-byte array containing the Ethernet address
  * @addr2: Pointer other six-byte array containing the Ethernet address
  *
- * Compare two ethernet addresses, returns 0 if equal
+ * Compare two ethernet addresses, returns 0 if equal, non-zero otherwise.
+ * Unlike memcmp(), it doesn't return a value suitable for sorting.
  */
 static inline unsigned compare_ether_addr(const u8 *addr1, const u8 *addr2)
 {
@@ -184,10 +185,10 @@ static inline unsigned long zap_last_2by
  * @addr1: Pointer to an array of 8 bytes
  * @addr2: Pointer to an other array of 8 bytes
  *
- * Compare two ethernet addresses, returns 0 if equal.
- * Same result than "memcmp(addr1, addr2, ETH_ALEN)" but without conditional
- * branches, and possibly long word memory accesses on CPU allowing cheap
- * unaligned memory reads.
+ * Compare two ethernet addresses, returns 0 if equal, non-zero otherwise.
+ * Unlike memcmp(), it doesn't return a value suitable for sorting.
+ * The function doesn't need any conditional branches and possibly uses
+ * word memory accesses on CPU allowing cheap unaligned memory reads.
  * arrays = { byte1, byte2, byte3, byte4, byte6, byte7, pad1, pad2}
  *
  * Please note that alignment of addr1 & addr2 is only guaranted to be 16 bits.

Re: [PATCH] net: compare_ether_addr[_64bits]() has no ordering

From: Eric Dumazet <hidden>
Date: 2012-05-07 13:53:34

On Mon, 2012-05-07 at 15:39 +0200, Johannes Berg wrote:
From: Johannes Berg <redacted>

Neither compare_ether_addr() nor compare_ether_addr_64bits()
(as it can fall back to the former) have comparison semantics
like memcmp() where the sign of the return value indicates sort
order. We had a bug in the wireless code due to a blind memcmp
replacement because of this.

A cursory look suggests that the wireless bug was the only one
due to this semantic difference.

Signed-off-by: Johannes Berg <redacted>
---
 include/linux/etherdevice.h |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)
The right way to avoid this kind of problems is to change these
functions to return a bool

Re: [PATCH] net: compare_ether_addr[_64bits]() has no ordering

From: Johannes Berg <johannes@sipsolutions.net>
Date: 2012-05-07 14:12:42

On Mon, 2012-05-07 at 15:53 +0200, Eric Dumazet wrote:
On Mon, 2012-05-07 at 15:39 +0200, Johannes Berg wrote:
quoted
From: Johannes Berg <redacted>

Neither compare_ether_addr() nor compare_ether_addr_64bits()
(as it can fall back to the former) have comparison semantics
like memcmp() where the sign of the return value indicates sort
order. We had a bug in the wireless code due to a blind memcmp
replacement because of this.

A cursory look suggests that the wireless bug was the only one
due to this semantic difference.

Signed-off-by: Johannes Berg <redacted>
---
 include/linux/etherdevice.h |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)
The right way to avoid this kind of problems is to change these
functions to return a bool
Well, I guess so, but that'd be a weird thing for a compare_ function...
should probably be named equal_... then, but I'm not really able to do
such a huge change on the first day after my vacation :-)

johannes

Re: [PATCH] net: compare_ether_addr[_64bits]() has no ordering

From: David Miller <davem@davemloft.net>
Date: 2012-05-07 23:21:58

From: Johannes Berg <johannes@sipsolutions.net>
Date: Mon, 07 May 2012 16:12:41 +0200
On Mon, 2012-05-07 at 15:53 +0200, Eric Dumazet wrote:
quoted
On Mon, 2012-05-07 at 15:39 +0200, Johannes Berg wrote:
quoted
From: Johannes Berg <redacted>

Neither compare_ether_addr() nor compare_ether_addr_64bits()
(as it can fall back to the former) have comparison semantics
like memcmp() where the sign of the return value indicates sort
order. We had a bug in the wireless code due to a blind memcmp
replacement because of this.

A cursory look suggests that the wireless bug was the only one
due to this semantic difference.

Signed-off-by: Johannes Berg <redacted>
---
 include/linux/etherdevice.h |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)
The right way to avoid this kind of problems is to change these
functions to return a bool
Well, I guess so, but that'd be a weird thing for a compare_ function...
should probably be named equal_... then, but I'm not really able to do
such a huge change on the first day after my vacation :-)
It's true the name could be improved, but changing the name is quite
a large undertaking even with automated scripts.

Even the bool change is slightly painful, since all of the explicit
tests against integers (%99.999 of these are in wireless BTW :-) would
need to be adjusted.

For now, I'll just apply Johannes's comment fix.

Re: [PATCH] net: compare_ether_addr[_64bits]() has no ordering

From: Johannes Berg <johannes@sipsolutions.net>
Date: 2012-05-08 05:25:48

On Mon, 2012-05-07 at 19:20 -0400, David Miller wrote:
quoted
quoted
quoted
Neither compare_ether_addr() nor compare_ether_addr_64bits()
(as it can fall back to the former) have comparison semantics
like memcmp() where the sign of the return value indicates sort
order. We had a bug in the wireless code due to a blind memcmp
replacement because of this.

A cursory look suggests that the wireless bug was the only one
due to this semantic difference.

Signed-off-by: Johannes Berg <redacted>
---
 include/linux/etherdevice.h |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)
The right way to avoid this kind of problems is to change these
functions to return a bool
Well, I guess so, but that'd be a weird thing for a compare_ function...
should probably be named equal_... then, but I'm not really able to do
such a huge change on the first day after my vacation :-)
It's true the name could be improved, but changing the name is quite
a large undertaking even with automated scripts.

Even the bool change is slightly painful, since all of the explicit
tests against integers (%99.999 of these are in wireless BTW :-) would
need to be adjusted.
I suppose I could fix those first and then later change the type, but I
think having a "compare_ether_addr" function that returns *false* when
they *match* would be rather confusing. I'd rather have
"equal_ether_addr()" that returns *true* when they match.

I guess we could introduce equal_ether_addr() though and slowly convert,
keeping compare_ether_addr() as a sort of wrapper around it.

johannes

Re: [PATCH] net: compare_ether_addr[_64bits]() has no ordering

From: David Miller <davem@davemloft.net>
Date: 2012-05-08 06:27:54

From: Johannes Berg <johannes@sipsolutions.net>
Date: Tue, 08 May 2012 07:25:44 +0200
I suppose I could fix those first and then later change the type, but I
think having a "compare_ether_addr" function that returns *false* when
they *match* would be rather confusing. I'd rather have
"equal_ether_addr()" that returns *true* when they match.

I guess we could introduce equal_ether_addr() though and slowly convert,
keeping compare_ether_addr() as a sort of wrapper around it.
Indeed, this is one way to proceed.

Re: [PATCH] net: compare_ether_addr[_64bits]() has no ordering

From: Joe Perches <joe@perches.com>
Date: 2012-05-08 06:35:39

On Tue, 2012-05-08 at 02:26 -0400, David Miller wrote:
From: Johannes Berg <johannes@sipsolutions.net>
Date: Tue, 08 May 2012 07:25:44 +0200
quoted
I suppose I could fix those first and then later change the type, but I
think having a "compare_ether_addr" function that returns *false* when
they *match* would be rather confusing. I'd rather have
"equal_ether_addr()" that returns *true* when they match.

I guess we could introduce equal_ether_addr() though and slowly convert,
keeping compare_ether_addr() as a sort of wrapper around it.
Indeed, this is one way to proceed.
perhaps is_equal_ether_addr or is_same_ether_addr instead?

Re: [PATCH] net: compare_ether_addr[_64bits]() has no ordering

From: David Miller <davem@davemloft.net>
Date: 2012-05-08 07:32:31

From: Joe Perches <joe@perches.com>
Date: Mon, 07 May 2012 23:35:36 -0700
On Tue, 2012-05-08 at 02:26 -0400, David Miller wrote:
quoted
From: Johannes Berg <johannes@sipsolutions.net>
Date: Tue, 08 May 2012 07:25:44 +0200
quoted
I suppose I could fix those first and then later change the type, but I
think having a "compare_ether_addr" function that returns *false* when
they *match* would be rather confusing. I'd rather have
"equal_ether_addr()" that returns *true* when they match.

I guess we could introduce equal_ether_addr() though and slowly convert,
keeping compare_ether_addr() as a sort of wrapper around it.
Indeed, this is one way to proceed.
perhaps is_equal_ether_addr or is_same_ether_addr instead?
Hmmm, my first choice would have been "eth_addr_equal()"

Re: [PATCH] net: compare_ether_addr[_64bits]() has no ordering

From: Joe Perches <joe@perches.com>
Date: 2012-05-08 16:44:32

On Tue, 2012-05-08 at 03:31 -0400, David Miller wrote:
From: Joe Perches <joe@perches.com>
Date: Mon, 07 May 2012 23:35:36 -0700
quoted
On Tue, 2012-05-08 at 02:26 -0400, David Miller wrote:
quoted
From: Johannes Berg <johannes@sipsolutions.net>
Date: Tue, 08 May 2012 07:25:44 +0200
quoted
I suppose I could fix those first and then later change the type, but I
think having a "compare_ether_addr" function that returns *false* when
they *match* would be rather confusing. I'd rather have
"equal_ether_addr()" that returns *true* when they match.

I guess we could introduce equal_ether_addr() though and slowly convert,
keeping compare_ether_addr() as a sort of wrapper around it.
Indeed, this is one way to proceed.
perhaps is_equal_ether_addr or is_same_ether_addr instead?
Hmmm, my first choice would have been "eth_addr_equal()"
Perhaps ether_addr_equal for some API naming semi-consistency.

$ grep "\bint.*is_.*ether_addr" include/linux/etherdevice.h
static inline int is_zero_ether_addr(const u8 *addr)
static inline int is_multicast_ether_addr(const u8 *addr)
static inline int is_local_ether_addr(const u8 *addr)
static inline int is_broadcast_ether_addr(const u8 *addr)
static inline int is_unicast_ether_addr(const u8 *addr)
static inline int is_valid_ether_addr(const u8 *addr)

Perhaps all of these should be bool too
(patch in a separate email)

[PATCH] etherdev.h: Convert int is_<foo>_ether_addr to bool

From: Joe Perches <joe@perches.com>
Date: 2012-05-08 16:44:43

Make the return value explicitly true or false.

Signed-off-by: Joe Perches <joe@perches.com>

---

I grepped through the uses, there are a couple of
tests that store to an int that are unaffected.

There are also a couple of senseless tests of
	is_broadcast_ether_addr() || is_multicast_ether_addr()
in staging that could be improved.

 include/linux/etherdevice.h |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
index 8a18358..46a95ef 100644
--- a/include/linux/etherdevice.h
+++ b/include/linux/etherdevice.h
@@ -59,7 +59,7 @@ extern struct net_device *alloc_etherdev_mqs(int sizeof_priv, unsigned int txqs,
  *
  * Return true if the address is all zeroes.
  */
-static inline int is_zero_ether_addr(const u8 *addr)
+static inline bool is_zero_ether_addr(const u8 *addr)
 {
 	return !(addr[0] | addr[1] | addr[2] | addr[3] | addr[4] | addr[5]);
 }
@@ -71,7 +71,7 @@ static inline int is_zero_ether_addr(const u8 *addr)
  * Return true if the address is a multicast address.
  * By definition the broadcast address is also a multicast address.
  */
-static inline int is_multicast_ether_addr(const u8 *addr)
+static inline bool is_multicast_ether_addr(const u8 *addr)
 {
 	return 0x01 & addr[0];
 }
@@ -82,7 +82,7 @@ static inline int is_multicast_ether_addr(const u8 *addr)
  *
  * Return true if the address is a local address.
  */
-static inline int is_local_ether_addr(const u8 *addr)
+static inline bool is_local_ether_addr(const u8 *addr)
 {
 	return 0x02 & addr[0];
 }
@@ -93,7 +93,7 @@ static inline int is_local_ether_addr(const u8 *addr)
  *
  * Return true if the address is the broadcast address.
  */
-static inline int is_broadcast_ether_addr(const u8 *addr)
+static inline bool is_broadcast_ether_addr(const u8 *addr)
 {
 	return (addr[0] & addr[1] & addr[2] & addr[3] & addr[4] & addr[5]) == 0xff;
 }
@@ -104,7 +104,7 @@ static inline int is_broadcast_ether_addr(const u8 *addr)
  *
  * Return true if the address is a unicast address.
  */
-static inline int is_unicast_ether_addr(const u8 *addr)
+static inline bool is_unicast_ether_addr(const u8 *addr)
 {
 	return !is_multicast_ether_addr(addr);
 }
@@ -118,7 +118,7 @@ static inline int is_unicast_ether_addr(const u8 *addr)
  *
  * Return true if the address is valid.
  */
-static inline int is_valid_ether_addr(const u8 *addr)
+static inline bool is_valid_ether_addr(const u8 *addr)
 {
 	/* FF:FF:FF:FF:FF:FF is a multicast address so we don't need to
 	 * explicitly check for it here. */

Re: [PATCH] etherdev.h: Convert int is_<foo>_ether_addr to bool

From: David Miller <davem@davemloft.net>
Date: 2012-05-08 17:08:59

From: Joe Perches <joe@perches.com>
Date: Tue, 08 May 2012 09:44:40 -0700
Make the return value explicitly true or false.

Signed-off-by: Joe Perches <joe@perches.com>
Looks good, applied, thanks Joe.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help