Received-SPF: pass (google.com: domain of linux-kernel+bounces-126094-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Sun, 31 Mar 2024 21:12:06 +0530
From: Ayush Tiwari <ayushtiw0110@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: alison.schofield@intel.com, paul@paul-moore.com, mic@digikod.net,
	fabio.maria.de.francesco@linux.intel.com,
	linux-kernel@vger.kernel.org, outreachy@lists.linux.dev,
	linux-security-module@vger.kernel.org
Subject: Re: [PATCH v2] landlock: Use kmem for landlock_object
Message-ID: <ZgmETqQr7+W9XtWN@ayush-HP-Pavilion-Gaming-Laptop-15-ec0xxx>
References: <ZggZi/EFICvb4xTU@ayush-HP-Pavilion-Gaming-Laptop-15-ec0xxx>
 <2024033030-tutu-dynamite-47c9@gregkh>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2024033030-tutu-dynamite-47c9@gregkh>

Hello Greg. Thanks for the feedback.
On Sat, Mar 30, 2024 at 05:12:18PM +0100, Greg KH wrote:
> On Sat, Mar 30, 2024 at 07:24:19PM +0530, Ayush Tiwari wrote:
> > Use kmem_cache replace kzalloc() calls with kmem_cache_zalloc() for
> > struct landlock_object and update the related dependencies to improve
> > memory allocation and deallocation performance.
> 
> So it's faster?  Great, what are the measurements?
> 
Thank you for the feedback. Regarding the performance improvements, I
realized I should have provided concrete measurements to support the
claim. The intention behind switching to kmem_cache_zalloc() was to
optimize memory management efficiency based on general principles.
Could you suggest some way to get some measurements if possible?
> > This patch does not
> > change kfree() and kfree_rcu() calls because according to kernel commit
> > ae65a5211d90("mm/slab: document kfree() as allowed for
> > kmem_cache_alloc() objects"), starting from kernel 6.4 with
> > CONFIG_SLOB, kfree() is safe to use for such objects.
> 
> There is no CONFIG_SLOB anymore so why mention it?
> 
About the mention of CONFIG_SLOB and commit ae65a5211d90, my aim was
to highlight the kernel's documentation of using kfree() for objects
allocated with kmem_cache_alloc(), ensuring this practice's safety
across kernel versions post-6.4. I acknowledge that referencing
CONFIG_SLOB was misleading due to its removal from the kernel
configuration options. The focus should be on the broader acceptance
and documentation of kfree() usage with kmem_cache allocated objects,
independent of the specific allocator configuration. I will revise the
patch description to clarify this point and remove any irrelevant
references to CONFIG_SLOB.
> 
> 
>   
> > +static struct kmem_cache *landlock_object_cache;
> > +
> > +void __init landlock_object_cache_init(void)
> > +{
> > +	landlock_object_cache = kmem_cache_create(
> > +		"landlock_object_cache", sizeof(struct landlock_object), 0,
> > +		SLAB_PANIC, NULL);
> 
> You really want SLAB_PANIC?  Why?
>
The SLAB_PANIC flag used in kmem_cache_create indicates that if the
kernel is unable to create the cache, it should panic. The use of
SLAB_PANIC in the creation of the landlock_object_cache is due to the
critical nature of this cache for the Landlock LSM's operation. I
found it to be a good choice to be used. Should I use some other
altrnative?
> > +
> >  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);
> 
> Odd indentation, why?
> 
This indentation is due to formatting introduced by running
clang-format.
> thanks,
> 
> greg k-h