From: Vlastimil Babka <vbabka@suse.cz>
To: Przemek Kitszel <przemyslaw.kitszel@intel.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
torvalds@linux-foundation.org, peterz@infradead.org,
Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>
Cc: andriy.shevchenko@linux.intel.com,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
Harry Yoo <harry.yoo@oracle.com>,
Matthew Wilcox <willy@infradead.org>,
Christoph Lameter <cl@gentwo.org>
Subject: Re: [RFC] slab: introduce auto_kfree macro
Date: Wed, 2 Apr 2025 12:44:50 +0200 [thread overview]
Message-ID: <3f387b13-5482-46ed-9f52-4a9ed7001e67@suse.cz> (raw)
In-Reply-To: <20250401134408.37312-1-przemyslaw.kitszel@intel.com>
Cc Kees and others from his related efforts:
https://lore.kernel.org/all/20250321202620.work.175-kees@kernel.org/
On 4/1/25 15:44, Przemek Kitszel wrote:
> 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))
>
> /**
next prev parent reply other threads:[~2025-04-02 10:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-01 13:44 Przemek Kitszel
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 [this message]
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=3f387b13-5482-46ed-9f52-4a9ed7001e67@suse.cz \
--to=vbabka@suse.cz \
--cc=andriy.shevchenko@linux.intel.com \
--cc=cl@gentwo.org \
--cc=harry.yoo@oracle.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jannh@google.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=netdev@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=przemyslaw.kitszel@intel.com \
--cc=torvalds@linux-foundation.org \
--cc=willy@infradead.org \
/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