[PATCH v3 0/2] Add scope-based cleanup capability to eventfd_ctx

[PATCH v3 0/2] Add scope-based cleanup capability to eventfd_ctx

[Bence Csokas]

Add __free() support to eventfd and update drm_syncobj to use it as an
example consumer.

A minor discrepancy I encountered is whether to put a semicolon after
DEFINE_FREE(). It seems some in-tree code does, some doesn't. In the end,
I followed the example set in core-api/cleanup.rst, and omitted it.

Signed-off-by: Bence Csokas <bence.csokas@arm.com>
---
Changes in v3:
- IS_ERR_OR_NULL() moved into DEFINE_FREE() body
- Link to v2: https://patch.msgid.link/20260915-efd-autofree-v2-0-06d2c9d1547f@arm.com

Changes in v2:
- IS_ERR_OR_NULL() check, instead of NULLing out pointer on IS_ERR
- Link to v1: https://patch.msgid.link/20260909-efd-autofree-v1-0-c6c3c19cc702@arm.com

To: Alexander Viro <viro@zeniv.linux.org.uk>
To: Christian Brauner <brauner@kernel.org>
To: Jan Kara <jack@suse.cz>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: Maxime Ripard <mripard@kernel.org>
To: Thomas Zimmermann <tzimmermann@suse.de>
To: David Airlie <airlied@gmail.com>
To: Simona Vetter <simona@ffwll.ch>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org

---
Bence Csokas (2):
      eventfd: Add scope-based cleanup capability
      drm/syncobj: Use scope-based cleanup for eventfd_ctx

 drivers/gpu/drm/drm_syncobj.c | 8 +++-----
 include/linux/eventfd.h       | 3 +++
 2 files changed, 6 insertions(+), 5 deletions(-)
---
base-commit: d135ab453a7400a34930bdda1ef4bdc8acfac80e
change-id: 20260826-efd-autofree-766608e8d8aa

Best regards,
--  
Bence Csokas <bence.csokas@arm.com>

[PATCH v3 1/2] eventfd: Add scope-based cleanup capability

[Bence Csokas]

Allow eventfd_ctx_put() to be used with the RAII-inspired __free() API.

Signed-off-by: Bence Csokas <bence.csokas@arm.com>
---
 include/linux/eventfd.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/eventfd.h b/include/linux/eventfd.h
index e32bee4345fb..48c40f8c4dfd 100644
--- a/include/linux/eventfd.h
+++ b/include/linux/eventfd.h
@@ -10,6 +10,7 @@
 #define _LINUX_EVENTFD_H
 
 #include <linux/wait.h>
+#include <linux/cleanup.h>
 #include <linux/err.h>
 #include <linux/percpu-defs.h>
 #include <linux/percpu.h>
@@ -89,5 +90,7 @@ static inline void eventfd_signal(struct eventfd_ctx *ctx)
 	eventfd_signal_mask(ctx, 0);
 }
 
+DEFINE_FREE(eventfd, struct eventfd_ctx *, if (!IS_ERR_OR_NULL(_T)) eventfd_ctx_put(_T))
+
 #endif /* _LINUX_EVENTFD_H */
 

-- 
2.56.0

[PATCH v3 2/2] drm/syncobj: Use scope-based cleanup for eventfd_ctx

[Bence Csokas]

Now that eventfd supports __free(), use it in drm_syncobj_eventfd_ioctl().

Signed-off-by: Bence Csokas <bence.csokas@arm.com>
---
 drivers/gpu/drm/drm_syncobj.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index f1d4da168545..40bedd30b2fc 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1429,9 +1429,9 @@ int
 drm_syncobj_eventfd_ioctl(struct drm_device *dev, void *data,
 			  struct drm_file *file_private)
 {
+	struct eventfd_ctx *ev_fd_ctx __free(eventfd) = NULL;
 	struct drm_syncobj_eventfd *args = data;
 	struct drm_syncobj *syncobj;
-	struct eventfd_ctx *ev_fd_ctx;
 	struct syncobj_eventfd_entry *entry;
 	int ret;
 
@@ -1457,10 +1457,10 @@ drm_syncobj_eventfd_ioctl(struct drm_device *dev, void *data,
 	entry = kzalloc_obj(*entry);
 	if (!entry) {
 		ret = -ENOMEM;
-		goto err_kzalloc;
+		goto err_fdget;
 	}
 	entry->syncobj = syncobj;
-	entry->ev_fd_ctx = ev_fd_ctx;
+	entry->ev_fd_ctx = no_free_ptr(ev_fd_ctx);
 	entry->point = args->point;
 	entry->flags = args->flags;
 
@@ -1469,8 +1469,6 @@ drm_syncobj_eventfd_ioctl(struct drm_device *dev, void *data,
 
 	return 0;
 
-err_kzalloc:
-	eventfd_ctx_put(ev_fd_ctx);
 err_fdget:
 	drm_syncobj_put(syncobj);
 	return ret;

-- 
2.56.0

Re: [PATCH v3 0/2] Add scope-based cleanup capability to eventfd_ctx

[Christian Brauner]

On Tue, Oct 27, 2026 at 05:22:00PM +0100, Bence Csokas wrote:
> Add __free() support to eventfd and update drm_syncobj to use it as an
> example consumer.
> 
> A minor discrepancy I encountered is whether to put a semicolon after
> DEFINE_FREE(). It seems some in-tree code does, some doesn't. In the end,
> I followed the example set in core-api/cleanup.rst, and omitted it.
> 
> Signed-off-by: Bence Csokas <bence.csokas@arm.com>
> ---

I'm really having trouble seeing how this improves anything
significantly. Probably others have the same impression which is why
this doesn't get a lot of review.

Re: [PATCH v3 0/2] Add scope-based cleanup capability to eventfd_ctx

[Bence Csókás]

Hi,

On 2026. 11. 06. 10:05, Christian Brauner wrote:
> On Tue, Oct 27, 2026 at 05:22:00PM +0100, Bence Csokas wrote:
>> Add __free() support to eventfd and update drm_syncobj to use it as an
>> example consumer.
>>
>> A minor discrepancy I encountered is whether to put a semicolon after
>> DEFINE_FREE(). It seems some in-tree code does, some doesn't. In the end,
>> I followed the example set in core-api/cleanup.rst, and omitted it.
>>
>> Signed-off-by: Bence Csokas <bence.csokas@arm.com>
>> ---
> 
> I'm really having trouble seeing how this improves anything
> significantly. Probably others have the same impression which is why
> this doesn't get a lot of review.

The goal of the __free() API is to reduce the number of goto-based error 
paths. Normally, you'd have to keep the state of every local in your 
head for every early return. (Has it been initialized? Has it been 
consumed? Or does it need to be freed?) Then you need to arrange your 
"goto tree" (error labels) in a way that frees everything, and then for 
every early exit, jump to the correct one. This can be quite complex for 
some functions. Look at KVM or HyperV eventfd code, for example.

By contrast, you just mark the local var with _free() and an appropriate 
destructor snippet, and the consumption point (the point after which we 
don't need to free it on a return) with no_free_ptr(), and the compiler 
instruments every early return accordingly.

Bence

Re: [PATCH v3 0/2] Add scope-based cleanup capability to eventfd_ctx

[Jan Kara]

Hi!

On Fri 06-11-26 10:31:58, Bence Csókás wrote:
> On 2026. 11. 06. 10:05, Christian Brauner wrote:
> > On Tue, Oct 27, 2026 at 05:22:00PM +0100, Bence Csokas wrote:
> > > Add __free() support to eventfd and update drm_syncobj to use it as an
> > > example consumer.
> > > 
> > > A minor discrepancy I encountered is whether to put a semicolon after
> > > DEFINE_FREE(). It seems some in-tree code does, some doesn't. In the end,
> > > I followed the example set in core-api/cleanup.rst, and omitted it.
> > > 
> > > Signed-off-by: Bence Csokas <bence.csokas@arm.com>
> > > ---
> > 
> > I'm really having trouble seeing how this improves anything
> > significantly. Probably others have the same impression which is why
> > this doesn't get a lot of review.
> 
> The goal of the __free() API is to reduce the number of goto-based error
> paths. Normally, you'd have to keep the state of every local in your head
> for every early return. (Has it been initialized? Has it been consumed? Or
> does it need to be freed?) Then you need to arrange your "goto tree" (error
> labels) in a way that frees everything, and then for every early exit, jump
> to the correct one. This can be quite complex for some functions. Look at
> KVM or HyperV eventfd code, for example.
> 
> By contrast, you just mark the local var with _free() and an appropriate
> destructor snippet, and the consumption point (the point after which we
> don't need to free it on a return) with no_free_ptr(), and the compiler
> instruments every early return accordingly.

Sure, but there's also the other side about which you don't speak: unless
the destructor is trivial (like kfree()), there are implications about
locking, when resources (such as references held by the object) get
released etc. So it can also be more complex to wrap your head around
__free usage than around standard cleanup code.

So unless __free is providing a noticeable simplification of some goto
hell, cleanup in many functions or similar, I generally don't find it worth
it...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR