[gnutls-devel] GnuTLS | gnutls_rnd manage memory per-thread (!1647)

[Read-only notification of GnuTLS library development activities]

Daiki Ueno commented on a discussion on lib/random.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1647#note_1115177278

>  
>  /* Per thread context of random generator, and a flag to indicate initialization */
> -static _Thread_local void *gnutls_rnd_ctx;
> -static _Thread_local unsigned rnd_initialized = 0;
> +gl_tls_key_t ctx_key;
> +_Thread_local unsigned rnd_initialized = 0;
>  
> -struct rnd_ctx_list_st {
> -	void *ctx;
> -	struct rnd_ctx_list_st *next;
> -};
> -
> -/* A global list of all allocated contexts - to be
> - * used during deinitialization. */
> -GNUTLS_STATIC_MUTEX(gnutls_rnd_ctx_list_mutex);
> -static struct rnd_ctx_list_st *head = NULL;

An alternative approach would be to make list entry object (`struct rnd_ctx_list_st *head`) thread-local instead of the actual context (`void *ctx`). In the TLS destructor, you could release `head->ctx` and set it to NULL. Then in the global destructor, you could traverse the list and release the elements, something like:

```c
struct rnd_ctx_list_st {
	void *ctx;
	struct rnd_ctx_list_st *next;
};
static struct rnd_ctx_list_st *head = NULL;
...
static void *
rnd_ctx_list_destructor(void *p)
{
  struct rnd_ctx_list_st *e = p;
  free_ctx(e->ctx);
  e->ctx = NULL;
  return NULL;
}
...
static inline int
_gnutls_rnd_init(void)
{
  ...
  glthread_tls_key_init(&ctx_key, rnd_ctx_list_destructor);
  glthread_tls_set(&ctx_key, ctx);
  ...
}
...
void
_gnutls_rnd_deinit(void)
{
  struct rnd_ctx_list_st *e = head;
  while (e) {
    struct rnd_ctx_list_st *next = e->next;
    free_ctx(e->ctx);
    gnutls_free(e);
    e = next;
  }
  head = NULL;
}
```
One drawback with this approach is that if destructor is not called on some platforms, list entries will remain unreleased, though it's only until `_gnutls_rnd_deinit` is called.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1647#note_1115177278
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20220926/82c5d87c/attachment-0001.html>