* [PATCH v2 1/5] hwrng: amd: Fix style problem with blank line
From: LABBE Corentin @ 2016-08-25 12:16 UTC (permalink / raw)
To: mpm, herbert, linux-crypto; +Cc: linux-kernel, LABBE Corentin
In-Reply-To: <1472127395-32195-1-git-send-email-clabbe.montjoie@gmail.com>
Some blank line are unncessary, and one is missing after declaration.
This patch fix thoses style problems.
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
drivers/char/hw_random/amd-rng.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index 48f6a83..45b7965 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -31,10 +31,8 @@
#include <linux/delay.h>
#include <asm/io.h>
-
#define PFX KBUILD_MODNAME ": "
-
/*
* Data for PCI driver interface
*
@@ -52,7 +50,6 @@ MODULE_DEVICE_TABLE(pci, pci_tbl);
static struct pci_dev *amd_pdev;
-
static int amd_rng_data_present(struct hwrng *rng, int wait)
{
u32 pmbase = (u32)rng->priv;
@@ -100,7 +97,6 @@ static void amd_rng_cleanup(struct hwrng *rng)
pci_write_config_byte(amd_pdev, 0x40, rnen);
}
-
static struct hwrng amd_rng = {
.name = "amd",
.init = amd_rng_init,
@@ -109,7 +105,6 @@ static struct hwrng amd_rng = {
.data_read = amd_rng_data_read,
};
-
static int __init mod_init(void)
{
int err = -ENODEV;
@@ -157,6 +152,7 @@ out:
static void __exit mod_exit(void)
{
u32 pmbase = (unsigned long)amd_rng.priv;
+
release_region(pmbase + 0xF0, 8);
hwrng_unregister(&amd_rng);
}
--
2.7.3
^ permalink raw reply related
* [PATCH v2 0/5] hwrng: amd: rework of the amd hwrng driver
From: LABBE Corentin @ 2016-08-25 12:16 UTC (permalink / raw)
To: mpm, herbert, linux-crypto; +Cc: linux-kernel, LABBE Corentin
Changes since v1:
- Keep the hwrng name as "amd"
LABBE Corentin (5):
hwrng: amd: Fix style problem with blank line
hwrng: amd: use the BIT macro
hwrng: amd: Be consitent with the driver name
hwrng: amd: Remove asm/io.h
hwrng: amd: Rework of the amd768-hwrng driver
drivers/char/hw_random/amd-rng.c | 173 ++++++++++++++++++++++++---------------
1 file changed, 107 insertions(+), 66 deletions(-)
--
2.7.3
^ permalink raw reply
* Re: [PATCH] hwrng: pasemi_rng.c: Migrate to managed API
From: LABBE Corentin @ 2016-08-25 12:15 UTC (permalink / raw)
To: PrasannaKumar Muralidharan
Cc: herbert, linux-kernel, linux-crypto, mpm, olof, linuxppc-dev
In-Reply-To: <1472124856-12767-1-git-send-email-prasannatsmkumar@gmail.com>
On Thu, Aug 25, 2016 at 05:04:16PM +0530, PrasannaKumar Muralidharan wrote:
> Use devm_ioremap and devm_hwrng_register instead of ioremap and
> hwrng_register. This removes unregistering and error handling code.
>
> This patch is not tested with hardware as I don't have access to it.
>
> Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
> ---
> drivers/char/hw_random/pasemi-rng.c | 26 +++-----------------------
> 1 file changed, 3 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/char/hw_random/pasemi-rng.c b/drivers/char/hw_random/pasemi-rng.c
> index 699b725..0f03397 100644
> --- a/drivers/char/hw_random/pasemi-rng.c
> +++ b/drivers/char/hw_random/pasemi-rng.c
> @@ -100,37 +100,18 @@ static int rng_probe(struct platform_device *ofdev)
> void __iomem *rng_regs;
> struct device_node *rng_np = ofdev->dev.of_node;
> struct resource res;
> - int err = 0;
>
> - err = of_address_to_resource(rng_np, 0, &res);
> - if (err)
> + if (of_address_to_resource(rng_np, 0, &res))
> return -ENODEV;
>
> - rng_regs = ioremap(res.start, 0x100);
> -
> + rng_regs = devm_ioremap(&ofdev->dev, res.start, 0x100);
> if (!rng_regs)
> return -ENOMEM;
>
I will propose to use devm_ioremap_resource() instead for removing this hardcoded 0x100, but i cannot find any user of this driver in any dts. (And so cannot check that this 0x100 is given in any DT resource node)
Is this normal ?
Regard
^ permalink raw reply
* [PATCH] hwrng: pasemi_rng.c: Migrate to managed API
From: PrasannaKumar Muralidharan @ 2016-08-25 11:34 UTC (permalink / raw)
To: olof, mpm, herbert, linuxppc-dev, linux-crypto, linux-kernel
Cc: prasannatsmkumar
Use devm_ioremap and devm_hwrng_register instead of ioremap and
hwrng_register. This removes unregistering and error handling code.
This patch is not tested with hardware as I don't have access to it.
Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
---
drivers/char/hw_random/pasemi-rng.c | 26 +++-----------------------
1 file changed, 3 insertions(+), 23 deletions(-)
diff --git a/drivers/char/hw_random/pasemi-rng.c b/drivers/char/hw_random/pasemi-rng.c
index 699b725..0f03397 100644
--- a/drivers/char/hw_random/pasemi-rng.c
+++ b/drivers/char/hw_random/pasemi-rng.c
@@ -100,37 +100,18 @@ static int rng_probe(struct platform_device *ofdev)
void __iomem *rng_regs;
struct device_node *rng_np = ofdev->dev.of_node;
struct resource res;
- int err = 0;
- err = of_address_to_resource(rng_np, 0, &res);
- if (err)
+ if (of_address_to_resource(rng_np, 0, &res))
return -ENODEV;
- rng_regs = ioremap(res.start, 0x100);
-
+ rng_regs = devm_ioremap(&ofdev->dev, res.start, 0x100);
if (!rng_regs)
return -ENOMEM;
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(&ofdev->dev, &pasemi_rng);
}
static const struct of_device_id rng_match[] = {
@@ -146,7 +127,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
* Re: crypto: mxs-dcp: do not call blocking ops when !TASK_RUNNING; state=1
From: Herbert Xu @ 2016-08-25 9:02 UTC (permalink / raw)
To: Stefan Wahren
Cc: Fabio Estevam, linux-crypto, Fabio Estevam, Marek Vašut
In-Reply-To: <539610224.17415.b37ed0be-b9b4-4de6-871e-3fc62b44240e.open-xchange@email.1und1.de>
On Thu, Aug 25, 2016 at 06:44:25AM +0200, Stefan Wahren wrote:
> Hi Fabio,
>
> > Fabio Estevam <festevam@gmail.com> hat am 25. August 2016 um 00:52
> > geschrieben:
> >
> >
> > Hi Stefan,
> >
> > On Tue, Aug 23, 2016 at 5:38 PM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> > > Hi,
> > >
> > > i'm using a iMX233-OLinuXino board and i get the following warning during
> > > boot
> > > with 4.8.0-rc2-next-20160819:
> > >
> > > [ 2.450000] ------------[ cut here ]------------
> > > [ 2.450000] WARNING: CPU: 0 PID: 42 at kernel/sched/core.c:7602
> > > __might_sleep+0x8c/0xa0
> > > [ 2.470000] do not call blocking ops when !TASK_RUNNING; state=1 set at
> > > [<c048f730>] dcp_chan_thread_aes+0x24/0x664
> >
> > Did you select any debug option to observe such messages?
>
> yes, it's CONFIG_DEBUG_ATOMIC_SLEEP. After a short web search i found this lwn
> article [1].
> I will try the suggested solution.
The problem is that the driver is setting the task state too early.
In fact, there is no reason why it should be using a kthread at all.
Someone should convert this over to a work queue.
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
* Re: Git bisected regression for ipsec/aead
From: Herbert Xu @ 2016-08-25 8:49 UTC (permalink / raw)
To: Sowmini Varadhan; +Cc: linux-crypto, joshua.a.hay, steffen.klassert
In-Reply-To: <20160819192124.GF25320@oracle.com>
On Fri, Aug 19, 2016 at 03:21:24PM -0400, Sowmini Varadhan wrote:
>
> Hi Herbert,
>
> In the process of testing ipsec I ran into panics (details below)
> with the algorithm
> "aead rfc4106(gcm(aes)) 0x1234567890123456789012345678901234567890 64"
>
> git-bisect analyzed this down to
>
> 7271b33cb87e80f3a416fb031ad3ca87f0bea80a is the first bad commit
> commit 7271b33cb87e80f3a416fb031ad3ca87f0bea80a
> Author: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Tue Jun 21 16:55:16 2016 +0800
>
> crypto: ghash-clmulni - Fix cryptd reordering
This bisection doesn't make much sense as this patch just causes
cryptd to be used a little more more frequently. But it does
point the finger at cryptd.
> [ 124.627594] BUG: unable to handle kernel paging request at 00000001000000c5
> [ 124.627612] ------------[ cut here ]------------
> [ 124.627620] WARNING: CPU: 3 PID: 0 at lib/list_debug.c:62 __list_del_entry+0x
> 86/0xd0
> [ 124.627621] list_del corruption. next->prev should be ffff88085cebd168, but w
> as 00000000ffffff8d
> [ 124.627622] Modules linked in:
So we have list corruption here, possibly caused by use-after-free.
I did spot one bug in the AEAD cryptd path where we end up using
the wrong tfm to track refcnt.
Does this patch help?
---8<---
Subject: crypto: cryptd - Use correct tfm object for AEAD tracking
The AEAD code path incorrectly uses the child tfm to track the
cryptd refcnt, and then potentially frees the child tfm.
Fixes: 81760ea6a95a ("crypto: cryptd - Add helpers to check...")
Reported-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/crypto/cryptd.c b/crypto/cryptd.c
index cf8037a..77207b4 100644
--- a/crypto/cryptd.c
+++ b/crypto/cryptd.c
@@ -733,13 +733,14 @@ static void cryptd_aead_crypt(struct aead_request *req,
rctx = aead_request_ctx(req);
compl = rctx->complete;
+ tfm = crypto_aead_reqtfm(req);
+
if (unlikely(err == -EINPROGRESS))
goto out;
aead_request_set_tfm(req, child);
err = crypt( req );
out:
- tfm = crypto_aead_reqtfm(req);
ctx = crypto_aead_ctx(tfm);
refcnt = atomic_read(&ctx->refcnt);
--
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: [PATCH -next] chcr: Fix non static symbol warning
From: Herbert Xu @ 2016-08-25 4:22 UTC (permalink / raw)
To: Wei Yongjun
Cc: David S. Miller, Hariprasad Shenai, Atul Gupta, Wei Yongjun,
linux-crypto
In-Reply-To: <06364d6b-bc23-26dd-df2f-9a7ec165674a@gmail.com>
On Wed, Aug 24, 2016 at 10:50:24PM +0800, Wei Yongjun wrote:
> Hi Herbert,
>
> On 08/24/2016 09:06 PM, Herbert Xu wrote:
> > On Mon, Aug 22, 2016 at 04:11:18PM +0000, Wei Yongjun wrote:
> >> From: Wei Yongjun <weiyongjun1@huawei.com>
> >>
> >> Fixes the following sparse warning:
> >>
> >> drivers/crypto/chelsio/chcr_algo.c:593:5: warning:
> >> symbol 'cxgb4_is_crypto_q_full' was not declared. Should it be static?
> >>
> >> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> > Please repost this to netdev as the chelsio patches were applied
> > in the net tree.
>
> This file only exists in net-next, not in netdev.
> http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/tree/drivers/crypto/chelsio/chcr_algo.c
> show not found.
I meant the netdev mailing list.
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
* Re: Problems with cbc(aes) and do_alg0test()
From: Stephan Mueller @ 2016-08-25 0:45 UTC (permalink / raw)
To: Michael McKay; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <1887F274-344C-4810-B2DD-DD6551CC4980@vmware.com>
Am Dienstag, 23. August 2016, 22:44:39 CEST schrieb Michael McKay:
Hi Michael,
> We are writing a device driver with kernel v3.14, and trying to encrypt some
> data using the Linux kernel algorithm “cbc(aes)”. Our /proc/crypto shows
> the following is loaded: driver “cbc-aes-aesni”, module “aesni_intel”, and
> type “ablkcipher”. But crypto_has_alg() gives us an error indicating the
> algo is not loaded. So knowing we have the algo string correct, most likely
> the problem is with the two other input variables: mask or type.
> Since AESNI is in use, we have a decent guess at the types by looking at the
> .cra_flags field in aensi-Intel_glue.c (which has
> “CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC”). That leaves just a few
> mask fields to guess at, but CRYPTO_ALG_TYPE_BLKCIPHER_MASK and
> CRYPTO_ALG_TYPE_MASK don’t work (not does OR’ing them together).
> What are the correct mask and type values for AESNI, and can you point me to
> any documentation? What else might we be doing wrong? Is /proc/crypto
> giving us relevant information? Thanks,
You can only use the cbc-aes-aesni code with the ablkcipher API. Using it with
the blkcipher API will not work.
So, a simple crypto_alloc_ablkcipher("cbc-aes-aesni", 0, 0) should work. If
not, what is the return code?
Ciao
Stephan
^ permalink raw reply
* [PATCH] softirq: fix tasklet_kill() and its users
From: Santosh Shilimkar @ 2016-08-25 1:52 UTC (permalink / raw)
To: linux-kernel
Cc: santosh.shilimkar, qat-linux, linux-crypto, netdev,
Santosh Shilimkar, Greg Kroah-Hartman, Andrew Morton,
Thomas Gleixner, Tadeusz Struk, Herbert Xu, David S. Miller,
Paul Bolle, Giovanni Cabiddu, Salvatore Benedetto, Karsten Keil,
Peter Zijlstra (Intel)
Semantically the expectation from the tasklet init/kill API
should be as below.
tasklet_init() == Init and Enable scheduling
tasklet_kill() == Disable scheduling and Destroy
tasklet_init() API exibit above behavior but not the
tasklet_kill(). The tasklet handler can still get scheduled
and run even after the tasklet_kill().
There are 2, 3 places where drivers are working around
this issue by calling tasklet_disable() which will add an
usecount and there by avoiding the handlers being called.
tasklet_enable/tasklet_disable is a pair API and expected
to be used together. Usage of tasklet_disable() *just* to
workround tasklet scheduling after kill is probably not the
correct and inteded use of the API as done the API.
We also happen to see similar issue where in shutdown path
the tasklet_handler was getting called even after the
tasklet_kill().
We fix this be making sure tasklet_kill() does right
thing and there by ensuring tasklet handler won't run after
tasklet_kil() with very simple change. Patch fixes the tasklet
code and also few drivers workarounds.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tadeusz Struk <tadeusz.struk@intel.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Paul Bolle <pebolle@tiscali.nl>
Cc: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Cc: Salvatore Benedetto <salvatore.benedetto@intel.com>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Signed-off-by: Santosh Shilimkar <ssantosh@kernel.org>
---
Removed RFC tag from last post and dropped atmel serial
driver which seems to have been fixed in 4.8
https://lkml.org/lkml/2016/8/7/7
drivers/crypto/qat/qat_common/adf_isr.c | 1 -
drivers/crypto/qat/qat_common/adf_sriov.c | 1 -
drivers/crypto/qat/qat_common/adf_vf_isr.c | 2 --
drivers/isdn/gigaset/interface.c | 1 -
kernel/softirq.c | 7 ++++---
5 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/adf_isr.c b/drivers/crypto/qat/qat_common/adf_isr.c
index 06d4901..fd5e900 100644
--- a/drivers/crypto/qat/qat_common/adf_isr.c
+++ b/drivers/crypto/qat/qat_common/adf_isr.c
@@ -296,7 +296,6 @@ static void adf_cleanup_bh(struct adf_accel_dev *accel_dev)
int i;
for (i = 0; i < hw_data->num_banks; i++) {
- tasklet_disable(&priv_data->banks[i].resp_handler);
tasklet_kill(&priv_data->banks[i].resp_handler);
}
}
diff --git a/drivers/crypto/qat/qat_common/adf_sriov.c b/drivers/crypto/qat/qat_common/adf_sriov.c
index 9320ae1..bc7c2fa 100644
--- a/drivers/crypto/qat/qat_common/adf_sriov.c
+++ b/drivers/crypto/qat/qat_common/adf_sriov.c
@@ -204,7 +204,6 @@ void adf_disable_sriov(struct adf_accel_dev *accel_dev)
}
for (i = 0, vf = accel_dev->pf.vf_info; i < totalvfs; i++, vf++) {
- tasklet_disable(&vf->vf2pf_bh_tasklet);
tasklet_kill(&vf->vf2pf_bh_tasklet);
mutex_destroy(&vf->pf2vf_lock);
}
diff --git a/drivers/crypto/qat/qat_common/adf_vf_isr.c b/drivers/crypto/qat/qat_common/adf_vf_isr.c
index bf99e11..6e38bff 100644
--- a/drivers/crypto/qat/qat_common/adf_vf_isr.c
+++ b/drivers/crypto/qat/qat_common/adf_vf_isr.c
@@ -191,7 +191,6 @@ static int adf_setup_pf2vf_bh(struct adf_accel_dev *accel_dev)
static void adf_cleanup_pf2vf_bh(struct adf_accel_dev *accel_dev)
{
- tasklet_disable(&accel_dev->vf.pf2vf_bh_tasklet);
tasklet_kill(&accel_dev->vf.pf2vf_bh_tasklet);
mutex_destroy(&accel_dev->vf.vf2pf_lock);
}
@@ -268,7 +267,6 @@ static void adf_cleanup_bh(struct adf_accel_dev *accel_dev)
{
struct adf_etr_data *priv_data = accel_dev->transport;
- tasklet_disable(&priv_data->banks[0].resp_handler);
tasklet_kill(&priv_data->banks[0].resp_handler);
}
diff --git a/drivers/isdn/gigaset/interface.c b/drivers/isdn/gigaset/interface.c
index 600c79b..2ce63b6 100644
--- a/drivers/isdn/gigaset/interface.c
+++ b/drivers/isdn/gigaset/interface.c
@@ -524,7 +524,6 @@ void gigaset_if_free(struct cardstate *cs)
if (!drv->have_tty)
return;
- tasklet_disable(&cs->if_wake_tasklet);
tasklet_kill(&cs->if_wake_tasklet);
cs->tty_dev = NULL;
tty_unregister_device(drv->tty, cs->minor_index);
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 17caf4b..21397eb 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -498,7 +498,7 @@ static void tasklet_action(struct softirq_action *a)
list = list->next;
if (tasklet_trylock(t)) {
- if (!atomic_read(&t->count)) {
+ if (atomic_read(&t->count) == 1) {
if (!test_and_clear_bit(TASKLET_STATE_SCHED,
&t->state))
BUG();
@@ -534,7 +534,7 @@ static void tasklet_hi_action(struct softirq_action *a)
list = list->next;
if (tasklet_trylock(t)) {
- if (!atomic_read(&t->count)) {
+ if (atomic_read(&t->count) == 1) {
if (!test_and_clear_bit(TASKLET_STATE_SCHED,
&t->state))
BUG();
@@ -559,7 +559,7 @@ void tasklet_init(struct tasklet_struct *t,
{
t->next = NULL;
t->state = 0;
- atomic_set(&t->count, 0);
+ atomic_set(&t->count, 1);
t->func = func;
t->data = data;
}
@@ -576,6 +576,7 @@ void tasklet_kill(struct tasklet_struct *t)
} while (test_bit(TASKLET_STATE_SCHED, &t->state));
}
tasklet_unlock_wait(t);
+ atomic_dec(&t->count);
clear_bit(TASKLET_STATE_SCHED, &t->state);
}
EXPORT_SYMBOL(tasklet_kill);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] crypto: vmx - fix null dereference in p8_aes_xts_crypt
From: Herbert Xu @ 2016-08-25 5:56 UTC (permalink / raw)
To: Li Zhong; +Cc: linux-crypto, leosilva, pfsmorigo
In-Reply-To: <1472024080.3313.20.camel@TP420>
On Wed, Aug 24, 2016 at 03:34:40PM +0800, Li Zhong wrote:
> walk.iv is not assigned a value in blkcipher_walk_init. It makes iv uninitialized.
> It is possibly a null value(as shown below), which is then used by aes_p8_encrypt.
>
> This patch moves iv = walk.iv after blkcipher_walk_virt, in which walk.iv is set.
>
> [17856.268050] Unable to handle kernel paging request for data at address 0x00000000
> [17856.268212] Faulting instruction address: 0xd000000002ff04bc
> 7:mon> t
> [link register ] d000000002ff47b8 p8_aes_xts_crypt+0x168/0x2a0 [vmx_crypto] (938)
> [c000000013b77960] d000000002ff4794 p8_aes_xts_crypt+0x144/0x2a0 [vmx_crypto] (unreliable)
> [c000000013b77a70] c000000000544d64 skcipher_decrypt_blkcipher+0x64/0x80
> [c000000013b77ac0] d000000003c0175c crypt_convert+0x53c/0x620 [dm_crypt]
> [c000000013b77ba0] d000000003c043fc kcryptd_crypt+0x3cc/0x440 [dm_crypt]
> [c000000013b77c50] c0000000000f3070 process_one_work+0x1e0/0x590
> [c000000013b77ce0] c0000000000f34c8 worker_thread+0xa8/0x660
> [c000000013b77d80] c0000000000fc0b0 kthread+0x110/0x130
> [c000000013b77e30] c0000000000098f0 ret_from_kernel_thread+0x5c/0x6c
>
> Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Patch applied. 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: mxs-dcp: do not call blocking ops when !TASK_RUNNING; state=1
From: Stefan Wahren @ 2016-08-25 4:44 UTC (permalink / raw)
To: Fabio Estevam; +Cc: linux-crypto, Herbert Xu, Fabio Estevam, Marek Vašut
In-Reply-To: <CAOMZO5DWBoVYfK67faj_i=YVUGE3aODCs0-s3-rbDjy7Y3ckFg@mail.gmail.com>
Hi Fabio,
> Fabio Estevam <festevam@gmail.com> hat am 25. August 2016 um 00:52
> geschrieben:
>
>
> Hi Stefan,
>
> On Tue, Aug 23, 2016 at 5:38 PM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> > Hi,
> >
> > i'm using a iMX233-OLinuXino board and i get the following warning during
> > boot
> > with 4.8.0-rc2-next-20160819:
> >
> > [ 2.450000] ------------[ cut here ]------------
> > [ 2.450000] WARNING: CPU: 0 PID: 42 at kernel/sched/core.c:7602
> > __might_sleep+0x8c/0xa0
> > [ 2.470000] do not call blocking ops when !TASK_RUNNING; state=1 set at
> > [<c048f730>] dcp_chan_thread_aes+0x24/0x664
>
> Did you select any debug option to observe such messages?
yes, it's CONFIG_DEBUG_ATOMIC_SLEEP. After a short web search i found this lwn
article [1].
I will try the suggested solution.
Regards
Stefan
[1] - https://lwn.net/Articles/628628/
>
> The kernelci boot log does not show this problem on a imx23-olinuxino
> running linux-next:
> https://storage.kernelci.org/next/next-20160824/arm-mxs_defconfig/lab-pengutronix/boot-imx23-olinuxino.html
>
> We still have the errors below:
>
> [ 4.400000] mxs-dcp 80028000.dcp: Failed to register sha1 hash!
> [ 4.410000] mxs-dcp: probe of 80028000.dcp failed with error -22
>
> ,but that's a different issue.
>
> Regards,
>
> Fabio Estevam
^ permalink raw reply
* Re: [PATCH 3/5] hwrng: amd: Be consitent with the driver name
From: Herbert Xu @ 2016-08-25 4:19 UTC (permalink / raw)
To: LABBE Corentin; +Cc: mpm, linux-crypto, linux-kernel
In-Reply-To: <20160824135122.GC29212@Red>
On Wed, Aug 24, 2016 at 03:51:22PM +0200, LABBE Corentin wrote:
> On Wed, Aug 24, 2016 at 06:58:11PM +0800, Herbert Xu wrote:
> > On Fri, Aug 19, 2016 at 03:42:55PM +0200, LABBE Corentin wrote:
> > > The driver name is displayed each time differently.
> > > This patch make use of the same name everywhere.
> > >
> > > Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
> > > ---
> > > drivers/char/hw_random/amd-rng.c | 13 ++++++-------
> > > 1 file changed, 6 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
> > > index d0042f5..d0a806a 100644
> > > --- a/drivers/char/hw_random/amd-rng.c
> > > +++ b/drivers/char/hw_random/amd-rng.c
> > > @@ -31,7 +31,7 @@
> > > #include <linux/delay.h>
> > > #include <asm/io.h>
> > >
> > > -#define PFX KBUILD_MODNAME ": "
> > > +#define DRV_NAME "AMD768-HWRNG"
> > >
> > > /*
> > > * Data for PCI driver interface
> > > @@ -98,7 +98,7 @@ static void amd_rng_cleanup(struct hwrng *rng)
> > > }
> > >
> > > static struct hwrng amd_rng = {
> > > - .name = "amd",
> > > + .name = DRV_NAME,
> >
> > Hmm, this changes a sysfs-exported name which has the potential
> > to break user-space. So I think you'd need to a stronger argument
> > to do it other than just cleaning it up.
> >
>
> amd is really really too generic.
Well this would have been a good reason to change it before it
went into the kernel.
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
* Re: [PATCH v2 2/2] HWRNG: thunderx: Add Cavium HWRNG driver for ThunderX SoC.
From: David Daney @ 2016-08-24 23:07 UTC (permalink / raw)
To: Corentin LABBE
Cc: Omer Khaliq, linux-kernel, linux-pci, linux-crypto,
linux-arm-kernel, bhelgaas, mpm, herbert, Ananth.Jasty,
David.Daney
In-Reply-To: <874d0bce-cf9b-8772-5af4-ec3844b3b255@gmail.com>
On 08/23/2016 10:46 PM, Corentin LABBE wrote:
> Hello
>
>> +/* Read data from the RNG unit */
>> +static int cavium_rng_read(struct hwrng *rng, void *dat, size_t max, bool wait)
>> +{
>> + struct cavium_rng *p = container_of(rng, struct cavium_rng, ops);
>> + unsigned int size = max;
>> +
>> + while (size >= 8) {
>> + *((u64 *)dat) = readq(p->result);
>> + size -= 8;
>> + dat += 8;
>> + }
>
> I think you could use readsq()
> This will increase throughput
If you look at the implementation of readsq(), you will see that it is a
similar loop. Since the overhead is primarily I/O latency from the RNG
hardware, the throughput cannot really be changed with micro
optimizations to this simple loop.
Also, on big-endian kernels, it appears that a loop of readq() and
readsq() will give different results as readq will byte swap the result
and readsq does not. Since this is a RNG, the byte swapping is not
important, but it is a difference.
Because of this, I think it should be acceptable to stick with the loop
we currently have.
If the hwrng maintainers want to change the loop, to a readsq(), we
might investigate this more.
Thanks,
David Daney
^ permalink raw reply
* Re: crypto: mxs-dcp: do not call blocking ops when !TASK_RUNNING; state=1
From: Fabio Estevam @ 2016-08-24 22:52 UTC (permalink / raw)
To: Stefan Wahren; +Cc: Herbert Xu, linux-crypto, Fabio Estevam, Marek Vašut
In-Reply-To: <140047983.403523.225ddbfe-fd96-4f9b-a2b9-e0173af882ba.open-xchange@email.1und1.de>
Hi Stefan,
On Tue, Aug 23, 2016 at 5:38 PM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> Hi,
>
> i'm using a iMX233-OLinuXino board and i get the following warning during boot
> with 4.8.0-rc2-next-20160819:
>
> [ 2.450000] ------------[ cut here ]------------
> [ 2.450000] WARNING: CPU: 0 PID: 42 at kernel/sched/core.c:7602
> __might_sleep+0x8c/0xa0
> [ 2.470000] do not call blocking ops when !TASK_RUNNING; state=1 set at
> [<c048f730>] dcp_chan_thread_aes+0x24/0x664
Did you select any debug option to observe such messages?
The kernelci boot log does not show this problem on a imx23-olinuxino
running linux-next:
https://storage.kernelci.org/next/next-20160824/arm-mxs_defconfig/lab-pengutronix/boot-imx23-olinuxino.html
We still have the errors below:
[ 4.400000] mxs-dcp 80028000.dcp: Failed to register sha1 hash!
[ 4.410000] mxs-dcp: probe of 80028000.dcp failed with error -22
,but that's a different issue.
Regards,
Fabio Estevam
^ permalink raw reply
* Re: [PATCH v2 1/2] PCI: quirk fixup for cavium invalid sriov link value.
From: Bjorn Helgaas @ 2016-08-24 16:47 UTC (permalink / raw)
To: Omer Khaliq
Cc: linux-kernel, linux-pci, linux-crypto, linux-arm-kernel, bhelgaas,
mpm, herbert, Ananth.Jasty, David.Daney, clabbe.montjoie
In-Reply-To: <1471994835-2423-2-git-send-email-okhaliq@caviumnetworks.com>
On Tue, Aug 23, 2016 at 04:27:14PM -0700, Omer Khaliq wrote:
> From: Ananth Jasty <Ananth.Jasty@cavium.com>
>
> Cavium cn88xx hardware presents an incorrect SR-IOV Function
> Dependency Link, add a fixup quirk for the affected devices.
>
> Acked-by: David Daney <david.daney@cavium.com>
> Signed-off-by: Ananth Jasty <Ananth.Jasty@cavium.com>
> Signed-off-by: Omer Khaliq <okhaliq@caviumnetworks.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
If you update this patch for any reason, please update the subject
like this:
-PCI: quirk fixup for cavium invalid sriov link value.
+PCI: Fix incorrect Cavium cn8xx SR-IOV Function Dependency Link
This will make "git log --oneline drivers/pci/quirks.c" show more
useful information and look more consistent.
I assume somebody else will merge this patch along with your HWRNG
driver.
> ---
> drivers/pci/quirks.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 37ff015..5980aae 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -834,6 +834,17 @@ 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
> +
> +static void quirk_cavium_sriov_rnm_link(struct pci_dev *dev)
> +{
> + /* Fix for improper SRIOV configuration on Cavium cn88xx RNM device */
> + if (dev->subsystem_device == 0xa118)
> + dev->sriov->link = dev->devfn;
> +}
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CAVIUM, 0xa018, quirk_cavium_sriov_rnm_link);
> +#endif
> +
> /*
> * Some settings of MMRBC can lead to data corruption so block changes.
> * See AMD 8131 HyperTransport PCI-X Tunnel Revision Guide
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next] chcr: Fix non static symbol warning
From: Wei Yongjun @ 2016-08-24 14:50 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, Hariprasad Shenai, Atul Gupta, Wei Yongjun,
linux-crypto
In-Reply-To: <20160824130651.GB2120@gondor.apana.org.au>
Hi Herbert,
On 08/24/2016 09:06 PM, Herbert Xu wrote:
> On Mon, Aug 22, 2016 at 04:11:18PM +0000, Wei Yongjun wrote:
>> From: Wei Yongjun <weiyongjun1@huawei.com>
>>
>> Fixes the following sparse warning:
>>
>> drivers/crypto/chelsio/chcr_algo.c:593:5: warning:
>> symbol 'cxgb4_is_crypto_q_full' was not declared. Should it be static?
>>
>> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> Please repost this to netdev as the chelsio patches were applied
> in the net tree.
This file only exists in net-next, not in netdev.
http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/tree/drivers/crypto/chelsio/chcr_algo.c
show not found.
Regards,
Wei Yongjun
^ permalink raw reply
* Re: [PATCH] crypto: FIPS - allow RSA keys >= 2048 bits
From: Herbert Xu @ 2016-08-24 13:18 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto
In-Reply-To: <3300015.Y5nlQbUkhj@positron.chronox.de>
On Tue, Aug 23, 2016 at 10:09:32AM +0200, Stephan Mueller wrote:
> With a public notification, NIST now allows the use of RSA keys with a
> modulus >= 2048 bits. The new rule allows any modulus size >= 2048 bits
> provided that either 2048 or 3072 bits are supported at least so that
> the entire RSA implementation can be CAVS tested.
>
> This patch fixes the inability to boot the kernel in FIPS mode, because
> certs/x509.genkey defines a 4096 bit RSA key per default. This key causes
> the RSA signature verification to fail in FIPS mode without the patch
> below.
>
> Signed-off-by: Stephan Mueller <smueller@chronox.de>
Patch applied. 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: [PATCH -next] chcr: Fix non static symbol warning
From: Herbert Xu @ 2016-08-24 13:06 UTC (permalink / raw)
To: Wei Yongjun
Cc: David S. Miller, Hariprasad Shenai, Atul Gupta, Wei Yongjun,
linux-crypto
In-Reply-To: <1471882278-25777-1-git-send-email-weiyj.lk@gmail.com>
On Mon, Aug 22, 2016 at 04:11:18PM +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fixes the following sparse warning:
>
> drivers/crypto/chelsio/chcr_algo.c:593:5: warning:
> symbol 'cxgb4_is_crypto_q_full' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Please repost this to netdev as the chelsio patches were applied
in the net tree.
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: [PATCH 3/5] hwrng: amd: Be consitent with the driver name
From: LABBE Corentin @ 2016-08-24 13:51 UTC (permalink / raw)
To: Herbert Xu; +Cc: mpm, linux-crypto, linux-kernel
In-Reply-To: <20160824105811.GA2120@gondor.apana.org.au>
On Wed, Aug 24, 2016 at 06:58:11PM +0800, Herbert Xu wrote:
> On Fri, Aug 19, 2016 at 03:42:55PM +0200, LABBE Corentin wrote:
> > The driver name is displayed each time differently.
> > This patch make use of the same name everywhere.
> >
> > Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
> > ---
> > drivers/char/hw_random/amd-rng.c | 13 ++++++-------
> > 1 file changed, 6 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
> > index d0042f5..d0a806a 100644
> > --- a/drivers/char/hw_random/amd-rng.c
> > +++ b/drivers/char/hw_random/amd-rng.c
> > @@ -31,7 +31,7 @@
> > #include <linux/delay.h>
> > #include <asm/io.h>
> >
> > -#define PFX KBUILD_MODNAME ": "
> > +#define DRV_NAME "AMD768-HWRNG"
> >
> > /*
> > * Data for PCI driver interface
> > @@ -98,7 +98,7 @@ static void amd_rng_cleanup(struct hwrng *rng)
> > }
> >
> > static struct hwrng amd_rng = {
> > - .name = "amd",
> > + .name = DRV_NAME,
>
> Hmm, this changes a sysfs-exported name which has the potential
> to break user-space. So I think you'd need to a stronger argument
> to do it other than just cleaning it up.
>
amd is really really too generic.
But if you still NACK that (and I understand perfectly why), I will update my series.
Regards
^ permalink raw reply
* Re: [PATCH] crypto: rockchip - use devm_add_action_or_reset()
From: Herbert Xu @ 2016-08-24 13:19 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Heiko Stuebner, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1471964334-27060-1-git-send-email-sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Aug 23, 2016 at 08:28:54PM +0530, Sudip Mukherjee wrote:
> If devm_add_action() fails we are explicitly calling the cleanup to free
> the resources allocated. Lets use the helper devm_add_action_or_reset()
> and return directly in case of error, as we know that the cleanup function
> has been already called by the helper if there was any error.
>
> Signed-off-by: Sudip Mukherjee <sudip.mukherjee-4yDnlxn2s6sWdaTGBSpHTA@public.gmane.org>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: mxc-scc - check clk_prepare_enable() error
From: Herbert Xu @ 2016-08-24 13:18 UTC (permalink / raw)
To: Fabio Estevam; +Cc: s.trumtrar, linux-crypto, Fabio Estevam
In-Reply-To: <1471833447-11446-1-git-send-email-festevam@gmail.com>
On Sun, Aug 21, 2016 at 11:37:27PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> clk_prepare_enable() may fail, so we should better check its return
> value and propagate it in the case of failure.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Patch applied. 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: [PATCH] hw_random: omap3-rom-rng.c: Remove obsoleted functions
From: Herbert Xu @ 2016-08-24 13:17 UTC (permalink / raw)
To: PrasannaKumar Muralidharan; +Cc: linux-crypto, aaro.koskinen, mpm, linux-kernel
In-Reply-To: <1471708866-1423-1-git-send-email-prasannatsmkumar@gmail.com>
On Sat, Aug 20, 2016 at 09:31:06PM +0530, PrasannaKumar Muralidharan wrote:
> Remove omap3_rom_rng_data_present method as it was returning 1 always.
> Use .read callback instead of .data_read callback. This avoids use of
> obsolete callbacks.
>
> This patch is not tested with hardware as I don't have access to it.
>
> Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Patch applied. 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: [PATCH] crypto/xor: skip speed test if the xor function is selected automatically
From: Herbert Xu @ 2016-08-24 13:17 UTC (permalink / raw)
To: Martin Schwidefsky; +Cc: davem, linux-crypto, schwidefsky
In-Reply-To: <1471609170-18816-1-git-send-email-schwidefsky@de.ibm.com>
Martin Schwidefsky <schwidefsky@de.ibm.com> wrote:
> If the architecture selected the xor function with XOR_SELECT_TEMPLATE
> the speed result of the do_xor_speed benchmark is of limited value.
> The speed measurement increases the bootup time a little, which can
> makes a difference for kernels used in container like virtual machines.
>
> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Patch applied. 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: [PATCH -next] crypto: drbg - fix error return code
From: Herbert Xu @ 2016-08-24 13:15 UTC (permalink / raw)
To: Wei Yongjun; +Cc: Stephan Mueller, linux-crypto
In-Reply-To: <1471705611-19309-1-git-send-email-weiyj.lk@gmail.com>
On Sat, Aug 20, 2016 at 03:06:51PM +0000, Wei Yongjun wrote:
> Fix to return a negative error code from the error handling
> case instead of 0.
>
> Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com>
Patch applied. 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: [PATCH -next v2] crypto: sun4i-ss - fix missing unlock on error in sun4i_hash()
From: Herbert Xu @ 2016-08-24 13:14 UTC (permalink / raw)
To: Wei Yongjun
Cc: Corentin Labbe, David S. Miller, Maxime Ripard, Chen-Yu Tsai,
linux-crypto, linux-arm-kernel
In-Reply-To: <1471690133-24396-1-git-send-email-weiyj.lk@gmail.com>
On Sat, Aug 20, 2016 at 10:48:53AM +0000, Wei Yongjun wrote:
> Add the missing unlock before return from function sun4i_hash()
> in the error handling case.
>
> Fixes: 477d9b2e591b ("crypto: sun4i-ss - unify update/final function")
> Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com>
Patch applied. 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
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