Am Freitag, 5. Juni 2015, 13:28:06 schrieb Herbert Xu:
Hi Herbert,
>
> Steffen, I think we need to revisit the idea of having a list
> of callbacks.
Ok, I will reactivate my patch with the list.
>
> Cheers,
--
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe
Am Freitag, 5. Juni 2015, 13:28:06 schrieb Herbert Xu:
Hi Herbert,
Steffen, I think we need to revisit the idea of having a list
of callbacks.
Ok, I will reactivate my patch with the list.
Cheers,
--
Ciao
Stephan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Tue, May 19, 2015 at 10:18:05PM +0800, Herbert Xu wrote:
> On Tue, May 19, 2015 at 09:50:28AM -0400, Theodore Ts'o wrote:
> >
> > Finally, this is only going to block *once*, when the system is
> > initially botting up. Why is it so important that we get the
> > asynchronous nature of this
On Tue, May 19, 2015 at 10:18:05PM +0800, Herbert Xu wrote:
On Tue, May 19, 2015 at 09:50:28AM -0400, Theodore Ts'o wrote:
Finally, this is only going to block *once*, when the system is
initially botting up. Why is it so important that we get the
asynchronous nature of this right, and
Am Mittwoch, 20. Mai 2015, 06:55:33 schrieb Herbert Xu:
Hi Herbert,
>
>You still need to handle the case where wait_event_interruptible
>returns an error. Otherwise this looks fine.
Thank you. I would suggest to add a while loop around the call that sets up
the wait if it terminated with
Am Mittwoch, 20. Mai 2015, 06:55:33 schrieb Herbert Xu:
Hi Herbert,
You still need to handle the case where wait_event_interruptible
returns an error. Otherwise this looks fine.
Thank you. I would suggest to add a while loop around the call that sets up
the wait if it terminated with
On Tue, May 19, 2015 at 04:36:58PM +0200, Stephan Mueller wrote:
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index 9cd6968..6f71354 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -1245,6 +1245,20 @@ void get_random_bytes(void *buf, int nbytes)
>
Am Dienstag, 19. Mai 2015, 22:30:22 schrieb Herbert Xu:
Hi Herbert,
>On Tue, May 19, 2015 at 04:27:54PM +0200, Stephan Mueller wrote:
>> The current modification with patch 1 to random.c is the smallest change to
>> date. Is that then appropriate?
>>
>> Herbert, based on your comment now, would
On Tue, May 19, 2015 at 04:27:54PM +0200, Stephan Mueller wrote:
>
> The current modification with patch 1 to random.c is the smallest change to
> date. Is that then appropriate?
>
> Herbert, based on your comment now, would the currently discussed patch with
> waiting in the work queue in
Am Dienstag, 19. Mai 2015, 22:18:05 schrieb Herbert Xu:
Hi Herbert,
>On Tue, May 19, 2015 at 09:50:28AM -0400, Theodore Ts'o wrote:
>> Finally, this is only going to block *once*, when the system is
>> initially botting up. Why is it so important that we get the
>> asynchronous nature of this
On Tue, May 19, 2015 at 09:50:28AM -0400, Theodore Ts'o wrote:
>
> Finally, this is only going to block *once*, when the system is
> initially botting up. Why is it so important that we get the
> asynchronous nature of this right, and why can't we solve it simply by
> just simply doing the work
On Tue, May 19, 2015 at 03:51:55PM +0800, Herbert Xu wrote:
> On Tue, May 19, 2015 at 09:35:15AM +0200, Stephan Mueller wrote:
> >
> > Thank you for the hints. I will follow your guidance.
> >
> > Just for my edification: why is this (rather complex sounding) approach
> > preferred over a
Am Dienstag, 19. Mai 2015, 15:51:55 schrieb Herbert Xu:
Hi Herbert,
>You're right. The cancel function is indeed simpler. I can
>certainly live with that.
Thank you. I will test my patch a bit more and then release it with the
discussed changes.
Ciao
Stephan
--
To unsubscribe from this
On Tue, May 19, 2015 at 09:35:15AM +0200, Stephan Mueller wrote:
>
> Thank you for the hints. I will follow your guidance.
>
> Just for my edification: why is this (rather complex sounding) approach
> preferred over a simple cancel API? Other async APIs (e.g. the AIO syscalls
> with io_cancel)
Am Dienstag, 19. Mai 2015, 15:22:27 schrieb Herbert Xu:
Hi Herbert,
> On Tue, May 19, 2015 at 07:58:25AM +0200, Stephan Mueller wrote:
> > Herbert, do you have any ideas?
>
> On the /dev/random side,
>
> 1) Add a struct module argument in addition to func/data.
> 2) Grab module ref count when
On Tue, May 19, 2015 at 07:58:25AM +0200, Stephan Mueller wrote:
>
> Herbert, do you have any ideas?
On the /dev/random side,
1) Add a struct module argument in addition to func/data.
2) Grab module ref count when func/data is registered.
3) Drop module ref count after func returns.
On the
Am Montag, 18. Mai 2015, 11:02:34 schrieb Theodore Ts'o:
Hi Theodore, Herbert,
>
> The simplest thing to do is to put a refcount on inside the DRBG
> handle structure. The caller instantiates the DRBG handle, and
> invokes the the DRBG. The DRBG, since it is kicking off an
> asynchronous
On Tue, May 19, 2015 at 09:35:15AM +0200, Stephan Mueller wrote:
Thank you for the hints. I will follow your guidance.
Just for my edification: why is this (rather complex sounding) approach
preferred over a simple cancel API? Other async APIs (e.g. the AIO syscalls
with io_cancel) have
Am Dienstag, 19. Mai 2015, 15:51:55 schrieb Herbert Xu:
Hi Herbert,
You're right. The cancel function is indeed simpler. I can
certainly live with that.
Thank you. I will test my patch a bit more and then release it with the
discussed changes.
Ciao
Stephan
--
To unsubscribe from this list:
Am Montag, 18. Mai 2015, 11:02:34 schrieb Theodore Ts'o:
Hi Theodore, Herbert,
The simplest thing to do is to put a refcount on inside the DRBG
handle structure. The caller instantiates the DRBG handle, and
invokes the the DRBG. The DRBG, since it is kicking off an
asynchronous operation,
On Tue, May 19, 2015 at 07:58:25AM +0200, Stephan Mueller wrote:
Herbert, do you have any ideas?
On the /dev/random side,
1) Add a struct module argument in addition to func/data.
2) Grab module ref count when func/data is registered.
3) Drop module ref count after func returns.
On the drbg
Am Dienstag, 19. Mai 2015, 15:22:27 schrieb Herbert Xu:
Hi Herbert,
On Tue, May 19, 2015 at 07:58:25AM +0200, Stephan Mueller wrote:
Herbert, do you have any ideas?
On the /dev/random side,
1) Add a struct module argument in addition to func/data.
2) Grab module ref count when
On Tue, May 19, 2015 at 03:51:55PM +0800, Herbert Xu wrote:
On Tue, May 19, 2015 at 09:35:15AM +0200, Stephan Mueller wrote:
Thank you for the hints. I will follow your guidance.
Just for my edification: why is this (rather complex sounding) approach
preferred over a simple cancel
Am Dienstag, 19. Mai 2015, 22:18:05 schrieb Herbert Xu:
Hi Herbert,
On Tue, May 19, 2015 at 09:50:28AM -0400, Theodore Ts'o wrote:
Finally, this is only going to block *once*, when the system is
initially botting up. Why is it so important that we get the
asynchronous nature of this right,
Am Dienstag, 19. Mai 2015, 22:30:22 schrieb Herbert Xu:
Hi Herbert,
On Tue, May 19, 2015 at 04:27:54PM +0200, Stephan Mueller wrote:
The current modification with patch 1 to random.c is the smallest change to
date. Is that then appropriate?
Herbert, based on your comment now, would the
On Tue, May 19, 2015 at 04:27:54PM +0200, Stephan Mueller wrote:
The current modification with patch 1 to random.c is the smallest change to
date. Is that then appropriate?
Herbert, based on your comment now, would the currently discussed patch with
waiting in the work queue in patch 3
On Tue, May 19, 2015 at 09:50:28AM -0400, Theodore Ts'o wrote:
Finally, this is only going to block *once*, when the system is
initially botting up. Why is it so important that we get the
asynchronous nature of this right, and why can't we solve it simply by
just simply doing the work in a
On Tue, May 19, 2015 at 04:36:58PM +0200, Stephan Mueller wrote:
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 9cd6968..6f71354 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1245,6 +1245,20 @@ void get_random_bytes(void *buf, int nbytes)
On Mon, May 18, 2015 at 03:26:13PM +0200, Stephan Mueller wrote:
>
> I am just running into an interesting problem with a missing cancel
> operation:
> a caller instantiates a DRBG handle and invokes the seeding operation. The
> nonblocking_pool is not initialized. Therefore, the callback is
Am Montag, 18. Mai 2015, 15:07:10 schrieb Stephan Mueller:
Hi Herbert,
>>
>>You can simplify this further and get rid of buf/nbytes. All
>>we need to know is whether the pool is ready. Everything else
>>can come from private.
>
>So, the async function is now just a notification of the caller.
Am Montag, 18. Mai 2015, 17:21:31 schrieb Herbert Xu:
Hi Herbert,
>> +/*
>> + * Equivalent function to get_random_bytes with the difference that this
>> + * function blocks the request until the nonblocking_pool is initialized.
>> + */
>> +int get_blocking_random_bytes_cb(void *buf, int nbytes,
On Mon, May 18, 2015 at 07:32:01AM +0200, Stephan Mueller wrote:
>
> Thanks for the hint to the list. Before handing in another formal patch, may
> i ask for checking the following approach? I would think that this one should
> cover your concerns.
Yes this is definitely going in the right
On Mon, May 18, 2015 at 03:26:13PM +0200, Stephan Mueller wrote:
I am just running into an interesting problem with a missing cancel
operation:
a caller instantiates a DRBG handle and invokes the seeding operation. The
nonblocking_pool is not initialized. Therefore, the callback is put
Am Montag, 18. Mai 2015, 15:07:10 schrieb Stephan Mueller:
Hi Herbert,
You can simplify this further and get rid of buf/nbytes. All
we need to know is whether the pool is ready. Everything else
can come from private.
So, the async function is now just a notification of the caller. Sounds
Am Montag, 18. Mai 2015, 17:21:31 schrieb Herbert Xu:
Hi Herbert,
+/*
+ * Equivalent function to get_random_bytes with the difference that this
+ * function blocks the request until the nonblocking_pool is initialized.
+ */
+int get_blocking_random_bytes_cb(void *buf, int nbytes, void
On Mon, May 18, 2015 at 07:32:01AM +0200, Stephan Mueller wrote:
Thanks for the hint to the list. Before handing in another formal patch, may
i ask for checking the following approach? I would think that this one should
cover your concerns.
Yes this is definitely going in the right
Am Freitag, 15. Mai 2015, 14:46:26 schrieb Herbert Xu:
Hi Herbert,
> On Wed, May 13, 2015 at 09:54:41PM +0200, Stephan Mueller wrote:
> > /*
> >
> > + * Equivalent function to get_random_bytes with the difference that this
> > + * function blocks the request until the nonblocking_pool is
Am Freitag, 15. Mai 2015, 14:46:26 schrieb Herbert Xu:
Hi Herbert,
On Wed, May 13, 2015 at 09:54:41PM +0200, Stephan Mueller wrote:
/*
+ * Equivalent function to get_random_bytes with the difference that this
+ * function blocks the request until the nonblocking_pool is initialized.
On Wed, May 13, 2015 at 09:54:41PM +0200, Stephan Mueller wrote:
> /*
> + * Equivalent function to get_random_bytes with the difference that this
> + * function blocks the request until the nonblocking_pool is initialized.
> + */
> +void get_blocking_random_bytes(void *buf, int nbytes)
> +{
> +
On Wed, May 13, 2015 at 09:54:41PM +0200, Stephan Mueller wrote:
/*
+ * Equivalent function to get_random_bytes with the difference that this
+ * function blocks the request until the nonblocking_pool is initialized.
+ */
+void get_blocking_random_bytes(void *buf, int nbytes)
+{
+ if
The added API calls provide a synchronous function call
get_blocking_random_bytes where the caller is blocked until
the nonblocking_pool is initialized.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
drivers/char/random.c | 14 ++
The added API calls provide a synchronous function call
get_blocking_random_bytes where the caller is blocked until
the nonblocking_pool is initialized.
CC: Andreas Steffen andreas.stef...@strongswan.org
CC: Theodore Ts'o ty...@mit.edu
CC: Sandy Harris sandyinch...@gmail.com
Signed-off-by:
42 matches
Mail list logo
