Re: [PATCH 3/5] staging: rtl8188eu: use is_multicast_ether_addr in rtw_xmit.c

[Michael Straube]

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@xxxxxxxxxx>
> > 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@xxxxxxxxxx>
> > ÂÂÂÂ Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
> >
> > 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) ?