netdev - Re: [PATCH net-next] net: shrink napi_skb_cache

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAVpQUCsYsvZG76xvR9iCdd_4bjo0iLCRXPmHMidGOAJQc0Jhg@mail.gmail.com>
Date: Wed, 15 Oct 2025 17:14:21 -0700
From: Kuniyuki Iwashima <kuniyu@...gle.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: "David S . Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, 
	Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, netdev@...r.kernel.org, 
	eric.dumazet@...il.com, Alexander Lobakin <aleksander.lobakin@...el.com>
Subject: Re: [PATCH net-next] net: shrink napi_skb_cache_put()

On Wed, Oct 15, 2025 at 4:38 PM Eric Dumazet <edumazet@...gle.com> wrote:
>
> Following loop in napi_skb_cache_put() is unrolled by the compiler
> even if CONFIG_KASAN is not enabled:
>
> for (i = NAPI_SKB_CACHE_HALF; i < NAPI_SKB_CACHE_SIZE; i++)
>         kasan_mempool_unpoison_object(nc->skb_cache[i],
>                                 kmem_cache_size(net_hotdata.skbuff_cache));
>
> We have 32 times this sequence, for a total of 384 bytes.
>
>         48 8b 3d 00 00 00 00    net_hotdata.skbuff_cache,%rdi
>         e8 00 00 00 00          call   kmem_cache_size
>
> This is because kmem_cache_size() is an extern function,
> and kasan_unpoison_object_data() is an inline function.
>
> Cache kmem_cache_size() result in a temporary variable, and
> make the loop conditional to CONFIG_KASAN.
>
> After this patch, napi_skb_cache_put() is inlined in its callers.
>
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>

Reviewed-by: Kuniyuki Iwashima <kuniyu@...gle.com>

Oh exactly, it's interesting that the compiler cannot optimise out
unused retval even though kmem_cache_size() is a single load :o

$ grep KASAN .config
CONFIG_HAVE_ARCH_KASAN=y
CONFIG_HAVE_ARCH_KASAN_VMALLOC=y
CONFIG_CC_HAS_KASAN_GENERIC=y
CONFIG_CC_HAS_KASAN_SW_TAGS=y
# CONFIG_KASAN is not set

$ objdump --disassemble=napi_skb_cache_put vmlinux
...
ffffffff81e9fe10 <napi_skb_cache_put>:
...
ffffffff81e9fe40: 48 8b 3d 89 bd d6 00 mov    0xd6bd89(%rip),%rdi
  # ffffffff82c0bbd0 <net_hotdata+0x150>
ffffffff81e9fe47: e8 a4 79 60 ff       call   ffffffff814a77f0 <kmem_cache_size>
ffffffff81e9fe4c: 83 eb 01             sub    $0x1,%ebx
ffffffff81e9fe4f: 75 ef                jne    ffffffff81e9fe40
<napi_skb_cache_put+0x30>