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
>> wait
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 uninterruptibl
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_w
>From http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf,
section 6.2.17 _CCA states that ARM platforms require ACPI _CCA
object to be specified for DMA-cabpable devices. Therefore, this patch
specifies ACPI_CCA_REQUIRED in arm64 Kconfig.
In addition, to handle the case when _CCA is mi
Currently, device drivers, which support both OF and ACPI,
need to call two separate APIs, of_dma_is_coherent() and
acpi_dma_is_coherent()) to determine device coherency attribute.
This patch simplifies this process by introducing a new device
property API, device_dma_is_coherent(), which calls th
Currently, the driver has separate logic to determine device coherency
for DT vs ACPI. This patch simplifies the code with a call to
device_dma_is_coherent().
Signed-off-by: Tom Lendacky
Signed-off-by: Suravee Suthikulpanit
---
drivers/crypto/ccp/ccp-platform.c | 60 +--
Currently, amd-xgbe driver has separate logic to determine device
coherency for DT vs. ACPI. This patch simplifies the code with
a call to device_dma_is_coherent().
Signed-off-by: Tom Lendacky
Signed-off-by: Suravee Suthikulpanit
---
drivers/net/ethernet/amd/xgbe/xgbe-main.c | 27 +-
This patch series introduce support for _CCA object, which is currently
used mainly by ARM64 platform to specify DMA coherency attribute for
devices when booting with ACPI.
A copy of ACPIv6 can be found here:
http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf
This patch also intro
This patch implements support for ACPI _CCA object, which is introduced in
ACPIv5.1, can be used for specifying device DMA coherency attribute.
The parsing logic traverses device namespace to parse coherency
information, and stores it in acpi_device_flags. Then uses it to call
arch_setup_dma_ops()
On 5/20/2015 5:28 AM, Will Deacon wrote:
On Fri, May 15, 2015 at 10:23:12PM +0100, Suravee Suthikulpanit wrote:
Currently, device drivers, which support both OF and ACPI,
need to call two separate APIs, of_dma_is_coherent() and
acpi_dma_is_coherent()) to determine device coherency attribute.
Th
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 d
On Wed, May 20, 2015 at 07:00:25AM -0500, Suravee Suthikulanit wrote:
> On 5/20/2015 4:34 AM, Catalin Marinas wrote:
> >We have a dummy of_dma_configure() already when !CONFIG_OF, otherwise
> >we would need #ifndef here. I already replied, I think for other
> >architectures we need this check to av
During initialization, the DRBG now tries to allocate a handle of the
Jitter RNG. If such a Jitter RNG is available during seeding, the DRBG
pulls the required entropy/nonce string from get_random_bytes and
concatenates it with a string of equal size from the Jitter RNG. That
combined string is now
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
Hi,
as of now, the DRBG is only seeded from get_random_bytes. In various
circumstances, the nonblocking_pool behind get_random_bytes may not be fully
seeded from hardware events at the time the DRBG requires to be seeded.
Based on the discussion in [1], the DRBG seeding is updated such that it
doe
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 | 20
In order to prepare for the addition of the asynchronous seeding call,
the invocation of seeding the DRBG is moved out into a helper function.
In addition, a block of memory is allocated during initialization time
that will be used as a scratchpad for obtaining entropy. That scratchpad
is used for
Am Mittwoch, 20. Mai 2015, 21:44:46 schrieb Stephan Mueller:
Hi,
> +int get_blocking_random_bytes(void *buf, int nbytes)
> +{
> + int rc;
Sorry, I should be more carefully here: the rc should be initialized to 0 :-(
--
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscrib
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
During initialization, the DRBG now tries to allocate a handle of the
Jitter RNG. If such a Jitter RNG is available during seeding, the DRBG
pulls the required entropy/nonce string from get_random_bytes and
concatenates it with a string of equal size from the Jitter RNG. That
combined string is now
Hi,
as of now, the DRBG is only seeded from get_random_bytes. In various
circumstances, the nonblocking_pool behind get_random_bytes may not be fully
seeded from hardware events at the time the DRBG requires to be seeded.
Based on the discussion in [1], the DRBG seeding is updated such that it
doe
In order to prepare for the addition of the asynchronous seeding call,
the invocation of seeding the DRBG is moved out into a helper function.
In addition, a block of memory is allocated during initialization time
that will be used as a scratchpad for obtaining entropy. That scratchpad
is used for
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 | 20
Am Mittwoch, 20. Mai 2015, 20:49:45 schrieb Stephan Mueller:
Hi Herbert,
> > This is just a convoluted way of doing an uninterruptible sleep.
> > Either make it uninterruptible or allow the function to return
> > an error.
>
> Sorry, I overlooked the availability of wait_event. I was looking for
Am Donnerstag, 21. Mai 2015, 02:45:35 schrieb Herbert Xu:
Hi Herbert,
> On Wed, May 20, 2015 at 07:44:39PM +0200, Stephan Mueller wrote:
> > + if (unlikely(nonblocking_pool.initialized == 0)) {
> > + do {
> > + rc = wait_event_interruptible(urandom_init_wait,
> > +
On Wed, May 20, 2015 at 07:44:39PM +0200, Stephan Mueller wrote:
>
> + if (unlikely(nonblocking_pool.initialized == 0)) {
> + do {
> + rc = wait_event_interruptible(urandom_init_wait,
> + nonblocking_pool.initialized);
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 | 18 ++
in
In order to prepare for the addition of the asynchronous seeding call,
the invocation of seeding the DRBG is moved out into a helper function.
In addition, a block of memory is allocated during initialization time
that will be used as a scratchpad for obtaining entropy. That scratchpad
is used for
During initialization, the DRBG now tries to allocate a handle of the
Jitter RNG. If such a Jitter RNG is available during seeding, the DRBG
pulls the required entropy/nonce string from get_random_bytes and
concatenates it with a string of equal size from the Jitter RNG. That
combined string is now
Hi,
as of now, the DRBG is only seeded from get_random_bytes. In various
circumstances, the nonblocking_pool behind get_random_bytes may not be fully
seeded from hardware events at the time the DRBG requires to be seeded.
Based on the discussion in [1], the DRBG seeding is updated such that it
doe
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
Am Mittwoch, 20. Mai 2015, 11:06:42 schrieb Theodore Ts'o:
Hi Theodore,
As a side note to this discussion, may I ask why entropy_total is used for
checking against the threshold value and not entropy_count?
The reason for my question is the following: until a DRNG (in the worst case,
nonblocki
On Wed, May 20, 2015 at 05:30:14PM +0200, Ard Biesheuvel wrote:
>
> However, it's quite a can of worms you're opening here. Speed is
> easily quantified, and it may even be feasible to introduce some kind
> of boottime benchmark to select the fastest implementation available
> (like already exists
On 20 May 2015 at 16:59, Theodore Ts'o wrote:
> On Wed, May 20, 2015 at 09:21:20AM +0200, Steffen Klassert wrote:
>> The current pcrypt version is used just for IPsec because it supports
>> only AEAD type algorithms and does not support request backlog. But
>> I have patches to support ablkcipher
On Wednesday 20 May 2015 06:52:03 Suravee Suthikulanit wrote:
> On 5/20/2015 5:01 AM, Catalin Marinas wrote:
> > On Fri, May 15, 2015 at 04:23:09PM -0500, Suravee Suthikulpanit wrote:
> >> +static inline bool acpi_dma_is_supported(struct acpi_device *adev)
> >> +{
> >> +/**
> >> + * Current
On 5/20/2015 5:03 AM, Catalin Marinas wrote:
On Fri, May 15, 2015 at 04:23:10PM -0500, Suravee Suthikulpanit wrote:
From http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf,
section 6.2.17 _CCA states that ARM platforms require ACPI _CCA
object to be specified for DMA-cabpable device
On Fri, May 15, 2015 at 04:23:09PM -0500, Suravee Suthikulpanit wrote:
> +static inline bool acpi_dma_is_supported(struct acpi_device *adev)
> +{
> + /**
> + * Currently, we mainly support _CCA=1 (i.e. is_coherent=1)
> + * This should be equivalent to specifyig dma-coherent for
> +
On Wed, May 20, 2015 at 11:27:54AM +0200, Arnd Bergmann wrote:
> On Wednesday 20 May 2015 10:24:15 Catalin Marinas wrote:
> > On Sat, May 16, 2015 at 01:59:00AM +0200, Rafael J. Wysocki wrote:
> > > On Friday, May 15, 2015 04:23:11 PM Suravee Suthikulpanit wrote:
> > > > +/**
> > > > + * pci_dma_co
39 matches
Mail list logo
