linux-kernel - Re: [PATCH] nfs: use KMEM_CACHE() to create nfs_commit

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]

Date: Fri, 1 Mar 2024 10:06:17 +0800
From: Kunwu Chan <chentao@...inos.cn>
To: Trond Myklebust <trondmy@...merspace.com>,
 "anna@...nel.org" <anna@...nel.org>,
 "kunwu.chan@...ux.dev" <kunwu.chan@...ux.dev>
Cc: "linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] nfs: use KMEM_CACHE() to create nfs_commit_data cache

Thanks for the reply.

On 2024/2/29 21:40, Trond Myklebust wrote:
> On Thu, 2024-02-29 at 17:41 +0800, kunwu.chan@...ux.dev wrote:
>> From: Kunwu Chan <chentao@...inos.cn>
>>
>> Use the KMEM_CACHE() macro instead of kmem_cache_create() to simplify
>> the creation of SLAB caches when the default values are used.
>>
>> Signed-off-by: Kunwu Chan <chentao@...inos.cn>
>> ---
>>   fs/nfs/write.c | 5 +----
>>   1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/fs/nfs/write.c b/fs/nfs/write.c
>> index bb79d3a886ae..6a75772d447f 100644
>> --- a/fs/nfs/write.c
>> +++ b/fs/nfs/write.c
>> @@ -2148,10 +2148,7 @@ int __init nfs_init_writepagecache(void)
>>   	if (nfs_wdata_mempool == NULL)
>>   		goto out_destroy_write_cache;
>>   
>> -	nfs_cdata_cachep = kmem_cache_create("nfs_commit_data",
>> -					     sizeof(struct
>> nfs_commit_data),
>> -					     0, SLAB_HWCACHE_ALIGN,
>> -					     NULL);
>> +	nfs_cdata_cachep = KMEM_CACHE(nfs_commit_data,
>> SLAB_HWCACHE_ALIGN);
>>   	if (nfs_cdata_cachep == NULL)
>>   		goto out_destroy_write_mempool;
> 
> If this were being done as part of an actual functional code change,
> then I'd be OK with it, but otherwise it is just unnecessary churn that
> gets in the way of back porting any future fixes.
It's just my personal opinion, I meant to do some cleanup. It's not 
entirely necessary either, as everyone prefers a different style of 
code. It doesn't matter.
> 
> 
-- 
Thanks,
   Kunwu