netdev - Re: [PATCH net-next v1] neighbour: Replace kvzalloc() with kzalloc() when GFP

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANn89i+ap-8BB_XKfcjMnXLR0ae+XV+6s_jacPLUd8rqSgyayA@mail.gmail.com>
Date: Mon, 17 Feb 2025 09:56:06 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Kuniyuki Iwashima <kuniyu@...zon.com>
Cc: enjuk@...zon.com, davem@...emloft.net, gnaaman@...venets.com, 
	horms@...nel.org, joel.granados@...nel.org, kohei.enju@...il.com, 
	kuba@...nel.org, linux-kernel@...r.kernel.org, lizetao1@...wei.com, 
	netdev@...r.kernel.org, pabeni@...hat.com
Subject: Re: [PATCH net-next v1] neighbour: Replace kvzalloc() with kzalloc()
 when GFP_ATOMIC is specified

On Sun, Feb 16, 2025 at 8:07 PM Kuniyuki Iwashima <kuniyu@...zon.com> wrote:
>
> From: Kohei Enju <enjuk@...zon.com>
> Date: Mon, 17 Feb 2025 01:30:16 +0900
> > Replace kvzalloc()/kvfree() with kzalloc()/kfree() when GFP_ATOMIC is
> > specified, since kvzalloc() doesn't support non-sleeping allocations such
> > as GFP_ATOMIC.
> >
> > With incompatible gfp flags, kvzalloc() never falls back to the vmalloc
> > path and returns immediately after the kmalloc path fails.
> > Therefore, using kzalloc() is sufficient in this case.
> >
> > Fixes: 41b3caa7c076 ("neighbour: Add hlist_node to struct neighbour")
>
> This commit followed the old hash_buckets allocation, so I'd add
>
>   Fixes: ab101c553bc1 ("neighbour: use kvzalloc()/kvfree()")
>
> too.
>
> Both commits were introduced in v6.13, so there's no difference in terms
> of backporting though.
>
> Also, it would be nice to CC mm maintainers in case they have some
> comments.

Oh well, we need to trigger neigh_hash_grow() from a process context,
or convert net/core/neighbour.c to modern rhashtable.