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 <[email protected]>
---
kernel/cred.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
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
On Tue, Jan 30, 2024 at 4:40 AM Kunwu Chan <[email protected]> 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 <[email protected]>
> ---
> 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.com
On Thu, Feb 15, 2024 at 10:54 PM Paul Moore <[email protected]> wrote:
> On Tue, Jan 30, 2024 at 4:40 AM Kunwu Chan <[email protected]> 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 <[email protected]>
> > ---
> > 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.
--
paul-moore.com
Thanks for your reply.
On 2024/2/22 08:10, Paul Moore wrote:
> On Thu, Feb 15, 2024 at 10:54 PM Paul Moore <[email protected]> wrote:
>> On Tue, Jan 30, 2024 at 4:40 AM Kunwu Chan <[email protected]> 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 <[email protected]>
>>> ---
>>> 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.
>
--
Thanks,
Kunwu
On Wed, Feb 21, 2024 at 10:06 PM Kunwu Chan <[email protected]> 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 <[email protected]> wrote:
> >> On Tue, Jan 30, 2024 at 4:40 AM Kunwu Chan <[email protected]> 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 <[email protected]>
> >>> ---
> >>> 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/[email protected]/raw
.. and then look at a correctly submitted patch:
https://lore.kernel.org/all/[email protected]/raw
--
paul-moore.com
On 2024/2/23 01:48, Paul Moore wrote:
> On Wed, Feb 21, 2024 at 10:06 PM Kunwu Chan <[email protected]> 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 <[email protected]> wrote:
>>>> On Tue, Jan 30, 2024 at 4:40 AM Kunwu Chan <[email protected]> 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 <[email protected]>
>>>>> ---
>>>>> 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/[email protected]/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/[email protected]/raw
>
--
Thanks,
Kunwu