[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2bcb7a6c-27b6-4929-ac9c-c6eba3b804b1@intel.com>
Date: Mon, 8 Apr 2024 12:50:48 +0200
From: Alexander Lobakin <aleksander.lobakin@...el.com>
To: Michal Swiatkowski <michal.swiatkowski@...ux.intel.com>
CC: Simon Horman <horms@...nel.org>, <davem@...emloft.net>,
<edumazet@...gle.com>, <kuba@...nel.org>, <pabeni@...hat.com>,
<netdev@...r.kernel.org>, <nex.sw.ncis.osdt.itp.upstreaming@...el.com>, "Arnd
Bergmann" <arnd@...db.de>
Subject: Re: [net-next v2] pfcp: avoid copy warning by simplifing code
From: Michal Swiatkowski <michal.swiatkowski@...ux.intel.com>
Date: Mon, 8 Apr 2024 12:46:42 +0200
> On Mon, Apr 08, 2024 at 09:18:29AM +0100, Simon Horman wrote:
>> On Fri, Apr 05, 2024 at 08:36:05AM +0200, Michal Swiatkowski wrote:
>>> >From Arnd comments:
>>> "The memcpy() in the ip_tunnel_info_opts_set() causes
>>> a string.h fortification warning, with at least gcc-13:
>>>
>>> In function 'fortify_memcpy_chk',
>>> inlined from 'ip_tunnel_info_opts_set' at include/net/ip_tunnels.h:619:3,
>>> inlined from 'pfcp_encap_recv' at drivers/net/pfcp.c:84:2:
>>> include/linux/fortify-string.h:553:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
>>> 553 | __write_overflow_field(p_size_field, size);"
>>>
>>> It is a false-positivie caused by ambiguity of the union.
>>>
>>> However, as Arnd noticed, copying here is unescessary. The code can be
>>> simplified to avoid calling ip_tunnel_info_opts_set(), which is doing
>>> copying, setting flags and options_len.
>>>
>>> Set correct flags and options_len directly on tun_info.
>>>
>>> Fixes: 6dd514f48110 ("pfcp: always set pfcp metadata")
>>> Reported-by: Arnd Bergmann <arnd@...db.de>
>>> Closes: https://lore.kernel.org/netdev/701f8f93-f5fb-408b-822a-37a1d5c424ba@app.fastmail.com/
>>> Acked-by: Arnd Bergmann <arnd@...db.de>
>>> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@...ux.intel.com>
>>
>> I agree that it's nice to avoid a copy.
>> But I do wonder where else this pattern may exist.
>> And if it might be worth introducing a helper for it.
>
> Right, the same is done in vxlan, ip_gre and ip6_gre at least. I will
> send v3 with helper.
Dave applied v2 already, so send this helper as a general improvement
w/o "Fixes:" :D
>
> Thanks,
> Michal
>
>>
>> Regardless, this looks good to me.
>>
>> Reviewed-by: Simon Horman <horms@...nel.org>
>>
>> ...
Thanks,
Olek
Powered by blists - more mailing lists