| Message ID | 20250219102227.72488-1-enjuk@amazon.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | ef75d8343bc14c5911574c07d18681d98e08ce20 |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net-next,v2] neighbour: Replace kvzalloc() with kzalloc() when GFP_ATOMIC is specified | expand |
On 2/19/25 11:22, Kohei Enju wrote: > kzalloc() uses page allocator when size is larger than > KMALLOC_MAX_CACHE_SIZE, so the intention of commit ab101c553bc1 > ("neighbour: use kvzalloc()/kvfree()") can be achieved by using kzalloc(). > > When using GFP_ATOMIC, kvzalloc() only tries the kmalloc path, > since the vmalloc path does not support the flag. > In this case, kvzalloc() is equivalent to kzalloc() in that neither try > the vmalloc path, so this replacement brings no functional change. > This is primarily a cleanup change, as the original code functions > correctly. > > This patch replaces kvzalloc() introduced by commit 41b3caa7c076 > ("neighbour: Add hlist_node to struct neighbour"), which is called in > the same context and with the same gfp flag as the aforementioned commit > ab101c553bc1 ("neighbour: use kvzalloc()/kvfree()"). > > Signed-off-by: Kohei Enju <enjuk@amazon.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> > --- > Notes: > One of the SLAB maintainers (Vlastimil Babka) looked at v1 patch and > double-checked kzalloc() is clearer in this context: > https://lore.kernel.org/netdev/b4a2bf18-c1ec-4ccd-bed9-671a2fd543a9@suse.cz/ > > Changes: > v1: https://lore.kernel.org/netdev/20250216163016.57444-1-enjuk@amazon.com/ > v1->v2: > - Change commit message > - Remove the Fixes tag since there is no real bug now > --- > net/core/neighbour.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/net/core/neighbour.c b/net/core/neighbour.c > index d8dd686b5287..344c9cd168ec 100644 > --- a/net/core/neighbour.c > +++ b/net/core/neighbour.c > @@ -518,7 +518,7 @@ static struct neigh_hash_table *neigh_hash_alloc(unsigned int shift) > if (!ret) > return NULL; > > - hash_heads = kvzalloc(size, GFP_ATOMIC); > + hash_heads = kzalloc(size, GFP_ATOMIC); > if (!hash_heads) { > kfree(ret); > return NULL; > @@ -536,7 +536,7 @@ static void neigh_hash_free_rcu(struct rcu_head *head) > struct neigh_hash_table, > rcu); > > - kvfree(nht->hash_heads); > + kfree(nht->hash_heads); > kfree(nht); > } >
…
> This patch replaces …
Thus replace?
See also:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.14-rc3#n94
Regards,
Markus
Hello: This patch was applied to netdev/net-next.git (main) by Jakub Kicinski <kuba@kernel.org>: On Wed, 19 Feb 2025 19:22:27 +0900 you wrote: > kzalloc() uses page allocator when size is larger than > KMALLOC_MAX_CACHE_SIZE, so the intention of commit ab101c553bc1 > ("neighbour: use kvzalloc()/kvfree()") can be achieved by using kzalloc(). > > When using GFP_ATOMIC, kvzalloc() only tries the kmalloc path, > since the vmalloc path does not support the flag. > In this case, kvzalloc() is equivalent to kzalloc() in that neither try > the vmalloc path, so this replacement brings no functional change. > This is primarily a cleanup change, as the original code functions > correctly. > > [...] Here is the summary with links: - [net-next,v2] neighbour: Replace kvzalloc() with kzalloc() when GFP_ATOMIC is specified https://git.kernel.org/netdev/net-next/c/ef75d8343bc1 You are awesome, thank you!
diff --git a/net/core/neighbour.c b/net/core/neighbour.c index d8dd686b5287..344c9cd168ec 100644 --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -518,7 +518,7 @@ static struct neigh_hash_table *neigh_hash_alloc(unsigned int shift) if (!ret) return NULL; - hash_heads = kvzalloc(size, GFP_ATOMIC); + hash_heads = kzalloc(size, GFP_ATOMIC); if (!hash_heads) { kfree(ret); return NULL; @@ -536,7 +536,7 @@ static void neigh_hash_free_rcu(struct rcu_head *head) struct neigh_hash_table, rcu); - kvfree(nht->hash_heads); + kfree(nht->hash_heads); kfree(nht); }
kzalloc() uses page allocator when size is larger than KMALLOC_MAX_CACHE_SIZE, so the intention of commit ab101c553bc1 ("neighbour: use kvzalloc()/kvfree()") can be achieved by using kzalloc(). When using GFP_ATOMIC, kvzalloc() only tries the kmalloc path, since the vmalloc path does not support the flag. In this case, kvzalloc() is equivalent to kzalloc() in that neither try the vmalloc path, so this replacement brings no functional change. This is primarily a cleanup change, as the original code functions correctly. This patch replaces kvzalloc() introduced by commit 41b3caa7c076 ("neighbour: Add hlist_node to struct neighbour"), which is called in the same context and with the same gfp flag as the aforementioned commit ab101c553bc1 ("neighbour: use kvzalloc()/kvfree()"). Signed-off-by: Kohei Enju <enjuk@amazon.com> --- Notes: One of the SLAB maintainers (Vlastimil Babka) looked at v1 patch and double-checked kzalloc() is clearer in this context: https://lore.kernel.org/netdev/b4a2bf18-c1ec-4ccd-bed9-671a2fd543a9@suse.cz/ Changes: v1: https://lore.kernel.org/netdev/20250216163016.57444-1-enjuk@amazon.com/ v1->v2: - Change commit message - Remove the Fixes tag since there is no real bug now --- net/core/neighbour.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)