* sha1_mb broken
From: Stephan Mueller @ 2016-08-26 1:15 UTC (permalink / raw)
To: linux-crypto
Hi,
I tried to execute tests with sha1_mb.
The execution simply stalls when invoking a digest operation -- i.e. the
digest operation does not finish. After some time after invoking the hashing
operation, the following log appears (note, the kccavs_* functions are my test
code; that test code works perfectly well with all other hash
implementations):
[ 140.426026] INFO: rcu_sched detected stalls on CPUs/tasks:
[ 140.426719] 2-...: (1 GPs behind) idle=9c3/140000000000000/0
softirq=2680/2707 fqs=14762
[ 140.427024] (detected by 0, t=60002 jiffies, g=655, c=654, q=35)
[ 140.427024] Task dump for CPU 2:
[ 140.427024] cavs_driver R running task 0 945 862
0x00000008
[ 140.427024] ffffffff9b78d965 ffffa527b8bfa640 ffffa527bb505940
ffffa52775c20c50
[ 140.427024] ffffa527bc300000 ffffa527b93d2a80 ffffa527bb857e00
ffffa527bc2ffd78
[ 140.427024] ffffa527b93d2ac8 ffffa527bc2ffcc0 ffffffff9b78dfc8
ffffa527bc2ffd70
[ 140.427024] Call Trace:
[ 140.427024] [<ffffffff9b78d965>] ? __schedule+0x245/0x690
[ 140.427024] [<ffffffff9b78dfc8>] ? preempt_schedule_common+0x18/0x30
[ 140.427024] [<ffffffff9b791a68>] ? _raw_spin_lock_irq+0x28/0x30
[ 140.427024] [<ffffffff9b78ed98>] ? wait_for_completion_interruptible
+0x28/0x180
[ 140.427024] [<ffffffffc028541c>] ? sha1_mb_async_digest+0x6c/0x70
[sha1_mb]
[ 140.427024] [<ffffffff9b3b1129>] ? crypto_ahash_op+0x29/0x70
[ 140.427024] [<ffffffffc0270148>] ? kccavs_test_ahash+0x198/0x2b0
[kcapi_cavs]
[ 140.427024] [<ffffffffc026e20a>] ? kccavs_data_read+0xda/0x160
[kcapi_cavs]
[ 140.427024] [<ffffffff9b370964>] ? full_proxy_read+0x54/0x90
[ 140.427024] [<ffffffff9b208088>] ? __vfs_read+0x28/0x110
[ 140.427024] [<ffffffff9b38a2c0>] ? security_file_permission+0xa0/0xc0
[ 140.427024] [<ffffffff9b20850e>] ? rw_verify_area+0x4e/0xb0
[ 140.427024] [<ffffffff9b208606>] ? vfs_read+0x96/0x130
[ 140.427024] [<ffffffff9b2099f6>] ? SyS_read+0x46/0xa0
[ 140.427024] [<ffffffff9b791cb6>] ? entry_SYSCALL_64_fastpath+0x1e/0xa8
Ciao
Stephan
^ permalink raw reply
* Re: Entropy sources
From: H. Peter Anvin @ 2016-08-26 0:20 UTC (permalink / raw)
To: Sandy Harris; +Cc: Jeffrey Walton, linux-crypto, LKML, Theodore Ts'o
In-Reply-To: <CACXcFmk8DWOxu+=J3i06bSvEW3tp_O2cxHLGdCuXTJROZ=hysA@mail.gmail.com>
On 08/25/16 16:35, Sandy Harris wrote:
> On Thu, Aug 25, 2016 at 5:30 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>
>> The network stack is a good source of entropy, *once it is online*.
>> However, the most serious case is while the machine is still booting,
>> when the network will not have enabled yet.
>>
>> -hpa
>
> One possible solution is at:
> https://github.com/sandy-harris/maxwell
>
> A small (< 700 lines) daemon that gets entropy from timer imprecision
> and variations in time for arithmetic (cache misses, interrupts, etc.)
> and pumps it into /dev/random. Make it the first userspace program
> started and all should be covered. Directory above includes a PDF doc
> with detailed rationale and some discussion of alternate solutions.
>
> Of course if you are dealing with a system-on-a-chip or low-end
> embedded CPU & the timer is really inadequate, this will not work
> well. Conceivably well enough, but we could not know that without
> detailed analysis for each chip in question.
>
A lot of this is exactly the same thing /dev/random already does in
kernel space. I have already in the past expressed skepticism toward
this approach, because a lot of the analysis done has simply been bogus.
-hpa
^ permalink raw reply
* Re: Entropy sources (was: /dev/random - a new approach)
From: Sandy Harris @ 2016-08-25 23:35 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Jeffrey Walton, linux-crypto, LKML, Theodore Ts'o
In-Reply-To: <f57f675f-a914-4c72-f32a-4091e547905f@zytor.com>
On Thu, Aug 25, 2016 at 5:30 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> The network stack is a good source of entropy, *once it is online*.
> However, the most serious case is while the machine is still booting,
> when the network will not have enabled yet.
>
> -hpa
One possible solution is at:
https://github.com/sandy-harris/maxwell
A small (< 700 lines) daemon that gets entropy from timer imprecision
and variations in time for arithmetic (cache misses, interrupts, etc.)
and pumps it into /dev/random. Make it the first userspace program
started and all should be covered. Directory above includes a PDF doc
with detailed rationale and some discussion of alternate solutions.
Of course if you are dealing with a system-on-a-chip or low-end
embedded CPU & the timer is really inadequate, this will not work
well. Conceivably well enough, but we could not know that without
detailed analysis for each chip in question.
^ permalink raw reply
* Re: Entropy sources (was: /dev/random - a new approach)
From: H. Peter Anvin @ 2016-08-25 21:30 UTC (permalink / raw)
To: noloader; +Cc: linux-crypto, linux-kernel
In-Reply-To: <CAH8yC8nZyAZT2OiRXgT=CBfQ4RSw-E1uZaQvKuQZ9BDYuPmGvA@mail.gmail.com>
On 08/20/16 22:37, Jeffrey Walton wrote:
>>
>> The biggest problem there is that the timer interrupt adds *no* entropy
>> unless there is a source of asynchronicity in the system. On PCs,
>> traditionally the timer has been run from a completely different crystal
>> (14.31818 MHz) than the CPU, which is the ideal situation, but if they
>> are run off the same crystal and run in lockstep, there is very little
>> if anything there. On some systems, the timer may even *be* the only
>> source of time, and the entropy truly is zero.
>
> It seems like a networked computer should have an abundance on entropy
> available from the network stack. Every common case I can come up with
> includes a networked computer. If a handheld is outside of coverage,
> then it probably does not have the randomness demands because it can't
> communicate (i.e., TCP sequence numbers, key agreement, etc).
>
> In fact, there are at least two papers that use bits from the network stack:
>
The network stack is a good source of entropy, *once it is online*.
However, the most serious case is while the machine is still booting,
when the network will not have enabled yet.
-hpa
^ permalink raw reply
* Re: Git bisected regression for ipsec/aead
From: Sowmini Varadhan @ 2016-08-25 15:45 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, joshua.a.hay, steffen.klassert
In-Reply-To: <20160825084951.GA11496@gondor.apana.org.au>
On (08/25/16 16:49), Herbert Xu wrote:
> 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.
:
> 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?
Unfortunately no, I still see the panic.
--Sowmini
^ permalink raw reply
* Re: [PATCH v2 5/5] hwrng: amd: Rework of the amd768-hwrng driver
From: Jason Cooper @ 2016-08-25 14:56 UTC (permalink / raw)
To: LABBE Corentin; +Cc: mpm, herbert, linux-crypto, linux-kernel
In-Reply-To: <1472127395-32195-6-git-send-email-clabbe.montjoie@gmail.com>
Hi Corentin,
On Thu, Aug 25, 2016 at 02:16:35PM +0200, LABBE Corentin wrote:
> This patch convert the hwrng interface used by amd768-rng to its new API
> by replacing data_read()/data_present() by read().
>
> Furthermore, Instead of having two global variable, it's better to use a
> private struct. This will permit to remove amd_pdev variable.
>
> Finally, Instead of accessing hw directly via pmbase, it's better to
> access after ioport_map() via ioread32/iowrite32.
I was going to recommend a better $subject line, but now I see why it's
vague. :( I would recommend breaking this patch up into three:
hwrng: amd - Access hardware via ioread32/iowrite32
hwrng: amd - Replace global variable with private struct
hwrng: amd - Convert to new hwrng read() API
thx,
Jason.
^ permalink raw reply
* Re: [PATCH] hwrng: pasemi_rng.c: Migrate to managed API
From: PrasannaKumar Muralidharan @ 2016-08-25 13:25 UTC (permalink / raw)
To: LABBE Corentin
Cc: olof, mpm, Herbert Xu, linuxppc-dev, linux-crypto, linux-kernel
In-Reply-To: <20160825121546.GA25650@Red>
> 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 ?
I wanted to use devm_ioremap_resource but could not find DT entry
required for this driver in any of the .dts files. So did not change
that. I could not find any dts/dtsi for this platform. So I assume
that the dtb is not present in the kernel, dtb is supplied by the
bootloader. I may be wrong in this. Can anyone confirm this?
Regards,
PrasannaKumar
^ permalink raw reply
* [PATCH] crypto: FIPS - allow tests to be disabled in FIPS mode
From: Stephan Mueller @ 2016-08-25 13:15 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, Tapas Sarangi
In FIPS mode, additional restrictions may apply. If these restrictions
are violated, the kernel will panic(). This patch allows test vectors
for symmetric ciphers to be marked as to be skipped in FIPS mode.
Together with the patch, the XTS test vectors where the AES key is
identical to the tweak key is disabled in FIPS mode. This test vector
violates the FIPS requirement that both keys must be different.
Reported-by: Tapas Sarangi <TSarangi@trustwave.com>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
crypto/testmgr.c | 9 +++++++++
crypto/testmgr.h | 4 ++++
2 files changed, 13 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index c2a8bd3..0b01c3d 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1008,6 +1008,9 @@ static int test_cipher(struct crypto_cipher *tfm, int enc,
if (template[i].np)
continue;
+ if (fips_enabled && template[i].fips_skip)
+ continue;
+
j++;
ret = -EINVAL;
@@ -1112,6 +1115,9 @@ static int __test_skcipher(struct crypto_skcipher *tfm, int enc,
if (template[i].np && !template[i].also_non_np)
continue;
+ if (fips_enabled && template[i].fips_skip)
+ continue;
+
if (template[i].iv)
memcpy(iv, template[i].iv, ivsize);
else
@@ -1198,6 +1204,9 @@ static int __test_skcipher(struct crypto_skcipher *tfm, int enc,
if (!template[i].np)
continue;
+ if (fips_enabled && template[i].fips_skip)
+ continue;
+
if (template[i].iv)
memcpy(iv, template[i].iv, ivsize);
else
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index acb6bbf..e64a4ef 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -59,6 +59,7 @@ struct hash_testvec {
* @tap: How to distribute data in @np SGs
* @also_non_np: if set to 1, the test will be also done without
* splitting data in @np SGs
+ * @fips_skip: Skip the test vector in FIPS mode
*/
struct cipher_testvec {
@@ -75,6 +76,7 @@ struct cipher_testvec {
unsigned char klen;
unsigned short ilen;
unsigned short rlen;
+ bool fips_skip;
};
struct aead_testvec {
@@ -18224,6 +18226,7 @@ static struct cipher_testvec aes_xts_enc_tv_template[] = {
"\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00",
.klen = 32,
+ .fips_skip = 1,
.iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00",
.input = "\x00\x00\x00\x00\x00\x00\x00\x00"
@@ -18566,6 +18569,7 @@ static struct cipher_testvec aes_xts_dec_tv_template[] = {
"\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00",
.klen = 32,
+ .fips_skip = 1,
.iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00",
.input = "\x91\x7c\xf6\x9e\xbd\x68\xb2\xec"
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/5] hwrng: amd: use the BIT macro
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>
This patch add usage of the BIT() macro
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
drivers/char/hw_random/amd-rng.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index 45b7965..d0042f5 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -78,11 +78,11 @@ static int amd_rng_init(struct hwrng *rng)
u8 rnen;
pci_read_config_byte(amd_pdev, 0x40, &rnen);
- rnen |= (1 << 7); /* RNG on */
+ rnen |= BIT(7); /* RNG on */
pci_write_config_byte(amd_pdev, 0x40, rnen);
pci_read_config_byte(amd_pdev, 0x41, &rnen);
- rnen |= (1 << 7); /* PMIO enable */
+ rnen |= BIT(7); /* PMIO enable */
pci_write_config_byte(amd_pdev, 0x41, rnen);
return 0;
@@ -93,7 +93,7 @@ static void amd_rng_cleanup(struct hwrng *rng)
u8 rnen;
pci_read_config_byte(amd_pdev, 0x40, &rnen);
- rnen &= ~(1 << 7); /* RNG off */
+ rnen &= ~BIT(7); /* RNG off */
pci_write_config_byte(amd_pdev, 0x40, rnen);
}
--
2.7.3
^ permalink raw reply related
* [PATCH v2 3/5] hwrng: amd: Be consitent with the driver name
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>
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 | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index d0042f5..93157af 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
@@ -128,8 +128,8 @@ found:
pmbase &= 0x0000FF00;
if (pmbase == 0)
goto out;
- if (!request_region(pmbase + 0xF0, 8, "AMD HWRNG")) {
- dev_err(&pdev->dev, "AMD HWRNG region 0x%x already in use!\n",
+ if (!request_region(pmbase + 0xF0, 8, DRV_NAME)) {
+ dev_err(&pdev->dev, DRV_NAME " region 0x%x already in use!\n",
pmbase + 0xF0);
err = -EBUSY;
goto out;
@@ -137,11 +137,10 @@ found:
amd_rng.priv = (unsigned long)pmbase;
amd_pdev = pdev;
- pr_info("AMD768 RNG detected\n");
+ pr_info(DRV_NAME " detected\n");
err = hwrng_register(&amd_rng);
if (err) {
- pr_err(PFX "RNG registering failed (%d)\n",
- err);
+ pr_err(DRV_NAME " registering failed (%d)\n", err);
release_region(pmbase + 0xF0, 8);
goto out;
}
--
2.7.3
^ permalink raw reply related
* [PATCH v2 5/5] hwrng: amd: Rework of the amd768-hwrng driver
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>
This patch convert the hwrng interface used by amd768-rng to its new API
by replacing data_read()/data_present() by read().
Furthermore, Instead of having two global variable, it's better to use a
private struct. This will permit to remove amd_pdev variable.
Finally, Instead of accessing hw directly via pmbase, it's better to
access after ioport_map() via ioread32/iowrite32.
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
drivers/char/hw_random/amd-rng.c | 151 +++++++++++++++++++++++++--------------
1 file changed, 99 insertions(+), 52 deletions(-)
diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index de82fe3..785bc3e 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -32,6 +32,14 @@
#define DRV_NAME "AMD768-HWRNG"
+#define GEN_CFG_REG1 0x40
+#define GEN_CFG_REG2 0x41
+#define SMIO_SPACEPTR 0x58
+#define RNGDATA 0x00
+#define RNGDONE 0x04
+#define PMBASE_OFFSET 0xF0
+#define PMBASE_SIZE 8
+
/*
* Data for PCI driver interface
*
@@ -39,6 +47,7 @@
* PCI ids via MODULE_DEVICE_TABLE. We do not actually
* register a pci_driver, because someone else might one day
* want to register another driver on the same PCI id.
+ * Like i2c-amd756
*/
static const struct pci_device_id pci_tbl[] = {
{ PCI_VDEVICE(AMD, 0x7443), 0, },
@@ -47,112 +56,150 @@ static const struct pci_device_id pci_tbl[] = {
};
MODULE_DEVICE_TABLE(pci, pci_tbl);
-static struct pci_dev *amd_pdev;
+struct amd768_priv {
+ void __iomem *iobase;
+ struct pci_dev *pcidev;
+ u32 pmbase;
+};
-static int amd_rng_data_present(struct hwrng *rng, int wait)
+static int amd_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
{
- u32 pmbase = (u32)rng->priv;
- int data, i;
-
- for (i = 0; i < 20; i++) {
- data = !!(inl(pmbase + 0xF4) & 1);
- if (data || !wait)
- break;
- udelay(10);
+ u32 *data = buf;
+ struct amd768_priv *priv = (struct amd768_priv *)rng->priv;
+ size_t read = 0;
+ /* We will wait at maximum one time per read */
+ int timeout = max / 4 + 1;
+
+ /*
+ * RNG data is available when RNGDONE is set to 1
+ * New random numbers are generated approximately 128 microseconds
+ * after RNGDATA is read
+ */
+ while (read < max) {
+ if (ioread32(priv->iobase + RNGDONE) == 0) {
+ if (wait) {
+ /* Delay given by datasheet */
+ usleep_range(128, 196);
+ if (timeout-- == 0)
+ return read;
+ } else {
+ return 0;
+ }
+ } else {
+ *data = ioread32(priv->iobase + RNGDATA);
+ data++;
+ read += 4;
+ }
}
- return data;
-}
-
-static int amd_rng_data_read(struct hwrng *rng, u32 *data)
-{
- u32 pmbase = (u32)rng->priv;
- *data = inl(pmbase + 0xF0);
-
- return 4;
+ return read;
}
static int amd_rng_init(struct hwrng *rng)
{
u8 rnen;
+ struct amd768_priv *priv = (struct amd768_priv *)rng->priv;
- pci_read_config_byte(amd_pdev, 0x40, &rnen);
+ pci_read_config_byte(priv->pcidev, GEN_CFG_REG1, &rnen);
rnen |= BIT(7); /* RNG on */
- pci_write_config_byte(amd_pdev, 0x40, rnen);
+ pci_write_config_byte(priv->pcidev, GEN_CFG_REG1, rnen);
- pci_read_config_byte(amd_pdev, 0x41, &rnen);
+ pci_read_config_byte(priv->pcidev, GEN_CFG_REG2, &rnen);
rnen |= BIT(7); /* PMIO enable */
- pci_write_config_byte(amd_pdev, 0x41, rnen);
-
+ pci_write_config_byte(priv->pcidev, GEN_CFG_REG2, rnen);
return 0;
}
static void amd_rng_cleanup(struct hwrng *rng)
{
u8 rnen;
+ struct amd768_priv *priv = (struct amd768_priv *)rng->priv;
- pci_read_config_byte(amd_pdev, 0x40, &rnen);
+ pci_read_config_byte(priv->pcidev, GEN_CFG_REG1, &rnen);
rnen &= ~BIT(7); /* RNG off */
- pci_write_config_byte(amd_pdev, 0x40, rnen);
+ pci_write_config_byte(priv->pcidev, GEN_CFG_REG1, rnen);
}
static struct hwrng amd_rng = {
.name = "amd",
+ .read = amd_rng_read,
.init = amd_rng_init,
.cleanup = amd_rng_cleanup,
- .data_present = amd_rng_data_present,
- .data_read = amd_rng_data_read,
};
-static int __init mod_init(void)
+static int mod_init(void)
{
- int err = -ENODEV;
+ int err;
struct pci_dev *pdev = NULL;
const struct pci_device_id *ent;
u32 pmbase;
+ struct amd768_priv *priv;
for_each_pci_dev(pdev) {
ent = pci_match_id(pci_tbl, pdev);
if (ent)
goto found;
}
- /* Device not found. */
- goto out;
-
+ return -ENODEV;
found:
- err = pci_read_config_dword(pdev, 0x58, &pmbase);
+
+ err = pci_read_config_dword(pdev, SMIO_SPACEPTR, &pmbase);
if (err)
- goto out;
- err = -EIO;
+ return err;
+
pmbase &= 0x0000FF00;
- if (pmbase == 0)
- goto out;
- if (!request_region(pmbase + 0xF0, 8, DRV_NAME)) {
- dev_err(&pdev->dev, DRV_NAME " region 0x%x already in use!\n",
- pmbase + 0xF0);
- err = -EBUSY;
- goto out;
+
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ if (!request_region(pmbase + PMBASE_OFFSET, PMBASE_SIZE, DRV_NAME)) {
+ pr_err(DRV_NAME "region 0x%x already in use!\n", pmbase);
+ goto err_pmbase;
+ }
+
+ priv->iobase = ioport_map(pmbase + PMBASE_OFFSET, PMBASE_SIZE);
+ if (!priv->iobase) {
+ pr_err(DRV_NAME "Cannot map ioport\n");
+ err = -EINVAL;
+ goto err_iomap;
}
- amd_rng.priv = (unsigned long)pmbase;
- amd_pdev = pdev;
+
+ amd_rng.priv = (unsigned long)priv;
+ priv->pmbase = pmbase;
+ priv->pcidev = pdev;
pr_info(DRV_NAME " detected\n");
+
err = hwrng_register(&amd_rng);
if (err) {
- pr_err(DRV_NAME " registering failed (%d)\n", err);
- release_region(pmbase + 0xF0, 8);
- goto out;
+ pr_err(DRV_NAME "Cannot register HWRNG %d\n", err);
+ goto err_hwrng;
}
-out:
+ return 0;
+
+err_hwrng:
+ ioport_unmap(priv->iobase);
+err_iomap:
+ release_region(pmbase + PMBASE_OFFSET, PMBASE_SIZE);
+err_pmbase:
+ kfree(priv);
return err;
}
-static void __exit mod_exit(void)
+static void mod_exit(void)
{
- u32 pmbase = (unsigned long)amd_rng.priv;
+ struct amd768_priv *priv;
+
+ priv = (struct amd768_priv *)amd_rng.priv;
- release_region(pmbase + 0xF0, 8);
hwrng_unregister(&amd_rng);
+
+ ioport_unmap(priv->iobase);
+
+ release_region(priv->pmbase + PMBASE_OFFSET, PMBASE_SIZE);
+
+ kfree(priv);
}
module_init(mod_init);
--
2.7.3
^ permalink raw reply related
* [PATCH v2 4/5] hwrng: amd: Remove asm/io.h
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>
checkpatch complains about <asm/io.h> used instead of linux/io.h.
In fact it is not needed.
This patch remove it, and in the process, alphabetize the other headers.
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
drivers/char/hw_random/amd-rng.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index 93157af..de82fe3 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -24,12 +24,11 @@
* warranty of any kind, whether express or implied.
*/
-#include <linux/module.h>
+#include <linux/delay.h>
+#include <linux/hw_random.h>
#include <linux/kernel.h>
+#include <linux/module.h>
#include <linux/pci.h>
-#include <linux/hw_random.h>
-#include <linux/delay.h>
-#include <asm/io.h>
#define DRV_NAME "AMD768-HWRNG"
--
2.7.3
^ permalink raw reply related
* [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
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