[v2,RESEND] crypto: lib/mpi - Extend support for scope-based resource management

Commit Message

Markus Elfring Oct. 5, 2024, 6:27 a.m. UTC

From: Markus Elfring <[e-mail]>
Date: Wed, 18 Sep 2024 11:06:35 +0200

Scope-based resource management became supported for some
programming interfaces by contributions of Peter Zijlstra on 2023-05-26.
See also the commit 54da6a0924311c7cf5015533991e44fb8eb12773 ("locking:
Introduce __cleanup() based infrastructure").

Thus add a macro call so that the attribute “__free(mpi_free)” can be
applied accordingly.

Signed-off-by: Markus Elfring <[e-mail]>
---

V2:
The kernel build service pointed out that the proposed identifier “T_”
was not recognised by the compiler.
Thus reserved identifiers need still be applied also at such a place instead
so far.
I became curious under which circumstances corresponding development concerns
will be reconsidered any more.


 include/linux/mpi.h | 4 ++++
 1 file changed, 4 insertions(+)

--
2.46.0

Comments

Herbert Xu Oct. 10, 2024, 8:40 a.m. UTC | #1

On Sat, Oct 05, 2024 at 08:27:03AM +0200, Markus Elfring wrote:
> From: Markus Elfring <[e-mail]>
> Date: Wed, 18 Sep 2024 11:06:35 +0200
> 
> Scope-based resource management became supported for some
> programming interfaces by contributions of Peter Zijlstra on 2023-05-26.
> See also the commit 54da6a0924311c7cf5015533991e44fb8eb12773 ("locking:
> Introduce __cleanup() based infrastructure").
> 
> Thus add a macro call so that the attribute “__free(mpi_free)” can be
> applied accordingly.

So where are the users of this?

Thanks,

Markus Elfring Oct. 10, 2024, 8:58 a.m. UTC | #2

>> Scope-based resource management became supported for some
>> programming interfaces by contributions of Peter Zijlstra on 2023-05-26.
>> See also the commit 54da6a0924311c7cf5015533991e44fb8eb12773 ("locking:
>> Introduce __cleanup() based infrastructure").
>>
>> Thus add a macro call so that the attribute “__free(mpi_free)” can be
>> applied accordingly.
>
> So where are the users of this?
Do you find the proposed software extension generally reasonable?

Can any more source code places benefit from such a programming interface adjustment?
https://elixir.bootlin.com/linux/v6.12-rc2/A/ident/mpi_free

Regards,
Markus

Herbert Xu Oct. 10, 2024, 9 a.m. UTC | #3

On Thu, Oct 10, 2024 at 10:58:26AM +0200, Markus Elfring wrote:
>
> Do you find the proposed software extension generally reasonable?
> 
> Can any more source code places benefit from such a programming interface adjustment?
> https://elixir.bootlin.com/linux/v6.12-rc2/A/ident/mpi_free

Please submit actual patches using this.

Thanks,

Markus Elfring Oct. 10, 2024, 9:10 a.m. UTC | #4

>> Do you find the proposed software extension generally reasonable?
>>
>> Can any more source code places benefit from such a programming interface adjustment?
>> https://elixir.bootlin.com/linux/v6.12-rc2/A/ident/mpi_free
>
> Please submit actual patches using this.
I would appreciate more positive indications according to scope-based resource management
extensions before.
I hope that change resistance/acceptance can be clarified already.

Would there be a need to make the activation of discussed special macro calls
depend on other constraints?

Regards,
Markus

Patch

diff --git a/include/linux/mpi.h b/include/linux/mpi.h
index 47be46f36435..6fbcb88ce296 100644
--- a/include/linux/mpi.h
+++ b/include/linux/mpi.h
@@ -19,6 +19,8 @@ 

 #include <linux/types.h>
 #include <linux/scatterlist.h>
+#include <linux/cleanup.h>
+#include <linux/err.h>

 #define BYTES_PER_MPI_LIMB	(BITS_PER_LONG / 8)
 #define BITS_PER_MPI_LIMB	BITS_PER_LONG
@@ -44,6 +46,8 @@  typedef struct gcry_mpi *MPI;
 /*-- mpiutil.c --*/
 MPI mpi_alloc(unsigned nlimbs);
 void mpi_free(MPI a);
+DEFINE_FREE(mpi_free, MPI, if (!IS_ERR_OR_NULL(_T)) mpi_free(_T))
+
 int mpi_resize(MPI a, unsigned nlimbs);

 MPI mpi_copy(MPI a);