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]
Message-ID: <d04a5dc3-ea0c-499a-b01f-86d0f1ad0e13@intel.com>
Date: Tue, 29 Oct 2024 16:08:05 +0100
From: Alexander Lobakin <aleksander.lobakin@...el.com>
To: Justin Iurman <justin.iurman@...ege.be>
CC: <netdev@...r.kernel.org>, <davem@...emloft.net>, <dsahern@...nel.org>,
	<edumazet@...gle.com>, <kuba@...nel.org>, <pabeni@...hat.com>,
	<horms@...nel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 1/3] net: ipv6: ioam6_iptunnel: mitigate
 2-realloc issue

From: Justin Iurman <justin.iurman@...ege.be>
Date: Fri, 25 Oct 2024 23:06:36 +0200

> On 10/25/24 17:12, Alexander Lobakin wrote:
>> From: Justin Iurman <justin.iurman@...ege.be>
>> Date: Fri, 25 Oct 2024 15:37:25 +0200
>>
>>> This patch mitigates the two-reallocations issue with ioam6_iptunnel by
>>> providing the dst_entry (in the cache) to the first call to
>>> skb_cow_head(). As a result, the very first iteration would still
>>> trigger two reallocations (i.e., empty cache), while next iterations
>>> would only trigger a single reallocation.
>>
>> [...]
>>
>>>   static int ioam6_do_inline(struct net *net, struct sk_buff *skb,
>>> -               struct ioam6_lwt_encap *tuninfo)
>>> +               struct ioam6_lwt_encap *tuninfo,
>>> +               struct dst_entry *dst)
>>>   {
>>>       struct ipv6hdr *oldhdr, *hdr;
>>>       int hdrlen, err;
>>>         hdrlen = (tuninfo->eh.hdrlen + 1) << 3;
>>>   -    err = skb_cow_head(skb, hdrlen + skb->mac_len);
>>> +    err = skb_cow_head(skb, hdrlen + (!dst ? skb->mac_len
>>> +                           : LL_RESERVED_SPACE(dst->dev)));
>>
>> You use this pattern a lot throughout the series. I believe you should
>> make a static inline or a macro from it.
>>
>> static inline u32 some_name(const *dst, const *skb)
>> {
>>     return dst ? LL_RESERVED_SPACE(dst->dev) : skb->mac_len;
>> }
>>
>> BTW why do you check for `!dst`, not `dst`? Does changing this affects
>> performance?
> 
> Not at all, you're right... even the opposite actually. Regarding the
> static inline suggestion, it could be a good idea and may even look like
> this as an optimization:
> 
> static inline u32 dev_overhead(struct dst_entry *dst, struct sk_buff *skb)
> {
>     if (likely(dst))
>         return LL_RESERVED_SPACE(dst->dev);
> 
>     return skb->mac_len;
> }

Oh, nice!

> 
> The question is... where should it go then? A static inline function per
> file (i.e., ioam6_iptunnel.c, seg6_iptunnel.c, and rpl_iptunnel.c)? In
> that case, it would still be repeated 3 times. Or in a header file
> somewhere, to have it defined only once? If so, what location do you
> think would be best?

100% should be in a header file. Can't suggest any since I don't usually
work with tunnels and ain't deep into its header structure.

Thanks,
Olek

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ