* Re: [PATCH] hwrng: stm32 - fix build warning
From: Maxime Coquelin @ 2016-05-24 8:50 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel@lists.infradead.org, Sudip Mukherjee,
Matt Mackall, Herbert Xu, linux-kernel@vger.kernel.org,
linux-crypto
In-Reply-To: <12548318.auB4PSA3KC@wuerfel>
2016-05-24 10:32 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> On Tuesday, May 24, 2016 9:59:41 AM CEST Maxime Coquelin wrote:
>> 2016-05-23 22:35 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> > On Monday, May 23, 2016 6:14:08 PM CEST Sudip Mukherjee wrote:
>> >> diff --git a/drivers/char/hw_random/stm32-rng.c b/drivers/char/hw_random/stm32-rng.c
>> >> index 92a8106..0533370 100644
>> >> --- a/drivers/char/hw_random/stm32-rng.c
>> >> +++ b/drivers/char/hw_random/stm32-rng.c
>> >> @@ -52,7 +52,7 @@ static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
>> >> {
>> >> struct stm32_rng_private *priv =
>> >> container_of(rng, struct stm32_rng_private, rng);
>> >> - u32 sr;
>> >> + u32 sr = 0;
>> >> int retval = 0;
>> >>
>> >> pm_runtime_get_sync((struct device *) priv->rng.priv);
>> >
>> > Does this work as well?
>> >
>> > diff --git a/drivers/char/hw_random/stm32-rng.c b/drivers/char/hw_random/stm32-rng.c
>> > index 92a810648bd0..5c836b0afa40 100644
>> > --- a/drivers/char/hw_random/stm32-rng.c
>> > +++ b/drivers/char/hw_random/stm32-rng.c
>> > @@ -79,7 +79,7 @@ static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
>> > max -= sizeof(u32);
>> > }
>> >
>> > - if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
>> > + if (WARN_ONCE(retval > 0 && (sr & (RNG_SR_SEIS | RNG_SR_CEIS)),
>> > "bad RNG status - %x\n", sr))
>> > writel_relaxed(0, priv->base + RNG_SR);
>> >
>> > I think it would be nicer to not add a bogus initialization.
>> Hmm, no sure this nicer.
>> The while loop can break before retval is incremented when sr value is
>> not expected (sr != RNG_SR_DRDY).
>> In that case, we certainly want to print sr value.
>
> Ah, you are right.
>
>> Maybe the better way is just to initialize sr with status register content?
>
>> pm_runtime_get_sync((struct device *) priv->rng.priv);
>>
>>+ sr = readl_relaxed(priv->base + RNG_SR);
>> while (max > sizeof(u32)) {
>>- sr = readl_relaxed(priv->base + RNG_SR);
>> if (!sr && wait) {
>> unsigned int timeout = RNG_TIMEOUT;
>
>
> I think that introduces a bug: you really want to read the status
> register on each loop iteration.
Actually, I read the status again at the end of the loop.
But my implementation isn't good anyway, because I read the status
register one time more every time.
>
> How about moving the error handling into the loop itself?
That would be better, indeed, but there is one problem with your below proposal:
>
> Arnd
>
>
> diff --git a/drivers/char/hw_random/stm32-rng.c b/drivers/char/hw_random/stm32-rng.c
> index 92a810648bd0..fceacd809462 100644
> --- a/drivers/char/hw_random/stm32-rng.c
> +++ b/drivers/char/hw_random/stm32-rng.c
> @@ -59,6 +59,10 @@ static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
>
> while (max > sizeof(u32)) {
> sr = readl_relaxed(priv->base + RNG_SR);
> + if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
> + "bad RNG status - %x\n", sr))
> + writel_relaxed(0, priv->base + RNG_SR);
> +
The error handling should be moved after the last status register read.
> if (!sr && wait) {
> unsigned int timeout = RNG_TIMEOUT;
>
> @@ -79,10 +83,6 @@ static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
> max -= sizeof(u32);
> }
>
> - if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
> - "bad RNG status - %x\n", sr))
> - writel_relaxed(0, priv->base + RNG_SR);
> -
> pm_runtime_mark_last_busy((struct device *) priv->rng.priv);
> pm_runtime_put_sync_autosuspend((struct device *) priv->rng.priv);
diff --git a/drivers/char/hw_random/stm32-rng.c
b/drivers/char/hw_random/stm32-rng.c
index 92a810648bd0..2a0fc90e4dc3 100644
--- a/drivers/char/hw_random/stm32-rng.c
+++ b/drivers/char/hw_random/stm32-rng.c
@@ -68,6 +68,10 @@ static int stm32_rng_read(struct hwrng *rng, void
*data, size_t max, bool wait)
} while (!sr && --timeout);
}
+ if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
+ "bad RNG status - %x\n", sr))
+ writel_relaxed(0, priv->base + RNG_SR);
+
/* If error detected or data not ready... */
if (sr != RNG_SR_DRDY)
break;
@@ -79,10 +83,6 @@ static int stm32_rng_read(struct hwrng *rng, void
*data, size_t max, bool wait)
max -= sizeof(u32);
}
- if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
- "bad RNG status - %x\n", sr))
- writel_relaxed(0, priv->base + RNG_SR);
-
pm_runtime_mark_last_busy((struct device *) priv->rng.priv);
pm_runtime_put_sync_autosuspend((struct device *) priv->rng.priv);
Thanks,
Maxime
^ permalink raw reply related
* Re: [PATCH] hwrng: stm32 - fix build warning
From: Arnd Bergmann @ 2016-05-24 8:58 UTC (permalink / raw)
To: Maxime Coquelin
Cc: linux-arm-kernel@lists.infradead.org, Sudip Mukherjee,
Matt Mackall, Herbert Xu, linux-kernel@vger.kernel.org,
linux-crypto
In-Reply-To: <CALszF6BPPA=tezMLhmdC4YFwmH1tGhDxCNDZNwGp1cTDWP7Fmg@mail.gmail.com>
On Tuesday, May 24, 2016 10:50:17 AM CEST Maxime Coquelin wrote:
> diff --git a/drivers/char/hw_random/stm32-rng.c
> b/drivers/char/hw_random/stm32-rng.c
> index 92a810648bd0..2a0fc90e4dc3 100644
> --- a/drivers/char/hw_random/stm32-rng.c
> +++ b/drivers/char/hw_random/stm32-rng.c
> @@ -68,6 +68,10 @@ static int stm32_rng_read(struct hwrng *rng, void
> *data, size_t max, bool wait)
> } while (!sr && --timeout);
> }
>
> + if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
> + "bad RNG status - %x\n", sr))
> + writel_relaxed(0, priv->base + RNG_SR);
> +
> /* If error detected or data not ready... */
> if (sr != RNG_SR_DRDY)
> break;
> @@ -79,10 +83,6 @@ static int stm32_rng_read(struct hwrng *rng, void
> *data, size_t max, bool wait)
> max -= sizeof(u32);
> }
>
> - if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
> - "bad RNG status - %x\n", sr))
> - writel_relaxed(0, priv->base + RNG_SR);
> -
> pm_runtime_mark_last_busy((struct device *) priv->rng.priv);
> pm_runtime_put_sync_autosuspend((struct device *) priv->rng.priv);
>
> Thanks,
>
Yes, that looks good to me.
Arnd
^ permalink raw reply
* Re: [PATCH] hwrng: stm32 - fix build warning
From: Maxime Coquelin @ 2016-05-24 9:20 UTC (permalink / raw)
To: Arnd Bergmann, Sudip Mukherjee
Cc: linux-arm-kernel@lists.infradead.org, Matt Mackall, Herbert Xu,
linux-kernel@vger.kernel.org, linux-crypto
In-Reply-To: <6044541.yeLQbYg2Jv@wuerfel>
2016-05-24 10:58 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> On Tuesday, May 24, 2016 10:50:17 AM CEST Maxime Coquelin wrote:
>> diff --git a/drivers/char/hw_random/stm32-rng.c
>> b/drivers/char/hw_random/stm32-rng.c
>> index 92a810648bd0..2a0fc90e4dc3 100644
>> --- a/drivers/char/hw_random/stm32-rng.c
>> +++ b/drivers/char/hw_random/stm32-rng.c
>> @@ -68,6 +68,10 @@ static int stm32_rng_read(struct hwrng *rng, void
>> *data, size_t max, bool wait)
>> } while (!sr && --timeout);
>> }
>>
>> + if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
>> + "bad RNG status - %x\n", sr))
>> + writel_relaxed(0, priv->base + RNG_SR);
>> +
>> /* If error detected or data not ready... */
>> if (sr != RNG_SR_DRDY)
>> break;
>> @@ -79,10 +83,6 @@ static int stm32_rng_read(struct hwrng *rng, void
>> *data, size_t max, bool wait)
>> max -= sizeof(u32);
>> }
>>
>> - if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
>> - "bad RNG status - %x\n", sr))
>> - writel_relaxed(0, priv->base + RNG_SR);
>> -
>> pm_runtime_mark_last_busy((struct device *) priv->rng.priv);
>> pm_runtime_put_sync_autosuspend((struct device *) priv->rng.priv);
>>
>> Thanks,
>>
>
> Yes, that looks good to me.
Thanks!
Sudip, do you want to send the patch, or I manage to do it?
Maxime
^ permalink raw reply
* Re: [PATCH] hwrng: stm32 - fix build warning
From: Daniel Thompson @ 2016-05-24 10:09 UTC (permalink / raw)
To: Maxime Coquelin, Arnd Bergmann
Cc: linux-arm-kernel@lists.infradead.org, Sudip Mukherjee,
Matt Mackall, Herbert Xu, linux-kernel@vger.kernel.org,
linux-crypto
In-Reply-To: <CALszF6BPPA=tezMLhmdC4YFwmH1tGhDxCNDZNwGp1cTDWP7Fmg@mail.gmail.com>
On 24/05/16 09:50, Maxime Coquelin wrote:
> diff --git a/drivers/char/hw_random/stm32-rng.c
> b/drivers/char/hw_random/stm32-rng.c
> index 92a810648bd0..2a0fc90e4dc3 100644
> --- a/drivers/char/hw_random/stm32-rng.c
> +++ b/drivers/char/hw_random/stm32-rng.c
> @@ -68,6 +68,10 @@ static int stm32_rng_read(struct hwrng *rng, void
> *data, size_t max, bool wait)
> } while (!sr && --timeout);
> }
>
> + if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
> + "bad RNG status - %x\n", sr))
> + writel_relaxed(0, priv->base + RNG_SR);
> +
> /* If error detected or data not ready... */
> if (sr != RNG_SR_DRDY)
> break;
Minor quibble but I might prefer that the error handling/recovery
actually be put on the error path itself (included in the if (sr !=
RNG_SR_DRDY) ).
Daniel.
^ permalink raw reply
* Re: [PATCH] hwrng: stm32 - fix build warning
From: Maxime Coquelin @ 2016-05-24 10:57 UTC (permalink / raw)
To: Daniel Thompson
Cc: Arnd Bergmann, linux-arm-kernel@lists.infradead.org,
Sudip Mukherjee, Matt Mackall, Herbert Xu,
linux-kernel@vger.kernel.org, linux-crypto
In-Reply-To: <56bb8ec4-fe7e-ec09-adc3-ec7eea2d7ddd@linaro.org>
2016-05-24 12:09 GMT+02:00 Daniel Thompson <daniel.thompson@linaro.org>:
> On 24/05/16 09:50, Maxime Coquelin wrote:
>>
>> diff --git a/drivers/char/hw_random/stm32-rng.c
>> b/drivers/char/hw_random/stm32-rng.c
>> index 92a810648bd0..2a0fc90e4dc3 100644
>> --- a/drivers/char/hw_random/stm32-rng.c
>> +++ b/drivers/char/hw_random/stm32-rng.c
>> @@ -68,6 +68,10 @@ static int stm32_rng_read(struct hwrng *rng, void
>> *data, size_t max, bool wait)
>> } while (!sr && --timeout);
>> }
>>
>> + if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
>> + "bad RNG status - %x\n", sr))
>> + writel_relaxed(0, priv->base + RNG_SR);
>> +
>> /* If error detected or data not ready... */
>> if (sr != RNG_SR_DRDY)
>> break;
>
>
> Minor quibble but I might prefer that the error handling/recovery actually
> be put on the error path itself (included in the if (sr != RNG_SR_DRDY) ).
Yes, it would be better.
Regards,
Maxime
^ permalink raw reply
* SKB dst field is NULL when AEAD request complete() is called
From: Denis B @ 2016-05-24 12:03 UTC (permalink / raw)
To: linux-crypto
Working with kernel 3.12.14, in AEAD mode, I register my crypto driver
and the givencrypt() method in the driver gets called when I send
IPSec traffic. I store the request, and later call its complete()
method from a work queue. There is no actual encryption happening at
the moment, I'm just testing flow. As stated, the complete() call
stumbles upon a NULL pointer exception in xfrm_output_resume() because
skb_dst(skb) is NULL. When I receive the request in givencrypt(), dst
is not null in the SKB.
Why would the framework meddle with the SKB? Has anyone experienced
anything similar?
Thanks,
Dennis.
^ permalink raw reply
* booting sun sparc T5120 with "nosmp" kernel 4.5.4 causes OOPS in n2_crypto module
From: Anatoly Pugachev @ 2016-05-24 12:04 UTC (permalink / raw)
To: sparclinux; +Cc: debian-sparc, linux-crypto
[-- Attachment #1: Type: text/plain, Size: 4139 bytes --]
Hello!
Tried to boot T5120 with nosmp kernel option, gives OOPS in n2_crypto
module:
May 24 13:11:48 nvg5120 kernel: Kernel command line:
root=/dev/mapper/vg1-root ro nosmp
...
May 24 13:11:48 nvg5120 kernel: Loading compiled-in X.509 certificates
May 24 13:11:48 nvg5120 kernel: Kernel unaligned access at TPC[739430]
mpi_read_buffer+0xd0/0x120
May 24 13:11:48 nvg5120 kernel: Loaded X.509 cert 'Debian Project: Ben
Hutchings: 008a018dca80932630'
May 24 13:11:48 nvg5120 kernel: rtc-sun4v rtc-sun4v: setting system clock
to 2016-05-24 10:11:26 UTC (1464084686)
May 24 13:11:48 nvg5120 kernel: aes_sparc64: module verification failed:
signature and/or required key missing - tainting kernel
May 24 13:11:48 nvg5120 kernel: aes_sparc64: sparc64 aes opcodes not
available.
...
May 24 13:11:50 nvg5120 kernel: sha256_sparc64: sparc64 sha256 opcode not
available.
May 24 13:11:50 nvg5120 kernel: n2rng.c:v0.2 (July 27, 2011)
May 24 13:11:50 nvg5120 kernel: n2rng f0286a1c: Registered RNG HVAPI major
2 minor 0
May 24 13:11:50 nvg5120 kernel: n2rng f0286a1c: Found single-unit RNG,
units: 1
May 24 13:11:50 nvg5120 kernel: n2rng f0286a1c: Selftest passed on unit 0
May 24 13:11:50 nvg5120 kernel: n2rng f0286a1c: RNG ready
May 24 13:11:50 nvg5120 kernel: des_sparc64: sparc64 des opcodes not
available.
May 24 13:11:50 nvg5120 kernel: des_sparc64: sparc64 des opcodes not
available.
May 24 13:11:50 nvg5120 kernel: des_sparc64: sparc64 des opcodes not
available.
May 24 13:11:50 nvg5120 kernel: sha1_sparc64: sparc64 sha1 opcode not
available.
May 24 13:11:50 nvg5120 kernel: des_sparc64: sparc64 des opcodes not
available.
May 24 13:11:50 nvg5120 kernel: n2_crypto: n2_crypto.c:v0.2 (July 28, 2011)
May 24 13:11:50 nvg5120 kernel: n2_crypto: Found N2CP at
/virtual-devices@100/n2cp@7
May 24 13:11:50 nvg5120 kernel: n2_crypto: Registered NCS HVAPI version 2.0
May 24 13:11:50 nvg5120 kernel: genirq: Flags mismatch irq 1. 00000000
(cwq-0) vs. 00000000 (cwq-0)
May 24 13:11:50 nvg5120 kernel: ------------[ cut here ]------------
May 24 13:11:50 nvg5120 kernel: WARNING: CPU: 0 PID: 260 at
/build/linux-c06pcb/linux-4.5.4/kernel/irq/manage.c:1449
__free_irq+0xac/0x2a0()
May 24 13:11:50 nvg5120 kernel: Trying to free already-free IRQ 1
May 24 13:11:50 nvg5120 kernel: Modules linked in: n2_crypto(E+) n2_rng(E+)
sha512_sparc64(E+) rng_core(E) des_generic(E) autofs4(E) ext4(E) ecb(E)
May 24 13:11:50 nvg5120 kernel: CPU: 0 PID: 260 Comm: systemd-udevd
Tainted: G E 4.5.0-2-sparc64-smp #1 Debian 4.5.4-1
May 24 13:11:50 nvg5120 kernel: Call Trace:
May 24 13:11:50 nvg5120 kernel: [00000000004669d0]
warn_slowpath_common+0x70/0xc0
May 24 13:11:50 nvg5120 kernel: [0000000000466a50]
warn_slowpath_fmt+0x30/0x40
May 24 13:11:50 nvg5120 kernel: [00000000004bdd0c] __free_irq+0xac/0x2a0
May 24 13:11:50 nvg5120 kernel: [00000000004bdfa0] free_irq+0x40/0x80
May 24 13:11:50 nvg5120 kernel: [0000000010aae24c]
spu_list_destroy+0xec/0x100 [n2_crypto]
May 24 13:11:50 nvg5120 kernel: [0000000010aafc98]
spu_mdesc_scan+0x298/0x4a0 [n2_crypto]
May 24 13:11:50 nvg5120 kernel: [0000000010ab0204]
n2_crypto_probe+0x1a4/0x680 [n2_crypto]
May 24 13:11:50 nvg5120 kernel: [00000000007c95f4]
platform_drv_probe+0x34/0xc0
May 24 13:11:50 nvg5120 kernel: [00000000007c708c]
driver_probe_device+0x24c/0x460
May 24 13:11:50 nvg5120 kernel: [00000000007c7328]
__driver_attach+0x88/0xa0
May 24 13:11:50 nvg5120 kernel: [00000000007c497c]
bus_for_each_dev+0x5c/0xa0
May 24 13:11:50 nvg5120 kernel: [00000000007c669c] driver_attach+0x1c/0x40
May 24 13:11:50 nvg5120 kernel: [00000000007c60b0]
bus_add_driver+0x1f0/0x2a0
May 24 13:11:50 nvg5120 kernel: [00000000007c7db4]
driver_register+0x74/0x120
May 24 13:11:50 nvg5120 kernel: [00000000007c97c4]
__platform_register_drivers+0x64/0x160
May 24 13:11:50 nvg5120 kernel: [0000000010ab6014] n2_init+0x14/0x24
[n2_crypto]
May 24 13:11:50 nvg5120 kernel: ---[ end trace 7aa1f0163177edff ]---
May 24 13:11:50 nvg5120 kernel: camellia_sparc64: sparc64 camellia opcodes
not available.
Full boot logs, "nosmp" and usual (smp) are in [1].
1. https://bugzilla.kernel.org/show_bug.cgi?id=118831
[-- Attachment #2: Type: text/html, Size: 4471 bytes --]
^ permalink raw reply
* Re: booting sun sparc T5120 with "nosmp" kernel 4.5.4 causes OOPS in n2_crypto module
From: Anatoly Pugachev @ 2016-05-24 12:08 UTC (permalink / raw)
To: sparclinux; +Cc: debian-sparc, linux-crypto
In-Reply-To: <CADxRZqyKYV=Y7P24uj-moc11qhd6To=i2jkXEu36=7vYFTvRqA@mail.gmail.com>
(re-sent in plain text)
Hello!
Tried to boot T5120 with nosmp kernel option, gives OOPS in n2_crypto module:
May 24 13:11:48 nvg5120 kernel: Kernel command line:
root=/dev/mapper/vg1-root ro nosmp
...
May 24 13:11:48 nvg5120 kernel: Loading compiled-in X.509 certificates
May 24 13:11:48 nvg5120 kernel: Kernel unaligned access at TPC[739430]
mpi_read_buffer+0xd0/0x120
May 24 13:11:48 nvg5120 kernel: Loaded X.509 cert 'Debian Project: Ben
Hutchings: 008a018dca80932630'
May 24 13:11:48 nvg5120 kernel: rtc-sun4v rtc-sun4v: setting system
clock to 2016-05-24 10:11:26 UTC (1464084686)
May 24 13:11:48 nvg5120 kernel: aes_sparc64: module verification
failed: signature and/or required key missing - tainting kernel
May 24 13:11:48 nvg5120 kernel: aes_sparc64: sparc64 aes opcodes not available.
...
May 24 13:11:50 nvg5120 kernel: sha256_sparc64: sparc64 sha256 opcode
not available.
May 24 13:11:50 nvg5120 kernel: n2rng.c:v0.2 (July 27, 2011)
May 24 13:11:50 nvg5120 kernel: n2rng f0286a1c: Registered RNG HVAPI
major 2 minor 0
May 24 13:11:50 nvg5120 kernel: n2rng f0286a1c: Found single-unit RNG, units: 1
May 24 13:11:50 nvg5120 kernel: n2rng f0286a1c: Selftest passed on unit 0
May 24 13:11:50 nvg5120 kernel: n2rng f0286a1c: RNG ready
May 24 13:11:50 nvg5120 kernel: des_sparc64: sparc64 des opcodes not available.
May 24 13:11:50 nvg5120 kernel: des_sparc64: sparc64 des opcodes not available.
May 24 13:11:50 nvg5120 kernel: des_sparc64: sparc64 des opcodes not available.
May 24 13:11:50 nvg5120 kernel: sha1_sparc64: sparc64 sha1 opcode not available.
May 24 13:11:50 nvg5120 kernel: des_sparc64: sparc64 des opcodes not available.
May 24 13:11:50 nvg5120 kernel: n2_crypto: n2_crypto.c:v0.2 (July 28, 2011)
May 24 13:11:50 nvg5120 kernel: n2_crypto: Found N2CP at
/virtual-devices@100/n2cp@7
May 24 13:11:50 nvg5120 kernel: n2_crypto: Registered NCS HVAPI version 2.0
May 24 13:11:50 nvg5120 kernel: genirq: Flags mismatch irq 1. 00000000
(cwq-0) vs. 00000000 (cwq-0)
May 24 13:11:50 nvg5120 kernel: ------------[ cut here ]------------
May 24 13:11:50 nvg5120 kernel: WARNING: CPU: 0 PID: 260 at
/build/linux-c06pcb/linux-4.5.4/kernel/irq/manage.c:1449
__free_irq+0xac/0x2a0()
May 24 13:11:50 nvg5120 kernel: Trying to free already-free IRQ 1
May 24 13:11:50 nvg5120 kernel: Modules linked in: n2_crypto(E+)
n2_rng(E+) sha512_sparc64(E+) rng_core(E) des_generic(E) autofs4(E)
ext4(E) ecb(E)
May 24 13:11:50 nvg5120 kernel: CPU: 0 PID: 260 Comm: systemd-udevd
Tainted: G E 4.5.0-2-sparc64-smp #1 Debian 4.5.4-1
May 24 13:11:50 nvg5120 kernel: Call Trace:
May 24 13:11:50 nvg5120 kernel: [00000000004669d0]
warn_slowpath_common+0x70/0xc0
May 24 13:11:50 nvg5120 kernel: [0000000000466a50] warn_slowpath_fmt+0x30/0x40
May 24 13:11:50 nvg5120 kernel: [00000000004bdd0c] __free_irq+0xac/0x2a0
May 24 13:11:50 nvg5120 kernel: [00000000004bdfa0] free_irq+0x40/0x80
May 24 13:11:50 nvg5120 kernel: [0000000010aae24c]
spu_list_destroy+0xec/0x100 [n2_crypto]
May 24 13:11:50 nvg5120 kernel: [0000000010aafc98]
spu_mdesc_scan+0x298/0x4a0 [n2_crypto]
May 24 13:11:50 nvg5120 kernel: [0000000010ab0204]
n2_crypto_probe+0x1a4/0x680 [n2_crypto]
May 24 13:11:50 nvg5120 kernel: [00000000007c95f4] platform_drv_probe+0x34/0xc0
May 24 13:11:50 nvg5120 kernel: [00000000007c708c]
driver_probe_device+0x24c/0x460
May 24 13:11:50 nvg5120 kernel: [00000000007c7328] __driver_attach+0x88/0xa0
May 24 13:11:50 nvg5120 kernel: [00000000007c497c] bus_for_each_dev+0x5c/0xa0
May 24 13:11:50 nvg5120 kernel: [00000000007c669c] driver_attach+0x1c/0x40
May 24 13:11:50 nvg5120 kernel: [00000000007c60b0] bus_add_driver+0x1f0/0x2a0
May 24 13:11:50 nvg5120 kernel: [00000000007c7db4] driver_register+0x74/0x120
May 24 13:11:50 nvg5120 kernel: [00000000007c97c4]
__platform_register_drivers+0x64/0x160
May 24 13:11:50 nvg5120 kernel: [0000000010ab6014] n2_init+0x14/0x24
[n2_crypto]
May 24 13:11:50 nvg5120 kernel: ---[ end trace 7aa1f0163177edff ]---
May 24 13:11:50 nvg5120 kernel: camellia_sparc64: sparc64 camellia opcodes
not available.
Full boot logs, "nosmp" and usual (smp) are in [1].
1. https://bugzilla.kernel.org/show_bug.cgi?id=118831
^ permalink raw reply
* Re: key retention service: DH support
From: Mat Martineau @ 2016-05-24 16:22 UTC (permalink / raw)
To: Stephan Mueller; +Cc: David Howells, keyrings, linux-crypto, mathew.j.martineau
In-Reply-To: <2025704.nsKCcck7Ux@tauon.atsec.com>
On Tue, 24 May 2016, Stephan Mueller wrote:
> Am Dienstag, 24. Mai 2016, 08:19:41 schrieb David Howells:
>
> Hi David,
>
>> Stephan Mueller <smueller@chronox.de> wrote:
>>> The KDF patches are fully tested. All that would be needed on the key
>>> retention side after the shared secret generation are the following calls:
>>>
>>> kdf = crypto_alloc_rng(NAME, 0, 0);
>>>
>>> crypto_rng_reset(kdf, <shared_secret>, sizeof(<shared_secret>));
>>>
>>> crypto_rng_generate(kdf, LABEL, sizeof(LABEL), outbuf, outbuflen);
>>>
>>> NAME would be the KDF type such as "kdf_ctr(hmac(sha256))"
>>>
>>> LABEL would be an arbitrary string defined by the key service (e.g.
>>> "LxKeyRet").
>>
>> So there wouldn't be a change to the DH keyctl (including functional)?
>
> Assuming that the LABEL and/or the KDF name are not configurable by user
> space, the only potential difference I would see is that a user could ask for
> the length of the output data.
KDF transformations would be extremely useful, but transforming the DH
output using a KDF needs to be configurable. There are enough different
uses for DH that it's important to have access to the raw values.
Since the KDF patches are not yet merged, I'm not sure of the best way to
accomodate the future feature. We could future-proof KEYCTL_DH_COMPUTE by
adding a 5th arg, an optional pointer to KDF configuration (NAME and
LABEL). Or a separate KEYCTL_DH_COMPUTE_KDF command can be added later.
--
Mat Martineau
Intel OTC
^ permalink raw reply
* Re: key retention service: DH support
From: Stephan Mueller @ 2016-05-24 16:45 UTC (permalink / raw)
To: Mat Martineau, herbert; +Cc: David Howells, keyrings, linux-crypto
In-Reply-To: <alpine.OSX.2.20.1605240851210.7071@tmhoole-mobl2.amr.corp.intel.com>
Am Dienstag, 24. Mai 2016, 09:22:22 schrieb Mat Martineau:
Hi Mat, Herbert
>
> KDF transformations would be extremely useful, but transforming the DH
> output using a KDF needs to be configurable. There are enough different
> uses for DH that it's important to have access to the raw values.
>
> Since the KDF patches are not yet merged, I'm not sure of the best way to
> accomodate the future feature. We could future-proof KEYCTL_DH_COMPUTE by
> adding a 5th arg, an optional pointer to KDF configuration (NAME and
> LABEL). Or a separate KEYCTL_DH_COMPUTE_KDF command can be added later.
With that statement, Herbert, should we start looking into my KDF patches
after the merge window closes?
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH v6 0/3] crypto: caam - add support for RSA algorithm
From: Stephan Mueller @ 2016-05-24 16:58 UTC (permalink / raw)
To: Tudor-Dan Ambarus
Cc: herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org,
Horia Ioan Geanta Neag, Ronald Harvey
In-Reply-To: <AMSPR04MB5360B73458157BC926CB57EB84F0@AMSPR04MB536.eurprd04.prod.outlook.com>
Am Dienstag, 24. Mai 2016, 16:13:48 schrieb Tudor-Dan Ambarus:
Hi Tudor,
> Hi Stephan,
>
> > > > as I am looking into the RSA countermeasures, I am wondering how much
> >
> > of
> >
> > > > countermeasures are actually applied inside hardware implementations.
> > >
> > > Please point me to the reference RSA countermeasures so that we have
> > > a common point of start.
> >
> > As the entire MPI logic is derived from libgcrypt, I am planning to use
> > the
> > libgcrypt implementation as a basis to implement the blinding defined by
> > the
> > Handbook of Applied Cryptograpy 11.118/11.119.
>
> When using private key operation commands, our hardware provides
> 'timing equalization' to hide key information from timing attacks such that
> the modular exponentiation will take the same amount of time for a given
> byte length of N combined with a given byte length of the exponent.
Great, that is the other countermeasure option for RSA. So, your
implementation would be covered.
I guess it would make sense to implement countermeasures on an as-needed basis
then.
>
> The other part of timing equalization causes each bit of exponent to take
> the same amount of time to process. In normal exponentiation, a one bit
> takes two multiplies, while a zero bit takes just one. In timing
> equalization, a zero bit causes an extra, but 'fake' multiply.
Good, so you have two types of countermeasures it seems. Again, you should be
good then.
Ciao
Stephan
^ permalink raw reply
* RE: [PATCH v6 0/3] crypto: caam - add support for RSA algorithm
From: Tudor-Dan Ambarus @ 2016-05-24 16:13 UTC (permalink / raw)
To: Stephan Mueller
Cc: herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org,
Horia Ioan Geanta Neag, Ronald Harvey
In-Reply-To: <3395695.ChDFsreWpU@tauon.atsec.com>
Hi Stephan,
> > > as I am looking into the RSA countermeasures, I am wondering how much
> of
> > > countermeasures are actually applied inside hardware implementations.
> >
> > Please point me to the reference RSA countermeasures so that we have
> > a common point of start.
>
> As the entire MPI logic is derived from libgcrypt, I am planning to use the
> libgcrypt implementation as a basis to implement the blinding defined by
> the
> Handbook of Applied Cryptograpy 11.118/11.119.
When using private key operation commands, our hardware provides
'timing equalization' to hide key information from timing attacks such that
the modular exponentiation will take the same amount of time for a given
byte length of N combined with a given byte length of the exponent.
The other part of timing equalization causes each bit of exponent to take
the same amount of time to process. In normal exponentiation, a one bit takes
two multiplies, while a zero bit takes just one. In timing equalization,
a zero bit causes an extra, but 'fake' multiply.
Thanks,
ta
^ permalink raw reply
* 我的交友信息在
From: 我的交友信息在 @ 2016-05-02 5:59 UTC (permalink / raw)
To: linux-crypto
你的小姐妹邀你加Q群：546645595 抢红包。
^ permalink raw reply
* Re: [PATCH] hwrng: stm32 - fix build warning
From: Sudip Mukherjee @ 2016-05-25 2:00 UTC (permalink / raw)
To: Maxime Coquelin, Arnd Bergmann
Cc: linux-arm-kernel@lists.infradead.org, Matt Mackall, Herbert Xu,
linux-kernel@vger.kernel.org, linux-crypto
In-Reply-To: <CALszF6BAFgoccC6fmkdnwQxwHmQ35oLcor6v9yOLyVeXrt-KGA@mail.gmail.com>
On Tuesday 24 May 2016 02:50 PM, Maxime Coquelin wrote:
> 2016-05-24 10:58 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> On Tuesday, May 24, 2016 10:50:17 AM CEST Maxime Coquelin wrote:
>>> diff --git a/drivers/char/hw_random/stm32-rng.c
>>> b/drivers/char/hw_random/stm32-rng.c
>>> index 92a810648bd0..2a0fc90e4dc3 100644
>>> --- a/drivers/char/hw_random/stm32-rng.c
>>> +++ b/drivers/char/hw_random/stm32-rng.c
>>> @@ -68,6 +68,10 @@ static int stm32_rng_read(struct hwrng *rng, void
>>> *data, size_t max, bool wait)
>>> } while (!sr && --timeout);
>>> }
>>>
>>> + if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
>>> + "bad RNG status - %x\n", sr))
>>> + writel_relaxed(0, priv->base + RNG_SR);
>>> +
>>> /* If error detected or data not ready... */
>>> if (sr != RNG_SR_DRDY)
>>> break;
>>> @@ -79,10 +83,6 @@ static int stm32_rng_read(struct hwrng *rng, void
>>> *data, size_t max, bool wait)
>>> max -= sizeof(u32);
>>> }
>>>
>>> - if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
>>> - "bad RNG status - %x\n", sr))
>>> - writel_relaxed(0, priv->base + RNG_SR);
>>> -
>>> pm_runtime_mark_last_busy((struct device *) priv->rng.priv);
>>> pm_runtime_put_sync_autosuspend((struct device *) priv->rng.priv);
>>>
>>> Thanks,
>>>
>>
>> Yes, that looks good to me.
>
> Thanks!
> Sudip, do you want to send the patch, or I manage to do it?
Maybe you should send it, i have not done anything in reaching its final
form.
Regards
Sudip
^ permalink raw reply
* [RFC 0/3] Introduce the bulk mode method when sending request to crypto layer
From: Baolin Wang @ 2016-05-25 6:12 UTC (permalink / raw)
To: axboe, agk, snitzer, dm-devel, herbert, davem
Cc: ebiggers3, js1304, tadeusz.struk, smueller, standby24x7, shli,
dan.j.williams, martin.petersen, sagig, kent.overstreet,
keith.busch, tj, ming.lei, broonie, arnd, linux-crypto,
linux-block, linux-raid, linux-kernel, baolin.wang
This patchset will check if the cipher can support bulk mode, then dm-crypt
will handle different ways to send requests to crypto layer according to
cipher mode.
Looking forward to any comments and suggestions. Thanks.
Baolin Wang (3):
block: Introduce blk_bio_map_sg() to map one bio
crypto: Introduce CRYPTO_ALG_BULK flag
md: dm-crypt: Introduce the bulk mode method when sending request
block/blk-merge.c | 45 +++++++++++
drivers/md/dm-crypt.c | 188 ++++++++++++++++++++++++++++++++++++++++++---
include/crypto/skcipher.h | 7 ++
include/linux/blkdev.h | 3 +
include/linux/crypto.h | 6 ++
5 files changed, 237 insertions(+), 12 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [RFC 1/3] block: Introduce blk_bio_map_sg() to map one bio
From: Baolin Wang @ 2016-05-25 6:12 UTC (permalink / raw)
To: axboe, agk, snitzer, dm-devel, herbert, davem
Cc: ebiggers3, js1304, tadeusz.struk, smueller, standby24x7, shli,
dan.j.williams, martin.petersen, sagig, kent.overstreet,
keith.busch, tj, ming.lei, broonie, arnd, linux-crypto,
linux-block, linux-raid, linux-kernel, baolin.wang
In-Reply-To: <cover.1464144790.git.baolin.wang@linaro.org>
In dm-crypt, it need to map one bio to scatterlist for improving the
hardware engine encryption efficiency. Thus this patch introduces the
blk_bio_map_sg() function to map one bio with scatterlists.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
block/blk-merge.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/blkdev.h | 3 +++
2 files changed, 48 insertions(+)
diff --git a/block/blk-merge.c b/block/blk-merge.c
index 2613531..9b92af4 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -417,6 +417,51 @@ single_segment:
}
/*
+ * map a bio to scatterlist, return number of sg entries setup.
+ */
+int blk_bio_map_sg(struct request_queue *q, struct bio *bio,
+ struct scatterlist *sglist,
+ struct scatterlist **sg)
+{
+ struct bio_vec bvec, bvprv = { NULL };
+ struct bvec_iter iter;
+ int nsegs, cluster;
+
+ nsegs = 0;
+ cluster = blk_queue_cluster(q);
+
+ if (bio->bi_rw & REQ_DISCARD) {
+ /*
+ * This is a hack - drivers should be neither modifying the
+ * biovec, nor relying on bi_vcnt - but because of
+ * blk_add_request_payload(), a discard bio may or may not have
+ * a payload we need to set up here (thank you Christoph) and
+ * bi_vcnt is really the only way of telling if we need to.
+ */
+
+ if (bio->bi_vcnt)
+ goto single_segment;
+
+ return 0;
+ }
+
+ if (bio->bi_rw & REQ_WRITE_SAME) {
+single_segment:
+ *sg = sglist;
+ bvec = bio_iovec(bio);
+ sg_set_page(*sg, bvec.bv_page, bvec.bv_len, bvec.bv_offset);
+ return 1;
+ }
+
+ bio_for_each_segment(bvec, bio, iter)
+ __blk_segment_map_sg(q, &bvec, sglist, &bvprv, sg,
+ &nsegs, &cluster);
+
+ return nsegs;
+}
+EXPORT_SYMBOL(blk_bio_map_sg);
+
+/*
* map a request to scatterlist, return number of sg entries setup. Caller
* must make sure sg can hold rq->nr_phys_segments entries
*/
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 1fd8fdf..e5de4f8 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1013,6 +1013,9 @@ extern void blk_queue_write_cache(struct request_queue *q, bool enabled, bool fu
extern struct backing_dev_info *blk_get_backing_dev_info(struct block_device *bdev);
extern int blk_rq_map_sg(struct request_queue *, struct request *, struct scatterlist *);
+extern int blk_bio_map_sg(struct request_queue *q, struct bio *bio,
+ struct scatterlist *sglist,
+ struct scatterlist **sg);
extern void blk_dump_rq_flags(struct request *, char *);
extern long nr_blockdev_pages(void);
--
1.7.9.5
^ permalink raw reply related
* [RFC 3/3] md: dm-crypt: Introduce the bulk mode method when sending request
From: Baolin Wang @ 2016-05-25 6:12 UTC (permalink / raw)
To: axboe, agk, snitzer, dm-devel, herbert, davem
Cc: ebiggers3, js1304, tadeusz.struk, smueller, standby24x7, shli,
dan.j.williams, martin.petersen, sagig, kent.overstreet,
keith.busch, tj, ming.lei, broonie, arnd, linux-crypto,
linux-block, linux-raid, linux-kernel, baolin.wang
In-Reply-To: <cover.1464144790.git.baolin.wang@linaro.org>
In now dm-crypt code, it is ineffective to map one segment (always one
sector) of one bio with just only one scatterlist at one time for hardware
crypto engine. Especially for some encryption mode (like ecb or xts mode)
cooperating with the crypto engine, they just need one initial IV or null
IV instead of different IV for each sector. In this situation We can consider
to use multiple scatterlists to map the whole bio and send all scatterlists
of one bio to crypto engine to encrypt or decrypt, which can improve the
hardware engine's efficiency.
With this optimization, On my test setup (beaglebone black board) using 64KB
I/Os on an eMMC storage device I saw about 60% improvement in throughput for
encrypted writes, and about 100% improvement for encrypted reads. But this
is not fit for other modes which need different IV for each sector.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
drivers/md/dm-crypt.c | 188 +++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 176 insertions(+), 12 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 4f3cb35..1c86ea7 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -33,6 +33,7 @@
#include <linux/device-mapper.h>
#define DM_MSG_PREFIX "crypt"
+#define DM_MAX_SG_LIST 1024
/*
* context holding the current state of a multi-part conversion
@@ -46,6 +47,8 @@ struct convert_context {
sector_t cc_sector;
atomic_t cc_pending;
struct skcipher_request *req;
+ struct sg_table sgt_in;
+ struct sg_table sgt_out;
};
/*
@@ -803,6 +806,108 @@ static struct crypt_iv_operations crypt_iv_tcw_ops = {
.post = crypt_iv_tcw_post
};
+/*
+ * Check how many sg entry numbers are needed when map one bio
+ * with scatterlists in advance.
+ */
+static unsigned int crypt_sg_entry(struct bio *bio_t)
+{
+ struct request_queue *q = bdev_get_queue(bio_t->bi_bdev);
+ int cluster = blk_queue_cluster(q);
+ struct bio_vec bvec, bvprv = { NULL };
+ struct bvec_iter biter;
+ unsigned long nbytes = 0, sg_length = 0;
+ unsigned int sg_cnt = 0, first_bvec = 0;
+
+ if (bio_t->bi_rw & REQ_DISCARD) {
+ if (bio_t->bi_vcnt)
+ return 1;
+ return 0;
+ }
+
+ if (bio_t->bi_rw & REQ_WRITE_SAME)
+ return 1;
+
+ bio_for_each_segment(bvec, bio_t, biter) {
+ nbytes = bvec.bv_len;
+
+ if (!cluster) {
+ sg_cnt++;
+ continue;
+ }
+
+ if (!first_bvec) {
+ first_bvec = 1;
+ goto new_segment;
+ }
+
+ if (sg_length + nbytes > queue_max_segment_size(q))
+ goto new_segment;
+
+ if (!BIOVEC_PHYS_MERGEABLE(&bvprv, &bvec))
+ goto new_segment;
+
+ if (!BIOVEC_SEG_BOUNDARY(q, &bvprv, &bvec))
+ goto new_segment;
+
+ sg_length += nbytes;
+ continue;
+
+new_segment:
+ memcpy(&bvprv, &bvec, sizeof(struct bio_vec));
+ sg_length = nbytes;
+ sg_cnt++;
+ }
+
+ return sg_cnt;
+}
+
+static int crypt_convert_alloc_table(struct crypt_config *cc,
+ struct convert_context *ctx)
+{
+ struct bio *bio_in = ctx->bio_in;
+ struct bio *bio_out = ctx->bio_out;
+ unsigned int mode = skcipher_is_bulk_mode(any_tfm(cc));
+ unsigned int sg_in_max, sg_out_max;
+ int ret = 0;
+
+ if (!mode)
+ goto out2;
+
+ /*
+ * Need to calculate how many sg entry need to be used
+ * for this bio.
+ */
+ sg_in_max = crypt_sg_entry(bio_in) + 1;
+ if (sg_in_max > DM_MAX_SG_LIST || sg_in_max <= 2)
+ goto out2;
+
+ ret = sg_alloc_table(&ctx->sgt_in, sg_in_max, GFP_KERNEL);
+ if (ret)
+ goto out2;
+
+ if (bio_data_dir(bio_in) == READ)
+ goto out1;
+
+ sg_out_max = crypt_sg_entry(bio_out) + 1;
+ if (sg_out_max > DM_MAX_SG_LIST || sg_out_max <= 2)
+ goto out3;
+
+ ret = sg_alloc_table(&ctx->sgt_out, sg_out_max, GFP_KERNEL);
+ if (ret)
+ goto out3;
+
+ return 0;
+
+out3:
+ sg_free_table(&ctx->sgt_in);
+out2:
+ ctx->sgt_in.orig_nents = 0;
+out1:
+ ctx->sgt_out.orig_nents = 0;
+ return ret;
+}
+
static void crypt_convert_init(struct crypt_config *cc,
struct convert_context *ctx,
struct bio *bio_out, struct bio *bio_in,
@@ -843,7 +948,13 @@ static int crypt_convert_block(struct crypt_config *cc,
{
struct bio_vec bv_in = bio_iter_iovec(ctx->bio_in, ctx->iter_in);
struct bio_vec bv_out = bio_iter_iovec(ctx->bio_out, ctx->iter_out);
+ unsigned int mode = skcipher_is_bulk_mode(any_tfm(cc));
+ struct bio *bio_in = ctx->bio_in;
+ struct bio *bio_out = ctx->bio_out;
+ unsigned int total_bytes = bio_in->bi_iter.bi_size;
struct dm_crypt_request *dmreq;
+ struct scatterlist *sg_in;
+ struct scatterlist *sg_out;
u8 *iv;
int r;
@@ -852,16 +963,6 @@ static int crypt_convert_block(struct crypt_config *cc,
dmreq->iv_sector = ctx->cc_sector;
dmreq->ctx = ctx;
- sg_init_table(&dmreq->sg_in, 1);
- sg_set_page(&dmreq->sg_in, bv_in.bv_page, 1 << SECTOR_SHIFT,
- bv_in.bv_offset);
-
- sg_init_table(&dmreq->sg_out, 1);
- sg_set_page(&dmreq->sg_out, bv_out.bv_page, 1 << SECTOR_SHIFT,
- bv_out.bv_offset);
-
- bio_advance_iter(ctx->bio_in, &ctx->iter_in, 1 << SECTOR_SHIFT);
- bio_advance_iter(ctx->bio_out, &ctx->iter_out, 1 << SECTOR_SHIFT);
if (cc->iv_gen_ops) {
r = cc->iv_gen_ops->generator(cc, iv, dmreq);
@@ -869,8 +970,63 @@ static int crypt_convert_block(struct crypt_config *cc,
return r;
}
- skcipher_request_set_crypt(req, &dmreq->sg_in, &dmreq->sg_out,
- 1 << SECTOR_SHIFT, iv);
+ if (mode && ctx->sgt_in.orig_nents > 0) {
+ struct scatterlist *sg = NULL;
+ unsigned int total_sg_in, total_sg_out;
+
+ total_sg_in = blk_bio_map_sg(bdev_get_queue(bio_in->bi_bdev),
+ bio_in, ctx->sgt_in.sgl, &sg);
+ if ((total_sg_in <= 0) ||
+ (total_sg_in > ctx->sgt_in.orig_nents)) {
+ DMERR("%s in sg map error %d, sg table nents[%d]\n",
+ __func__, total_sg_in, ctx->sgt_in.orig_nents);
+ return -EINVAL;
+ }
+
+ if (sg)
+ sg_mark_end(sg);
+
+ ctx->iter_in.bi_size -= total_bytes;
+ sg_in = ctx->sgt_in.sgl;
+ sg_out = ctx->sgt_in.sgl;
+
+ if (bio_data_dir(bio_in) == READ)
+ goto set_crypt;
+
+ sg = NULL;
+ total_sg_out = blk_bio_map_sg(bdev_get_queue(bio_out->bi_bdev),
+ bio_out, ctx->sgt_out.sgl, &sg);
+ if ((total_sg_out <= 0) ||
+ (total_sg_out > ctx->sgt_out.orig_nents)) {
+ DMERR("%s out sg map error %d, sg table nents[%d]\n",
+ __func__, total_sg_out, ctx->sgt_out.orig_nents);
+ return -EINVAL;
+ }
+
+ if (sg)
+ sg_mark_end(sg);
+
+ ctx->iter_out.bi_size -= total_bytes;
+ sg_out = ctx->sgt_out.sgl;
+ } else {
+ sg_init_table(&dmreq->sg_in, 1);
+ sg_set_page(&dmreq->sg_in, bv_in.bv_page, 1 << SECTOR_SHIFT,
+ bv_in.bv_offset);
+
+ sg_init_table(&dmreq->sg_out, 1);
+ sg_set_page(&dmreq->sg_out, bv_out.bv_page, 1 << SECTOR_SHIFT,
+ bv_out.bv_offset);
+
+ bio_advance_iter(ctx->bio_in, &ctx->iter_in, 1 << SECTOR_SHIFT);
+ bio_advance_iter(ctx->bio_out, &ctx->iter_out, 1 << SECTOR_SHIFT);
+
+ sg_in = &dmreq->sg_in;
+ sg_out = &dmreq->sg_out;
+ total_bytes = 1 << SECTOR_SHIFT;
+ }
+
+set_crypt:
+ skcipher_request_set_crypt(req, sg_in, sg_out, total_bytes, iv);
if (bio_data_dir(ctx->bio_in) == WRITE)
r = crypto_skcipher_encrypt(req);
@@ -1081,6 +1237,8 @@ static void crypt_dec_pending(struct dm_crypt_io *io)
if (io->ctx.req)
crypt_free_req(cc, io->ctx.req, base_bio);
+ sg_free_table(&io->ctx.sgt_in);
+ sg_free_table(&io->ctx.sgt_out);
base_bio->bi_error = error;
bio_endio(base_bio);
}
@@ -1312,6 +1470,9 @@ static void kcryptd_crypt_write_convert(struct dm_crypt_io *io)
io->ctx.iter_out = clone->bi_iter;
sector += bio_sectors(clone);
+ r = crypt_convert_alloc_table(cc, &io->ctx);
+ if (r < 0)
+ io->error = -EIO;
crypt_inc_pending(io);
r = crypt_convert(cc, &io->ctx);
@@ -1343,6 +1504,9 @@ static void kcryptd_crypt_read_convert(struct dm_crypt_io *io)
crypt_convert_init(cc, &io->ctx, io->base_bio, io->base_bio,
io->sector);
+ r = crypt_convert_alloc_table(cc, &io->ctx);
+ if (r < 0)
+ io->error = -EIO;
r = crypt_convert(cc, &io->ctx);
if (r < 0)
--
1.7.9.5
^ permalink raw reply related
* [RFC 2/3] crypto: Introduce CRYPTO_ALG_BULK flag
From: Baolin Wang @ 2016-05-25 6:12 UTC (permalink / raw)
To: axboe, agk, snitzer, dm-devel, herbert, davem
Cc: ebiggers3, js1304, tadeusz.struk, smueller, standby24x7, shli,
dan.j.williams, martin.petersen, sagig, kent.overstreet,
keith.busch, tj, ming.lei, broonie, arnd, linux-crypto,
linux-block, linux-raid, linux-kernel, baolin.wang
In-Reply-To: <cover.1464144790.git.baolin.wang@linaro.org>
Now some cipher hardware engines prefer to handle bulk block rather than one
sector (512 bytes) created by dm-crypt, cause these cipher engines can handle
the intermediate values (IV) by themselves in one bulk block. This means we
can increase the size of the request by merging request rather than always 512
bytes and thus increase the hardware engine processing speed.
So introduce 'CRYPTO_ALG_BULK' flag to indicate this cipher can support bulk
mode.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
include/crypto/skcipher.h | 7 +++++++
include/linux/crypto.h | 6 ++++++
2 files changed, 13 insertions(+)
diff --git a/include/crypto/skcipher.h b/include/crypto/skcipher.h
index 0f987f5..d89d29a 100644
--- a/include/crypto/skcipher.h
+++ b/include/crypto/skcipher.h
@@ -519,5 +519,12 @@ static inline void skcipher_request_set_crypt(
req->iv = iv;
}
+static inline unsigned int skcipher_is_bulk_mode(struct crypto_skcipher *sk_tfm)
+{
+ struct crypto_tfm *tfm = crypto_skcipher_tfm(sk_tfm);
+
+ return crypto_tfm_alg_bulk(tfm);
+}
+
#endif /* _CRYPTO_SKCIPHER_H */
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 6e28c89..a315487 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -63,6 +63,7 @@
#define CRYPTO_ALG_DEAD 0x00000020
#define CRYPTO_ALG_DYING 0x00000040
#define CRYPTO_ALG_ASYNC 0x00000080
+#define CRYPTO_ALG_BULK 0x00000100
/*
* Set this bit if and only if the algorithm requires another algorithm of
@@ -623,6 +624,11 @@ static inline u32 crypto_tfm_alg_type(struct crypto_tfm *tfm)
return tfm->__crt_alg->cra_flags & CRYPTO_ALG_TYPE_MASK;
}
+static inline unsigned int crypto_tfm_alg_bulk(struct crypto_tfm *tfm)
+{
+ return tfm->__crt_alg->cra_flags & CRYPTO_ALG_BULK;
+}
+
static inline unsigned int crypto_tfm_alg_blocksize(struct crypto_tfm *tfm)
{
return tfm->__crt_alg->cra_blocksize;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] hwrng: stm32 - fix build warning
From: Sudip Mukherjee @ 2016-05-25 2:05 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel
Cc: Matt Mackall, Herbert Xu, Maxime Coquelin, linux-kernel,
linux-crypto
In-Reply-To: <6297051.TAxtzW5OIB@wuerfel>
On Tuesday 24 May 2016 02:05 AM, Arnd Bergmann wrote:
> On Monday, May 23, 2016 6:14:08 PM CEST Sudip Mukherjee wrote:
>> We have been getting build warning about:
>> drivers/char/hw_random/stm32-rng.c: In function 'stm32_rng_read':
>> drivers/char/hw_random/stm32-rng.c:82:19: warning: 'sr' may be used
>> uninitialized in this function
>>
>> On checking the code it turns out that sr can never be used
>> uninitialized as sr is getting initialized in the while loop and while
>> loop will always execute as the minimum value of max can be 32.
>> So just initialize sr to 0 while declaring it to silence the compiler.
>>
>> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
>> ---
>
> I notice that you are using a really old compiler. While this warning
> seems to be valid in the sense that the compiler should figure out that
> the variable might be used uninitialized, please update your toolchain
> before reporting other such problems, as gcc-4.6 had a lot more false
> positives that newer ones (5.x or 6.x) have.
yes, i need to upgrade gcc in my travis bot. But in my local system I am
having gcc-4.8.4 and there also I am having this error and i am sure
4.8.4 is still being used by many people.
Regards
Sudip
^ permalink raw reply
* tcrypt failing on hmac(crc32)
From: Marcus Meissner @ 2016-05-25 7:07 UTC (permalink / raw)
To: linux-crypto
Hi,
when enabling the testmgr framework and FIPS in 4.6 and 4.4 and running "modprobe tcrypt"
[ 1153.298266] alg: hash: Failed to load transform for hmac(crc32): -2
[ 1153.340636] tcrypt: one or more tests failed!
I spent some hours making sense of what is missing, but I got lost in the maze
of the crypto apis between sync and async hashes somewhere.
Does anyone know the solution for this, otherwise I will need to continue looking.
Ciao, Marcus
^ permalink raw reply
* Re: tcrypt failing on hmac(crc32)
From: Stephan Mueller @ 2016-05-25 7:10 UTC (permalink / raw)
To: Marcus Meissner; +Cc: linux-crypto
In-Reply-To: <20160525070752.GB6559@suse.de>
Am Mittwoch, 25. Mai 2016, 09:07:52 schrieb Marcus Meissner:
Hi Marcus,
> Hi,
>
> when enabling the testmgr framework and FIPS in 4.6 and 4.4 and running
> "modprobe tcrypt"
}, {
.alg = "hmac(crc32)",
.test = alg_test_hash,
...
fips_allowed = 1 missing?
>
> [ 1153.298266] alg: hash: Failed to load transform for hmac(crc32): -2
> [ 1153.340636] tcrypt: one or more tests failed!
>
> I spent some hours making sense of what is missing, but I got lost in the
> maze of the crypto apis between sync and async hashes somewhere.
>
> Does anyone know the solution for this, otherwise I will need to continue
> looking.
>
> Ciao, Marcus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Ciao
Stephan
^ permalink raw reply
* Re: [RFC 1/3] block: Introduce blk_bio_map_sg() to map one bio
From: Ming Lei @ 2016-05-25 8:52 UTC (permalink / raw)
To: Baolin Wang
Cc: Jens Axboe, Alasdair Kergon, Mike Snitzer,
open list:DEVICE-MAPPER (LVM), Herbert Xu, David Miller,
ebiggers3, js1304, tadeusz.struk, smueller, standby24x7,
Shaohua Li, Dan Williams, Martin K. Petersen, Sagi Grimberg,
Kent Overstreet, Keith Busch, Tejun Heo, Mark Brown,
Arnd Bergmann, linux-crypto, linux-block,
open list:SOFTWARE RAID (Multiple Disks) SUPPORT,
Linux Kernel Mailing List
In-Reply-To: <abe693fad3abb0adfc0cf9ca5b3d287fdb0f2d5b.1464144791.git.baolin.wang@linaro.org>
On Wed, May 25, 2016 at 2:12 PM, Baolin Wang <baolin.wang@linaro.org> wrote:
> In dm-crypt, it need to map one bio to scatterlist for improving the
> hardware engine encryption efficiency. Thus this patch introduces the
> blk_bio_map_sg() function to map one bio with scatterlists.
>
> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
> ---
> block/blk-merge.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
> include/linux/blkdev.h | 3 +++
> 2 files changed, 48 insertions(+)
>
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index 2613531..9b92af4 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -417,6 +417,51 @@ single_segment:
> }
>
> /*
> + * map a bio to scatterlist, return number of sg entries setup.
> + */
> +int blk_bio_map_sg(struct request_queue *q, struct bio *bio,
> + struct scatterlist *sglist,
> + struct scatterlist **sg)
> +{
> + struct bio_vec bvec, bvprv = { NULL };
> + struct bvec_iter iter;
> + int nsegs, cluster;
> +
> + nsegs = 0;
> + cluster = blk_queue_cluster(q);
> +
> + if (bio->bi_rw & REQ_DISCARD) {
> + /*
> + * This is a hack - drivers should be neither modifying the
> + * biovec, nor relying on bi_vcnt - but because of
> + * blk_add_request_payload(), a discard bio may or may not have
> + * a payload we need to set up here (thank you Christoph) and
> + * bi_vcnt is really the only way of telling if we need to.
> + */
> +
> + if (bio->bi_vcnt)
> + goto single_segment;
> +
> + return 0;
> + }
> +
> + if (bio->bi_rw & REQ_WRITE_SAME) {
> +single_segment:
> + *sg = sglist;
> + bvec = bio_iovec(bio);
> + sg_set_page(*sg, bvec.bv_page, bvec.bv_len, bvec.bv_offset);
> + return 1;
> + }
> +
> + bio_for_each_segment(bvec, bio, iter)
> + __blk_segment_map_sg(q, &bvec, sglist, &bvprv, sg,
> + &nsegs, &cluster);
> +
> + return nsegs;
> +}
> +EXPORT_SYMBOL(blk_bio_map_sg);
You can use __blk_bios_map_sg() to implement blk_bio_map_sg(),
then code duplication may be avoided.
> +
> +/*
> * map a request to scatterlist, return number of sg entries setup. Caller
> * must make sure sg can hold rq->nr_phys_segments entries
> */
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index 1fd8fdf..e5de4f8 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -1013,6 +1013,9 @@ extern void blk_queue_write_cache(struct request_queue *q, bool enabled, bool fu
> extern struct backing_dev_info *blk_get_backing_dev_info(struct block_device *bdev);
>
> extern int blk_rq_map_sg(struct request_queue *, struct request *, struct scatterlist *);
> +extern int blk_bio_map_sg(struct request_queue *q, struct bio *bio,
> + struct scatterlist *sglist,
> + struct scatterlist **sg);
> extern void blk_dump_rq_flags(struct request *, char *);
> extern long nr_blockdev_pages(void);
>
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [RFC 1/3] block: Introduce blk_bio_map_sg() to map one bio
From: Baolin Wang @ 2016-05-25 9:02 UTC (permalink / raw)
To: Ming Lei
Cc: Jens Axboe, Alasdair Kergon, Mike Snitzer,
open list:DEVICE-MAPPER (LVM), Herbert Xu, David Miller,
ebiggers3, js1304, tadeusz.struk, smueller, Masanari Iida,
Shaohua Li, Dan Williams, Martin K. Petersen, Sagi Grimberg,
Kent Overstreet, Keith Busch, Tejun Heo, Mark Brown,
Arnd Bergmann, linux-crypto, linux-block,
open list:SOFTWARE RAID (Multiple Disks) SUPPORT,
Linux Kernel Mailing List
In-Reply-To: <CACVXFVMYm_3rHe5wxs9YA15h+N0EfjMcGQEgnzLZTVbh7HUaRw@mail.gmail.com>
On 25 May 2016 at 16:52, Ming Lei <ming.lei@canonical.com> wrote:
>> /*
>> + * map a bio to scatterlist, return number of sg entries setup.
>> + */
>> +int blk_bio_map_sg(struct request_queue *q, struct bio *bio,
>> + struct scatterlist *sglist,
>> + struct scatterlist **sg)
>> +{
>> + struct bio_vec bvec, bvprv = { NULL };
>> + struct bvec_iter iter;
>> + int nsegs, cluster;
>> +
>> + nsegs = 0;
>> + cluster = blk_queue_cluster(q);
>> +
>> + if (bio->bi_rw & REQ_DISCARD) {
>> + /*
>> + * This is a hack - drivers should be neither modifying the
>> + * biovec, nor relying on bi_vcnt - but because of
>> + * blk_add_request_payload(), a discard bio may or may not have
>> + * a payload we need to set up here (thank you Christoph) and
>> + * bi_vcnt is really the only way of telling if we need to.
>> + */
>> +
>> + if (bio->bi_vcnt)
>> + goto single_segment;
>> +
>> + return 0;
>> + }
>> +
>> + if (bio->bi_rw & REQ_WRITE_SAME) {
>> +single_segment:
>> + *sg = sglist;
>> + bvec = bio_iovec(bio);
>> + sg_set_page(*sg, bvec.bv_page, bvec.bv_len, bvec.bv_offset);
>> + return 1;
>> + }
>> +
>> + bio_for_each_segment(bvec, bio, iter)
>> + __blk_segment_map_sg(q, &bvec, sglist, &bvprv, sg,
>> + &nsegs, &cluster);
>> +
>> + return nsegs;
>> +}
>> +EXPORT_SYMBOL(blk_bio_map_sg);
>
> You can use __blk_bios_map_sg() to implement blk_bio_map_sg(),
> then code duplication may be avoided.
OK. I'll re-factor the code to map one bio.
>
>> +
>> +/*
>> * map a request to scatterlist, return number of sg entries setup. Caller
>> * must make sure sg can hold rq->nr_phys_segments entries
>> */
>> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
>> index 1fd8fdf..e5de4f8 100644
>> --- a/include/linux/blkdev.h
>> +++ b/include/linux/blkdev.h
>> @@ -1013,6 +1013,9 @@ extern void blk_queue_write_cache(struct request_queue *q, bool enabled, bool fu
>> extern struct backing_dev_info *blk_get_backing_dev_info(struct block_device *bdev);
>>
>> extern int blk_rq_map_sg(struct request_queue *, struct request *, struct scatterlist *);
>> +extern int blk_bio_map_sg(struct request_queue *q, struct bio *bio,
>> + struct scatterlist *sglist,
>> + struct scatterlist **sg);
>> extern void blk_dump_rq_flags(struct request *, char *);
>> extern long nr_blockdev_pages(void);
>>
>> --
>> 1.7.9.5
>>
--
Baolin.wang
Best Regards
^ permalink raw reply
* Re: [PATCH] hwrng: stm32 - fix build warning
From: Arnd Bergmann @ 2016-05-25 10:06 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sudip Mukherjee, linux-crypto, linux-kernel, Herbert Xu,
Maxime Coquelin, Matt Mackall
In-Reply-To: <5745085D.6000104@gmail.com>
On Wednesday, May 25, 2016 7:35:17 AM CEST Sudip Mukherjee wrote:
> On Tuesday 24 May 2016 02:05 AM, Arnd Bergmann wrote:
> > On Monday, May 23, 2016 6:14:08 PM CEST Sudip Mukherjee wrote:
> >> We have been getting build warning about:
> >> drivers/char/hw_random/stm32-rng.c: In function 'stm32_rng_read':
> >> drivers/char/hw_random/stm32-rng.c:82:19: warning: 'sr' may be used
> >> uninitialized in this function
> >>
> >> On checking the code it turns out that sr can never be used
> >> uninitialized as sr is getting initialized in the while loop and while
> >> loop will always execute as the minimum value of max can be 32.
> >> So just initialize sr to 0 while declaring it to silence the compiler.
> >>
> >> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
> >> ---
> >
> > I notice that you are using a really old compiler. While this warning
> > seems to be valid in the sense that the compiler should figure out that
> > the variable might be used uninitialized, please update your toolchain
> > before reporting other such problems, as gcc-4.6 had a lot more false
> > positives that newer ones (5.x or 6.x) have.
>
> yes, i need to upgrade gcc in my travis bot. But in my local system I am
> having gcc-4.8.4 and there also I am having this error and i am sure
> 4.8.4 is still being used by many people.
Right, the change from gcc-4.8 to 4.9 is what drastically changed hte
maybe-uninitialized warnings, introducing a number of additional warnings
(many of them correct) but removing many others (mostly false positives).
I tend to care only about the ones in 4.9+ for this reason. I haven't
run statistics on this in a while, but I guess we could consider turning
off this warning for 4.8 and earlier (though IIRC the switch to turn it
off only appeared in 4.9).
BTW, regarding your build infrastructure, I'd also recommend building
with 'make -s' to make the output more compact.
Arnd
^ permalink raw reply
* Your Audience
From: Richard Williams @ 2016-05-25 10:05 UTC (permalink / raw)
To: Recipients
Hello
I want to tell you something about Davies Ryan. Being the executor of the
Will, it is possible that we may be tempted to make fortune out of our
client situation. This proposal is with full financial benefit for both of
us,If we can be of one accord, I shall give you a comprehensive detail as
soon as you respond thank you.
Regards
Richard Williams
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox