From: Jan Glauber <jan.glauber@caviumnetworks.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S . Miller" <davem@davemloft.net>,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
Mahipal Challa <Mahipal.Challa@cavium.com>,
Robert Richter <rrichter@cavium.com>,
stable <stable@vger.kernel.org>
Subject: Re: [PATCH 1/2] crypto: thunderx_zip: Fix fallout from CONFIG_VMAP_STACK
Date: Thu, 5 Apr 2018 10:40:18 +0200 [thread overview]
Message-ID: <20180405084018.GB24281@hc> (raw)
In-Reply-To: <20180328130557.10560-1-jglauber@cavium.com>
On Wed, Mar 28, 2018 at 03:05:56PM +0200, Jan Glauber wrote:
> Enabling virtual mapped kernel stacks breaks the thunderx_zip
> driver. On compression or decompression the executing CPU hangs
> in an endless loop. The reason for this is the usage of __pa
> by the driver which does no longer work for an address that is
> not part of the 1:1 mapping.
>
> The zip driver allocates a result struct on the stack and needs
> to tell the hardware the physical address within this struct
> that is used to signal the completion of the request.
>
> As the hardware gets the wrong address after the broken __pa
> conversion it writes to an arbitrary address. The zip driver then
> waits forever for the completion byte to contain a non-zero value.
>
> Allocating the result struct from 1:1 mapped memory resolves this
> bug.
Hi Herbert,
Just realized that we might sleep in this path, so GFP_KERNEL wont
work here. Same with usleep in the second patch.
I'll respin the patches.
--Jan
> Signed-off-by: Jan Glauber <jglauber@cavium.com>
> Reviewed-by: Robert Richter <rrichter@cavium.com>
> Cc: stable <stable@vger.kernel.org> # 4.14
> ---
> drivers/crypto/cavium/zip/zip_crypto.c | 22 ++++++++++++++--------
> 1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/crypto/cavium/zip/zip_crypto.c b/drivers/crypto/cavium/zip/zip_crypto.c
> index 8df4d26..2fc9b03 100644
> --- a/drivers/crypto/cavium/zip/zip_crypto.c
> +++ b/drivers/crypto/cavium/zip/zip_crypto.c
> @@ -124,7 +124,7 @@ int zip_compress(const u8 *src, unsigned int slen,
> struct zip_kernel_ctx *zip_ctx)
> {
> struct zip_operation *zip_ops = NULL;
> - struct zip_state zip_state;
> + struct zip_state *zip_state;
> struct zip_device *zip = NULL;
> int ret;
>
> @@ -135,20 +135,23 @@ int zip_compress(const u8 *src, unsigned int slen,
> if (!zip)
> return -ENODEV;
>
> - memset(&zip_state, 0, sizeof(struct zip_state));
> + zip_state = kzalloc(sizeof(*zip_state), GFP_KERNEL);
> + if (!zip_state)
> + return -ENOMEM;
> +
> zip_ops = &zip_ctx->zip_comp;
>
> zip_ops->input_len = slen;
> zip_ops->output_len = *dlen;
> memcpy(zip_ops->input, src, slen);
>
> - ret = zip_deflate(zip_ops, &zip_state, zip);
> + ret = zip_deflate(zip_ops, zip_state, zip);
>
> if (!ret) {
> *dlen = zip_ops->output_len;
> memcpy(dst, zip_ops->output, *dlen);
> }
> -
> + kfree(zip_state);
> return ret;
> }
>
> @@ -157,7 +160,7 @@ int zip_decompress(const u8 *src, unsigned int slen,
> struct zip_kernel_ctx *zip_ctx)
> {
> struct zip_operation *zip_ops = NULL;
> - struct zip_state zip_state;
> + struct zip_state *zip_state;
> struct zip_device *zip = NULL;
> int ret;
>
> @@ -168,7 +171,10 @@ int zip_decompress(const u8 *src, unsigned int slen,
> if (!zip)
> return -ENODEV;
>
> - memset(&zip_state, 0, sizeof(struct zip_state));
> + zip_state = kzalloc(sizeof(*zip_state), GFP_KERNEL);
> + if (!zip_state)
> + return -ENOMEM;
> +
> zip_ops = &zip_ctx->zip_decomp;
> memcpy(zip_ops->input, src, slen);
>
> @@ -179,13 +185,13 @@ int zip_decompress(const u8 *src, unsigned int slen,
> zip_ops->input_len = slen;
> zip_ops->output_len = *dlen;
>
> - ret = zip_inflate(zip_ops, &zip_state, zip);
> + ret = zip_inflate(zip_ops, zip_state, zip);
>
> if (!ret) {
> *dlen = zip_ops->output_len;
> memcpy(dst, zip_ops->output, *dlen);
> }
> -
> + kfree(zip_state);
> return ret;
> }
>
> --
> 2.7.4
prev parent reply other threads:[~2018-04-05 8:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-28 13:05 [PATCH 1/2] crypto: thunderx_zip: Fix fallout from CONFIG_VMAP_STACK Jan Glauber
2018-03-28 13:05 ` [PATCH 2/2] crypto: thunderx_zip: Limit result reading attempts Jan Glauber
2018-04-05 8:40 ` Jan Glauber [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180405084018.GB24281@hc \
--to=jan.glauber@caviumnetworks.com \
--cc=Mahipal.Challa@cavium.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rrichter@cavium.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox