* [PATCH] hwrng: pasemi-rng - Use linux/io.h instead of asm/io.h
From: PrasannaKumar Muralidharan @ 2016-09-06 8:28 UTC (permalink / raw)
To: olof, linuxppc-dev, linux-crypto, herbert, mpm; +Cc: PrasannaKumar Muralidharan
Checkpatch.pl warns about usage of asm/io.h. Use linux/io.h instead.
Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
---
drivers/char/hw_random/pasemi-rng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/pasemi-rng.c b/drivers/char/hw_random/pasemi-rng.c
index b4e32f7..545df48 100644
--- a/drivers/char/hw_random/pasemi-rng.c
+++ b/drivers/char/hw_random/pasemi-rng.c
@@ -26,7 +26,7 @@
#include <linux/delay.h>
#include <linux/of_address.h>
#include <linux/of_platform.h>
-#include <asm/io.h>
+#include <linux/io.h>
#define SDCRNG_CTL_REG 0x00
#define SDCRNG_CTL_FVLD_M 0x0000f000
--
2.5.0
^ permalink raw reply related
* [PATCH][V2] s390/crypto: initialize ret to nbytes to avoid returning garbage value
From: Colin King @ 2016-09-06 7:25 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Martin Schwidefsky, Heiko Carstens,
linux-crypto, linux-s390
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Static analysis with cppcheck detected that ret is not initialized
and hence garbage is potentially being returned in the case where
prng_data->ppnows.reseed_counter <= prng_reseed_limit.
Thanks to Martin Schwidefsky for spotting a mistake in my original
fix.
Fixes: 0177db01adf26cf9 ("s390/crypto: simplify return code handling")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
arch/s390/crypto/prng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/crypto/prng.c b/arch/s390/crypto/prng.c
index 79e3a1f..5592df9 100644
--- a/arch/s390/crypto/prng.c
+++ b/arch/s390/crypto/prng.c
@@ -412,7 +412,7 @@ static int prng_sha512_reseed(void)
static int prng_sha512_generate(u8 *buf, size_t nbytes)
{
- int ret;
+ int ret = nbytes;
/* reseed needed ? */
if (prng_data->ppnows.reseed_counter > prng_reseed_limit) {
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] s390/crypto: initialize ret to zero to avoid returning garbage value
From: Martin Schwidefsky @ 2016-09-06 7:10 UTC (permalink / raw)
To: Colin King
Cc: Herbert Xu, David S . Miller, Heiko Carstens, linux-crypto,
linux-s390, linux-kernel
In-Reply-To: <20160905162118.16510-1-colin.king@canonical.com>
On Mon, 5 Sep 2016 17:21:18 +0100
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> static analysis with cppcheck detected that ret is not initialized
> and hence garbage is potentially being returned in the case where
> prng_data->ppnows.reseed_counter <= prng_reseed_limit.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> arch/s390/crypto/prng.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/s390/crypto/prng.c b/arch/s390/crypto/prng.c
> index 79e3a1f..a21fdf4 100644
> --- a/arch/s390/crypto/prng.c
> +++ b/arch/s390/crypto/prng.c
> @@ -412,7 +412,7 @@ static int prng_sha512_reseed(void)
>
> static int prng_sha512_generate(u8 *buf, size_t nbytes)
> {
> - int ret;
> + int ret = 0;
>
> /* reseed needed ? */
> if (prng_data->ppnows.reseed_counter > prng_reseed_limit) {
This issue has been introduced by git commit 0177db01adf26cf9
"s390/crypto: simplify return code handling" which is only on
the features branch right now. And to set ret=0 does not fix
the problem. The correct fix is to return nbytes.
Still a good catch though.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* [PATCH] s390/crypto: initialize ret to zero to avoid returning garbage value
From: Colin King @ 2016-09-05 16:21 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Martin Schwidefsky, Heiko Carstens,
linux-crypto, linux-s390
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
static analysis with cppcheck detected that ret is not initialized
and hence garbage is potentially being returned in the case where
prng_data->ppnows.reseed_counter <= prng_reseed_limit.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
arch/s390/crypto/prng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/crypto/prng.c b/arch/s390/crypto/prng.c
index 79e3a1f..a21fdf4 100644
--- a/arch/s390/crypto/prng.c
+++ b/arch/s390/crypto/prng.c
@@ -412,7 +412,7 @@ static int prng_sha512_reseed(void)
static int prng_sha512_generate(u8 *buf, size_t nbytes)
{
- int ret;
+ int ret = 0;
/* reseed needed ? */
if (prng_data->ppnows.reseed_counter > prng_reseed_limit) {
--
2.9.3
^ permalink raw reply related
* Re: [PATCHv3 03/11] crypto: omap-sham: implement context export/import APIs
From: Tero Kristo @ 2016-09-05 12:06 UTC (permalink / raw)
To: Herbert Xu
Cc: lokeshvutla, davem, linux-crypto, tony, linux-omap,
linux-arm-kernel
In-Reply-To: <9af173f7-cc94-a92f-80ee-c746d97ab110@ti.com>
On 01/09/16 10:46, Tero Kristo wrote:
> On 01/09/16 10:31, Herbert Xu wrote:
>> On Thu, Sep 01, 2016 at 10:28:47AM +0300, Tero Kristo wrote:
>>>
>>> Yeah, the flush should do the trick now. Kind of a chicken-egg
>>> problem here. :P How do you see the situation with the above
>>> explanation?
>>
>> The export function is not allowed to sleep so you must not wait
>> for the hardware to complete in it.
>>
>> If you need to wait, then you must use the completion mechanism.
>
> I don't think export is allowed to return -EINPROGRESS either? At least
> currently the kernel pieces using this functionality won't work if I do
> that.
>
> If thats the case, I need to think of something else to handle this...
>
> -Tero
>
Hi Herbert,
Additional request, would it be possible for you to check the rest of
the series and just ignore patches #2 and #3 for now, the rest don't
have any dependencies against these and can be applied cleanly without.
I would like to see these move forward while I figure out how to handle
the buffer / export+import...
-Tero
^ permalink raw reply
* [PATCH] crypto: arm/ghash: change internal cra_name to "__ghash"
From: Ard Biesheuvel @ 2016-09-05 11:58 UTC (permalink / raw)
To: linux-crypto, herbert; +Cc: Ard Biesheuvel
The fact that the internal synchrous hash implementation is called
"ghash" like the publicly visible one is causing the testmgr code
to misidentify it as an algorithm that requires testing at boottime.
So rename it to "__ghash" to prevent this.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
Hi Herbert,
This one should be able to go on top of the 3-pieces series I sent you
last week.
Thanks,
Ard.
arch/arm/crypto/ghash-ce-glue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/crypto/ghash-ce-glue.c b/arch/arm/crypto/ghash-ce-glue.c
index b88364aa149a..7546b3c02466 100644
--- a/arch/arm/crypto/ghash-ce-glue.c
+++ b/arch/arm/crypto/ghash-ce-glue.c
@@ -138,7 +138,7 @@ static struct shash_alg ghash_alg = {
.setkey = ghash_setkey,
.descsize = sizeof(struct ghash_desc_ctx),
.base = {
- .cra_name = "ghash",
+ .cra_name = "__ghash",
.cra_driver_name = "__driver-ghash-ce",
.cra_priority = 0,
.cra_flags = CRYPTO_ALG_TYPE_SHASH | CRYPTO_ALG_INTERNAL,
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/2] crypto: arm/ghash-ce - add missing async import/export
From: Herbert Xu @ 2016-09-05 9:41 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <CAKv+Gu8yEDbQS651Q3-GbQw+AwJfqvH1WHKa-LUE4=43NwyWSw@mail.gmail.com>
On Thu, Sep 01, 2016 at 04:14:22PM +0100, Ard Biesheuvel wrote:
>
> The culprit appears to be that the .cra_name of the internal shash is
> "ghash", (and not "__ghash" like in the x86 case) which causes the
> test code to run the test on not only the public ahash, but also on
> the internal cryptd() encapsulated shash, and also on the internal
> shash itself.
Hmm that's not good. The test code is not meant to process these
internal algorithms. I recently added a check to automatically
filter out internal algorithms when testing. But we should still
change its name to __ghash just to avoid confusion.
> However, that does not answer the question whether .init() must be
> called before .import() [which the test code does not do]. If not,
> then please disregard my v2, and I will followup with a patch that
> renames ghash to __ghash (but .import() will still require the .init()
> bits as well). Given that these internal shashes/ahashes are in fact
> callable, and calling .import() will result in a crash, I suppose
> duplicating some of the init() code in .import() makes sense
> regardless.
Right. This is definitely a bug and I will take your patches.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Crypto Fixes for 4.8
From: Herbert Xu @ 2016-09-05 9:33 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <20160801095821.GA1260@gondor.apana.org.au>
Hi Linus:
This push fixes a regression in the cryptd code that breaks certain
accelerated AED algorithms as well as an older regression in the
caam driver that breaks IPsec.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
Herbert Xu (1):
crypto: cryptd - Use correct tfm object for AEAD tracking
Horia Geantă (1):
crypto: caam - fix IV loading for authenc (giv)decryption
crypto/cryptd.c | 3 +-
drivers/crypto/caam/caamalg.c | 77 ++++++++++++++++++++---------------------
2 files changed, 39 insertions(+), 41 deletions(-)
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [cryptodev:master 65/80] drivers/pci/quirks.c:843:6: error: 'struct pci_dev' has no member named 'sriov'
From: Herbert Xu @ 2016-09-05 9:12 UTC (permalink / raw)
To: Ananth Jasty
Cc: kbuild test robot, Ananth Jasty, kbuild-all, linux-crypto,
Omer Khaliq, Bjorn Helgaas, Linux Kernel Mailing List
In-Reply-To: <59722569-EC4C-4A31-AB54-B6BF9B8B7A5C@caviumnetworks.com>
On Sat, Sep 03, 2016 at 06:40:27PM -0700, Ananth Jasty wrote:
> As this fix is purely SRIOV related, an ifdef guard for SRIOV support should be sufficient to prevent this header dependency.
Please don't top-post.
> On Sep 3, 2016, at 5:16 PM, kbuild test robot <fengguang.wu@intel.com> wrote:
>
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
> > head: 10faa8c0d6c3b22466f97713a9533824a2ea1c57
> > commit: 21b5b8eebbae427d7d890b7dd1e43a63aca7c26c [65/80] PCI: quirk fixup for cavium invalid sriov link value.
> > config: arm64-kexec_dev_defconfig (attached as .config)
> > compiler: aarch64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
> > reproduce:
> > wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > git checkout 21b5b8eebbae427d7d890b7dd1e43a63aca7c26c
> > # save the attached .config to linux build tree
> > make.cross ARCH=arm64
> >
> > All errors (new ones prefixed by >>):
> >
> > drivers/pci/quirks.c: In function 'quirk_cavium_sriov_rnm_link':
> >>> drivers/pci/quirks.c:843:6: error: 'struct pci_dev' has no member named 'sriov'
> > dev->sriov->link = dev->devfn;
> > ^
> >
> > vim +843 drivers/pci/quirks.c
> >
> > 837 #ifdef CONFIG_ARM64
> > 838
> > 839 static void quirk_cavium_sriov_rnm_link(struct pci_dev *dev)
> > 840 {
> > 841 /* Fix for improper SRIOV configuration on Cavium cn88xx RNM device */
> > 842 if (dev->subsystem_device == 0xa118)
> >> 843 dev->sriov->link = dev->devfn;
> > 844 }
> > 845 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CAVIUM, 0xa018, quirk_cavium_sriov_rnm_link);
> > 846 #endif
---8<---
Subject: PCI: Fix cavium quirk compile failure with PCI_ATS off
The newly added quirk_cavium_sriov_rnm_link doesn't compile if
PCI_ATS is off. This patch adds a check for PCI_ATS.
Fixes: 21b5b8eebbae ("PCI: quirk fixup for cavium invalid sriov...")
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 5980aae..7060823 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -834,7 +834,7 @@ static void quirk_amd_ioapic(struct pci_dev *dev)
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_VIPER_7410, quirk_amd_ioapic);
#endif /* CONFIG_X86_IO_APIC */
-#ifdef CONFIG_ARM64
+#if defined(CONFIG_ARM64) && defined(CONFIG_PCI_ATS)
static void quirk_cavium_sriov_rnm_link(struct pci_dev *dev)
{
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: algif_akcipher
From: Herbert Xu @ 2016-09-05 8:57 UTC (permalink / raw)
To: Stephan Mueller; +Cc: dhowells, linux-crypto, keyrings
In-Reply-To: <1708704.H7uTHYKb98@positron.chronox.de>
On Sun, Sep 04, 2016 at 04:06:43PM +0200, Stephan Mueller wrote:
> Hi Herbert, David,
>
> may I inquire for the plans with algif_akcipher? The reason I am asking is
> whether this interface may be accepted or whether a key rings based solution
> is used and whether I can leave or remove the akcipher related API from my
> libkcapi.
I do plan to add something like this eventually. However, at this
point in time I'd like to see akcipher itself mature a bit before
we set it in stone with a user-space interface.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v2] hwrng: pasemi_rng.c: Migrate to managed API
From: PrasannaKumar Muralidharan @ 2016-09-04 18:13 UTC (permalink / raw)
To: olof, mpm, herbert, linuxppc-dev, linux-crypto, darren,
clabbe.montjoie
Cc: PrasannaKumar Muralidharan
Use devm_ioremap and devm_hwrng_register instead of ioremap and
hwrng_register. This removes unregistering and error handling code.
Changes in v2:
Remove hardcoded resource size in ioremap, use resource struct obtained
by calling platform_get_resource.
Removing hardcoded resource size was suggested by LABBE Corentin.
CC: Darren Stevens <darren@stevens-zone.net>
Suggested-by: LABBE Corentin <clabbe.montjoie@gmail.com>
Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
---
drivers/char/hw_random/pasemi-rng.c | 37 +++++++------------------------------
1 file changed, 7 insertions(+), 30 deletions(-)
diff --git a/drivers/char/hw_random/pasemi-rng.c b/drivers/char/hw_random/pasemi-rng.c
index 699b725..b4e32f7 100644
--- a/drivers/char/hw_random/pasemi-rng.c
+++ b/drivers/char/hw_random/pasemi-rng.c
@@ -95,42 +95,20 @@ static struct hwrng pasemi_rng = {
.data_read = pasemi_rng_data_read,
};
-static int rng_probe(struct platform_device *ofdev)
+static int rng_probe(struct platform_device *pdev)
{
void __iomem *rng_regs;
- struct device_node *rng_np = ofdev->dev.of_node;
- struct resource res;
- int err = 0;
+ struct resource *res;
- err = of_address_to_resource(rng_np, 0, &res);
- if (err)
- return -ENODEV;
-
- rng_regs = ioremap(res.start, 0x100);
-
- if (!rng_regs)
- return -ENOMEM;
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ rng_regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(rng_regs))
+ return PTR_ERR(rng_regs);
pasemi_rng.priv = (unsigned long)rng_regs;
pr_info("Registering PA Semi RNG\n");
-
- err = hwrng_register(&pasemi_rng);
-
- if (err)
- iounmap(rng_regs);
-
- return err;
-}
-
-static int rng_remove(struct platform_device *dev)
-{
- void __iomem *rng_regs = (void __iomem *)pasemi_rng.priv;
-
- hwrng_unregister(&pasemi_rng);
- iounmap(rng_regs);
-
- return 0;
+ return devm_hwrng_register(&pdev->dev, &pasemi_rng);
}
static const struct of_device_id rng_match[] = {
@@ -146,7 +124,6 @@ static struct platform_driver rng_driver = {
.of_match_table = rng_match,
},
.probe = rng_probe,
- .remove = rng_remove,
};
module_platform_driver(rng_driver);
--
2.5.0
^ permalink raw reply related
* algif_akcipher
From: Stephan Mueller @ 2016-09-04 14:06 UTC (permalink / raw)
To: herbert, dhowells; +Cc: linux-crypto, keyrings
Hi Herbert, David,
may I inquire for the plans with algif_akcipher? The reason I am asking is
whether this interface may be accepted or whether a key rings based solution
is used and whether I can leave or remove the akcipher related API from my
libkcapi.
Thanks a lot
Stephan
^ permalink raw reply
* [PATCH] hwrng: core - Allocate memory during module init
From: PrasannaKumar Muralidharan @ 2016-09-04 8:29 UTC (permalink / raw)
To: mpm, herbert, jslaby, peter, lee.jones, linux-crypto; +Cc: prasannatsmkumar
In core rng_buffer and rng_fillbuf is allocated in hwrng_register only
once and it is freed during module exit. This patch moves allocating
rng_buffer and rng_fillbuf from hwrng_register to rng core's init. This
avoids checking whether rng_buffer and rng_fillbuf was allocated from
every hwrng_register call. Also moving them to module init makes it
explicit that it is freed in module exit.
Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
---
drivers/char/hw_random/core.c | 27 +++++++++++----------------
1 file changed, 11 insertions(+), 16 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 9203f2d..ec6846b 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -449,22 +449,6 @@ int hwrng_register(struct hwrng *rng)
goto out;
mutex_lock(&rng_mutex);
-
- /* kmalloc makes this safe for virt_to_page() in virtio_rng.c */
- err = -ENOMEM;
- if (!rng_buffer) {
- rng_buffer = kmalloc(rng_buffer_size(), GFP_KERNEL);
- if (!rng_buffer)
- goto out_unlock;
- }
- if (!rng_fillbuf) {
- rng_fillbuf = kmalloc(rng_buffer_size(), GFP_KERNEL);
- if (!rng_fillbuf) {
- kfree(rng_buffer);
- goto out_unlock;
- }
- }
-
/* Must not register two RNGs with the same name. */
err = -EEXIST;
list_for_each_entry(tmp, &rng_list, list) {
@@ -573,6 +557,17 @@ EXPORT_SYMBOL_GPL(devm_hwrng_unregister);
static int __init hwrng_modinit(void)
{
+ /* kmalloc makes this safe for virt_to_page() in virtio_rng.c */
+ rng_buffer = kmalloc(rng_buffer_size(), GFP_KERNEL);
+ if (!rng_buffer)
+ return -ENOMEM;
+
+ rng_fillbuf = kmalloc(rng_buffer_size(), GFP_KERNEL);
+ if (!rng_fillbuf) {
+ kfree(rng_buffer);
+ return -ENOMEM;
+ }
+
return register_miscdev();
}
--
2.5.0
^ permalink raw reply related
* Re: [cryptodev:master 65/80] drivers/pci/quirks.c:843:6: error: 'struct pci_dev' has no member named 'sriov'
From: Ananth Jasty @ 2016-09-04 1:40 UTC (permalink / raw)
To: kbuild test robot
Cc: Ananth Jasty, kbuild-all, linux-crypto, Herbert Xu, Omer Khaliq
In-Reply-To: <201609040817.Rs5sdqia%fengguang.wu@intel.com>
As this fix is purely SRIOV related, an ifdef guard for SRIOV support should be sufficient to prevent this header dependency.
Ananth
On Sep 3, 2016, at 5:16 PM, kbuild test robot <fengguang.wu@intel.com> wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
> head: 10faa8c0d6c3b22466f97713a9533824a2ea1c57
> commit: 21b5b8eebbae427d7d890b7dd1e43a63aca7c26c [65/80] PCI: quirk fixup for cavium invalid sriov link value.
> config: arm64-kexec_dev_defconfig (attached as .config)
> compiler: aarch64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
> reproduce:
> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 21b5b8eebbae427d7d890b7dd1e43a63aca7c26c
> # save the attached .config to linux build tree
> make.cross ARCH=arm64
>
> All errors (new ones prefixed by >>):
>
> drivers/pci/quirks.c: In function 'quirk_cavium_sriov_rnm_link':
>>> drivers/pci/quirks.c:843:6: error: 'struct pci_dev' has no member named 'sriov'
> dev->sriov->link = dev->devfn;
> ^
>
> vim +843 drivers/pci/quirks.c
>
> 837 #ifdef CONFIG_ARM64
> 838
> 839 static void quirk_cavium_sriov_rnm_link(struct pci_dev *dev)
> 840 {
> 841 /* Fix for improper SRIOV configuration on Cavium cn88xx RNM device */
> 842 if (dev->subsystem_device == 0xa118)
>> 843 dev->sriov->link = dev->devfn;
> 844 }
> 845 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CAVIUM, 0xa018, quirk_cavium_sriov_rnm_link);
> 846 #endif
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
> <.config.gz>
^ permalink raw reply
* [cryptodev:master 65/80] drivers/pci/quirks.c:843:6: error: 'struct pci_dev' has no member named 'sriov'
From: kbuild test robot @ 2016-09-04 0:16 UTC (permalink / raw)
To: Ananth Jasty; +Cc: kbuild-all, linux-crypto, Herbert Xu, Omer Khaliq
[-- Attachment #1: Type: text/plain, Size: 1504 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: 10faa8c0d6c3b22466f97713a9533824a2ea1c57
commit: 21b5b8eebbae427d7d890b7dd1e43a63aca7c26c [65/80] PCI: quirk fixup for cavium invalid sriov link value.
config: arm64-kexec_dev_defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 21b5b8eebbae427d7d890b7dd1e43a63aca7c26c
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
drivers/pci/quirks.c: In function 'quirk_cavium_sriov_rnm_link':
>> drivers/pci/quirks.c:843:6: error: 'struct pci_dev' has no member named 'sriov'
dev->sriov->link = dev->devfn;
^
vim +843 drivers/pci/quirks.c
837 #ifdef CONFIG_ARM64
838
839 static void quirk_cavium_sriov_rnm_link(struct pci_dev *dev)
840 {
841 /* Fix for improper SRIOV configuration on Cavium cn88xx RNM device */
842 if (dev->subsystem_device == 0xa118)
> 843 dev->sriov->link = dev->devfn;
844 }
845 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CAVIUM, 0xa018, quirk_cavium_sriov_rnm_link);
846 #endif
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 17985 bytes --]
^ permalink raw reply
* [PATCH] crypto: qce: Initialize core src clock @100Mhz
From: Iaroslav Gridin @ 2016-09-03 16:45 UTC (permalink / raw)
To: herbert
Cc: davem, linux-crypto, linux-kernel, andy.gross, david.brown,
linux-arm-msm, linux-soc, Iaroslav Gridin
Without that, QCE performance is about 2x less.
Signed-off-by: Iaroslav Gridin <voker57@gmail.com>
---
drivers/crypto/qce/core.c | 18 +++++++++++++++++-
drivers/crypto/qce/core.h | 2 +-
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
index 0cde513..657354c 100644
--- a/drivers/crypto/qce/core.c
+++ b/drivers/crypto/qce/core.c
@@ -193,6 +193,10 @@ static int qce_crypto_probe(struct platform_device *pdev)
if (ret < 0)
return ret;
+ qce->core_src = devm_clk_get(qce->dev, "core_src");
+ if (IS_ERR(qce->core_src))
+ return PTR_ERR(qce->core_src);
+
qce->core = devm_clk_get(qce->dev, "core");
if (IS_ERR(qce->core))
return PTR_ERR(qce->core);
@@ -205,10 +209,20 @@ static int qce_crypto_probe(struct platform_device *pdev)
if (IS_ERR(qce->bus))
return PTR_ERR(qce->bus);
- ret = clk_prepare_enable(qce->core);
+ ret = clk_prepare_enable(qce->core_src);
if (ret)
return ret;
+ ret = clk_set_rate(qce->core_src, 100000000);
+ if (ret) {
+ dev_warn(qce->dev, "Unable to set QCE core src clk @100Mhz, performance might be degraded\n");
+ goto err_clks_core_src;
+ }
+
+ ret = clk_prepare_enable(qce->core);
+ if (ret)
+ goto err_clks_core_src;
+
ret = clk_prepare_enable(qce->iface);
if (ret)
goto err_clks_core;
@@ -247,6 +261,8 @@ err_clks_iface:
clk_disable_unprepare(qce->iface);
err_clks_core:
clk_disable_unprepare(qce->core);
+err_clks_core_src:
+ clk_disable_unprepare(qce->core_src);
return ret;
}
diff --git a/drivers/crypto/qce/core.h b/drivers/crypto/qce/core.h
index 549965d..c5f8d08 100644
--- a/drivers/crypto/qce/core.h
+++ b/drivers/crypto/qce/core.h
@@ -42,7 +42,7 @@ struct qce_device {
int result;
void __iomem *base;
struct device *dev;
- struct clk *core, *iface, *bus;
+ struct clk *core, *iface, *bus, *core_src;
struct qce_dma_data dma;
int burst_size;
unsigned int pipe_pair_id;
--
2.9.3
^ permalink raw reply related
* Re: Who will copy the AAD data to dest. buffer
From: Stephan Mueller @ 2016-09-03 13:19 UTC (permalink / raw)
To: Harsh Jain; +Cc: Herbert Xu, linux-crypto
In-Reply-To: <CAFXBA=ndKKGhfQdWtRuAAQdeBCeoKyS6-obExPHFjBsrj4OjXw@mail.gmail.com>
Am Samstag, 3. September 2016, 10:45:08 CEST schrieb Harsh Jain:
Hi Harsh,
> Thanks Herbert for clarification. It means Libkcapi documentation
> needs update of chapter "Aead Cipher API".
Fixed, I will release a new version shortly.
Thanks for the pointer.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH] crypto: mv_cesa: remove NO_IRQ reference
From: Boris Brezillon @ 2016-09-03 6:54 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Herbert Xu, Romain Perier, Arnaud Ebalard, Thomas Petazzoni,
David S. Miller, linux-crypto, linux-kernel
In-Reply-To: <20160902232648.2119621-1-arnd@arndb.de>
On Sat, 3 Sep 2016 01:26:40 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> Drivers should not use NO_IRQ, as we are trying to get rid of that.
> In this case, the call to irq_of_parse_and_map() is both wrong
> (as it returns '0' on failure, not NO_IRQ) and unnecessary
> (as platform_get_irq() does the same thing)
>
> This removes the call to irq_of_parse_and_map() and checks for
> the error code correctly.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> drivers/crypto/mv_cesa.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> It would be good if someone could test this on a machine that boots
> from DT to ensure the conversion was correct.
>
> diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
> index e6b658faef63..104e9ce9400a 100644
> --- a/drivers/crypto/mv_cesa.c
> +++ b/drivers/crypto/mv_cesa.c
> @@ -1091,11 +1091,8 @@ static int mv_probe(struct platform_device *pdev)
>
> cp->max_req_size = cp->sram_size - SRAM_CFG_SPACE;
>
> - if (pdev->dev.of_node)
> - irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
> - else
> - irq = platform_get_irq(pdev, 0);
> - if (irq < 0 || irq == NO_IRQ) {
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0) {
> ret = irq;
> goto err;
> }
^ permalink raw reply
* Re: [dm-devel] dm-crypt: flush crypt_queue on suspend? on REQ_FLUSH?
From: Eric Wheeler @ 2016-09-03 6:26 UTC (permalink / raw)
To: dm-devel; +Cc: linux-block, linux-crypto
In-Reply-To: <alpine.LRH.2.11.1609021430390.5413@mail.ewheeler.net>
On Fri, 2 Sep 2016, Eric Wheeler wrote:
> We have a KVM => dm-crypt => dm-thin stack and a snapshot may have
> partially completed queued IO out-of-order. EXT4 is giving errors like
> this after mounting a snapshot, but only on files recently modified near
> the snapshot time. This might imply out-of-order writes since,
> presumably, the ext4 journal would handle deletions in journal order and
> snapshots should be safe at any time:
>
> kernel: EXT4-fs error (device dm-2): ext4_lookup:1441: inode #1196093: comm rsync: deleted inode referenced: 1188710
>
> Notably, the ext4 error did not present prior to the snapshot. We have
> rsync logs from hours before that didn't report this message, but all
> later rsyncs do.
>
> Perhaps related, or perhaps not, crypt_map() notes the following:
> 1914 * If bio is REQ_FLUSH or REQ_DISCARD, just bypass crypt queues.
> 1915 * - for REQ_FLUSH device-mapper core ensures that no IO is in-flight
> 1916 * - for REQ_DISCARD caller must use flush if IO ordering matters
>
> However, crypt_map returns DM_MAPIO_SUBMITTED after calling
> kcryptd_queue_crypt(io) which processes asynchronously on
> cc->crypto_queue. In crypt_ctr(), alloc_workqueue sets max_active to
> num_online_cpus() unless 'same_cpu_crypt' is set in the dm table (mine is
> not), so if I understand correctly, completion could happen out of order
> with CPUs >1.
>
> Does the dm stack know that the bio (dm_crypt_io) hasn't been completed
> [since] it was put on a work queue [and then a write_thread]? If so, I
> would like to understand that dm bio-tracking mechanism, so please point
> me at documentation or code.
>
> If not, then does crypt_map() need a workqueue_flush(cc->crypto_queue) on
> REQ_FLUSH?
>
> I'm new to the dm-crypt code, so please educate me if I'm missing
> something here.
On second look, simply adding workqueue_flush isn't enough since I've not
set 'submit_from_crypt_cpus'; it's the cc->write_thread's job to get the
bio's submitted via kcryptd_io_write() after pulling them from a red-black
tree that kcryptd_crypt_write_io_submit() inserted into. Is the red-black
tree guaranteed to pop off in order, or at least to flush in order when a
REQ_FLUSH comes through?
If not, then I think this means I need to set both 'same_cpu_crypt'
(DM_CRYPT_SAME_CPU) and 'submit_from_crypt_cpus' (DM_CRYPT_NO_OFFLOAD) to
guarantee ordering by restricting the workqueue to serial work
(DM_CRYPT_SAME_CPU) and force immediate generic_make_request inside
kcryptd_crypt_write_io_submit (DM_CRYPT_NO_OFFLOAD) instead of queuing to
the cc->write_thread.
Your thoughts?
-Eric
> Thank you for your help!
>
> --
> Eric Wheeler
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
>
^ permalink raw reply
* Re: Who will copy the AAD data to dest. buffer
From: Harsh Jain @ 2016-09-03 5:15 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, Stephan Mueller
In-Reply-To: <20160902144203.GA13135@gondor.apana.org.au>
Thanks Herbert for clarification. It means Libkcapi documentation
needs update of chapter "Aead Cipher API".
Regards
Harsh Jain
On Fri, Sep 2, 2016 at 8:12 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Fri, Sep 02, 2016 at 08:05:04PM +0530, Harsh Jain wrote:
>> Hi Herbert,
>>
>> Is copy of AAD data to destination buffer when dst != src is mandatory
>> requirements for crypto drivers or we can skip this copy. Actually I
>> am bit confused, In following link Stephen had mentioned caller will
>> memcpy the AAD to destination buffer but authenc.c also copies the AAD
>> to dest. buffer.
>>
>> http://www.chronox.de/libkcapi/html/ch02s02.html
>
> It has to be copied if src != dst.
>
>> Secondly When AAD data remains unchanged in AEAD encryption/decryption
>> operations. Why we copy the same data to destination buffer?
>
> This greatly simplifies the implementation of the AEAD algorithms
> because we can throw away src and use the dst only. For example,
> authenc hashes the AAD and ciphertext. If we didn't force the
> copy it would have to hash them separately, meaning the use of
> the slow init/update/final interface. With the copy it can use
> the digest interface.
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] crypto: caam: add missing header dependencies
From: Baoyou Xie @ 2016-09-03 3:29 UTC (permalink / raw)
To: herbert, davem, horia.geanta, srinivas.kandagatla,
alexandru.porosanu, arnd
Cc: linux-crypto, linux-kernel, baoyou.xie, xie.baoyou
We get 1 warning when building kernel with W=1:
drivers/crypto/caam/ctrl.c:398:5: warning: no previous prototype for 'caam_get_era' [-Wmissing-prototypes]
In fact, this function is declared in drivers/crypto/caam/ctrl.h
and be exported, thus can be refrenced by modules, so this patch
adds missing header dependencies.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/crypto/caam/ctrl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index 0ec112e..46e72ed 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -14,6 +14,7 @@
#include "jr.h"
#include "desc_constr.h"
#include "error.h"
+#include "ctrl.h"
bool caam_little_end;
EXPORT_SYMBOL(caam_little_end);
--
2.7.4
^ permalink raw reply related
* [PATCH] crypto: mv_cesa: remove NO_IRQ reference
From: Arnd Bergmann @ 2016-09-02 23:26 UTC (permalink / raw)
To: Herbert Xu
Cc: Romain Perier, Boris Brezillon, Arnaud Ebalard, Thomas Petazzoni,
Arnd Bergmann, David S. Miller, linux-crypto, linux-kernel
Drivers should not use NO_IRQ, as we are trying to get rid of that.
In this case, the call to irq_of_parse_and_map() is both wrong
(as it returns '0' on failure, not NO_IRQ) and unnecessary
(as platform_get_irq() does the same thing)
This removes the call to irq_of_parse_and_map() and checks for
the error code correctly.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/crypto/mv_cesa.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
It would be good if someone could test this on a machine that boots
from DT to ensure the conversion was correct.
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index e6b658faef63..104e9ce9400a 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -1091,11 +1091,8 @@ static int mv_probe(struct platform_device *pdev)
cp->max_req_size = cp->sram_size - SRAM_CFG_SPACE;
- if (pdev->dev.of_node)
- irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
- else
- irq = platform_get_irq(pdev, 0);
- if (irq < 0 || irq == NO_IRQ) {
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
ret = irq;
goto err;
}
--
2.9.0
^ permalink raw reply related
* dm-crypt: flush crypt_queue on suspend? on REQ_FLUSH?
From: Eric Wheeler @ 2016-09-02 22:13 UTC (permalink / raw)
To: dm-devel; +Cc: linux-crypto, linux-block
Hello all,
We have a KVM => dm-crypt => dm-thin stack in and a snapshot may have
partially completed queued IO out-of-order. EXT4 is giving errors like
this after mounting a snapshot, but only on files recently modified near
the snapshot time. This might imply out-of-order writes since,
presumably, the ext4 journal would handle deletions in journal order and
snapshots should be safe at any time:
kernel: EXT4-fs error (device dm-2): ext4_lookup:1441: inode #1196093: comm rsync: deleted inode referenced: 1188710
Notably, the ext4 error did not present prior to the snapshot. We have
rsync logs from hours before that didn't report this message, but all
later rsyncs do.
Perhaps related, or perhaps not, crypt_map() notes the following:
1914 * If bio is REQ_FLUSH or REQ_DISCARD, just bypass crypt queues.
1915 * - for REQ_FLUSH device-mapper core ensures that no IO is in-flight
1916 * - for REQ_DISCARD caller must use flush if IO ordering matters
However, crypt_map returns DM_MAPIO_SUBMITTED after calling
kcryptd_queue_crypt(io) which processes asynchronously on
cc->crypto_queue. In crypt_ctr(), alloc_workqueue sets max_active to
num_online_cpus() unless 'same_cpu_crypt' is set in the dm table (mine is
not), so if I understand correctly, completion could happen out of order
with CPUs >1.
Does the dm stack know that the bio (dm_crypt_io) hasn't been completed
even though it was put on a work queue? If so, I would like to understand
that dm bio-tracking mechanism, so please point me at documentation or
code.
If not, then does crypt_map() need a workqueue_flush(cc->crypto_queue) on
REQ_FLUSH?
I'm new to the dm-crypt code, so please educate me if I'm missing
something here.
Thank you for your help!
--
Eric Wheeler
^ permalink raw reply
* [PATCH v2 2/2] crypto: qat - fix resource release omissions
From: Quentin Lambert @ 2016-09-02 14:47 UTC (permalink / raw)
To: Giovanni Cabiddu, Salvatore Benedetto, Herbert Xu,
David S. Miller, qat-linux, linux-crypto, linux-kernel
Cc: kernel-janitors, Quentin Lambert
In-Reply-To: <20160902144753.31334-1-lambert.quentin@gmail.com>
In certain cases qat_uclo_parse_uof_obj used to return with an error code
before releasing all resources. This patch add a jump to the appropriate label
ensuring that the resources are properly released before returning.
This issue was found with Hector.
Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
---
drivers/crypto/qat/qat_common/qat_uclo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/crypto/qat/qat_common/qat_uclo.c
+++ b/drivers/crypto/qat/qat_common/qat_uclo.c
@@ -981,7 +981,8 @@ static int qat_uclo_parse_uof_obj(struct
(PID_MINOR_REV & handle->hal_handle->revision_id);
if (qat_uclo_check_uof_compat(obj_handle)) {
pr_err("QAT: UOF incompatible\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto out_err;
}
obj_handle->ustore_phy_size = ICP_QAT_UCLO_MAX_USTORE;
if (!obj_handle->obj_hdr->file_buff ||
^ permalink raw reply
* [PATCH v2 1/2] crypto: qat - introduces a variable to handle error codes
From: Quentin Lambert @ 2016-09-02 14:47 UTC (permalink / raw)
To: Giovanni Cabiddu, Salvatore Benedetto, Herbert Xu,
David S. Miller, qat-linux, linux-crypto, linux-kernel
Cc: kernel-janitors, Quentin Lambert
In-Reply-To: <20160902144753.31334-1-lambert.quentin@gmail.com>
Most error code used to jump to a label that lead to a "return -EFAULT"
statement. This patch introduces a variable that stores the error code
so that other error branches can use the same label to exit.
Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
---
drivers/crypto/qat/qat_common/qat_uclo.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
--- a/drivers/crypto/qat/qat_common/qat_uclo.c
+++ b/drivers/crypto/qat/qat_common/qat_uclo.c
@@ -966,6 +966,7 @@ static int qat_uclo_parse_uof_obj(struct
{
struct icp_qat_uclo_objhandle *obj_handle = handle->obj_handle;
unsigned int ae;
+ int ret;
obj_handle->uword_buf = kcalloc(UWORD_CPYBUF_SIZE, sizeof(uint64_t),
GFP_KERNEL);
@@ -987,29 +988,35 @@ static int qat_uclo_parse_uof_obj(struct
!qat_uclo_map_str_table(obj_handle->obj_hdr, ICP_QAT_UOF_STRT,
&obj_handle->str_table)) {
pr_err("QAT: UOF doesn't have effective images\n");
+ ret = -EFAULT;
goto out_err;
}
obj_handle->uimage_num =
qat_uclo_map_uimage(obj_handle, obj_handle->ae_uimage,
ICP_QAT_UCLO_MAX_AE * ICP_QAT_UCLO_MAX_CTX);
- if (!obj_handle->uimage_num)
+ if (!obj_handle->uimage_num) {
+ ret = -EFAULT;
goto out_err;
+ }
if (qat_uclo_map_ae(handle, handle->hal_handle->ae_max_num)) {
pr_err("QAT: Bad object\n");
+ ret = -EFAULT;
goto out_check_uof_aemask_err;
}
qat_uclo_init_uword_num(handle);
qat_uclo_map_initmem_table(&obj_handle->encap_uof_obj,
&obj_handle->init_mem_tab);
- if (qat_uclo_set_ae_mode(handle))
+ if (qat_uclo_set_ae_mode(handle)) {
+ ret = -EFAULT;
goto out_check_uof_aemask_err;
+ }
return 0;
out_check_uof_aemask_err:
for (ae = 0; ae < obj_handle->uimage_num; ae++)
kfree(obj_handle->ae_uimage[ae].page);
out_err:
kfree(obj_handle->uword_buf);
- return -EFAULT;
+ return ret;
}
static int qat_uclo_map_suof_file_hdr(struct icp_qat_fw_loader_handle *handle,
^ 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