Message ID | 20250317092945.764490535@linutronix.de (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | genirq/msi: Spring cleaning | expand |
On Mon, 2025-03-17 at 14:29 +0100, Thomas Gleixner wrote: [...] > +/* > + * Only for situations where an allocation is handed in to another > function > + * and consumed by that function on success. > + * > + * struct foo *f __free(kfree) = kzalloc(sizeof(*f), > GFP_KERNEL); > + * > + * setup(f); > + * if (some_condition) > + * return -EINVAL; > + * .... > + * ret = bar(f); > + * if (!ret) > + * retain_ptr(f); > + * return ret; > + */ > +#define retain_ptr(p) \ > + __get_and_null(p, NULL) This doesn't score very highly on the Rusty API design scale because it can be used anywhere return_ptr() should be used. To force the distinction between the two cases at the compiler level, should there be a cast to void in the above to prevent using the return value? Regards, James
--- a/include/linux/cleanup.h +++ b/include/linux/cleanup.h @@ -216,6 +216,23 @@ const volatile void * __must_check_fn(co #define return_ptr(p) return no_free_ptr(p) +/* + * Only for situations where an allocation is handed in to another function + * and consumed by that function on success. + * + * struct foo *f __free(kfree) = kzalloc(sizeof(*f), GFP_KERNEL); + * + * setup(f); + * if (some_condition) + * return -EINVAL; + * .... + * ret = bar(f); + * if (!ret) + * retain_ptr(f); + * return ret; + */ +#define retain_ptr(p) \ + __get_and_null(p, NULL) /* * DEFINE_CLASS(name, type, exit, init, init_args...):