Re: [PATCH] LANDLOCK: use kmem_cache for landlock_object
From: Paul Moore <paul@paul-moore.com>
Date: 2024-03-27 23:43:48
Also in:
linux-staging, lkml
On Wed, Mar 27, 2024 at 7:26 PM Ayush Tiwari [off-list ref] wrote:
Use kmem_cache replace kzalloc() calls with kmem_cache_zalloc() for struct landlock_object and update the related dependencies. Signed-off-by: Ayush Tiwari <redacted> --- security/landlock/fs.c | 2 +- security/landlock/object.c | 14 ++++++++++++-- security/landlock/object.h | 4 ++++ security/landlock/setup.c | 2 ++ 4 files changed, 19 insertions(+), 3 deletions(-)
Hi Ayush, Mickaël has the final say on Landlock patches, but I had a few comments that I've included below ...
quoted hunk ↗ jump to hunk
diff --git a/security/landlock/fs.c b/security/landlock/fs.c index fc520a06f9af..227dd67dd902 100644 --- a/security/landlock/fs.c +++ b/security/landlock/fs.c@@ -124,7 +124,7 @@ static struct landlock_object *get_inode_object(struct inode *const inode) if (unlikely(rcu_access_pointer(inode_sec->object))) { /* Someone else just created the object, bail out and retry. */ spin_unlock(&inode->i_lock); - kfree(new_object); + kmem_cache_free(landlock_object_cache, new_object);
See my comment below, but you may want to wrap this in a Landlock object API function.
quoted hunk ↗ jump to hunk
rcu_read_lock(); goto retry;diff --git a/security/landlock/object.c b/security/landlock/object.c index 1f50612f0185..df1354215617 100644 --- a/security/landlock/object.c +++ b/security/landlock/object.c@@ -17,6 +17,15 @@ #include "object.h" +struct kmem_cache *landlock_object_cache; + +void __init landlock_object_init(void) +{ + landlock_object_cache = kmem_cache_create( + "landlock_object_cache", sizeof(struct landlock_object), 0, + SLAB_PANIC, NULL);
The comments in include/linux/slab.h suggest using the KMEM_CACHE() macro, instead of kmem_cache_create(), as a best practice for creating slab caches.
quoted hunk ↗ jump to hunk
+} + struct landlock_object * landlock_create_object(const struct landlock_object_underops *const underops, void *const underobj)@@ -25,7 +34,8 @@ landlock_create_object(const struct landlock_object_underops *const underops, if (WARN_ON_ONCE(!underops || !underobj)) return ERR_PTR(-ENOENT); - new_object = kzalloc(sizeof(*new_object), GFP_KERNEL_ACCOUNT); + new_object = + kmem_cache_zalloc(landlock_object_cache, GFP_KERNEL_ACCOUNT);
If the line is too long, you might want to consider splitting the
function parameters like this:
new_object = kmem_cache_zalloc(landlock_object_cache,
GFP_KERNEL_ACCOUNT);
quoted hunk ↗ jump to hunk
if (!new_object) return ERR_PTR(-ENOMEM); refcount_set(&new_object->usage, 1);@@ -62,6 +72,6 @@ void landlock_put_object(struct landlock_object *const object) * @object->underobj to @object (if it still exists). */ object->underops->release(object); - kfree_rcu(object, rcu_free); + kmem_cache_free(landlock_object_cache, object); } }diff --git a/security/landlock/object.h b/security/landlock/object.h index 5f28c35e8aa8..8ba1af3ddc2e 100644 --- a/security/landlock/object.h +++ b/security/landlock/object.h@@ -13,6 +13,10 @@ #include <linux/refcount.h> #include <linux/spinlock.h> +extern struct kmem_cache *landlock_object_cache;
This really is a decision for Mickaël, but you may want to make @landlock_object_cache private to object.c and create functions to manage it as needed, e.g. put/free operations.
quoted hunk ↗ jump to hunk
+void __init landlock_object_init(void); + struct landlock_object; /**diff --git a/security/landlock/setup.c b/security/landlock/setup.c index f6dd33143b7f..a5fca4582ee1 100644
-- paul-moore.com