On Thu, 2022-02-24 at 18:17 +0200, Amir Goldstein wrote:
> The nfsd file cache table can be pretty large and its allocation
> may require as many as 80 contigious pages.
>
> Employ the same fix that was employed for similar issue that was
> reported for the reply cache hash table allocation several years ago
> by commit 8f97514b423a ("nfsd: more robust allocation failure handling
> in nfsd_reply_cache_init").
>
> Fixes: 65294c1f2c5e ("nfsd: add a new struct file caching facility to nfsd")
> Link: https://lore.kernel.org/linux-nfs/e3cdaeec85a6cfec980e87fc294327c0381c1778.camel@xxxxxxxxxx/
> Suggested-by: Jeff Layton <jlayton@xxxxxxxxxx>
> Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
> ---
>
> Since v1:
> - Use kvcalloc()
> - Use kvfree()
>
> fs/nfsd/filecache.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/fs/nfsd/filecache.c b/fs/nfsd/filecache.c
> index 8bc807c5fea4..cc2831cec669 100644
> --- a/fs/nfsd/filecache.c
> +++ b/fs/nfsd/filecache.c
> @@ -632,7 +632,7 @@ nfsd_file_cache_init(void)
> if (!nfsd_filecache_wq)
> goto out;
>
> - nfsd_file_hashtbl = kcalloc(NFSD_FILE_HASH_SIZE,
> + nfsd_file_hashtbl = kvcalloc(NFSD_FILE_HASH_SIZE,
> sizeof(*nfsd_file_hashtbl), GFP_KERNEL);
> if (!nfsd_file_hashtbl) {
> pr_err("nfsd: unable to allocate nfsd_file_hashtbl\n");
> @@ -700,7 +700,7 @@ nfsd_file_cache_init(void)
> nfsd_file_slab = NULL;
> kmem_cache_destroy(nfsd_file_mark_slab);
> nfsd_file_mark_slab = NULL;
> - kfree(nfsd_file_hashtbl);
> + kvfree(nfsd_file_hashtbl);
> nfsd_file_hashtbl = NULL;
> destroy_workqueue(nfsd_filecache_wq);
> nfsd_filecache_wq = NULL;
> @@ -811,7 +811,7 @@ nfsd_file_cache_shutdown(void)
> fsnotify_wait_marks_destroyed();
> kmem_cache_destroy(nfsd_file_mark_slab);
> nfsd_file_mark_slab = NULL;
> - kfree(nfsd_file_hashtbl);
> + kvfree(nfsd_file_hashtbl);
> nfsd_file_hashtbl = NULL;
> destroy_workqueue(nfsd_filecache_wq);
> nfsd_filecache_wq = NULL;
Reviewed-by: Jeff Layton <jlayton@xxxxxxxxxx>
