isdn: bugfix in isdn_net_ciscohdlck_slarp_send_reply, trivial sparse fixes
Subsystems (2)
PATCH 1/1 isdn: bugfix in isdn_net_ciscohdlck_slarp_send_reply, trivial sparse fixes
commit a144ea4b7a13087081ab5402fa9ad0bcfd249e67 [IPV4]: annotate struct in_ifaddr
Missed the extra byteswap because the previous isdn inline helpers hid the extra htonl inside put_u32. This was causing an extra byteswap on little-endian arches.
While here, do the trivial annotation of the struct ip_ports and change the remaining casts to __be16 where applicable.
---
Dave, the yesterday's patch was a zero-change patch that exposed this bug, this patch changes behavior in the above-referenced function.
drivers/isdn/i4l/isdn_net.c | 16 ++++++++-------- 1 files changed, 8 insertions(+), 8 deletions(-)
drivers/isdn/i4l/isdn_net.c +8 -8
@@ -865,8 +865,8 @@ isdn_net_hangup(struct net_device *d) }typedef struct { -unsigned short source; -unsigned short dest; +__be16 source; +__be16 dest; }ip_ports ; static void
@@ -1355,7 +1355,7 @@ isdn_net_get_stats(struct net_device *dev)* This is normal practice and works for any 'now in use' protocol. */ -static unsigned short +static __be16 isdn_net_type_trans (struct sk_buff *skb,struct net_device *dev) {struct ethhdr *eth;
@@ -1637,8 +1637,8 @@ isdn_net_ciscohdlck_slarp_send_reply(isdn_net_local *lp)/* slarp reply, send own ip/netmask; if values are nonsense remote * should think we are unable to provide it with an address via SLARP */ *(__be32 *)(p +4 ) =cpu_to_be32 (CISCO_SLARP_REPLY ); - *(__be32 *)(p +8 ) =cpu_to_be32 (addr);// address - *(__be32 *)(p +12 ) =cpu_to_be32 (mask);// netmask + *(__be32 *)(p +8 ) = addr;// address + *(__be32 *)(p +12 ) = mask;// netmask *(__be16 *)(p +16 ) =cpu_to_be16 (0 );// unused p +=18 ;
@@ -1817,7 +1817,7 @@ isdn_net_receive(struct net_device *ndev, struct sk_buff *skb)/* IP with type field */ olp->huptimer =0 ; lp->huptimer =0 ; - skb->protocol = *(unsigned short *) &(skb->data[0 ]); + skb->protocol = *(__be16 *)&(skb->data[0 ]);skb_pull (skb,2 );if (*(unsigned short *) skb->data ==0xFFFF ) skb->protocol =htons (ETH_P_802_3 );
@@ -1899,12 +1899,12 @@ static int isdn_net_header(struct sk_buff *skb, struct net_device *dev,break ;case ISDN_NET_ENCAP_IPTYP :/* ethernet type field */ - *((ushort *)skb_push (skb,2 )) =htons (type); + *((__be16 *)skb_push (skb,2 )) =htons (type); len =2 ;break ;case ISDN_NET_ENCAP_UIHDLC :/* HDLC with UI-Frames (for ispa with -h1 option) */ - *((ushort *)skb_push (skb,2 )) =htons (0x0103 ); + *((__be16 *)skb_push (skb,2 )) =htons (0x0103 ); len =2 ;break ;case ISDN_NET_ENCAP_CISCOHDLC :
Signature · 1 line
1.6.0.4.879.g9d19a
David Miller
maintainerFrom: Harvey Harrison <[email protected]>
Date: Fri, 14 Nov 2008 09:33:49 -0800
Quoted 6 lines
commit
a144ea4b7a13087081ab5402fa9ad0bcfd249e67[IPV4]: annotate structin_ifaddrMissed the extra byteswap because the previous isdn inline helpers hid the extra htonl inside
put_u32. This was causing an extra byteswap on little-endian arches.
Quoted 7 lines
While here, do the trivial annotation of the struct
ip_portsand change the remaining casts to__be16where applicable.Signed-off-by Harvey Harrison <[email protected]>---
Dave, the yesterday's patch was a zero-change patch that exposed this bug, this patch changes behavior in the above-referenced function.
Well, you've created an incredibly difficult situation for me.
The bug exists in 2.6.28-rcX but your cleanup patch was only appropriate for net-next-2.6 so that's where it went.
But this bug fix here will only apply on top of that cleanup.
This is wrong, please propose a way to correct this so that 2.6.28-rcX can get this bug fixed properly, without a dependency on a cleanup with is not appropriate for 2.6.28-rcX.