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(-)
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
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
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.
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
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.
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?
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()"
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)
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(-)
@@ -71,7 +71,7 @@ static inline int is_zero_ether_addr(const u8 *addr)*Returntrueiftheaddressisamulticastaddress.*Bydefinitionthebroadcastaddressisalsoamulticastaddress.*/-staticinlineintis_multicast_ether_addr(constu8*addr)+staticinlineboolis_multicast_ether_addr(constu8*addr){return0x01&addr[0];}
@@ -82,7 +82,7 @@ static inline int is_multicast_ether_addr(const u8 *addr)**Returntrueiftheaddressisalocaladdress.*/-staticinlineintis_local_ether_addr(constu8*addr)+staticinlineboolis_local_ether_addr(constu8*addr){return0x02&addr[0];}
@@ -93,7 +93,7 @@ static inline int is_local_ether_addr(const u8 *addr)**Returntrueiftheaddressisthebroadcastaddress.*/-staticinlineintis_broadcast_ether_addr(constu8*addr)+staticinlineboolis_broadcast_ether_addr(constu8*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)**Returntrueiftheaddressisaunicastaddress.*/-staticinlineintis_unicast_ether_addr(constu8*addr)+staticinlineboolis_unicast_ether_addr(constu8*addr){return!is_multicast_ether_addr(addr);}
@@ -118,7 +118,7 @@ static inline int is_unicast_ether_addr(const u8 *addr)**Returntrueiftheaddressisvalid.*/-staticinlineintis_valid_ether_addr(constu8*addr)+staticinlineboolis_valid_ether_addr(constu8*addr){/* FF:FF:FF:FF:FF:FF is a multicast address so we don't need to*explicitlycheckforithere.*/