Message ID | 20240130094037.76895-1-chentao@kylinos.cn |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-44283-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2087:b0:106:209c:c626 with SMTP id gs7csp1107670dyb; Tue, 30 Jan 2024 01:55:38 -0800 (PST) X-Google-Smtp-Source: AGHT+IEd6eejUwCM0TSnw5TO63LUHdHwnT2tDG1QJcnianNVY/j6XeqbZkAetV9hccl956WyXvFE X-Received: by 2002:a05:6808:1442:b0:3be:2f6e:5a93 with SMTP id x2-20020a056808144200b003be2f6e5a93mr5793056oiv.14.1706608538161; Tue, 30 Jan 2024 01:55:38 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706608538; cv=pass; d=google.com; s=arc-20160816; b=vgoMZx3ApyJD0HSKMOo7EOPMbGvxdIqceiC2xu1gPEgoQZgVV2LMRLjqT1eGYV4CMr mMRMVEVbNK3w858iFAXBlbtjiJQ96pbJB5zSon5XbNZU8uEAessCENR8UHLCKzUMks14 nMTSLMTmnx4vo8tQYOSHQrA9e0L2+pB96J3Ya9gygopCH77VpTuS/5xVMbu42fNtpgl/ PxevT8KysIa2Rd94+K5MMPnBzQeNFXRqZ008gJtOSF9kTztoaUeNXrG+uBZJ709WvQ0Y 2yy5OzRwvAKZ8qTcTabwV3v6eWE8z92+OghSnaJ1jaR482VTMaE4rlOWxq//rvOYRuWM tSEQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from; bh=+eU+01yLCCmooM5WtL5VuPJ2aBFOzWQkWAYxHrd7uSA=; fh=kHpibI+zl+zquEML9CSJvcQABWCQqUm0qhxAit9pDVw=; b=NjY2azA9tIxPRXV9vt+S2mIqzTi3aENp7iY7Vnlet8AZltLlDSEllYuXoi6taXE6Av /2zxOtZ/e2L2bCnniCsgHiiAa1ptBM/s7Lri2xo9hxcLKUUy6flmYgYk9sK6ex2LvCAX cyt3gSCQAM6fdGOSM3jxOIbHHmHZS64ukOANifeglXM1nASVnXdJk/9Ag37MtCnFpnCy 3ftki2JhMsON7sKGH8vGnQxAHA/HEjCd3Da6YbOgk1mJEZaRZY357GR2KxRFn0D319xk YjW8URmJuqOboSJUjU0aUJqQcY06tAjE5l8MZgGu0EaotHbf9gqsrQ+vEd9fkL4Xbieh 52tQ== ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=kylinos.cn); spf=pass (google.com: domain of linux-kernel+bounces-44283-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-44283-ouuuleilei=gmail.com@vger.kernel.org" Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id fa18-20020a056a002d1200b006dbb024d06bsi7338358pfb.43.2024.01.30.01.55.38 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jan 2024 01:55:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-44283-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=kylinos.cn); spf=pass (google.com: domain of linux-kernel+bounces-44283-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-44283-ouuuleilei=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 333B7293CAE for <ouuuleilei@gmail.com>; Tue, 30 Jan 2024 09:42:34 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E083160B8F; Tue, 30 Jan 2024 09:40:57 +0000 (UTC) Received: from mailgw.kylinos.cn (mailgw.kylinos.cn [124.126.103.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DDF1756448 for <linux-kernel@vger.kernel.org>; Tue, 30 Jan 2024 09:40:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=124.126.103.232 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706607656; cv=none; b=jMMBP6kaw+bmQwrx4VgJDybvS/0eOI6z/u/a3EzJmwCWWBGZwnzH4TV/qe2q7opOUV0SKPw8U0r0GBYVQ5ODVc30bpMO6rolybxBRT+Nb/6liaA9Hr/hXZBK4vXbcc6+CbFojYvk5CLx9tOwNS4/YNcH8ROdvUPgg6mgPxWgbsM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706607656; c=relaxed/simple; bh=ufH/YfkovaUPjRe2Wr0p28Xr1kor2t9YuM7pYvf8SEg=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=VxkCWo5pYJMG7MVchYiFIAAHqMAixhsR/XPa30N266DxCwKEjTVK2e3wUi//yfm2ZzDlg/uEym8pPCuzgo3xXBfaIvmfCqvQovAUKDOX3gkryO5XIVdXHxbzB5xheKLmQAnqRBr7Bc/BmUZ5dLTElZbWz0FH9C0vUg8xyUb0w/8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kylinos.cn; spf=pass smtp.mailfrom=kylinos.cn; arc=none smtp.client-ip=124.126.103.232 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kylinos.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kylinos.cn X-UUID: d9510a6461524e2b8a80b966313b8d64-20240130 X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.35,REQID:91328706-21cf-49b7-9778-703d31fd7df0,IP:20, URL:0,TC:0,Content:0,EDM:0,RT:0,SF:-15,FILE:0,BULK:0,RULE:Release_Ham,ACTI ON:release,TS:5 X-CID-INFO: VERSION:1.1.35,REQID:91328706-21cf-49b7-9778-703d31fd7df0,IP:20,UR L:0,TC:0,Content:0,EDM:0,RT:0,SF:-15,FILE:0,BULK:0,RULE:Release_Ham,ACTION :release,TS:5 X-CID-META: VersionHash:5d391d7,CLOUDID:551e6a83-8d4f-477b-89d2-1e3bdbef96d1,B ulkID:2401301740489IUEEHSU,BulkQuantity:0,Recheck:0,SF:66|38|24|17|19|44|1 02,TC:nil,Content:0,EDM:-3,IP:-2,URL:0,File:nil,Bulk:nil,QS:nil,BEC:nil,CO L:0,OSI:0,OSA:0,AV:0,LES:1,SPR:NO,DKR:0,DKP:0,BRR:0,BRE:0 X-CID-BVR: 0,NGT X-CID-BAS: 0,NGT,0,_ X-CID-FACTOR: TF_CID_SPAM_SNR,TF_CID_SPAM_FAS,TF_CID_SPAM_FSD,TF_CID_SPAM_FSI X-UUID: d9510a6461524e2b8a80b966313b8d64-20240130 Received: from mail.kylinos.cn [(39.156.73.10)] by mailgw (envelope-from <chentao@kylinos.cn>) (Generic MTA) with ESMTP id 1433395071; Tue, 30 Jan 2024 17:40:46 +0800 Received: from mail.kylinos.cn (localhost [127.0.0.1]) by mail.kylinos.cn (NSMail) with SMTP id 522A9E000EB9; Tue, 30 Jan 2024 17:40:46 +0800 (CST) X-ns-mid: postfix-65B8C41E-1119281145 Received: from kernel.. (unknown [172.20.15.213]) by mail.kylinos.cn (NSMail) with ESMTPA id 3DBF6E000EB9; Tue, 30 Jan 2024 17:40:44 +0800 (CST) From: Kunwu Chan <chentao@kylinos.cn> To: axboe@kernel.dk, paul@paul-moore.com, elena.reshetova@intel.com Cc: linux-kernel@vger.kernel.org, Kunwu Chan <chentao@kylinos.cn> Subject: [PATCH] cred: Use KMEM_CACHE instead of kmem_cache_create Date: Tue, 30 Jan 2024 17:40:37 +0800 Message-Id: <20240130094037.76895-1-chentao@kylinos.cn> X-Mailer: git-send-email 2.39.2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789508754468365387 X-GMAIL-MSGID: 1789508754468365387 |
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
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
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 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. >
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
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 >
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); } /**