Re: [PATCH net-next v2 6/6] net: qualcomm: rmnet: don't use C bit-fields in rmnet checksum header

[Alex Elder]

On 3/8/21 4:18 AM, David Laight wrote:
> From: Alex Elder
> > Sent: 06 March 2021 03:16
> >
> > Replace the use of C bit-fields in the rmnet_map_ul_csum_header
> > structure with a single two-byte (big endian) structure member,
> > and use field masks to encode or get values within it.
> >
> > Previously rmnet_map_ipv4_ul_csum_header() would update values in
> > the host byte-order fields, and then forcibly fix their byte order
> > using a combination of byte order operations and types.
> >
> > Instead, just compute the value that needs to go into the new
> > structure member and save it with a simple byte-order conversion.
> >
> > Make similar simplifications in rmnet_map_ipv6_ul_csum_header().
> >
> > Finally, in rmnet_map_checksum_uplink_packet() a set of assignments
> > zeroes every field in the upload checksum header.  Replace that with
> > a single memset() operation.
> >
> > Signed-off-by: Alex Elder <elder@xxxxxxxxxx>
> > Reported-by: kernel test robot <lkp@xxxxxxxxx>
> > ---
> > v2: Fixed to use u16_encode_bits() instead of be16_encode_bits().
> >
> >   .../ethernet/qualcomm/rmnet/rmnet_map_data.c  | 34 ++++++-------------
> >   include/linux/if_rmnet.h                      | 21 ++++++------
> >   2 files changed, 21 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
> > b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
> > index 29d485b868a65..b76ad48da7325 100644
> > --- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
> > +++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
> > @@ -198,23 +198,19 @@ rmnet_map_ipv4_ul_csum_header(void *iphdr,
> >   			      struct rmnet_map_ul_csum_header *ul_header,
> >   			      struct sk_buff *skb)
> >   {
> > -	__be16 *hdr = (__be16 *)ul_header;
> >   	struct iphdr *ip4h = iphdr;
> >   	u16 offset;
> > +	u16 val;
> >
> >   	offset = skb_transport_header(skb) - (unsigned char *)iphdr;
> >   	ul_header->csum_start_offset = htons(offset);
> >
> > -	ul_header->csum_insert_offset = skb->csum_offset;
> > -	ul_header->csum_enabled = 1;
> > +	val = u16_encode_bits(1, MAP_CSUM_UL_ENABLED_FMASK);
> >   	if (ip4h->protocol == IPPROTO_UDP)
> > -		ul_header->udp_ind = 1;
> > -	else
> > -		ul_header->udp_ind = 0;
> > +		val |= u16_encode_bits(1, MAP_CSUM_UL_UDP_FMASK);
> > +	val |= u16_encode_bits(skb->csum_offset, MAP_CSUM_UL_OFFSET_FMASK);
> >
> > -	/* Changing remaining fields to network order */
> > -	hdr++;
> > -	*hdr = htons((__force u16)*hdr);
> > +	ul_header->csum_info = htons(val);
>
> Isn't this potentially misaligned?

At first I thought you were talking about column alignment.

The short answer:  Yes (at least it's possible)!  And
that's a problem elsewhere in the driver.  I noticed
that before and confirmed that unaligned accesses *do*
occur in this driver.

I would want to fix that comprehensively (and separate
from this patch), and not just in this one spot.  I have
not done it because I am not set up to readily test the
change; unaligned access does not cause a fault on aarch64
(or at least on the platforms I'm using).

Sort of related, I have been meaning to eliminate the
pointless __aligned(1) tags on rmnet structures defined
in <linux/if_rmnet.h>.  It wouldn't hurt to use __packed,
though I think they're all 4 or 8 bytes naturally anyway.
Perhaps marking them __aligned(4) would help identify
potential unaligned accesses?

Anyway, assuming you're not talking about tab stops, yes
it's possible this assignment is misaligned.  But it's a
bigger problem than what you point out.  I will take this
as a sign that I'm not the only one who has this concern,
meaning I should maybe bump the priority on getting this
alignment thing fixed.

					-Alex

> 	David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)