2012-09-03 09:14:36 +00:00
|
|
|
/*
|
|
|
|
* shctx.c - shared context management functions for SSL
|
|
|
|
*
|
|
|
|
* Copyright (C) 2011-2012 EXCELIANCE
|
|
|
|
*
|
|
|
|
* Author: Emeric Brun - emeric@exceliance.fr
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version
|
|
|
|
* 2 of the License, or (at your option) any later version.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <sys/mman.h>
|
2012-11-28 17:47:52 +00:00
|
|
|
#include <arpa/inet.h>
|
2014-05-28 14:47:01 +00:00
|
|
|
#include <ebmbtree.h>
|
2017-10-09 12:17:39 +00:00
|
|
|
#include <types/global.h>
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
#include <common/mini-clist.h>
|
|
|
|
#include "proto/shctx.h"
|
2017-10-30 18:36:36 +00:00
|
|
|
|
2017-10-09 12:17:39 +00:00
|
|
|
#if !defined (USE_PRIVATE_CACHE)
|
2012-09-03 09:14:36 +00:00
|
|
|
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
int use_shared_mem = 0;
|
2012-09-03 09:14:36 +00:00
|
|
|
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
#endif
|
2012-09-03 09:14:36 +00:00
|
|
|
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
/*
|
|
|
|
* Reserve a row, put it in the hotlist, set the refcount to 1
|
|
|
|
*
|
|
|
|
* Reserve blocks in the avail list and put them in the hot list
|
|
|
|
* Return the first block put in the hot list or NULL if not enough blocks available
|
|
|
|
*/
|
|
|
|
struct shared_block *shctx_row_reserve_hot(struct shared_context *shctx, int data_len)
|
2012-11-28 17:47:52 +00:00
|
|
|
{
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
struct shared_block *block, *sblock, *ret = NULL, *first;
|
|
|
|
int enough = 0;
|
|
|
|
int freed = 0;
|
|
|
|
|
|
|
|
/* not enough usable blocks */
|
|
|
|
if (data_len > shctx->nbav * shctx->block_size)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
while (!enough && !LIST_ISEMPTY(&shctx->avail)) {
|
|
|
|
int count = 0;
|
|
|
|
int first_count = 0, first_len = 0;
|
|
|
|
|
|
|
|
first = block = LIST_NEXT(&shctx->avail, struct shared_block *, list);
|
|
|
|
if (ret == NULL)
|
|
|
|
ret = first;
|
|
|
|
|
|
|
|
first_count = first->block_count;
|
|
|
|
first_len = first->len;
|
|
|
|
/*
|
|
|
|
Should never been set to 0.
|
|
|
|
if (first->block_count == 0)
|
|
|
|
first->block_count = 1;
|
|
|
|
*/
|
|
|
|
|
|
|
|
list_for_each_entry_safe_from(block, sblock, &shctx->avail, list) {
|
|
|
|
|
|
|
|
/* release callback */
|
|
|
|
if (first_len && shctx->free_block)
|
|
|
|
shctx->free_block(first, block);
|
|
|
|
|
|
|
|
block->block_count = 1;
|
|
|
|
block->len = 0;
|
|
|
|
|
|
|
|
freed++;
|
|
|
|
data_len -= shctx->block_size;
|
|
|
|
|
|
|
|
if (data_len > 0)
|
|
|
|
shctx_block_set_hot(shctx, block);
|
|
|
|
|
|
|
|
if (data_len <= 0 && !enough) {
|
|
|
|
shctx_block_set_hot(shctx, block);
|
|
|
|
ret->block_count = freed;
|
|
|
|
ret->refcount = 1;
|
|
|
|
enough = 1;
|
|
|
|
}
|
2012-09-03 09:14:36 +00:00
|
|
|
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
count++;
|
|
|
|
if (count >= first_count)
|
|
|
|
break;
|
2012-11-28 17:47:52 +00:00
|
|
|
}
|
|
|
|
}
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
|
|
|
|
out:
|
2012-11-28 17:47:52 +00:00
|
|
|
return ret;
|
|
|
|
}
|
2012-09-03 09:14:36 +00:00
|
|
|
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
/*
|
|
|
|
* if the refcount is 0 move the row to the hot list. Increment the refcount
|
2012-11-28 17:47:52 +00:00
|
|
|
*/
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
void shctx_row_inc_hot(struct shared_context *shctx, struct shared_block *first)
|
2012-11-28 17:47:52 +00:00
|
|
|
{
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
struct shared_block *block, *sblock;
|
|
|
|
int count = 0;
|
|
|
|
|
|
|
|
if (first->refcount <= 0) {
|
|
|
|
|
|
|
|
block = first;
|
|
|
|
|
|
|
|
list_for_each_entry_safe_from(block, sblock, &shctx->avail, list) {
|
|
|
|
|
|
|
|
shctx_block_set_hot(shctx, block);
|
|
|
|
|
|
|
|
count++;
|
|
|
|
if (count >= first->block_count)
|
|
|
|
break;
|
2012-11-28 17:47:52 +00:00
|
|
|
}
|
|
|
|
}
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
|
|
|
|
first->refcount++;
|
2012-11-28 17:47:52 +00:00
|
|
|
}
|
2012-09-03 09:14:36 +00:00
|
|
|
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
/*
|
|
|
|
* decrement the refcount and move the row at the end of the avail list if it reaches 0.
|
2012-11-28 17:47:52 +00:00
|
|
|
*/
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
void shctx_row_dec_hot(struct shared_context *shctx, struct shared_block *first)
|
2012-09-03 09:14:36 +00:00
|
|
|
{
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
struct shared_block *block, *sblock;
|
|
|
|
int count = 0;
|
2012-11-28 17:47:52 +00:00
|
|
|
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
first->refcount--;
|
2012-09-03 09:14:36 +00:00
|
|
|
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
if (first->refcount <= 0) {
|
2012-09-03 09:14:36 +00:00
|
|
|
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
block = first;
|
2012-09-03 09:14:36 +00:00
|
|
|
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
list_for_each_entry_safe_from(block, sblock, &shctx->hot, list) {
|
|
|
|
|
|
|
|
shctx_block_set_avail(shctx, block);
|
|
|
|
|
|
|
|
count++;
|
|
|
|
if (count >= first->block_count)
|
2012-11-28 17:47:52 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2012-09-03 09:14:36 +00:00
|
|
|
|
2012-11-28 17:47:52 +00:00
|
|
|
}
|
2012-09-03 09:14:36 +00:00
|
|
|
|
|
|
|
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
/*
|
|
|
|
* Append data in the row if there is enough space.
|
|
|
|
* The row should be in the hot list
|
|
|
|
*
|
|
|
|
* Return the amount of appended data if ret >= 0
|
|
|
|
* or how much more space it needs to contains the data if < 0.
|
|
|
|
*/
|
|
|
|
int shctx_row_data_append(struct shared_context *shctx, struct shared_block *first, unsigned char *data, int len)
|
|
|
|
{
|
|
|
|
int remain, start;
|
|
|
|
int count = 0;
|
|
|
|
struct shared_block *block;
|
|
|
|
|
|
|
|
|
|
|
|
/* return -<len> needed to work */
|
|
|
|
if (len > first->block_count * shctx->block_size - first->len)
|
|
|
|
return (first->block_count * shctx->block_size - first->len) - len;
|
|
|
|
|
|
|
|
/* skipping full buffers, stop at the first buffer with remaining space */
|
|
|
|
block = first;
|
|
|
|
list_for_each_entry_from(block, &shctx->hot, list) {
|
|
|
|
count++;
|
|
|
|
|
|
|
|
|
|
|
|
/* break if there is not enough blocks */
|
|
|
|
if (count > first->block_count)
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* end of copy */
|
|
|
|
if (len <= 0)
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* skip full buffers */
|
|
|
|
if (count * shctx->block_size <= first->len)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* remaining space in the current block which is not full */
|
|
|
|
remain = (shctx->block_size * count - first->len) % shctx->block_size;
|
|
|
|
/* if remain == 0, previous buffer are full, or first->len == 0 */
|
|
|
|
remain = remain ? remain : shctx->block_size;
|
|
|
|
|
|
|
|
/* start must be calculated before remain is modified */
|
|
|
|
start = shctx->block_size - remain;
|
|
|
|
|
|
|
|
/* must not try to copy more than len */
|
|
|
|
remain = MIN(remain, len);
|
|
|
|
|
|
|
|
memcpy(block->data + start, data, remain);
|
|
|
|
data += remain;
|
|
|
|
len -= remain;
|
|
|
|
first->len += remain; /* update len in the head of the row */
|
|
|
|
}
|
|
|
|
|
|
|
|
return len;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Copy <len> data from a row of blocks, return the remaining data to copy
|
|
|
|
* If 0 is returned, the full data has successfuly be copied
|
|
|
|
*
|
|
|
|
* The row should be in the hot list
|
|
|
|
*/
|
|
|
|
int shctx_row_data_get(struct shared_context *shctx, struct shared_block *first,
|
|
|
|
unsigned char *dst, int offset, int len)
|
|
|
|
{
|
|
|
|
int count = 0, size = 0, start = -1;
|
|
|
|
struct shared_block *block;
|
|
|
|
|
2017-10-31 19:21:46 +00:00
|
|
|
/* can't copy more */
|
|
|
|
if (len > first->len)
|
|
|
|
len = first->len;
|
|
|
|
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
block = first;
|
|
|
|
count = 0;
|
|
|
|
/* Pass through the blocks to copy them */
|
|
|
|
list_for_each_entry_from(block, &shctx->hot, list) {
|
|
|
|
if (count >= first->block_count || len <= 0)
|
|
|
|
break;
|
|
|
|
|
|
|
|
count++;
|
|
|
|
/* continue until we are in right block
|
|
|
|
corresponding to the offset */
|
|
|
|
if (count < offset / shctx->block_size + 1)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* on the first block, data won't possibly began at offset 0 */
|
|
|
|
if (start == -1)
|
|
|
|
start = offset - (count - 1) * shctx->block_size;
|
|
|
|
|
|
|
|
/* size can be lower than a block when copying the last block */
|
|
|
|
size = MIN(shctx->block_size - start, len);
|
|
|
|
|
|
|
|
memcpy(dst, block->data + start, size);
|
|
|
|
dst += size;
|
|
|
|
len -= size;
|
|
|
|
start = 0;
|
|
|
|
}
|
|
|
|
return len;
|
|
|
|
}
|
2012-09-03 09:14:36 +00:00
|
|
|
|
|
|
|
/* Allocate shared memory context.
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
* <maxblocks> is maximum blocks.
|
|
|
|
* If <maxblocks> is set to less or equal to 0, ssl cache is disabled.
|
|
|
|
* Returns: -1 on alloc failure, <maxblocks> if it performs context alloc,
|
2012-11-28 17:47:52 +00:00
|
|
|
* and 0 if cache is already allocated.
|
|
|
|
*/
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
int shctx_init(struct shared_context **orig_shctx, int maxblocks, int blocksize, int extra, int shared)
|
2012-09-03 09:14:36 +00:00
|
|
|
{
|
|
|
|
int i;
|
2017-10-09 14:30:50 +00:00
|
|
|
struct shared_context *shctx;
|
|
|
|
int ret;
|
2012-09-25 09:11:16 +00:00
|
|
|
#ifndef USE_PRIVATE_CACHE
|
2014-05-07 21:11:42 +00:00
|
|
|
#ifdef USE_PTHREAD_PSHARED
|
2012-09-03 09:14:36 +00:00
|
|
|
pthread_mutexattr_t attr;
|
2014-05-07 21:11:42 +00:00
|
|
|
#endif
|
2012-09-25 09:11:16 +00:00
|
|
|
#endif
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
void *cur;
|
2012-09-24 13:48:52 +00:00
|
|
|
int maptype = MAP_PRIVATE;
|
2012-09-03 09:14:36 +00:00
|
|
|
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
if (maxblocks <= 0)
|
2012-09-03 09:14:36 +00:00
|
|
|
return 0;
|
|
|
|
|
2012-09-25 09:11:16 +00:00
|
|
|
#ifndef USE_PRIVATE_CACHE
|
2012-09-24 13:48:52 +00:00
|
|
|
if (shared)
|
|
|
|
maptype = MAP_SHARED;
|
2012-09-25 09:11:16 +00:00
|
|
|
#endif
|
2012-09-24 13:48:52 +00:00
|
|
|
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
shctx = (struct shared_context *)mmap(NULL, sizeof(struct shared_context) + extra + (maxblocks * (sizeof(struct shared_block) + blocksize)),
|
2012-09-24 13:48:52 +00:00
|
|
|
PROT_READ | PROT_WRITE, maptype | MAP_ANON, -1, 0);
|
2012-09-03 09:14:36 +00:00
|
|
|
if (!shctx || shctx == MAP_FAILED) {
|
|
|
|
shctx = NULL;
|
2017-10-09 14:30:50 +00:00
|
|
|
ret = SHCTX_E_ALLOC_CACHE;
|
|
|
|
goto err;
|
2012-09-03 09:14:36 +00:00
|
|
|
}
|
|
|
|
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
shctx->nbav = 0;
|
|
|
|
|
2012-09-25 09:11:16 +00:00
|
|
|
#ifndef USE_PRIVATE_CACHE
|
2014-05-07 14:10:18 +00:00
|
|
|
if (maptype == MAP_SHARED) {
|
2014-05-07 21:11:42 +00:00
|
|
|
#ifdef USE_PTHREAD_PSHARED
|
2014-05-07 14:10:18 +00:00
|
|
|
if (pthread_mutexattr_init(&attr)) {
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
munmap(shctx, sizeof(struct shared_context) + extra + (maxblocks * (sizeof(struct shared_block) + blocksize)));
|
2014-05-07 14:10:18 +00:00
|
|
|
shctx = NULL;
|
2017-10-09 14:30:50 +00:00
|
|
|
ret = SHCTX_E_INIT_LOCK;
|
|
|
|
goto err;
|
2014-05-07 14:10:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_SHARED)) {
|
|
|
|
pthread_mutexattr_destroy(&attr);
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
munmap(shctx, sizeof(struct shared_context) + extra + (maxblocks * (sizeof(struct shared_block) + blocksize)));
|
2014-05-07 14:10:18 +00:00
|
|
|
shctx = NULL;
|
2017-10-09 14:30:50 +00:00
|
|
|
ret = SHCTX_E_INIT_LOCK;
|
|
|
|
goto err;
|
2014-05-07 14:10:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (pthread_mutex_init(&shctx->mutex, &attr)) {
|
|
|
|
pthread_mutexattr_destroy(&attr);
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
munmap(shctx, sizeof(struct shared_context) + extra + (maxblocks * (sizeof(struct shared_block) + blocksize)));
|
2014-05-07 14:10:18 +00:00
|
|
|
shctx = NULL;
|
2017-10-09 14:30:50 +00:00
|
|
|
ret = SHCTX_E_INIT_LOCK;
|
|
|
|
goto err;
|
2014-05-07 14:10:18 +00:00
|
|
|
}
|
2014-05-07 21:11:42 +00:00
|
|
|
#else
|
|
|
|
shctx->waiters = 0;
|
2012-09-03 09:14:36 +00:00
|
|
|
#endif
|
2012-09-24 13:48:52 +00:00
|
|
|
use_shared_mem = 1;
|
2014-05-07 14:10:18 +00:00
|
|
|
}
|
2012-09-25 09:11:16 +00:00
|
|
|
#endif
|
2012-09-24 13:48:52 +00:00
|
|
|
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
LIST_INIT(&shctx->avail);
|
|
|
|
LIST_INIT(&shctx->hot);
|
|
|
|
|
|
|
|
shctx->block_size = blocksize;
|
|
|
|
|
|
|
|
/* init the free blocks after the shared context struct */
|
|
|
|
cur = (void *)shctx + sizeof(struct shared_context) + extra;
|
|
|
|
for (i = 0; i < maxblocks; i++) {
|
|
|
|
struct shared_block *cur_block = (struct shared_block *)cur;
|
|
|
|
cur_block->len = 0;
|
|
|
|
cur_block->refcount = 0;
|
|
|
|
cur_block->block_count = 1;
|
|
|
|
LIST_ADDQ(&shctx->avail, &cur_block->list);
|
|
|
|
shctx->nbav++;
|
|
|
|
cur += sizeof(struct shared_block) + blocksize;
|
2012-09-03 09:14:36 +00:00
|
|
|
}
|
MEDIUM: shctx: separate ssl and shctx
This patch reorganize the shctx API in a generic storage API, separating
the shared SSL session handling from its core.
The shctx API only handles the generic data part, it does not know what
kind of data you use with it.
A shared_context is a storage structure allocated in a shared memory,
allowing its usage in a multithread or a multiprocess context.
The structure use 2 linked list, one containing the available blocks,
and another for the hot locked blocks. At initialization the available
list is filled with <maxblocks> blocks of size <blocksize>. An <extra>
space is initialized outside the list in case you need some specific
storage.
+-----------------------+--------+--------+--------+--------+----
| struct shared_context | extra | block1 | block2 | block3 | ...
+-----------------------+--------+--------+--------+--------+----
<-------- maxblocks --------->
* blocksize
The API allows to store content on several linked blocks. For example,
if you allocated blocks of 16 bytes, and you want to store an object of
60 bytes, the object will be allocated in a row of 4 blocks.
The API was made for LRU usage, each time you get an object, it pushes
the object at the end of the list. When it needs more space, it discards
The functions name have been renamed in a more logical way, the part
regarding shctx have been prefixed by shctx_ and the functions for the
shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 19:08:51 +00:00
|
|
|
ret = maxblocks;
|
2017-10-09 14:30:50 +00:00
|
|
|
|
|
|
|
err:
|
|
|
|
*orig_shctx = shctx;
|
|
|
|
return ret;
|
2012-09-03 09:14:36 +00:00
|
|
|
}
|
|
|
|
|