Messages in this thread | | | Subject | Re: [PATCH 3/5] staging: rtl8188eu: use is_multicast_ether_addr in rtw_xmit.c | From | Michael Straube <> | Date | Thu, 9 Aug 2018 21:44:54 +0200 |
| |
On 8/9/18 8:03 PM, Michael Straube wrote: > On 8/9/18 7:51 PM, Joe Perches wrote: >> On Thu, 2018-08-09 at 19:42 +0200, Michael Straube wrote: >>> On 8/9/18 7:13 PM, Joe Perches wrote: >>>> On Thu, 2018-08-09 at 19:01 +0200, Michael Straube wrote: >>>>> Use is_multicast_ether_addr instead of custom IS_MCAST in >>>>> core/rtw_xmit.c. >>>> >>>> Have you verified that all accesses are __aligned(2) ? >>>> >>>> If so, please state that in the patch description. >>>> >>>>> diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c b/drivers/staging/rtl8188eu/core/rtw_xmit.c >>>> >>>> [] >>>>> @@ -460,10 +460,10 @@ static s32 update_attrib(struct adapter *padapter, struct sk_buff *pkt, struct p >>>>> if ((pattrib->ether_type == ETH_P_ARP) || (pattrib->ether_type == ETH_P_PAE) || (pattrib->dhcp_pkt == 1)) >>>>> rtw_lps_ctrl_wk_cmd(padapter, LPS_CTRL_SPECIAL_PACKET, 1); >>>>> - bmcast = IS_MCAST(pattrib->ra); >>>>> + mcast = is_multicast_ether_addr(pattrib->ra); >>>> >>>> i.e.: is pattrib->ra __aligned(2) ? >>>> >>>> etc... >>>> >>> >>> Hi Joe, >>> >>> I looked at the function comment for is_multicast_ether_addr in etherdevice.h. >>> There is not mentioned that __aligned(2) is required. If it is, I will check. >>> >>> So, is it required although it's not mentioned for is_multicast_ether_addr? >> >> Well, it wasn't required initially, but >> >> commit d54385ce68cd18ab002b46f61246ad197cec92de >> Author: Alexander Duyck <alexander.h.duyck@redhat.com> >> Date: Thu Apr 30 14:53:54 2015 -0700 >> >> etherdev: Process is_multicast_ether_addr at same size as other operations >> This change makes it so that we process the address in >> is_multicast_ether_addr at the same size as the other calls. This allows >> us to avoid duplicate reads when used with other calls such as >> is_zero_ether_addr or eth_addr_copy. In addition I have added a 64 bit >> version of the function so in eth_type_trans we can process the destination >> address as a 64 bit value throughout. >> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com> >> Signed-off-by: David S. Miller <davem@davemloft.net> >> >> changed it without adding a note in the kernel-doc. >> >> So this is likely appropriate to avoid unaligned access traps: >> --- >> include/linux/etherdevice.h | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h >> index 572e11bb8696..0f7086b4836a 100644 >> --- a/include/linux/etherdevice.h >> +++ b/include/linux/etherdevice.h >> @@ -115,6 +115,8 @@ static inline bool 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. >> + * >> + * Please note: addr must be aligned to u16. >> */ >> static inline bool is_multicast_ether_addr(const u8 *addr) >> { >> > > Ok, then I will check and resend the series. > Thanks again.
I looked at it and I'm not sure about this one: (where precv_frame->pkt is a sk_buff)
is_multicast_ether_addr(GetAddr1Ptr(precv_frame->pkt->data))
and the macro GetAddr1Ptr:
#define GetAddr1Ptr(pbuf) ((unsigned char *)((size_t)(pbuf) + 4))
Is the memory pointed to by sk_buff->data (always) __aligned(2) ?
| |