lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Fri, 5 Mar 2021 15:02:56 -0600
From:   Alex Elder <elder@...e.org>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Alex Elder <elder@...aro.org>
Cc:     subashab@...eaurora.org, stranche@...eaurora.org,
        davem@...emloft.net, kuba@...nel.org, sharathv@...eaurora.org,
        evgreen@...omium.org, cpratapa@...eaurora.org, elder@...nel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 2/6] net: qualcomm: rmnet: simplify some byte
 order logic

On 3/4/21 10:07 PM, Bjorn Andersson wrote:
> On Thu 04 Mar 16:34 CST 2021, Alex Elder wrote:
> 
>> In rmnet_map_ipv4_ul_csum_header() and rmnet_map_ipv6_ul_csum_header()
>> the offset within a packet at which checksumming should commence is
>> calculated.  This calculation involves byte swapping and a forced type
>> conversion that makes it hard to understand.
>>
>> Simplify this by computing the offset in host byte order, then
>> converting the result when assigning it into the header field.
>>
>> Signed-off-by: Alex Elder <elder@...aro.org>
>> ---
>>   .../ethernet/qualcomm/rmnet/rmnet_map_data.c  | 22 ++++++++++---------
>>   1 file changed, 12 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
>> index 21d38167f9618..bd1aa11c9ce59 100644
>> --- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
>> +++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
>> @@ -197,12 +197,13 @@ rmnet_map_ipv4_ul_csum_header(void *iphdr,
>>   			      struct rmnet_map_ul_csum_header *ul_header,
>>   			      struct sk_buff *skb)
>>   {
>> -	struct iphdr *ip4h = (struct iphdr *)iphdr;
>> -	__be16 *hdr = (__be16 *)ul_header, offset;
>> +	__be16 *hdr = (__be16 *)ul_header;
>> +	struct iphdr *ip4h = iphdr;
>> +	u16 offset;
>> +
>> +	offset = skb_transport_header(skb) - (unsigned char *)iphdr;
>> +	ul_header->csum_start_offset = htons(offset);
>>   
>> -	offset = htons((__force u16)(skb_transport_header(skb) -
> 
> Just curious, why does this require a __force, or even a cast?

The argument to htons() has type __u16.  In this case it
is passed the difference between pointers, which will
have type ptrdiff_t, which is certainly bigger than
16 bits.  I don't think the __force is needed, but the
cast to u16 might just be making the conversion to the
smaller type explicit.  Here too though, I don't think
it's necessary.

					-Alex

> Regardless, your proposed way of writing it is easier to read.
> 
> Reviewed-by: Bjorn Andersson <bjorn.andersson@...aro.org>
> 
> Regards,
> Bjorn
> 
>> -				     (unsigned char *)iphdr));
>> -	ul_header->csum_start_offset = offset;
>>   	ul_header->csum_insert_offset = skb->csum_offset;
>>   	ul_header->csum_enabled = 1;
>>   	if (ip4h->protocol == IPPROTO_UDP)
>> @@ -239,12 +240,13 @@ rmnet_map_ipv6_ul_csum_header(void *ip6hdr,
>>   			      struct rmnet_map_ul_csum_header *ul_header,
>>   			      struct sk_buff *skb)
>>   {
>> -	struct ipv6hdr *ip6h = (struct ipv6hdr *)ip6hdr;
>> -	__be16 *hdr = (__be16 *)ul_header, offset;
>> +	__be16 *hdr = (__be16 *)ul_header;
>> +	struct ipv6hdr *ip6h = ip6hdr;
>> +	u16 offset;
>> +
>> +	offset = skb_transport_header(skb) - (unsigned char *)ip6hdr;
>> +	ul_header->csum_start_offset = htons(offset);
>>   
>> -	offset = htons((__force u16)(skb_transport_header(skb) -
>> -				     (unsigned char *)ip6hdr));
>> -	ul_header->csum_start_offset = offset;
>>   	ul_header->csum_insert_offset = skb->csum_offset;
>>   	ul_header->csum_enabled = 1;
>>   
>> -- 
>> 2.20.1
>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ