[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <170905252721.2268463.6714121678946763402.stgit@dwillia2-xfh.jf.intel.com>
Date: Tue, 27 Feb 2024 08:48:47 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: torvalds@...ux-foundation.org, peterz@...radead.org,
gregkh@...uxfoundation.org
Cc: Ira Weiny <ira.weiny@...el.com>, Dave Jiang <dave.jiang@...el.com>,
Jonathan Cameron <Jonathan.Cameron@...wei.com>,
"Fabio M. De Francesco" <fabio.maria.de.francesco@...ux.intel.com>,
linux-kernel@...r.kernel.org, linux-cxl@...r.kernel.org
Subject: [PATCH 0/2] cleanup: A couple extensions for conditional resource
management
Hi Peter, Linus, Greg,
The cond_guard() patch has gone through several rounds of review and is
looking good to me, but is missing feedback from one of you that have
been grappling with a cross-kernel view of what these new facilities
should look like.
Separately I have been running into trouble trying to fit no_free_ptr()
into some cleanup patches and thought of another way to build on the
conditional syntax originated in scoped_cond_guard().
More specifically, scoped_cond_guard() introduced the concept of passing
a statement to the macro to handle the failure case. cond_guard()
extends that to be used within an existing scope to automatically
release a conditionally acquired lock rather than defining a new scope.
The cond_no_free_ptr() helper takes that concept for ending the cleanup
scope for objects when responsibility for freeing them has been
transferred to a 3rd object or subsystem.
---
Dan Williams (1):
cleanup: Introduce cond_no_free_ptr()
Fabio M. De Francesco (1):
cleanup: Add cond_guard() to conditional guards
include/linux/cleanup.h | 42 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
base-commit: 54be6c6c5ae8e0d93a6c4641cb7528eb0b6ba478
Powered by blists - more mailing lists