Received-SPF: pass (google.com: domain of linux-kernel+bounces-67991-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20240130094037.76895-1-chentao@kylinos.cn>
In-Reply-To: <20240130094037.76895-1-chentao@kylinos.cn>
From: Paul Moore <paul@paul-moore.com>
Date: Thu, 15 Feb 2024 22:54:49 -0500
Message-ID: <CAHC9VhQG6XAm3R3wtgFrb0b0UHoxkSV2yziVAnUy2x7Ovun_pQ@mail.gmail.com>
Subject: Re: [PATCH] cred: Use KMEM_CACHE instead of kmem_cache_create
To: Kunwu Chan <chentao@kylinos.cn>
Cc: axboe@kernel.dk, elena.reshetova@intel.com, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 30, 2024 at 4:40=E2=80=AFAM Kunwu Chan <chentao@kylinos.cn> wro=
te:
>
> 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 =3D kmem_cache_create("cred_jar", sizeof(struct cred), 0=
,
> -                       SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_ACCOUNT, NULL)=
;
> +       cred_jar =3D KMEM_CACHE(cred,
> +                               SLAB_HWCACHE_ALIGN | SLAB_PANIC | SLAB_AC=
COUNT);
>  }
>
>  /**
> --
> 2.39.2

--=20
paul-moore.com