Linux kernel staging patches
 help / color / mirror / Atom feed
From: Ayush Tiwari <ayushtiw0110@gmail.com>
To: "Mickaël Salaün" <mic@digikod.net>
Cc: paul@paul-moore.com, alison.schofield@intel.com,
	fabio.maria.de.francesco@linux.intel.com,
	linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org,
	gregkh@linuxfoundation.org, outreachy@lists.linux.dev,
	linux-security-module@vger.kernel.org
Subject: Re: [PATCH] LANDLOCK: use kmem_cache for landlock_object
Date: Fri, 29 Mar 2024 12:02:16 +0530	[thread overview]
Message-ID: <ZgZgcPxkG1TEVnt6@ayush-HP-Pavilion-Gaming-Laptop-15-ec0xxx> (raw)
In-Reply-To: <20240328.aiPh0phaJ6ai@digikod.net>

On Thu, Mar 28, 2024 at 03:45:12PM +0100, Mickaël Salaün wrote:
> The subject should start with "landlock: Use" instead of "LANDLOCK: use"
> 
> On Thu, Mar 28, 2024 at 01:23:17PM +0530, Ayush Tiwari wrote:
> > Hello Paul
> > Thanks a lot for the feedback. Apologies for the mistakes. Could you
> > help me in some places so that I can correct the errors, like:
> > On Wed, Mar 27, 2024 at 07:43:36PM -0400, Paul Moore wrote:
> > > On Wed, Mar 27, 2024 at 7:26 PM Ayush Tiwari <ayushtiw0110@gmail.com> 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 <ayushtiw0110@gmail.com>
> > > > ---
> > > >  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 ...
> > > 
> > > > 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.
> > Sure. I will definitely implement this.
> > > 
> > > >                 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,
> 
> No need for the "_cache" name suffix.
> 
> > > > +               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.
> > > 

Hello mentors
I was trying to work on the above suggestion and I am facing some problem
regarding replacing kzalloc with kmem_cache_zalloc calls when using KMEM
macro from include/linux/slab.h because for kmem_cache_zalloc I will be
needing a cache pointer, but KMEM macro doesn't return any such pointer.
So is there any way to do this using macro or do i have to avoid using
that macro for this case and use all methods regarding kmem as defined in
the linux memory management API doc?

> Agree with Paul and Greg unless commented otherwise. Thanks

  parent reply	other threads:[~2024-03-29  6:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-27 23:25 [PATCH] LANDLOCK: use kmem_cache for landlock_object Ayush Tiwari
2024-03-27 23:43 ` Paul Moore
2024-03-28  7:53   ` Ayush Tiwari
2024-03-28 14:45     ` Mickaël Salaün
2024-03-29  2:19       ` Ayush Tiwari
2024-03-29  6:32       ` Ayush Tiwari [this message]
2024-03-28  6:08 ` Greg KH
2024-03-28  7:57   ` Ayush Tiwari
2024-03-28  6:39 ` Dan Carpenter
2024-03-29  2:14   ` Ayush Tiwari

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZgZgcPxkG1TEVnt6@ayush-HP-Pavilion-Gaming-Laptop-15-ec0xxx \
    --to=ayushtiw0110@gmail.com \
    --cc=alison.schofield@intel.com \
    --cc=fabio.maria.de.francesco@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=mic@digikod.net \
    --cc=outreachy@lists.linux.dev \
    --cc=paul@paul-moore.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).