Am Donnerstag, 21. Mai 2015, 05:44:08 schrieb Herbert Xu:
Hi Herbert,
> On Wed, May 20, 2015 at 10:03:45PM +0200, Stephan Mueller wrote:
> >> @@ -1487,6 +1514,7 @@ unlock:
> > */
> >
> > static int drbg_uninstantiate(struct drbg_state *drbg)
> > {
> >
> > + cancel_work_sync(>seed_work);
On Thu, May 21, 2015 at 08:53:13AM +0200, Stephan Mueller wrote:
>
> Thank you for pointing that out - I have seen that too. But the crux is that
> when using wait_event, the cancel function to serialize the destruction code
> path will *not* return at all, even when the async callback function
Am Donnerstag, 21. Mai 2015, 14:36:18 schrieb Herbert Xu:
Hi Herbert,
>On Thu, May 21, 2015 at 08:10:13AM +0200, Stephan Mueller wrote:
>> The cancel operation is needed as otherwise my drbg context handle will be
>> removed by the crypto API during the sleep. That is the whole reason why
>>
On Thu, May 21, 2015 at 08:10:13AM +0200, Stephan Mueller wrote:
>
> The cancel operation is needed as otherwise my drbg context handle will be
> removed by the crypto API during the sleep. That is the whole reason why
> wait_event_interruptible is used.
>
> So, even when using an
Am Donnerstag, 21. Mai 2015, 05:44:08 schrieb Herbert Xu:
Hi Herbert,
> On Wed, May 20, 2015 at 10:03:45PM +0200, Stephan Mueller wrote:
> >> @@ -1487,6 +1514,7 @@ unlock:
> > */
> >
> > static int drbg_uninstantiate(struct drbg_state *drbg)
> > {
> >
> > + cancel_work_sync(>seed_work);
Am Donnerstag, 21. Mai 2015, 05:44:08 schrieb Herbert Xu:
Hi Herbert,
On Wed, May 20, 2015 at 10:03:45PM +0200, Stephan Mueller wrote:
@@ -1487,6 +1514,7 @@ unlock:
*/
static int drbg_uninstantiate(struct drbg_state *drbg)
{
+ cancel_work_sync(drbg-seed_work);
This
Am Donnerstag, 21. Mai 2015, 05:44:08 schrieb Herbert Xu:
Hi Herbert,
On Wed, May 20, 2015 at 10:03:45PM +0200, Stephan Mueller wrote:
@@ -1487,6 +1514,7 @@ unlock:
*/
static int drbg_uninstantiate(struct drbg_state *drbg)
{
+ cancel_work_sync(drbg-seed_work);
This
On Thu, May 21, 2015 at 08:10:13AM +0200, Stephan Mueller wrote:
The cancel operation is needed as otherwise my drbg context handle will be
removed by the crypto API during the sleep. That is the whole reason why
wait_event_interruptible is used.
So, even when using an uninterruptible
Am Donnerstag, 21. Mai 2015, 14:36:18 schrieb Herbert Xu:
Hi Herbert,
On Thu, May 21, 2015 at 08:10:13AM +0200, Stephan Mueller wrote:
The cancel operation is needed as otherwise my drbg context handle will be
removed by the crypto API during the sleep. That is the whole reason why
On Thu, May 21, 2015 at 08:53:13AM +0200, Stephan Mueller wrote:
Thank you for pointing that out - I have seen that too. But the crux is that
when using wait_event, the cancel function to serialize the destruction code
path will *not* return at all, even when the async callback function
On Wed, May 20, 2015 at 10:03:45PM +0200, Stephan Mueller wrote:
>> @@ -1487,6 +1514,7 @@ unlock:
> */
> static int drbg_uninstantiate(struct drbg_state *drbg)
> {
> + cancel_work_sync(>seed_work);
This will just block until the work is done, i.e., until the
pool is ready. It's no
The async seeding operation is triggered during initalization right
after the first non-blocking seeding is completed. As required by the
asynchronous operation of random.c, a callback function is provided that
is triggered by random.c once entropy is available. That callback
function performs the
The async seeding operation is triggered during initalization right
after the first non-blocking seeding is completed. As required by the
asynchronous operation of random.c, a callback function is provided that
is triggered by random.c once entropy is available. That callback
function performs the
On Wed, May 20, 2015 at 10:03:45PM +0200, Stephan Mueller wrote:
@@ -1487,6 +1514,7 @@ unlock:
*/
static int drbg_uninstantiate(struct drbg_state *drbg)
{
+ cancel_work_sync(drbg-seed_work);
This will just block until the work is done, i.e., until the
pool is ready. It's no
14 matches
Mail list logo
