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 <el...@linaro.org>
Reported-by: kernel test robot <l...@intel.com>
---
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)
