* Re: algif_aead: AIO broken with more than one iocb
From: Herbert Xu @ 2016-09-13 10:12 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto
In-Reply-To: <6245755.LbXSUvPjJL@positron.chronox.de>
On Sun, Sep 11, 2016 at 04:59:19AM +0200, Stephan Mueller wrote:
> Hi Herbert,
>
> The AIO support for algif_aead is broken when submitting more than one iocb.
> The break happens in aead_recvmsg_async at the following code:
>
> /* ensure output buffer is sufficiently large */
> if (usedpages < outlen)
> goto free;
>
> The reason is that when submitting, say, two iocb, ctx->used contains the
> buffer length for two AEAD operations (as expected). However, the recvmsg code
I don't think we should allow that. We should make it so that you
must start a recvmsg before you can send data for a new request.
Remember that the async path should be identical to the sync path,
except that you don't wait for completion.
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 v3] crypto: only call put_page on referenced and used pages
From: Herbert Xu @ 2016-09-13 10:08 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto
In-Reply-To: <1794862.SeMhQgguHO@positron.chronox.de>
On Tue, Sep 13, 2016 at 10:18:54AM +0200, Stephan Mueller wrote:
> Am Montag, 12. September 2016, 14:43:45 CEST schrieb Stephan Mueller:
>
> Hi Herbert,
>
> > Hi Herbert,
> >
> > after getting the AIO code working on sendmsg, tried it with vmsplice/splice
> > and I get a memory corruption. Interestingly, the stack trace is partially
> > garbled too. Thus, tracking this one down may be a bit of a challenge.
>
> The issue is a NULL pointer dereference in skcipher_free_async_sgls. The issue is that SGs may not have even a page mapped to them and thus the page entry is NULL.
>
> The following patch fixes the issue and replaces the patch I sent earlier.
This patch appears to be papering over a real bug.
The async path should be exactly the same as the sync path, except
that we don't wait for completion. So the question is why are we
getting this crash here for async but not sync?
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: [RFC PATCH v1 01/28] kvm: svm: Add support for additional SVM NPF error codes
From: Borislav Petkov @ 2016-09-13 9:56 UTC (permalink / raw)
To: Brijesh Singh
Cc: simon.guinot, linux-efi, kvm, rkrcmar, matt, linus.walleij,
linux-mm, paul.gortmaker, hpa, dan.j.williams, aarcange, sfr,
andriy.shevchenko, herbert, bhe, xemul, joro, x86, mingo, msalter,
ross.zwisler, dyoung, thomas.lendacky, jroedel, keescook,
toshi.kani, mathieu.desnoyers, devel, tglx, mchehab,
iamjoonsoo.kim, labbott, tony.luck, alexandre.bounine,
kuleshovmail, linux-kernel, mcgrof, linux-crypto
In-Reply-To: <147190822443.9523.7814744422402462127.stgit@brijesh-build-machine>
On Mon, Aug 22, 2016 at 07:23:44PM -0400, Brijesh Singh wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> AMD hardware adds two additional bits to aid in nested page fault handling.
>
> Bit 32 - NPF occurred while translating the guest's final physical address
> Bit 33 - NPF occurred while translating the guest page tables
>
> The guest page tables fault indicator can be used as an aid for nested
> virtualization. Using V0 for the host, V1 for the first level guest and
> V2 for the second level guest, when both V1 and V2 are using nested paging
> there are currently a number of unnecessary instruction emulations. When
> V2 is launched shadow paging is used in V1 for the nested tables of V2. As
> a result, KVM marks these pages as RO in the host nested page tables. When
> V2 exits and we resume V1, these pages are still marked RO.
>
> Every nested walk for a guest page table is treated as a user-level write
> access and this causes a lot of NPFs because the V1 page tables are marked
> RO in the V0 nested tables. While executing V1, when these NPFs occur KVM
> sees a write to a read-only page, emulates the V1 instruction and unprotects
> the page (marking it RW). This patch looks for cases where we get a NPF due
> to a guest page table walk where the page was marked RO. It immediately
> unprotects the page and resumes the guest, leading to far fewer instruction
> emulations when nested virtualization is used.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> arch/x86/include/asm/kvm_host.h | 11 ++++++++++-
> arch/x86/kvm/mmu.c | 20 ++++++++++++++++++--
> arch/x86/kvm/svm.c | 2 +-
> 3 files changed, 29 insertions(+), 4 deletions(-)
FWIW: Reviewed-by: Borislav Petkov <bp@suse.de>
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v2 3/8] hwrng: omap - Switch to non-obsolete read API implementation
From: Herbert Xu @ 2016-09-13 9:48 UTC (permalink / raw)
To: Romain Perier
Cc: dsaxena, mpm, Gregory Clement, Thomas Petazzoni, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas, linux-crypto
In-Reply-To: <20160907155743.6403-4-romain.perier@free-electrons.com>
On Wed, Sep 07, 2016 at 05:57:38PM +0200, Romain Perier wrote:
> +
> +static int omap_rng_do_read(struct hwrng *rng, void *data, size_t max,
> + bool wait)
> {
> struct omap_rng_dev *priv;
> - int data, i;
>
> priv = (struct omap_rng_dev *)rng->priv;
>
> - for (i = 0; i < 20; i++) {
> - data = priv->pdata->data_present(priv);
> - if (data || !wait)
> - break;
> - /* RNG produces data fast enough (2+ MBit/sec, even
> - * during "rngtest" loads, that these delays don't
> - * seem to trigger. We *could* use the RNG IRQ, but
> - * that'd be higher overhead ... so why bother?
> - */
> - udelay(10);
So in the wait case you're changing the driver's behaviour. Instead
of waiting for 1us you'll now wait for 1s if there is no data. Is
this what really what you want?
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: [PATCHv3 06/11] crypto: omap-des: Fix support for unequal lengths
From: Herbert Xu @ 2016-09-13 9:35 UTC (permalink / raw)
To: Tero Kristo
Cc: lokeshvutla, davem, linux-crypto, tony, linux-omap,
linux-arm-kernel, Lokesh Vutla
In-Reply-To: <1470306526-27219-7-git-send-email-t-kristo@ti.com>
On Thu, Aug 04, 2016 at 01:28:41PM +0300, Tero Kristo wrote:
> From: Lokesh Vutla <a0131933@ti.com>
>
> For cases where total length of an input SGs is not same as
> length of the input data for encryption, omap-des driver
> crashes. This happens in the case when IPsec is trying to use
> omap-des driver.
>
> To avoid this, we copy all the pages from the input SG list
> into a contiguous buffer and prepare a single element SG list
> for this buffer with length as the total bytes to crypt, which is
> similar thing that is done in case of unaligned lengths.
Ugh, that means copying every single packet, right?
So if it's just the SG list that's the problem, why don't you
copy that instead? That is, allocate a new SG list and set it
up so that there is no excess data.
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 2/2] crypto: arm64/aes-ctr: fix NULL dereference in tail processing
From: Ard Biesheuvel @ 2016-09-13 8:48 UTC (permalink / raw)
To: linux-crypto, herbert, linux-arm-kernel; +Cc: xiakaixu, Ard Biesheuvel
In-Reply-To: <1473756533-21078-1-git-send-email-ard.biesheuvel@linaro.org>
The AES-CTR glue code avoids calling into the blkcipher API for the
tail portion of the walk, by comparing the remainder of walk.nbytes
modulo AES_BLOCK_SIZE with the residual nbytes, and jumping straight
into the tail processing block if they are equal. This tail processing
block checks whether nbytes != 0, and does nothing otherwise.
However, in case of an allocation failure in the blkcipher layer, we
may enter this code with walk.nbytes == 0, while nbytes > 0. In this
case, we should not dereference the source and destination pointers,
since they may be NULL. So instead of checking for nbytes != 0, check
for (walk.nbytes % AES_BLOCK_SIZE) != 0, which implies the former in
non-error conditions.
Fixes: 49788fe2a128 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions")
Reported-by: xiakaixu <xiakaixu@huawei.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/aes-glue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
index 5c888049d061..6b2aa0fd6cd0 100644
--- a/arch/arm64/crypto/aes-glue.c
+++ b/arch/arm64/crypto/aes-glue.c
@@ -216,7 +216,7 @@ static int ctr_encrypt(struct blkcipher_desc *desc, struct scatterlist *dst,
err = blkcipher_walk_done(desc, &walk,
walk.nbytes % AES_BLOCK_SIZE);
}
- if (nbytes) {
+ if (walk.nbytes % AES_BLOCK_SIZE) {
u8 *tdst = walk.dst.virt.addr + blocks * AES_BLOCK_SIZE;
u8 *tsrc = walk.src.virt.addr + blocks * AES_BLOCK_SIZE;
u8 __aligned(8) tail[AES_BLOCK_SIZE];
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] crypto: arm/aes-ctr: fix NULL dereference in tail processing
From: Ard Biesheuvel @ 2016-09-13 8:48 UTC (permalink / raw)
To: linux-crypto, herbert, linux-arm-kernel; +Cc: xiakaixu, Ard Biesheuvel
The AES-CTR glue code avoids calling into the blkcipher API for the
tail portion of the walk, by comparing the remainder of walk.nbytes
modulo AES_BLOCK_SIZE with the residual nbytes, and jumping straight
into the tail processing block if they are equal. This tail processing
block checks whether nbytes != 0, and does nothing otherwise.
However, in case of an allocation failure in the blkcipher layer, we
may enter this code with walk.nbytes == 0, while nbytes > 0. In this
case, we should not dereference the source and destination pointers,
since they may be NULL. So instead of checking for nbytes != 0, check
for (walk.nbytes % AES_BLOCK_SIZE) != 0, which implies the former in
non-error conditions.
Fixes: 86464859cc77 ("crypto: arm - AES in ECB/CBC/CTR/XTS modes using ARMv8 Crypto Extensions")
Reported-by: xiakaixu <xiakaixu@huawei.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/crypto/aes-ce-glue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/crypto/aes-ce-glue.c b/arch/arm/crypto/aes-ce-glue.c
index da3c0428507b..aef022a87c53 100644
--- a/arch/arm/crypto/aes-ce-glue.c
+++ b/arch/arm/crypto/aes-ce-glue.c
@@ -284,7 +284,7 @@ static int ctr_encrypt(struct blkcipher_desc *desc, struct scatterlist *dst,
err = blkcipher_walk_done(desc, &walk,
walk.nbytes % AES_BLOCK_SIZE);
}
- if (nbytes) {
+ if (walk.nbytes % AES_BLOCK_SIZE) {
u8 *tdst = walk.dst.virt.addr + blocks * AES_BLOCK_SIZE;
u8 *tsrc = walk.src.virt.addr + blocks * AES_BLOCK_SIZE;
u8 __aligned(8) tail[AES_BLOCK_SIZE];
--
2.7.4
^ permalink raw reply related
* [PATCH v3] crypto: only call put_page on referenced and used pages
From: Stephan Mueller @ 2016-09-13 8:18 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto
In-Reply-To: <13399079.xub8KL5p6S@positron.chronox.de>
Am Montag, 12. September 2016, 14:43:45 CEST schrieb Stephan Mueller:
Hi Herbert,
> Hi Herbert,
>
> after getting the AIO code working on sendmsg, tried it with vmsplice/splice
> and I get a memory corruption. Interestingly, the stack trace is partially
> garbled too. Thus, tracking this one down may be a bit of a challenge.
The issue is a NULL pointer dereference in skcipher_free_async_sgls. The issue is that SGs may not have even a page mapped to them and thus the page entry is NULL.
The following patch fixes the issue and replaces the patch I sent earlier.
---8<---
For asynchronous operation, SGs are allocated without a page mapped to
them or with a page that is not used (ref-counted). If the SGL is freed,
the code must only call put_page for an SG if there was a page assigned
and ref-counted in the first place.
This fixes a kernel crash when using io_submit with more than one iocb
using the sendmsg and sendpage (vmsplice/splice) interface
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
crypto/algif_skcipher.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index 28556fc..45af0fe 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -86,8 +86,13 @@ static void skcipher_free_async_sgls(struct skcipher_async_req *sreq)
}
sgl = sreq->tsg;
n = sg_nents(sgl);
- for_each_sg(sgl, sg, n, i)
- put_page(sg_page(sg));
+ for_each_sg(sgl, sg, n, i) {
+ struct page *page = sg_page(sg);
+
+ /* some SGs may not have a page mapped */
+ if (page && page_ref_count(page))
+ put_page(page);
+ }
kfree(sreq->tsg);
}
--
2.7.4
^ permalink raw reply related
* Re: Kernel panic - encryption/decryption failed when open file on Arm64
From: Ard Biesheuvel @ 2016-09-13 7:56 UTC (permalink / raw)
To: Herbert Xu
Cc: liushuoran, Xiakaixu, David S. Miller, Theodore Ts'o,
Jaegeuk Kim, nhorman@tuxdriver.com, mh1@iki.fi,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
Wangbintian, Huxinwei, zhangzhibin (C)
In-Reply-To: <20160913064329.GA26933@gondor.apana.org.au>
On 13 September 2016 at 07:43, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Mon, Sep 12, 2016 at 06:40:15PM +0100, Ard Biesheuvel wrote:
>>
>> So to me, it seems like we should be taking the blkcipher_next_slow()
>> path, which does a kmalloc() and bails with -ENOMEM if that fails.
>
> Indeed. This was broken a long time ago. It does seem to be
> fixed in the new skcipher_walk code but here is a patch to fix
> it for older kernels.
>
> ---8<---
> Subject: crypto: skcipher - Fix blkcipher walk OOM crash
>
> When we need to allocate a temporary blkcipher_walk_next and it
> fails, the code is supposed to take the slow path of processing
> the data block by block. However, due to an unrelated change
> we instead end up dereferencing the NULL pointer.
>
> This patch fixes it by moving the unrelated bsize setting out
> of the way so that we enter the slow path as inteded.
>
inteNded ^^^
> Fixes: 7607bd8ff03b ("[CRYPTO] blkcipher: Added blkcipher_walk_virt_block")
> Cc: stable@vger.kernel.org
> Reported-by: xiakaixu <xiakaixu@huawei.com>
> Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
This fixes the issue for me
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
I will follow up with fixes for the ARM and arm64 CTR code shortly.
Thanks,
Ard.
> diff --git a/crypto/blkcipher.c b/crypto/blkcipher.c
> index 3699995..a832426 100644
> --- a/crypto/blkcipher.c
> +++ b/crypto/blkcipher.c
> @@ -233,6 +233,8 @@ static int blkcipher_walk_next(struct blkcipher_desc *desc,
> return blkcipher_walk_done(desc, walk, -EINVAL);
> }
>
> + bsize = min(walk->walk_blocksize, n);
> +
> walk->flags &= ~(BLKCIPHER_WALK_SLOW | BLKCIPHER_WALK_COPY |
> BLKCIPHER_WALK_DIFF);
> if (!scatterwalk_aligned(&walk->in, walk->alignmask) ||
> @@ -245,7 +247,6 @@ static int blkcipher_walk_next(struct blkcipher_desc *desc,
> }
> }
>
> - bsize = min(walk->walk_blocksize, n);
> n = scatterwalk_clamp(&walk->in, n);
> n = scatterwalk_clamp(&walk->out, n);
>
> --
> 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: Kernel panic - encryption/decryption failed when open file on Arm64
From: Herbert Xu @ 2016-09-13 6:43 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: liushuoran, Xiakaixu, David S. Miller, Theodore Ts'o,
Jaegeuk Kim, nhorman@tuxdriver.com, mh1@iki.fi,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
Wangbintian, Huxinwei, zhangzhibin (C)
In-Reply-To: <CAKv+Gu9jaVyJ4PYsxZfiZXB3Uezr26YWhSyE-g+n6-AuWFcneQ@mail.gmail.com>
On Mon, Sep 12, 2016 at 06:40:15PM +0100, Ard Biesheuvel wrote:
>
> So to me, it seems like we should be taking the blkcipher_next_slow()
> path, which does a kmalloc() and bails with -ENOMEM if that fails.
Indeed. This was broken a long time ago. It does seem to be
fixed in the new skcipher_walk code but here is a patch to fix
it for older kernels.
---8<---
Subject: crypto: skcipher - Fix blkcipher walk OOM crash
When we need to allocate a temporary blkcipher_walk_next and it
fails, the code is supposed to take the slow path of processing
the data block by block. However, due to an unrelated change
we instead end up dereferencing the NULL pointer.
This patch fixes it by moving the unrelated bsize setting out
of the way so that we enter the slow path as inteded.
Fixes: 7607bd8ff03b ("[CRYPTO] blkcipher: Added blkcipher_walk_virt_block")
Cc: stable@vger.kernel.org
Reported-by: xiakaixu <xiakaixu@huawei.com>
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/crypto/blkcipher.c b/crypto/blkcipher.c
index 3699995..a832426 100644
--- a/crypto/blkcipher.c
+++ b/crypto/blkcipher.c
@@ -233,6 +233,8 @@ static int blkcipher_walk_next(struct blkcipher_desc *desc,
return blkcipher_walk_done(desc, walk, -EINVAL);
}
+ bsize = min(walk->walk_blocksize, n);
+
walk->flags &= ~(BLKCIPHER_WALK_SLOW | BLKCIPHER_WALK_COPY |
BLKCIPHER_WALK_DIFF);
if (!scatterwalk_aligned(&walk->in, walk->alignmask) ||
@@ -245,7 +247,6 @@ static int blkcipher_walk_next(struct blkcipher_desc *desc,
}
}
- bsize = min(walk->walk_blocksize, n);
n = scatterwalk_clamp(&walk->in, n);
n = scatterwalk_clamp(&walk->out, n);
--
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] crypto: qce: Initialize core src clock @100Mhz
From: Bjorn Andersson @ 2016-09-13 4:00 UTC (permalink / raw)
To: Iaroslav Gridin
Cc: herbert, davem, linux-crypto, linux-kernel, andy.gross,
david.brown, linux-arm-msm, linux-soc
In-Reply-To: <20160903164535.1118-1-voker57@gmail.com>
On Sat 03 Sep 09:45 PDT 2016, Iaroslav Gridin wrote:
> 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
[..]
> @@ -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");
This warning is misleading as you return a failure from probe() when it
happens.
> + goto err_clks_core_src;
> + }
> +
[..]
> +err_clks_core_src:
> + clk_disable_unprepare(qce->core_src);
> return ret;
> }
>
Regards,
Bjorn
^ permalink raw reply
* Re: Kernel panic - encryption/decryption failed when open file on Arm64
From: xiakaixu @ 2016-09-13 2:05 UTC (permalink / raw)
To: Ard Biesheuvel, Herbert Xu
Cc: liushuoran, David S. Miller, Theodore Ts'o, Jaegeuk Kim,
nhorman@tuxdriver.com, mh1@iki.fi, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org, Wangbintian, Huxinwei,
zhangzhibin (C)
In-Reply-To: <CAKv+Gu9jaVyJ4PYsxZfiZXB3Uezr26YWhSyE-g+n6-AuWFcneQ@mail.gmail.com>
> On 12 September 2016 at 03:16, liushuoran <liushuoran@huawei.com> wrote:
>> Hi Ard,
>>
>> Thanks for the prompt reply. With the patch, there is no panic anymore. But it seems that the encryption/decryption is not successful anyway.
>>
>> As Herbert points out, "If the page allocation fails in blkcipher_walk_next it'll simply switch over to processing it block by block". So does that mean the encryption/decryption should be successful even if the page allocation fails? Please correct me if I misunderstand anything. Thanks in advance.
>>
>
> Perhaps Herbert can explain: I don't see how the 'n = 0' assignment
> results in the correct path being taken; this chunk (blkcipher.c:252)
>
> if (unlikely(n < bsize)) {
> err = blkcipher_next_slow(desc, walk, bsize, walk->alignmask);
> goto set_phys_lowmem;
> }
>
> is skipped due to the fact that n == 0 and therefore bsize == 0, and
> so the condition is always false for n == 0
>
> Therefore we end up here (blkcipher.c:257)
>
> walk->nbytes = n;
> if (walk->flags & BLKCIPHER_WALK_COPY) {
> err = blkcipher_next_copy(walk);
> goto set_phys_lowmem;
> }
>
> where blkcipher_next_copy() unconditionally calls memcpy() with
> walk->page as destination (even though we ended up here due to the
> fact that walk->page == NULL)
>
> So to me, it seems like we should be taking the blkcipher_next_slow()
> path, which does a kmalloc() and bails with -ENOMEM if that fails.
Hi Ard,
Thanks for such a detailed reply.
According to your reply, I just make a little change to take the
blkcipher_next_slow() path. I test it on arm64 board, there is
no panic anymore and seems the encryption/decryption is successful.
diff --git a/crypto/blkcipher.c b/crypto/blkcipher.c
index 0122bec..5389d40 100644
--- a/crypto/blkcipher.c
+++ b/crypto/blkcipher.c
@@ -240,12 +240,13 @@ static int blkcipher_walk_next(struct blkcipher_desc *desc,
walk->flags |= BLKCIPHER_WALK_COPY;
if (!walk->page) {
walk->page = (void *)__get_free_page(GFP_ATOMIC);
+ walk->page = NULL;
if (!walk->page)
n = 0;
}
}
- bsize = min(walk->walk_blocksize, n);
+ bsize = walk->walk_blocksize;
n = scatterwalk_clamp(&walk->in, n);
n = scatterwalk_clamp(&walk->out, n);
It is just a trial and not sure it makes sense. But anyway, we can do
something here to fix the crash result from the page allocation failure.
What's your opinions, Herbert?
Regards
Kaixu Xia
>
> .
>
^ permalink raw reply related
* Re: [PATCH] crypto: squash lines for simple wrapper functions
From: Joe Perches @ 2016-09-12 19:44 UTC (permalink / raw)
To: Masahiro Yamada, linux-crypto; +Cc: Herbert Xu, linux-kernel, David S. Miller
In-Reply-To: <1473708474-32359-1-git-send-email-yamada.masahiro@socionext.com>
On Tue, 2016-09-13 at 04:27 +0900, Masahiro Yamada wrote:
> Remove unneeded variables and assignments.
Was this found by visual inspection or some tool?
If it's via a tool, it's good to mention that in the changelog.
^ permalink raw reply
* [PATCH] crypto: squash lines for simple wrapper functions
From: Masahiro Yamada @ 2016-09-12 19:27 UTC (permalink / raw)
To: linux-crypto; +Cc: Masahiro Yamada, Herbert Xu, linux-kernel, David S. Miller
Remove unneeded variables and assignments.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
crypto/crct10dif_generic.c | 5 +----
crypto/mcryptd.c | 7 +------
drivers/crypto/hifn_795x.c | 12 ++----------
3 files changed, 4 insertions(+), 20 deletions(-)
diff --git a/crypto/crct10dif_generic.c b/crypto/crct10dif_generic.c
index c1229614..8e94e29 100644
--- a/crypto/crct10dif_generic.c
+++ b/crypto/crct10dif_generic.c
@@ -107,10 +107,7 @@ static struct shash_alg alg = {
static int __init crct10dif_mod_init(void)
{
- int ret;
-
- ret = crypto_register_shash(&alg);
- return ret;
+ return crypto_register_shash(&alg);
}
static void __exit crct10dif_mod_fini(void)
diff --git a/crypto/mcryptd.c b/crypto/mcryptd.c
index 86fb59b..94ee44a 100644
--- a/crypto/mcryptd.c
+++ b/crypto/mcryptd.c
@@ -612,12 +612,7 @@ EXPORT_SYMBOL_GPL(mcryptd_alloc_ahash);
int ahash_mcryptd_digest(struct ahash_request *desc)
{
- int err;
-
- err = crypto_ahash_init(desc) ?:
- ahash_mcryptd_finup(desc);
-
- return err;
+ return crypto_ahash_init(desc) ?: ahash_mcryptd_finup(desc);
}
int ahash_mcryptd_update(struct ahash_request *desc)
diff --git a/drivers/crypto/hifn_795x.c b/drivers/crypto/hifn_795x.c
index eee2c7e..e09d405 100644
--- a/drivers/crypto/hifn_795x.c
+++ b/drivers/crypto/hifn_795x.c
@@ -636,20 +636,12 @@ struct hifn_request_context {
static inline u32 hifn_read_0(struct hifn_device *dev, u32 reg)
{
- u32 ret;
-
- ret = readl(dev->bar[0] + reg);
-
- return ret;
+ return readl(dev->bar[0] + reg);
}
static inline u32 hifn_read_1(struct hifn_device *dev, u32 reg)
{
- u32 ret;
-
- ret = readl(dev->bar[1] + reg);
-
- return ret;
+ return readl(dev->bar[1] + reg);
}
static inline void hifn_write_0(struct hifn_device *dev, u32 reg, u32 val)
--
1.9.1
^ permalink raw reply related
* Re: Kernel panic - encryption/decryption failed when open file on Arm64
From: Ard Biesheuvel @ 2016-09-12 17:40 UTC (permalink / raw)
To: liushuoran
Cc: Xiakaixu, Herbert Xu, David S. Miller, Theodore Ts'o,
Jaegeuk Kim, nhorman@tuxdriver.com, mh1@iki.fi,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
Wangbintian, Huxinwei, zhangzhibin (C)
In-Reply-To: <00B10D30F2BAA743B48953A4D86C96D54C8A8A@SZXEMI506-MBS.china.huawei.com>
On 12 September 2016 at 03:16, liushuoran <liushuoran@huawei.com> wrote:
> Hi Ard,
>
> Thanks for the prompt reply. With the patch, there is no panic anymore. But it seems that the encryption/decryption is not successful anyway.
>
> As Herbert points out, "If the page allocation fails in blkcipher_walk_next it'll simply switch over to processing it block by block". So does that mean the encryption/decryption should be successful even if the page allocation fails? Please correct me if I misunderstand anything. Thanks in advance.
>
Perhaps Herbert can explain: I don't see how the 'n = 0' assignment
results in the correct path being taken; this chunk (blkcipher.c:252)
if (unlikely(n < bsize)) {
err = blkcipher_next_slow(desc, walk, bsize, walk->alignmask);
goto set_phys_lowmem;
}
is skipped due to the fact that n == 0 and therefore bsize == 0, and
so the condition is always false for n == 0
Therefore we end up here (blkcipher.c:257)
walk->nbytes = n;
if (walk->flags & BLKCIPHER_WALK_COPY) {
err = blkcipher_next_copy(walk);
goto set_phys_lowmem;
}
where blkcipher_next_copy() unconditionally calls memcpy() with
walk->page as destination (even though we ended up here due to the
fact that walk->page == NULL)
So to me, it seems like we should be taking the blkcipher_next_slow()
path, which does a kmalloc() and bails with -ENOMEM if that fails.
^ permalink raw reply
* Memory corruption in algif_skciper AIO sendpage with multiple iocb
From: Stephan Mueller @ 2016-09-12 12:43 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto
Hi Herbert,
after getting the AIO code working on sendmsg, tried it with vmsplice/splice
and I get a memory corruption. Interestingly, the stack trace is partially
garbled too. Thus, tracking this one down may be a bit of a challenge.
Ciao
Stephan
^ permalink raw reply
* Re: [STLinux Kernel] [PATCH -next] hwrng: st - Fix missing clk_disable_unprepare() on error in st_rng_probe()
From: Peter Griffin @ 2016-09-12 8:31 UTC (permalink / raw)
To: Wei Yongjun
Cc: Patrice Chotard, Matt Mackall, Herbert Xu, Wei Yongjun, kernel,
linux-arm-kernel, linux-crypto
In-Reply-To: <1473509022-3478-1-git-send-email-weiyj.lk@gmail.com>
Hi Wei,
On Sat, 10 Sep 2016, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fix the missing clk_disable_unprepare() before return
> from st_rng_probe() in the error handling case.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> drivers/char/hw_random/st-rng.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/char/hw_random/st-rng.c b/drivers/char/hw_random/st-rng.c
> index 7e8aa6b..938ec10 100644
> --- a/drivers/char/hw_random/st-rng.c
> +++ b/drivers/char/hw_random/st-rng.c
> @@ -108,6 +108,7 @@ static int st_rng_probe(struct platform_device *pdev)
> ret = hwrng_register(&ddata->ops);
> if (ret) {
> dev_err(&pdev->dev, "Failed to register HW RNG\n");
> + clk_disable_unprepare(clk);
> return ret;
> }
>
>
Acked-by: Peter Griffin <peter.griffin@linaro.org>
^ permalink raw reply
* Re: [PATCH -next] hwrng: st - Fix missing clk_disable_unprepare() on error in st_rng_probe()
From: Patrice Chotard @ 2016-09-12 7:27 UTC (permalink / raw)
To: Wei Yongjun, Matt Mackall, Herbert Xu
Cc: Wei Yongjun, linux-arm-kernel, kernel, linux-crypto
In-Reply-To: <1473509022-3478-1-git-send-email-weiyj.lk@gmail.com>
Hi Wey
On 09/10/2016 02:03 PM, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fix the missing clk_disable_unprepare() before return
> from st_rng_probe() in the error handling case.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> drivers/char/hw_random/st-rng.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/char/hw_random/st-rng.c b/drivers/char/hw_random/st-rng.c
> index 7e8aa6b..938ec10 100644
> --- a/drivers/char/hw_random/st-rng.c
> +++ b/drivers/char/hw_random/st-rng.c
> @@ -108,6 +108,7 @@ static int st_rng_probe(struct platform_device *pdev)
> ret = hwrng_register(&ddata->ops);
> if (ret) {
> dev_err(&pdev->dev, "Failed to register HW RNG\n");
> + clk_disable_unprepare(clk);
> return ret;
> }
>
>
>
>
Acked-by: Patrice Chotard <patrice.chotard@st.com>
Thanks
^ permalink raw reply
* RE: Kernel panic - encryption/decryption failed when open file on Arm64
From: liushuoran @ 2016-09-12 2:16 UTC (permalink / raw)
To: Ard Biesheuvel, Xiakaixu
Cc: Herbert Xu, David S. Miller, Theodore Ts'o, Jaegeuk Kim,
nhorman@tuxdriver.com, mh1@iki.fi, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org, Wangbintian, Huxinwei,
zhangzhibin (C)
In-Reply-To: <CAKv+Gu8w+BuwxQjOtpnFPHnJNUzq7m0K+KJ8=FG2wHigaB54ng@mail.gmail.com>
Hi Ard,
Thanks for the prompt reply. With the patch, there is no panic anymore. But it seems that the encryption/decryption is not successful anyway.
As Herbert points out, "If the page allocation fails in blkcipher_walk_next it'll simply switch over to processing it block by block". So does that mean the encryption/decryption should be successful even if the page allocation fails? Please correct me if I misunderstand anything. Thanks in advance.
Regards,
Shuoran
> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: Friday, September 09, 2016 6:57 PM
> To: Xiakaixu
> Cc: Herbert Xu; David S. Miller; Theodore Ts'o; Jaegeuk Kim;
> nhorman@tuxdriver.com; mh1@iki.fi; linux-crypto@vger.kernel.org;
> linux-kernel@vger.kernel.org; Wangbintian; liushuoran; Huxinwei; zhangzhibin
> (C)
> Subject: Re: Kernel panic - encryption/decryption failed when open file on
> Arm64
>
> On 9 September 2016 at 11:31, Ard Biesheuvel <ard.biesheuvel@linaro.org>
> wrote:
> > On 9 September 2016 at 11:19, xiakaixu <xiakaixu@huawei.com> wrote:
> >> Hi,
> >>
> >> After a deeply research about this crash, seems it is a specific
> >> bug that only exists in armv8 board. And it occurs in this function
> >> in arch/arm64/crypto/aes-glue.c.
> >>
> >> static int ctr_encrypt(struct blkcipher_desc *desc, struct scatterlist *dst,
> >> struct scatterlist *src, unsigned int nbytes)
> >> {
> >> ...
> >>
> >> desc->flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP;
> >> blkcipher_walk_init(&walk, dst, src, nbytes);
> >> err = blkcipher_walk_virt_block(desc, &walk, AES_BLOCK_SIZE);
> --->
> >> page allocation failed
> >>
> >> ...
> >>
> >> while ((blocks = (walk.nbytes / AES_BLOCK_SIZE)))
> { ---->
> >> walk.nbytes = 0, and skip this loop
> >> aes_ctr_encrypt(walk.dst.virt.addr, walk.src.virt.addr,
> >> (u8 *)ctx->key_enc, rounds, blocks,
> walk.iv,
> >> first);
> >> ...
> >> err = blkcipher_walk_done(desc, &walk,
> >> walk.nbytes %
> AES_BLOCK_SIZE);
> >> }
> >> if (nbytes)
> { ---->
> >> enter this if() statement
> >> u8 *tdst = walk.dst.virt.addr + blocks * AES_BLOCK_SIZE;
> >> u8 *tsrc = walk.src.virt.addr + blocks * AES_BLOCK_SIZE;
> >> ...
> >>
> >> aes_ctr_encrypt(tail, tsrc, (u8 *)ctx->key_enc, rounds,
> >> ----> the the sencond input parameter is NULL, so crash...
> >> blocks, walk.iv, first);
> >> ...
> >> }
> >> ...
> >> }
> >>
> >>
> >> If the page allocation failed in the function blkcipher_walk_virt_block(),
> >> the variable walk.nbytes = 0, so it will skip the while() loop and enter
> >> the if(nbytes) statment. But here the varibale tsrc is NULL and it is also
> >> the sencond input parameter of the function aes_ctr_encrypt()... Kernel
> >> Panic...
> >>
> >> I have also researched the similar function in other architectures, and
> >> there if(walk.nbytes) is used, not this if(nbytes) statement in the armv8.
> >> so I think this armv8 function ctr_encrypt() should deal with the page
> >> allocation failed situation.
> >>
>
> Does this solve your problem?
>
> diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
> index 5c888049d061..6b2aa0fd6cd0 100644
> --- a/arch/arm64/crypto/aes-glue.c
> +++ b/arch/arm64/crypto/aes-glue.c
> @@ -216,7 +216,7 @@ static int ctr_encrypt(struct blkcipher_desc
> *desc, struct scatterlist *dst,
> err = blkcipher_walk_done(desc, &walk,
> walk.nbytes % AES_BLOCK_SIZE);
> }
> - if (nbytes) {
> + if (walk.nbytes % AES_BLOCK_SIZE) {
> u8 *tdst = walk.dst.virt.addr + blocks * AES_BLOCK_SIZE;
> u8 *tsrc = walk.src.virt.addr + blocks * AES_BLOCK_SIZE;
> u8 __aligned(8) tail[AES_BLOCK_SIZE];
^ permalink raw reply
* [PATCH] hwrng: geode-rng - Use linux/io.h instead of asm/io.h
From: PrasannaKumar Muralidharan @ 2016-09-11 15:24 UTC (permalink / raw)
To: herbert, mpm, linux-geode, linux-crypto; +Cc: PrasannaKumar Muralidharan
Fix checkpatch.pl warning by changing from asm/io.h to linux/io.h. In
the mean time arrange the includes in alphabetical order.
Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
---
drivers/char/hw_random/geode-rng.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/hw_random/geode-rng.c b/drivers/char/hw_random/geode-rng.c
index 79e7482..0cae210 100644
--- a/drivers/char/hw_random/geode-rng.c
+++ b/drivers/char/hw_random/geode-rng.c
@@ -24,12 +24,12 @@
* warranty of any kind, whether express or implied.
*/
-#include <linux/module.h>
+#include <linux/delay.h>
+#include <linux/hw_random.h>
+#include <linux/io.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 GEODE_RNG_DATA_REG 0x50
#define GEODE_RNG_STATUS_REG 0x54
--
2.5.0
^ permalink raw reply related
* [PATCH] hwrng: geode-rng - Migrate to managed API
From: PrasannaKumar Muralidharan @ 2016-09-11 15:23 UTC (permalink / raw)
To: herbert, mpm, linux-geode, linux-crypto; +Cc: PrasannaKumar Muralidharan
Use devm_ioremap and devm_hwrng_register instead of ioremap and
hwrng_register. This removes error handling code. Also moved code around
by removing goto statements. This improves code readability.
Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
---
drivers/char/hw_random/geode-rng.c | 50 ++++++++++++--------------------------
1 file changed, 15 insertions(+), 35 deletions(-)
diff --git a/drivers/char/hw_random/geode-rng.c b/drivers/char/hw_random/geode-rng.c
index 0d0579f..79e7482 100644
--- a/drivers/char/hw_random/geode-rng.c
+++ b/drivers/char/hw_random/geode-rng.c
@@ -31,9 +31,6 @@
#include <linux/delay.h>
#include <asm/io.h>
-
-#define PFX KBUILD_MODNAME ": "
-
#define GEODE_RNG_DATA_REG 0x50
#define GEODE_RNG_STATUS_REG 0x54
@@ -85,7 +82,6 @@ static struct hwrng geode_rng = {
static int __init mod_init(void)
{
- int err = -ENODEV;
struct pci_dev *pdev = NULL;
const struct pci_device_id *ent;
void __iomem *mem;
@@ -93,43 +89,27 @@ static int __init mod_init(void)
for_each_pci_dev(pdev) {
ent = pci_match_id(pci_tbl, pdev);
- if (ent)
- goto found;
- }
- /* Device not found. */
- goto out;
-
-found:
- rng_base = pci_resource_start(pdev, 0);
- if (rng_base == 0)
- goto out;
- err = -ENOMEM;
- mem = ioremap(rng_base, 0x58);
- if (!mem)
- goto out;
- geode_rng.priv = (unsigned long)mem;
-
- pr_info("AMD Geode RNG detected\n");
- err = hwrng_register(&geode_rng);
- if (err) {
- pr_err(PFX "RNG registering failed (%d)\n",
- err);
- goto err_unmap;
+ if (ent) {
+ rng_base = pci_resource_start(pdev, 0);
+ if (rng_base == 0)
+ return -ENODEV;
+
+ mem = devm_ioremap(&pdev->dev, rng_base, 0x58);
+ if (IS_ERR(mem))
+ return PTR_ERR(mem);
+ geode_rng.priv = (unsigned long)mem;
+
+ pr_info("AMD Geode RNG detected\n");
+ return devm_hwrng_register(&pdev->dev, &geode_rng);
+ }
}
-out:
- return err;
-err_unmap:
- iounmap(mem);
- goto out;
+ /* Device not found. */
+ return -ENODEV;
}
static void __exit mod_exit(void)
{
- void __iomem *mem = (void __iomem *)geode_rng.priv;
-
- hwrng_unregister(&geode_rng);
- iounmap(mem);
}
module_init(mod_init);
--
2.5.0
^ permalink raw reply related
* Re: algif_aead: AIO broken with more than one iocb
From: Stephan Mueller @ 2016-09-11 13:41 UTC (permalink / raw)
To: noloader; +Cc: Herbert Xu, linux-crypto
In-Reply-To: <CAH8yC8knD0U4-BhgzkUfyHMm-KyNyDCx-3PPqQOm0bdVh4qjiA@mail.gmail.com>
Am Sonntag, 11. September 2016, 08:43:00 CEST schrieb Jeffrey Walton:
Hi Jeffrey,
> > The AIO support for algif_aead is broken when submitting more than one
> > iocb.
> > The break happens in aead_recvmsg_async at the following code:
> I think the kernel needs to take a half step back, and add the missing
> self tests and test cases to be more proactive in detecting breaks
> earlier. Speaking first hand, some of these breaks have existed for
> months.
>
> I don't take the position you can't break things. I believe you can't
> make an omelet without breaking eggs; and if you're not breaking
> something, then you're probably not getting anything done. The
> engineering defect is not detecting the break.
The testing that is implemented for libkcapi should cover almost all code
paths of AF_ALG in the kernel. However, I just added the AIO support to the
library in the last few days as this logic is not straight forward. Thus these
issues show up now.
If you wish to analyze the AIO support more, I can certainly push my current
development branch of libkcapi to my github tree so that you would have a
working AIO user space component.
Ciao
Stephan
^ permalink raw reply
* Re: algif_aead: AIO broken with more than one iocb
From: Jeffrey Walton @ 2016-09-11 12:43 UTC (permalink / raw)
To: Stephan Mueller; +Cc: Herbert Xu, linux-crypto
In-Reply-To: <6245755.LbXSUvPjJL@positron.chronox.de>
> The AIO support for algif_aead is broken when submitting more than one iocb.
> The break happens in aead_recvmsg_async at the following code:
>
I think the kernel needs to take a half step back, and add the missing
self tests and test cases to be more proactive in detecting breaks
earlier. Speaking first hand, some of these breaks have existed for
months.
I don't take the position you can't break things. I believe you can't
make an omelet without breaking eggs; and if you're not breaking
something, then you're probably not getting anything done. The
engineering defect is not detecting the break.
Jeff
^ permalink raw reply
* algif_aead: AIO broken with more than one iocb
From: Stephan Mueller @ 2016-09-11 2:59 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto
Hi Herbert,
The AIO support for algif_aead is broken when submitting more than one iocb.
The break happens in aead_recvmsg_async at the following code:
/* ensure output buffer is sufficiently large */
if (usedpages < outlen)
goto free;
The reason is that when submitting, say, two iocb, ctx->used contains the
buffer length for two AEAD operations (as expected). However, the recvmsg code
is invoked for each iocb individually and thus usedpages should only be
expected to point to memory for one AEAD operation. But this violates the
check above.
For example, I have two independent AEAD operations that I want to trigger.
The input to each is 48 bytes (including space for AAD and tag). The output
buffer that I have for each AEAD operation is also 48 bytes and thus
sufficient for the AEAD operation. Yet, when submitting the two AEAD
operations in one io_submit (i.e. using two iocb), ctx->used indicates that
the kernel has 96 bytes to process. This is correct, but only half of it
should be processed in one recvmsg_async invocation.
Note, the AIO operation works perfectly well, when io_submit only sends one
iocb.
Do you have any idea on how to fix that?
Ciao
Stephan
^ permalink raw reply
* [PATCH -next] hwrng: st - Fix missing clk_disable_unprepare() on error in st_rng_probe()
From: Wei Yongjun @ 2016-09-10 12:03 UTC (permalink / raw)
To: Patrice Chotard, Matt Mackall, Herbert Xu
Cc: Wei Yongjun, linux-arm-kernel, kernel, linux-crypto
From: Wei Yongjun <weiyongjun1@huawei.com>
Fix the missing clk_disable_unprepare() before return
from st_rng_probe() in the error handling case.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/char/hw_random/st-rng.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/char/hw_random/st-rng.c b/drivers/char/hw_random/st-rng.c
index 7e8aa6b..938ec10 100644
--- a/drivers/char/hw_random/st-rng.c
+++ b/drivers/char/hw_random/st-rng.c
@@ -108,6 +108,7 @@ static int st_rng_probe(struct platform_device *pdev)
ret = hwrng_register(&ddata->ops);
if (ret) {
dev_err(&pdev->dev, "Failed to register HW RNG\n");
+ clk_disable_unprepare(clk);
return ret;
}
^ permalink raw reply related
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