[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f3849725-b7b3-4edc-8220-aabeb79b8151@web.de>
Date: Sat, 23 Mar 2024 19:01:03 +0100
From: Markus Elfring <Markus.Elfring@....de>
To: Dan Williams <dan.j.williams@...el.com>,
Peter Zijlstra <peterz@...radead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
kernel-janitors@...r.kernel.org
Cc: Bjorn Helgaas <bhelgaas@...gle.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
Ira Weiny <ira.weiny@...el.com>,
Jesse Brandeburg <jesse.brandeburg@...el.com>,
Jonathan Cameron <Jonathan.Cameron@...wei.com>,
Julia Lawall <Julia.Lawall@...ia.fr>, Kevin Tian <kevin.tian@...el.com>,
Lukas Wunner <lukas.wunner@...el.com>
Subject: RE: [PATCH] cleanup: Add usage and style documentation
> DEFINE_FREE(remove_free, struct object *, if (_T) remove_free(_T))
> static int init(void)
> {
> struct object *obj __free(remove_free) = NULL;
> int err;
>
> guard(mutex)(lock);
> obj = alloc_add();
>
> if (!obj)
> return -ENOMEM;
>
> err = other_init(obj);
> if (err)
> return err; // remove_free() called without the lock!!
>
> no_free_ptr(obj);
> return 0;
> }
You demonstrated an improvable lock granularity and a questionable combination
of variable scopes.
> The fix for this bug is to replace the "__free(...) = NULL" pattern and
> move the assignment to the declaration.
>
> guard(mutex)(lock);
> struct object *obj __free(remove_free) = alloc_add();
How do you think about to describe such a source code transformation
as a conversion of a variable assignment to a variable definition
at the place of a resource allocation?
Would you like to increase the collaboration with the macros “DEFINE_CLASS” and “CLASS”?
https://elixir.bootlin.com/linux/v6.8.1/source/include/linux/cleanup.h#L82
Regards,
Markus
Powered by blists - more mailing lists