[PATCH 2.6.2] drivers/net/bonding/bond_alb.c

[PATCH 2.6.2] drivers/net/bonding/bond_alb.c

[Bryan Whitehead]

__constant_htons is used on a variable that is only a byte. This results
in an if statement always returning true in function bond_alb_xmit.

This is the compiler warning on gcc 3.3.2 a gentoo linux system:
  CC [M]  drivers/net/bonding/bond_alb.o
drivers/net/bonding/bond_alb.c: In function `bond_alb_xmit':
drivers/net/bonding/bond_alb.c:1340: warning: comparison is always true due to limited range of data type

Here is the patch:
--- linux-2.6.2/drivers/net/bonding/bond_alb.c.orig     2004-02-04 15:08:04.228336168 -0800
+++ linux-2.6.2/drivers/net/bonding/bond_alb.c  2004-02-04 15:26:03.769221008 -0800
@@ -1336,8 +1336,7 @@ bond_alb_xmit(struct sk_buff *skb, struc
                        break;
                }
  
-               if (ipx_hdr(skb)->ipx_type !=
-                   __constant_htons(IPX_TYPE_NCP)) {
+               if (ipx_hdr(skb)->ipx_type != IPX_TYPE_NCP) {
                        /* The only protocol worth balancing in
                         * this family since it has an "ARP" like
                         * mechanism


--
Bryan Whitehead
driver@megahappy.net

Re: [PATCH 2.6.2] drivers/net/bonding/bond_alb.c

[Bryan Whitehead]

oops, sorry for duplicate email, thought I didn't send in the patch 
already...

Bryan Whitehead wrote:
> __constant_htons is used on a variable that is only a byte. This results
> in an if statement always returning true in function bond_alb_xmit.
> 
> This is the compiler warning on gcc 3.3.2 a gentoo linux system:
>   CC [M]  drivers/net/bonding/bond_alb.o
> drivers/net/bonding/bond_alb.c: In function `bond_alb_xmit':
> drivers/net/bonding/bond_alb.c:1340: warning: comparison is always true due to limited range of data type
> 
> Here is the patch:
> --- linux-2.6.2/drivers/net/bonding/bond_alb.c.orig     2004-02-04 15:08:04.228336168 -0800
> +++ linux-2.6.2/drivers/net/bonding/bond_alb.c  2004-02-04 15:26:03.769221008 -0800
> @@ -1336,8 +1336,7 @@ bond_alb_xmit(struct sk_buff *skb, struc
>                         break;
>                 }
>   
> -               if (ipx_hdr(skb)->ipx_type !=
> -                   __constant_htons(IPX_TYPE_NCP)) {
> +               if (ipx_hdr(skb)->ipx_type != IPX_TYPE_NCP) {
>                         /* The only protocol worth balancing in
>                          * this family since it has an "ARP" like
>                          * mechanism
> 
> 
> --
> Bryan Whitehead
> driver@megahappy.net
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


-- 
Bryan Whitehead
Email:driver@megahappy.net
WorkE:driver@jpl.nasa.gov

[PATCH 2.6.2] drivers/net/bonding/bond_alb.c

[Bryan Whitehead]

Building with gcc 3.3.2 on gentoo linux on Athlon x86 system I get
a warning:
  CC [M]  drivers/net/bonding/bond_alb.o
drivers/net/bonding/bond_alb.c: In function `bond_alb_xmit':
drivers/net/bonding/bond_alb.c:1340: warning: comparison is always true due to limited range of data type                                                                                                         
This is due to using __constant_htons for endian issues. This is a byte so there
is no point in using __constant_htons in the first place. Unless I'm mistaken using
__constant_htons makes this statment always true as the compiler states.
 
if ipx_type = IPX_TYPE_NCP then the intended logic will not happen?

--- linux-2.6.2/drivers/net/bonding/bond_alb.c.orig     2004-02-04 15:08:04.228336168 -0800
+++ linux-2.6.2/drivers/net/bonding/bond_alb.c  2004-02-04 15:26:03.769221008 -0800
@@ -1336,8 +1336,7 @@ bond_alb_xmit(struct sk_buff *skb, struc
                        break;
                }
  
-               if (ipx_hdr(skb)->ipx_type !=
-                   __constant_htons(IPX_TYPE_NCP)) {
+               if (ipx_hdr(skb)->ipx_type != IPX_TYPE_NCP) {
                        /* The only protocol worth balancing in
                         * this family since it has an "ARP" like
                         * mechanism


--
Bryan Whitehead
Email:driver@megahappy.net
WorkE:driver@jpl.nasa.gov