linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Przemek Kitszel <przemyslaw.kitszel@intel.com>
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org, vbabka@suse.cz,
	torvalds@linux-foundation.org, peterz@infradead.org
Cc: andriy.shevchenko@linux.intel.com,
	intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
	Przemek Kitszel <przemyslaw.kitszel@intel.com>
Subject: [RFC] slab: introduce auto_kfree macro
Date: Tue,  1 Apr 2025 15:44:08 +0200	[thread overview]
Message-ID: <20250401134408.37312-1-przemyslaw.kitszel@intel.com> (raw)

Add auto_kfree macro that acts as a higher level wrapper for manual
__free(kfree) invocation, and sets the pointer to NULL - to have both
well defined behavior also for the case code would lack other assignement.

Consider the following code:
int my_foo(int arg)
{
	struct my_dev_foo *foo __free(kfree); /* no assignement */

	foo = kzalloc(sizeof(*foo), GFP_KERNEL);
	/* ... */
}

So far it is fine and even optimal in terms of not assigning when
not needed. But it is typical to don't touch (and sadly to don't
think about) code that is not related to the change, so let's consider
an extension to the above, namely an "early return" style to check
arg prior to allocation:
int my_foo(int arg)
{
        struct my_dev_foo *foo __free(kfree); /* no assignement */
+
+	if (!arg)
+		return -EINVAL;
        foo = kzalloc(sizeof(*foo), GFP_KERNEL);
        /* ... */
}
Now we have uninitialized foo passed to kfree, what likely will crash.
One could argue that `= NULL` should be added to this patch, but it is
easy to forgot, especially when the foo declaration is outside of the
default git context.

With new auto_kfree, we simply will start with
	struct my_dev_foo *foo auto_kfree;
and be safe against future extensions.

I believe this will open up way for broader adoption of Scope Based
Resource Management, say in networking.
I also believe that my proposed name is special enough that it will
be easy to know/spot that the assignement is hidden.

Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
---
 include/linux/slab.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/slab.h b/include/linux/slab.h
index 98e07e9e9e58..b943be0ce626 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -471,6 +471,7 @@ void kfree_sensitive(const void *objp);
 size_t __ksize(const void *objp);
 
 DEFINE_FREE(kfree, void *, if (!IS_ERR_OR_NULL(_T)) kfree(_T))
+#define auto_kfree __free(kfree) = NULL
 DEFINE_FREE(kfree_sensitive, void *, if (_T) kfree_sensitive(_T))
 
 /**
-- 
2.39.3



             reply	other threads:[~2025-04-01 13:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-01 13:44 Przemek Kitszel [this message]
2025-04-02 10:32 ` Andy Shevchenko
2025-04-02 10:40   ` Andy Shevchenko
2025-04-02 12:19   ` Peter Zijlstra
2025-04-02 12:22     ` Peter Zijlstra
2025-04-02 12:57       ` Andy Shevchenko
2025-04-04  3:05     ` Herbert Xu
2025-04-02 12:21   ` Peter Zijlstra
2025-04-02 12:55     ` Andy Shevchenko
2025-04-02 10:44 ` Vlastimil Babka
2025-04-03 16:59   ` Kees Cook
2025-04-03 17:35     ` Matthew Wilcox
2025-04-03 17:46       ` Andy Shevchenko
2025-04-03 18:15 ` Linus Torvalds

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=20250401134408.37312-1-przemyslaw.kitszel@intel.com \
    --to=przemyslaw.kitszel@intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@suse.cz \
    /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