cred: Use KMEM_CACHE instead of kmem_cache_create

Message ID 20240130094037.76895-1-chentao@kylinos.cn
State New
Headers
Series cred: Use KMEM_CACHE instead of kmem_cache_create |

Commit Message

Kunwu Chan Jan. 30, 2024, 9:40 a.m. UTC
  commit 0a31bd5f2bbb ("KMEM_CACHE(): simplify slab cache creation")
introduces a new macro.
Use the new KMEM_CACHE() macro instead of direct kmem_cache_create
to simplify the creation of SLAB caches.

Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
---
 kernel/cred.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
  

Comments

Paul Moore Feb. 16, 2024, 3:54 a.m. UTC | #1
On Tue, Jan 30, 2024 at 4:40 AM Kunwu Chan <chentao@kylinos.cn> wrote:
>
> commit 0a31bd5f2bbb ("KMEM_CACHE(): simplify slab cache creation")
> introduces a new macro.
> Use the new KMEM_CACHE() macro instead of direct kmem_cache_create
> to simplify the creation of SLAB caches.
>
> Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
> ---
>  kernel/cred.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

This seems reasonable to me, unless I see any objections I can pull
this via the LSM tree next week.

> diff --git a/kernel/cred.c b/kernel/cred.c
> index c033a201c808..02a96e9d9cfd 100644
> --- a/kernel/cred.c
> +++ b/kernel/cred.c
> @@ -606,8 +606,8 @@ int set_cred_ucounts(struct cred *new)
>  void __init cred_init(void)
>  {
>         /* allocate a slab in which we can store credentials */
> -       cred_jar = kmem_cache_create("cred_jar", sizeof(struct cred), 0,
> -                       SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_ACCOUNT, NULL);
> +       cred_jar = KMEM_CACHE(cred,
> +                               SLAB_HWCACHE_ALIGN | SLAB_PANIC | SLAB_ACCOUNT);
>  }
>
>  /**
> --
> 2.39.2
  
Paul Moore Feb. 22, 2024, 12:10 a.m. UTC | #2
On Thu, Feb 15, 2024 at 10:54 PM Paul Moore <paul@paul-moore.com> wrote:
> On Tue, Jan 30, 2024 at 4:40 AM Kunwu Chan <chentao@kylinos.cn> wrote:
> >
> > commit 0a31bd5f2bbb ("KMEM_CACHE(): simplify slab cache creation")
> > introduces a new macro.
> > Use the new KMEM_CACHE() macro instead of direct kmem_cache_create
> > to simplify the creation of SLAB caches.
> >
> > Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
> > ---
> >  kernel/cred.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
>
> This seems reasonable to me, unless I see any objections I can pull
> this via the LSM tree next week.

Actually, never mind, the original posting has some non-ASCII junk in
the patch and I'm not able to import it cleanly.
  
Kunwu Chan Feb. 22, 2024, 3:04 a.m. UTC | #3
Thanks for your reply.
On 2024/2/22 08:10, Paul Moore wrote:
> On Thu, Feb 15, 2024 at 10:54 PM Paul Moore <paul@paul-moore.com> wrote:
>> On Tue, Jan 30, 2024 at 4:40 AM Kunwu Chan <chentao@kylinos.cn> wrote:
>>>
>>> commit 0a31bd5f2bbb ("KMEM_CACHE(): simplify slab cache creation")
>>> introduces a new macro.
>>> Use the new KMEM_CACHE() macro instead of direct kmem_cache_create
>>> to simplify the creation of SLAB caches.
>>>
>>> Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
>>> ---
>>>   kernel/cred.c | 4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> This seems reasonable to me, unless I see any objections I can pull
>> this via the LSM tree next week.
> 
> Actually, never mind, the original posting has some non-ASCII junk in
> the patch and I'm not able to import it cleanly.
Thanks for reply.

I checked the patch with the checkpatch.pl script and applied it to 
another machine to compile and found no issues.
Seems ok to me, what should I do next to clean up that non-ASCII junk.

And i use :perl -ne 'print if /[^[:ascii:]]/' 
0001-cred-Use-KMEM_CACHE-instead-of-kmem_cache_create.patch seems ok too.
>
  
Paul Moore Feb. 22, 2024, 5:48 p.m. UTC | #4
On Wed, Feb 21, 2024 at 10:06 PM Kunwu Chan <chentao@kylinos.cn> wrote:
> Thanks for your reply.
> On 2024/2/22 08:10, Paul Moore wrote:
> > On Thu, Feb 15, 2024 at 10:54 PM Paul Moore <paul@paul-moore.com> wrote:
> >> On Tue, Jan 30, 2024 at 4:40 AM Kunwu Chan <chentao@kylinos.cn> wrote:
> >>>
> >>> commit 0a31bd5f2bbb ("KMEM_CACHE(): simplify slab cache creation")
> >>> introduces a new macro.
> >>> Use the new KMEM_CACHE() macro instead of direct kmem_cache_create
> >>> to simplify the creation of SLAB caches.
> >>>
> >>> Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
> >>> ---
> >>>   kernel/cred.c | 4 ++--
> >>>   1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> This seems reasonable to me, unless I see any objections I can pull
> >> this via the LSM tree next week.
> >
> > Actually, never mind, the original posting has some non-ASCII junk in
> > the patch and I'm not able to import it cleanly.
> Thanks for reply.
>
> I checked the patch with the checkpatch.pl script and applied it to
> another machine to compile and found no issues.
> Seems ok to me, what should I do next to clean up that non-ASCII junk.
>
> And i use :perl -ne 'print if /[^[:ascii:]]/'
> 0001-cred-Use-KMEM_CACHE-instead-of-kmem_cache_create.patch seems ok too.

Look at the message when in the mailing list archive (link below) and
you'll notice the extra characters:
https://lore.kernel.org/all/20240130094037.76895-1-chentao@kylinos.cn/raw

.. and then look at a correctly submitted patch:
https://lore.kernel.org/all/20240126104403.1040692-1-omosnace@redhat.com/raw
  
Kunwu Chan Feb. 23, 2024, 2:49 a.m. UTC | #5
On 2024/2/23 01:48, Paul Moore wrote:
> On Wed, Feb 21, 2024 at 10:06 PM Kunwu Chan <chentao@kylinos.cn> wrote:
>> Thanks for your reply.
>> On 2024/2/22 08:10, Paul Moore wrote:
>>> On Thu, Feb 15, 2024 at 10:54 PM Paul Moore <paul@paul-moore.com> wrote:
>>>> On Tue, Jan 30, 2024 at 4:40 AM Kunwu Chan <chentao@kylinos.cn> wrote:
>>>>>
>>>>> commit 0a31bd5f2bbb ("KMEM_CACHE(): simplify slab cache creation")
>>>>> introduces a new macro.
>>>>> Use the new KMEM_CACHE() macro instead of direct kmem_cache_create
>>>>> to simplify the creation of SLAB caches.
>>>>>
>>>>> Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
>>>>> ---
>>>>>    kernel/cred.c | 4 ++--
>>>>>    1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> This seems reasonable to me, unless I see any objections I can pull
>>>> this via the LSM tree next week.
>>>
>>> Actually, never mind, the original posting has some non-ASCII junk in
>>> the patch and I'm not able to import it cleanly.
>> Thanks for reply.
>>
>> I checked the patch with the checkpatch.pl script and applied it to
>> another machine to compile and found no issues.
>> Seems ok to me, what should I do next to clean up that non-ASCII junk.
>>
>> And i use :perl -ne 'print if /[^[:ascii:]]/'
>> 0001-cred-Use-KMEM_CACHE-instead-of-kmem_cache_create.patch seems ok too.
> 
> Look at the message when in the mailing list archive (link below) and
> you'll notice the extra characters:
> https://lore.kernel.org/all/20240130094037.76895-1-chentao@kylinos.cn/raw
Thanks for your reply. I'll try to figure out what happened and resend a 
new one.
> 
> ... and then look at a correctly submitted patch:
> https://lore.kernel.org/all/20240126104403.1040692-1-omosnace@redhat.com/raw
>
  

Patch

diff --git a/kernel/cred.c b/kernel/cred.c
index c033a201c808..02a96e9d9cfd 100644
--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -606,8 +606,8 @@  int set_cred_ucounts(struct cred *new)
 void __init cred_init(void)
 {
 	/* allocate a slab in which we can store credentials */
-	cred_jar = kmem_cache_create("cred_jar", sizeof(struct cred), 0,
-			SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_ACCOUNT, NULL);
+	cred_jar = KMEM_CACHE(cred,
+				SLAB_HWCACHE_ALIGN | SLAB_PANIC | SLAB_ACCOUNT);
 }
 
 /**