Re: [PATCH 0/4] crypto: nx - convert to skcipher API
On Sun, 13 Oct 2019 at 06:40, Eric Biggers wrote: > > This series converts the PowerPC Nest (NX) implementations of AES modes > from the deprecated "blkcipher" API to the "skcipher" API. This is > needed in order for the blkcipher API to be removed. > > This patchset is compile-tested only, as I don't have this hardware. > If anyone has this hardware, please test this patchset with > CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y. > > Eric Biggers (4): > crypto: nx - don't abuse blkcipher_desc to pass iv around > crypto: nx - convert AES-ECB to skcipher API > crypto: nx - convert AES-CBC to skcipher API > crypto: nx - convert AES-CTR to skcipher API > > drivers/crypto/nx/nx-aes-cbc.c | 81 ++- > drivers/crypto/nx/nx-aes-ccm.c | 40 ++-- > drivers/crypto/nx/nx-aes-ctr.c | 87 +++--- > drivers/crypto/nx/nx-aes-ecb.c | 76 + > drivers/crypto/nx/nx-aes-gcm.c | 24 -- > drivers/crypto/nx/nx.c | 64 ++--- > drivers/crypto/nx/nx.h | 19 > 7 files changed, 176 insertions(+), 215 deletions(-) > Hi Eric, Thanks for taking this on. I'll look in more detail at these patches during the week. In the meantime, I may have a stab at converting ccp, virtio-crypto and omap aes/des myself, since i have the hardware to test those. Thanks, Ard.
[PATCH 1/4] crypto: nx - don't abuse blkcipher_desc to pass iv around
From: Eric Biggers
The NX crypto driver is using 'struct blkcipher_desc' to pass the IV
around, even for AEADs (for which it creates the struct on the stack).
This is not appropriate since this structure is part of the "blkcipher"
API, which is deprecated and will be removed.
Just pass around the IV directly instead.
Signed-off-by: Eric Biggers
---
drivers/crypto/nx/nx-aes-cbc.c | 5 +++--
drivers/crypto/nx/nx-aes-ccm.c | 40 --
drivers/crypto/nx/nx-aes-ctr.c | 5 +++--
drivers/crypto/nx/nx-aes-ecb.c | 4 ++--
drivers/crypto/nx/nx-aes-gcm.c | 24 +---
drivers/crypto/nx/nx.c | 16 +++---
drivers/crypto/nx/nx.h | 6 ++---
7 files changed, 43 insertions(+), 57 deletions(-)
diff --git a/drivers/crypto/nx/nx-aes-cbc.c b/drivers/crypto/nx/nx-aes-cbc.c
index e631f9979127..482a203a9260 100644
--- a/drivers/crypto/nx/nx-aes-cbc.c
+++ b/drivers/crypto/nx/nx-aes-cbc.c
@@ -72,8 +72,9 @@ static int cbc_aes_nx_crypt(struct blkcipher_desc *desc,
do {
to_process = nbytes - processed;
- rc = nx_build_sg_lists(nx_ctx, desc, dst, src, &to_process,
- processed, csbcpb->cpb.aes_cbc.iv);
+ rc = nx_build_sg_lists(nx_ctx, desc->info, dst, src,
+ &to_process, processed,
+ csbcpb->cpb.aes_cbc.iv);
if (rc)
goto out;
diff --git a/drivers/crypto/nx/nx-aes-ccm.c b/drivers/crypto/nx/nx-aes-ccm.c
index 5be8f01c5da8..84fed736ed2e 100644
--- a/drivers/crypto/nx/nx-aes-ccm.c
+++ b/drivers/crypto/nx/nx-aes-ccm.c
@@ -327,7 +327,7 @@ static int generate_pat(u8 *iv,
}
static int ccm_nx_decrypt(struct aead_request *req,
- struct blkcipher_desc *desc,
+ u8*iv,
unsigned int assoclen)
{
struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(req->base.tfm);
@@ -348,7 +348,7 @@ static int ccm_nx_decrypt(struct aead_request *req,
req->src, nbytes + req->assoclen, authsize,
SCATTERWALK_FROM_SG);
- rc = generate_pat(desc->info, req, nx_ctx, authsize, nbytes, assoclen,
+ rc = generate_pat(iv, req, nx_ctx, authsize, nbytes, assoclen,
csbcpb->cpb.aes_ccm.in_pat_or_b0);
if (rc)
goto out;
@@ -367,7 +367,7 @@ static int ccm_nx_decrypt(struct aead_request *req,
NX_CPB_FDM(nx_ctx->csbcpb) &= ~NX_FDM_ENDE_ENCRYPT;
- rc = nx_build_sg_lists(nx_ctx, desc, req->dst, req->src,
+ rc = nx_build_sg_lists(nx_ctx, iv, req->dst, req->src,
&to_process, processed + req->assoclen,
csbcpb->cpb.aes_ccm.iv_or_ctr);
if (rc)
@@ -381,7 +381,7 @@ static int ccm_nx_decrypt(struct aead_request *req,
/* for partial completion, copy following for next
* entry into loop...
*/
- memcpy(desc->info, csbcpb->cpb.aes_ccm.out_ctr, AES_BLOCK_SIZE);
+ memcpy(iv, csbcpb->cpb.aes_ccm.out_ctr, AES_BLOCK_SIZE);
memcpy(csbcpb->cpb.aes_ccm.in_pat_or_b0,
csbcpb->cpb.aes_ccm.out_pat_or_mac, AES_BLOCK_SIZE);
memcpy(csbcpb->cpb.aes_ccm.in_s0,
@@ -405,7 +405,7 @@ static int ccm_nx_decrypt(struct aead_request *req,
}
static int ccm_nx_encrypt(struct aead_request *req,
- struct blkcipher_desc *desc,
+ u8*iv,
unsigned int assoclen)
{
struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(req->base.tfm);
@@ -418,7 +418,7 @@ static int ccm_nx_encrypt(struct aead_request *req,
spin_lock_irqsave(&nx_ctx->lock, irq_flags);
- rc = generate_pat(desc->info, req, nx_ctx, authsize, nbytes, assoclen,
+ rc = generate_pat(iv, req, nx_ctx, authsize, nbytes, assoclen,
csbcpb->cpb.aes_ccm.in_pat_or_b0);
if (rc)
goto out;
@@ -436,7 +436,7 @@ static int ccm_nx_encrypt(struct aead_request *req,
NX_CPB_FDM(csbcpb) |= NX_FDM_ENDE_ENCRYPT;
- rc = nx_build_sg_lists(nx_ctx, desc, req->dst, req->src,
+ rc = nx_build_sg_lists(nx_ctx, iv, req->dst, req->src,
&to_process, processed + req->assoclen,
csbcpb->cpb.aes_ccm.iv_or_ctr);
if (rc)
@@ -450,7 +450,7 @@ static int ccm_nx_encrypt(struct aead_request *req,
/* for partial completion, copy following for next
* entry into loop...
*/
- memcpy(desc->info, csbcpb->cpb.aes_ccm.out_ctr, AES_BLOCK_SIZE);
+
[PATCH 4/4] crypto: nx - convert AES-CTR to skcipher API
From: Eric Biggers
Convert the PowerPC Nest (NX) implementation of AES-CTR from the
deprecated "blkcipher" API to the "skcipher" API. This is needed in
order for the blkcipher API to be removed.
Signed-off-by: Eric Biggers
---
drivers/crypto/nx/nx-aes-ctr.c | 84 +++---
drivers/crypto/nx/nx.c | 25 +++---
drivers/crypto/nx/nx.h | 4 +-
3 files changed, 46 insertions(+), 67 deletions(-)
diff --git a/drivers/crypto/nx/nx-aes-ctr.c b/drivers/crypto/nx/nx-aes-ctr.c
index 05e558cefe94..6d5ce1a66f1e 100644
--- a/drivers/crypto/nx/nx-aes-ctr.c
+++ b/drivers/crypto/nx/nx-aes-ctr.c
@@ -19,11 +19,11 @@
#include "nx.h"
-static int ctr_aes_nx_set_key(struct crypto_tfm *tfm,
- const u8 *in_key,
- unsigned int key_len)
+static int ctr_aes_nx_set_key(struct crypto_skcipher *tfm,
+ const u8 *in_key,
+ unsigned intkey_len)
{
- struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(tfm);
+ struct nx_crypto_ctx *nx_ctx = crypto_skcipher_ctx(tfm);
struct nx_csbcpb *csbcpb = nx_ctx->csbcpb;
nx_ctx_init(nx_ctx, HCOP_FC_AES);
@@ -51,11 +51,11 @@ static int ctr_aes_nx_set_key(struct crypto_tfm *tfm,
return 0;
}
-static int ctr3686_aes_nx_set_key(struct crypto_tfm *tfm,
- const u8 *in_key,
- unsigned int key_len)
+static int ctr3686_aes_nx_set_key(struct crypto_skcipher *tfm,
+ const u8 *in_key,
+ unsigned intkey_len)
{
- struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(tfm);
+ struct nx_crypto_ctx *nx_ctx = crypto_skcipher_ctx(tfm);
if (key_len < CTR_RFC3686_NONCE_SIZE)
return -EINVAL;
@@ -69,12 +69,10 @@ static int ctr3686_aes_nx_set_key(struct crypto_tfm *tfm,
return ctr_aes_nx_set_key(tfm, in_key, key_len);
}
-static int ctr_aes_nx_crypt(struct blkcipher_desc *desc,
- struct scatterlist*dst,
- struct scatterlist*src,
- unsigned int nbytes)
+static int ctr_aes_nx_crypt(struct skcipher_request *req, u8 *iv)
{
- struct nx_crypto_ctx *nx_ctx = crypto_blkcipher_ctx(desc->tfm);
+ struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
+ struct nx_crypto_ctx *nx_ctx = crypto_skcipher_ctx(tfm);
struct nx_csbcpb *csbcpb = nx_ctx->csbcpb;
unsigned long irq_flags;
unsigned int processed = 0, to_process;
@@ -83,9 +81,9 @@ static int ctr_aes_nx_crypt(struct blkcipher_desc *desc,
spin_lock_irqsave(&nx_ctx->lock, irq_flags);
do {
- to_process = nbytes - processed;
+ to_process = req->cryptlen - processed;
- rc = nx_build_sg_lists(nx_ctx, desc->info, dst, src,
+ rc = nx_build_sg_lists(nx_ctx, iv, req->dst, req->src,
&to_process, processed,
csbcpb->cpb.aes_ctr.iv);
if (rc)
@@ -97,59 +95,51 @@ static int ctr_aes_nx_crypt(struct blkcipher_desc *desc,
}
rc = nx_hcall_sync(nx_ctx, &nx_ctx->op,
- desc->flags & CRYPTO_TFM_REQ_MAY_SLEEP);
+ req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP);
if (rc)
goto out;
- memcpy(desc->info, csbcpb->cpb.aes_cbc.cv, AES_BLOCK_SIZE);
+ memcpy(iv, csbcpb->cpb.aes_cbc.cv, AES_BLOCK_SIZE);
atomic_inc(&(nx_ctx->stats->aes_ops));
atomic64_add(csbcpb->csb.processed_byte_count,
&(nx_ctx->stats->aes_bytes));
processed += to_process;
- } while (processed < nbytes);
+ } while (processed < req->cryptlen);
out:
spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
-static int ctr3686_aes_nx_crypt(struct blkcipher_desc *desc,
- struct scatterlist*dst,
- struct scatterlist*src,
- unsigned int nbytes)
+static int ctr3686_aes_nx_crypt(struct skcipher_request *req)
{
- struct nx_crypto_ctx *nx_ctx = crypto_blkcipher_ctx(desc->tfm);
+ struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
+ struct nx_crypto_ctx *nx_ctx = crypto_skcipher_ctx(tfm);
u8 iv[16];
memcpy(iv, nx_ctx->priv.ctr.nonce, CTR_RFC3686_IV_SIZE);
- memcpy(iv + CTR_RFC3686_NONCE_SIZE,
- desc->info, CTR_RFC3686_IV_SIZE);
+ memcpy(iv + CTR_RFC3686_NONCE_SIZE, req->iv, CTR_RFC3686_IV_SIZE);
iv[12] = iv[13] = iv[14] = 0;
iv[15] = 1;
- d
[PATCH 0/4] crypto: nx - convert to skcipher API
This series converts the PowerPC Nest (NX) implementations of AES modes from the deprecated "blkcipher" API to the "skcipher" API. This is needed in order for the blkcipher API to be removed. This patchset is compile-tested only, as I don't have this hardware. If anyone has this hardware, please test this patchset with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y. Eric Biggers (4): crypto: nx - don't abuse blkcipher_desc to pass iv around crypto: nx - convert AES-ECB to skcipher API crypto: nx - convert AES-CBC to skcipher API crypto: nx - convert AES-CTR to skcipher API drivers/crypto/nx/nx-aes-cbc.c | 81 ++- drivers/crypto/nx/nx-aes-ccm.c | 40 ++-- drivers/crypto/nx/nx-aes-ctr.c | 87 +++--- drivers/crypto/nx/nx-aes-ecb.c | 76 + drivers/crypto/nx/nx-aes-gcm.c | 24 -- drivers/crypto/nx/nx.c | 64 ++--- drivers/crypto/nx/nx.h | 19 7 files changed, 176 insertions(+), 215 deletions(-) -- 2.23.0
[PATCH 3/4] crypto: nx - convert AES-CBC to skcipher API
From: Eric Biggers
Convert the PowerPC Nest (NX) implementation of AES-CBC from the
deprecated "blkcipher" API to the "skcipher" API. This is needed in
order for the blkcipher API to be removed.
Signed-off-by: Eric Biggers
---
drivers/crypto/nx/nx-aes-cbc.c | 78 ++
drivers/crypto/nx/nx.c | 11 ++---
drivers/crypto/nx/nx.h | 4 +-
3 files changed, 41 insertions(+), 52 deletions(-)
diff --git a/drivers/crypto/nx/nx-aes-cbc.c b/drivers/crypto/nx/nx-aes-cbc.c
index 482a203a9260..92e921eceed7 100644
--- a/drivers/crypto/nx/nx-aes-cbc.c
+++ b/drivers/crypto/nx/nx-aes-cbc.c
@@ -18,11 +18,11 @@
#include "nx.h"
-static int cbc_aes_nx_set_key(struct crypto_tfm *tfm,
- const u8 *in_key,
- unsigned int key_len)
+static int cbc_aes_nx_set_key(struct crypto_skcipher *tfm,
+ const u8 *in_key,
+ unsigned intkey_len)
{
- struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(tfm);
+ struct nx_crypto_ctx *nx_ctx = crypto_skcipher_ctx(tfm);
struct nx_csbcpb *csbcpb = nx_ctx->csbcpb;
nx_ctx_init(nx_ctx, HCOP_FC_AES);
@@ -50,13 +50,11 @@ static int cbc_aes_nx_set_key(struct crypto_tfm *tfm,
return 0;
}
-static int cbc_aes_nx_crypt(struct blkcipher_desc *desc,
- struct scatterlist*dst,
- struct scatterlist*src,
- unsigned int nbytes,
- intenc)
+static int cbc_aes_nx_crypt(struct skcipher_request *req,
+ int enc)
{
- struct nx_crypto_ctx *nx_ctx = crypto_blkcipher_ctx(desc->tfm);
+ struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
+ struct nx_crypto_ctx *nx_ctx = crypto_skcipher_ctx(tfm);
struct nx_csbcpb *csbcpb = nx_ctx->csbcpb;
unsigned long irq_flags;
unsigned int processed = 0, to_process;
@@ -70,9 +68,9 @@ static int cbc_aes_nx_crypt(struct blkcipher_desc *desc,
NX_CPB_FDM(csbcpb) &= ~NX_FDM_ENDE_ENCRYPT;
do {
- to_process = nbytes - processed;
+ to_process = req->cryptlen - processed;
- rc = nx_build_sg_lists(nx_ctx, desc->info, dst, src,
+ rc = nx_build_sg_lists(nx_ctx, req->iv, req->dst, req->src,
&to_process, processed,
csbcpb->cpb.aes_cbc.iv);
if (rc)
@@ -84,56 +82,46 @@ static int cbc_aes_nx_crypt(struct blkcipher_desc *desc,
}
rc = nx_hcall_sync(nx_ctx, &nx_ctx->op,
- desc->flags & CRYPTO_TFM_REQ_MAY_SLEEP);
+ req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP);
if (rc)
goto out;
- memcpy(desc->info, csbcpb->cpb.aes_cbc.cv, AES_BLOCK_SIZE);
+ memcpy(req->iv, csbcpb->cpb.aes_cbc.cv, AES_BLOCK_SIZE);
atomic_inc(&(nx_ctx->stats->aes_ops));
atomic64_add(csbcpb->csb.processed_byte_count,
&(nx_ctx->stats->aes_bytes));
processed += to_process;
- } while (processed < nbytes);
+ } while (processed < req->cryptlen);
out:
spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
-static int cbc_aes_nx_encrypt(struct blkcipher_desc *desc,
- struct scatterlist*dst,
- struct scatterlist*src,
- unsigned int nbytes)
+static int cbc_aes_nx_encrypt(struct skcipher_request *req)
{
- return cbc_aes_nx_crypt(desc, dst, src, nbytes, 1);
+ return cbc_aes_nx_crypt(req, 1);
}
-static int cbc_aes_nx_decrypt(struct blkcipher_desc *desc,
- struct scatterlist*dst,
- struct scatterlist*src,
- unsigned int nbytes)
+static int cbc_aes_nx_decrypt(struct skcipher_request *req)
{
- return cbc_aes_nx_crypt(desc, dst, src, nbytes, 0);
+ return cbc_aes_nx_crypt(req, 0);
}
-struct crypto_alg nx_cbc_aes_alg = {
- .cra_name= "cbc(aes)",
- .cra_driver_name = "cbc-aes-nx",
- .cra_priority= 300,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
- .cra_blocksize = AES_BLOCK_SIZE,
- .cra_ctxsize = sizeof(struct nx_crypto_ctx),
- .cra_type= &crypto_blkcipher_type,
- .cra_alignmask = 0xf,
- .cra_module = THIS_MODULE,
- .cra_init= nx_crypto_ctx_aes_cbc_init,
- .cra_exit= nx_crypto_ctx_exit,
- .cra_blkcipher = {
- .min_keysize = AES_MIN_KEY_SIZE,
- .max_keysize =
[PATCH 2/4] crypto: nx - convert AES-ECB to skcipher API
From: Eric Biggers
Convert the PowerPC Nest (NX) implementation of AES-ECB from the
deprecated "blkcipher" API to the "skcipher" API. This is needed in
order for the blkcipher API to be removed.
Signed-off-by: Eric Biggers
---
drivers/crypto/nx/nx-aes-ecb.c | 76 ++
drivers/crypto/nx/nx.c | 28 ++---
drivers/crypto/nx/nx.h | 5 ++-
3 files changed, 58 insertions(+), 51 deletions(-)
diff --git a/drivers/crypto/nx/nx-aes-ecb.c b/drivers/crypto/nx/nx-aes-ecb.c
index 87183890d1ab..77e338dc33f1 100644
--- a/drivers/crypto/nx/nx-aes-ecb.c
+++ b/drivers/crypto/nx/nx-aes-ecb.c
@@ -18,11 +18,11 @@
#include "nx.h"
-static int ecb_aes_nx_set_key(struct crypto_tfm *tfm,
- const u8 *in_key,
- unsigned int key_len)
+static int ecb_aes_nx_set_key(struct crypto_skcipher *tfm,
+ const u8 *in_key,
+ unsigned intkey_len)
{
- struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(tfm);
+ struct nx_crypto_ctx *nx_ctx = crypto_skcipher_ctx(tfm);
struct nx_csbcpb *csbcpb = (struct nx_csbcpb *)nx_ctx->csbcpb;
nx_ctx_init(nx_ctx, HCOP_FC_AES);
@@ -50,13 +50,11 @@ static int ecb_aes_nx_set_key(struct crypto_tfm *tfm,
return 0;
}
-static int ecb_aes_nx_crypt(struct blkcipher_desc *desc,
- struct scatterlist*dst,
- struct scatterlist*src,
- unsigned int nbytes,
- intenc)
+static int ecb_aes_nx_crypt(struct skcipher_request *req,
+ int enc)
{
- struct nx_crypto_ctx *nx_ctx = crypto_blkcipher_ctx(desc->tfm);
+ struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
+ struct nx_crypto_ctx *nx_ctx = crypto_skcipher_ctx(tfm);
struct nx_csbcpb *csbcpb = nx_ctx->csbcpb;
unsigned long irq_flags;
unsigned int processed = 0, to_process;
@@ -70,10 +68,10 @@ static int ecb_aes_nx_crypt(struct blkcipher_desc *desc,
NX_CPB_FDM(csbcpb) &= ~NX_FDM_ENDE_ENCRYPT;
do {
- to_process = nbytes - processed;
+ to_process = req->cryptlen - processed;
- rc = nx_build_sg_lists(nx_ctx, NULL, dst, src, &to_process,
- processed, NULL);
+ rc = nx_build_sg_lists(nx_ctx, NULL, req->dst, req->src,
+ &to_process, processed, NULL);
if (rc)
goto out;
@@ -83,7 +81,7 @@ static int ecb_aes_nx_crypt(struct blkcipher_desc *desc,
}
rc = nx_hcall_sync(nx_ctx, &nx_ctx->op,
- desc->flags & CRYPTO_TFM_REQ_MAY_SLEEP);
+ req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP);
if (rc)
goto out;
@@ -92,46 +90,36 @@ static int ecb_aes_nx_crypt(struct blkcipher_desc *desc,
&(nx_ctx->stats->aes_bytes));
processed += to_process;
- } while (processed < nbytes);
+ } while (processed < req->cryptlen);
out:
spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
-static int ecb_aes_nx_encrypt(struct blkcipher_desc *desc,
- struct scatterlist*dst,
- struct scatterlist*src,
- unsigned int nbytes)
+static int ecb_aes_nx_encrypt(struct skcipher_request *req)
{
- return ecb_aes_nx_crypt(desc, dst, src, nbytes, 1);
+ return ecb_aes_nx_crypt(req, 1);
}
-static int ecb_aes_nx_decrypt(struct blkcipher_desc *desc,
- struct scatterlist*dst,
- struct scatterlist*src,
- unsigned int nbytes)
+static int ecb_aes_nx_decrypt(struct skcipher_request *req)
{
- return ecb_aes_nx_crypt(desc, dst, src, nbytes, 0);
+ return ecb_aes_nx_crypt(req, 0);
}
-struct crypto_alg nx_ecb_aes_alg = {
- .cra_name= "ecb(aes)",
- .cra_driver_name = "ecb-aes-nx",
- .cra_priority= 300,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
- .cra_blocksize = AES_BLOCK_SIZE,
- .cra_alignmask = 0xf,
- .cra_ctxsize = sizeof(struct nx_crypto_ctx),
- .cra_type= &crypto_blkcipher_type,
- .cra_module = THIS_MODULE,
- .cra_init= nx_crypto_ctx_aes_ecb_init,
- .cra_exit= nx_crypto_ctx_exit,
- .cra_blkcipher = {
- .min_keysize = AES_MIN_KEY_SIZE,
- .max_keysize = AES_MAX_KEY_SIZE,
- .setkey = ecb_aes_nx_set_key,
- .encrypt = ecb_aes_nx_encrypt
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.4-3 tag
The pull request you sent on Sat, 12 Oct 2019 22:37:15 +1100: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-5.4-3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/db60a5a035aa8692dc7cee293356bdcc078fa7b7 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[GIT PULL] Please pull powerpc/linux.git powerpc-5.4-3 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull some more powerpc fixes for 5.4: The following changes since commit da0c9ea146cbe92b832f1b0f694840ea8eb33cce: Linux 5.4-rc2 (2019-10-06 14:27:30 -0700) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.4-3 for you to fetch changes up to 2272905a4580f26630f7d652cc33935b59f96d4c: spufs: fix a crash in spufs_create_root() (2019-10-11 16:57:41 +1100) - -- powerpc fixes for 5.4 #3 Fix a kernel crash in spufs_create_root() on Cell machines, since the new mount API went in. Fix a regression in our KVM code caused by our recent PCR changes. Avoid a warning message about a failing hypervisor API on systems that don't have that API. A couple of minor build fixes. Thanks to: Alexey Kardashevskiy, Alistair Popple, Desnes A. Nunes do Rosario, Emmanuel Nicolet, Jordan Niethe, Laurent Dufour, Stephen Rothwell. - -- Desnes A. Nunes do Rosario (1): selftests/powerpc: Fix compile error on tlbie_test due to newer gcc Emmanuel Nicolet (1): spufs: fix a crash in spufs_create_root() Jordan Niethe (1): powerpc/kvm: Fix kvmppc_vcore->in_guest value in kvmhv_switch_to_host Laurent Dufour (1): powerpc/pseries: Remove confusing warning message. Stephen Rothwell (1): powerpc/64s/radix: Fix build failure with RADIX_MMU=n arch/powerpc/include/asm/book3s/64/tlbflush-radix.h | 4 arch/powerpc/kvm/book3s_hv_rmhandlers.S | 1 + arch/powerpc/platforms/cell/spufs/inode.c | 1 + arch/powerpc/platforms/pseries/lpar.c | 3 +++ tools/testing/selftests/powerpc/mm/tlbie_test.c | 2 +- 5 files changed, 10 insertions(+), 1 deletion(-) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAl2hsbMACgkQUevqPMjh pYAvTg//SxycPkVZLln4SzXGj3f8dHyFUJS+796BXAyIS2ylIqRYFTvj9Uqfry/w leCvU0xgB1LC0FTP2FCB9/q4GluB5uxkM32ziNFDSrPdfhtsV+WM4312ytrQEeLe 838D009gkDgd2NDxg0titW5pAq1oP7iwSilPKzZrb3pejJcHLK+qZ6+2SKefuXRs Sn3nRT2yBJZqq1ECJjCH+mP/QGndf4sjyHQD43yTIT+SxKrnOWDEOqUCxHduhcYh R2sof4pv5aC43b85C609D+yUi/VTbeHdrj8dbKHKHXmcDCmyRsYPpSNxd/irmLMr c5hKbD0Nwu8p/TDv+NcjxA5w6Mf2Jo+btSPxTKErFpFCmbwQeM9OyUmLhpjKcbZl PW8ArrMRkz0ypRhbDJz0oMp7mHLOWXwy0F8bxm96VoNgM8QpqJVwEh6J1O2DWzJY Nwfc9nMKKtJNuQGWvpADvylIjbCPAUzl70vlPDEytx6JMu3JS/WwMfqqH4PQrGIs BUllm98MBY9FrQFAVxnOPvpB16IQbsfKk/Vf1CY4RLYwIDfErA3sHXvnO0UepAtE HEW/WF3VnRrU3wGdk2mHDVNyEwY7UIm6xp1QEcQDebLAS0bXdRhUmyrG9IBHOLLO 43UGwtlMKMf87ebx+Ps1l8Ih3bpwwFw+YJySMwQdhgF9CQOdXzY= =2HLb -END PGP SIGNATURE-
Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware
On Sat, Oct 12, 2019 at 12:40:01PM +0200, Greg KH wrote: > On Sat, Oct 12, 2019 at 05:47:56PM +0800, Yunsheng Lin wrote: > > On 2019/10/12 15:40, Greg KH wrote: > > > On Sat, Oct 12, 2019 at 02:17:26PM +0800, Yunsheng Lin wrote: > > >> add pci and acpi maintainer > > >> cc linux-...@vger.kernel.org and linux-a...@vger.kernel.org > > >> > > >> On 2019/10/11 19:15, Peter Zijlstra wrote: > > >>> On Fri, Oct 11, 2019 at 11:27:54AM +0800, Yunsheng Lin wrote: > > But I failed to see why the above is related to making > > node_to_cpumask_map() > > NUMA_NO_NODE aware? > > >>> > > >>> Your initial bug is for hns3, which is a PCI device, which really _MUST_ > > >>> have a node assigned. > > >>> > > >>> It not having one, is a straight up bug. We must not silently accept > > >>> NO_NODE there, ever. > > >>> > > >> > > >> I suppose you mean reporting a lack of affinity when the node of a pcie > > >> device is not set by "not silently accept NO_NODE". > > > > > > If the firmware of a pci device does not provide the node information, > > > then yes, warn about that. > > > > > >> As Greg has asked about in [1]: > > >> what is a user to do when the user sees the kernel reporting that? > > >> > > >> We may tell user to contact their vendor for info or updates about > > >> that when they do not know about their system well enough, but their > > >> vendor may get away with this by quoting ACPI spec as the spec > > >> considering this optional. Should the user believe this is indeed a > > >> fw bug or a misreport from the kernel? > > > > > > Say it is a firmware bug, if it is a firmware bug, that's simple. > > > > > >> If this kind of reporting is common pratice and will not cause any > > >> misunderstanding, then maybe we can report that. > > > > > > Yes, please do so, that's the only way those boxes are ever going to get > > > fixed. And go add the test to the "firmware testing" tool that is based > > > on Linux that Intel has somewhere, to give vendors a chance to fix this > > > before they ship hardware. > > > > > > This shouldn't be a big deal, we warn of other hardware bugs all the > > > time. > > > > Ok, thanks for clarifying. > > > > Will send a patch to catch the case when a pcie device without numa node > > being set and warn about it. > > > > Maybe use dev->bus to verify if it is a pci device? > > No, do that in the pci bus core code itself, when creating the devices > as that is when you know, or do not know, the numa node, right? > > This can't be in the driver core only, as each bus type will have a > different way of determining what the node the device is on. For some > reason, I thought the PCI core code already does this, right? Yes, pci_irq_get_node(), which NO ONE CALLS! I should go delete that thing... Anyway, it looks like the pci core code does call set_dev_node() based on the PCI bridge, so if that is set up properly, all should be fine. If not, well, you have buggy firmware and you need to warn about that at the time you are creating the bridge. Look at the call to pcibus_to_node() in pci_register_host_bridge(). And yes, you need to do this all on a per-bus-type basis, as has been pointed out. It's up to the bus to create the device and set this up properly. thanks, greg k-h
Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware
On Sat, Oct 12, 2019 at 05:47:56PM +0800, Yunsheng Lin wrote: > On 2019/10/12 15:40, Greg KH wrote: > > On Sat, Oct 12, 2019 at 02:17:26PM +0800, Yunsheng Lin wrote: > >> add pci and acpi maintainer > >> cc linux-...@vger.kernel.org and linux-a...@vger.kernel.org > >> > >> On 2019/10/11 19:15, Peter Zijlstra wrote: > >>> On Fri, Oct 11, 2019 at 11:27:54AM +0800, Yunsheng Lin wrote: > But I failed to see why the above is related to making > node_to_cpumask_map() > NUMA_NO_NODE aware? > >>> > >>> Your initial bug is for hns3, which is a PCI device, which really _MUST_ > >>> have a node assigned. > >>> > >>> It not having one, is a straight up bug. We must not silently accept > >>> NO_NODE there, ever. > >>> > >> > >> I suppose you mean reporting a lack of affinity when the node of a pcie > >> device is not set by "not silently accept NO_NODE". > > > > If the firmware of a pci device does not provide the node information, > > then yes, warn about that. > > > >> As Greg has asked about in [1]: > >> what is a user to do when the user sees the kernel reporting that? > >> > >> We may tell user to contact their vendor for info or updates about > >> that when they do not know about their system well enough, but their > >> vendor may get away with this by quoting ACPI spec as the spec > >> considering this optional. Should the user believe this is indeed a > >> fw bug or a misreport from the kernel? > > > > Say it is a firmware bug, if it is a firmware bug, that's simple. > > > >> If this kind of reporting is common pratice and will not cause any > >> misunderstanding, then maybe we can report that. > > > > Yes, please do so, that's the only way those boxes are ever going to get > > fixed. And go add the test to the "firmware testing" tool that is based > > on Linux that Intel has somewhere, to give vendors a chance to fix this > > before they ship hardware. > > > > This shouldn't be a big deal, we warn of other hardware bugs all the > > time. > > Ok, thanks for clarifying. > > Will send a patch to catch the case when a pcie device without numa node > being set and warn about it. > > Maybe use dev->bus to verify if it is a pci device? No, do that in the pci bus core code itself, when creating the devices as that is when you know, or do not know, the numa node, right? This can't be in the driver core only, as each bus type will have a different way of determining what the node the device is on. For some reason, I thought the PCI core code already does this, right? thanks, greg k-h
Re: [PATCH] powerpc/papr_scm: Fix an off-by-one check in papr_scm_meta_{get, set}
On Fri, 2019-09-27 at 06:20:02 UTC, Vaibhav Jain wrote:
> A validation check to prevent out of bounds read/write inside
> functions papr_scm_meta_{get,set}() is off-by-one that prevent reads
> and writes to the last byte of the label area.
>
> This bug manifests as a failure to probe a dimm when libnvdimm is
> unable to read the entire config-area as advertised by
> ND_CMD_GET_CONFIG_SIZE. This usually happens when there are large
> number of namespaces created in the region backed by the dimm and the
> label-index spans max possible config-area. An error of the form below
> usually reported in the kernel logs:
>
> [ 255.293912] nvdimm: probe of nmem0 failed with error -22
>
> The patch fixes these validation checks there by letting libnvdimm
> access the entire config-area.
>
> Fixes: 53e80bd042773('powerpc/nvdimm: Add support for multibyte read/write
> for metadata')
> Signed-off-by: Vaibhav Jain
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/612ee81b9461475b5a5612c2e8d71559dd3c7920
cheers
Re: [PATCH v2 23/29] parisc: Move EXCEPTION_TABLE to RO_DATA segment
On 11.10.19 02:06, Kees Cook wrote:
Since the EXCEPTION_TABLE is read-only, collapse it into RO_DATA.
Signed-off-by: Kees Cook
---
arch/parisc/kernel/vmlinux.lds.S | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
Acked-by: Helge Deller # parisc
Helge
diff --git a/arch/parisc/kernel/vmlinux.lds.S b/arch/parisc/kernel/vmlinux.lds.S
index 12b3d7d5e9e4..53e29d88f99c 100644
--- a/arch/parisc/kernel/vmlinux.lds.S
+++ b/arch/parisc/kernel/vmlinux.lds.S
@@ -19,6 +19,7 @@
*(.data..vm0.pte)
#define CC_USING_PATCHABLE_FUNCTION_ENTRY
+#define RO_EXCEPTION_TABLE_ALIGN 8
#include
@@ -129,9 +130,6 @@ SECTIONS
RO_DATA(8)
- /* RO because of BUILDTIME_EXTABLE_SORT */
- EXCEPTION_TABLE(8)
-
/* unwind info */
.PARISC.unwind : {
__start___unwind = .;
Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware
On 2019/10/12 15:40, Greg KH wrote: > On Sat, Oct 12, 2019 at 02:17:26PM +0800, Yunsheng Lin wrote: >> add pci and acpi maintainer >> cc linux-...@vger.kernel.org and linux-a...@vger.kernel.org >> >> On 2019/10/11 19:15, Peter Zijlstra wrote: >>> On Fri, Oct 11, 2019 at 11:27:54AM +0800, Yunsheng Lin wrote: But I failed to see why the above is related to making node_to_cpumask_map() NUMA_NO_NODE aware? >>> >>> Your initial bug is for hns3, which is a PCI device, which really _MUST_ >>> have a node assigned. >>> >>> It not having one, is a straight up bug. We must not silently accept >>> NO_NODE there, ever. >>> >> >> I suppose you mean reporting a lack of affinity when the node of a pcie >> device is not set by "not silently accept NO_NODE". > > If the firmware of a pci device does not provide the node information, > then yes, warn about that. > >> As Greg has asked about in [1]: >> what is a user to do when the user sees the kernel reporting that? >> >> We may tell user to contact their vendor for info or updates about >> that when they do not know about their system well enough, but their >> vendor may get away with this by quoting ACPI spec as the spec >> considering this optional. Should the user believe this is indeed a >> fw bug or a misreport from the kernel? > > Say it is a firmware bug, if it is a firmware bug, that's simple. > >> If this kind of reporting is common pratice and will not cause any >> misunderstanding, then maybe we can report that. > > Yes, please do so, that's the only way those boxes are ever going to get > fixed. And go add the test to the "firmware testing" tool that is based > on Linux that Intel has somewhere, to give vendors a chance to fix this > before they ship hardware. > > This shouldn't be a big deal, we warn of other hardware bugs all the > time. Ok, thanks for clarifying. Will send a patch to catch the case when a pcie device without numa node being set and warn about it. Maybe use dev->bus to verify if it is a pci device? > > thanks, > > greg k-h > > . >
Re: [PATCH v4 0/5] Powerpc/Watchpoint: Few important fixes
Le 10/10/2019 à 06:44, Ravi Bangoria a écrit : @Christophe, Is patch5 works for you on 8xx? Getting the following : root@vgoip:~# ./ptrace-hwbreak test: ptrace-hwbreak tags: git_version:v5.4-rc2-710-gf0082e173fe4-dirty PTRACE_SET_DEBUGREG, WO, len: 1: Ok PTRACE_SET_DEBUGREG, WO, len: 2: Ok PTRACE_SET_DEBUGREG, WO, len: 4: Ok PTRACE_SET_DEBUGREG, WO, len: 8: Ok PTRACE_SET_DEBUGREG, RO, len: 1: Ok PTRACE_SET_DEBUGREG, RO, len: 2: Ok PTRACE_SET_DEBUGREG, RO, len: 4: Ok PTRACE_SET_DEBUGREG, RO, len: 8: Ok PTRACE_SET_DEBUGREG, RW, len: 1: Ok PTRACE_SET_DEBUGREG, RW, len: 2: Ok PTRACE_SET_DEBUGREG, RW, len: 4: Ok PTRACE_SET_DEBUGREG, RW, len: 8: Ok PPC_PTRACE_SETHWDEBUG, MODE_EXACT, WO, len: 1: Ok PPC_PTRACE_SETHWDEBUG, MODE_EXACT, RO, len: 1: Ok PPC_PTRACE_SETHWDEBUG, MODE_EXACT, RW, len: 1: Ok PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW ALIGNED, WO, len: 6: Ok PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW ALIGNED, RO, len: 6: Fail failure: ptrace-hwbreak I also tried on a 83xx (book3s/32). This one has a regular DABR : root@vgoippro:~# ./ptrace-hwbreak test: ptrace-hwbreak tags: git_version:v5.4-rc2-710-gf0082e173fe4-dirty PTRACE_SET_DEBUGREG, WO, len: 1: Ok PTRACE_SET_DEBUGREG, WO, len: 2: Ok PTRACE_SET_DEBUGREG, WO, len: 4: Ok PTRACE_SET_DEBUGREG, WO, len: 8: Ok PTRACE_SET_DEBUGREG, RO, len: 1: Ok PTRACE_SET_DEBUGREG, RO, len: 2: Ok PTRACE_SET_DEBUGREG, RO, len: 4: Ok PTRACE_SET_DEBUGREG, RO, len: 8: Ok PTRACE_SET_DEBUGREG, RW, len: 1: Ok PTRACE_SET_DEBUGREG, RW, len: 2: Ok PTRACE_SET_DEBUGREG, RW, len: 4: Ok PTRACE_SET_DEBUGREG, RW, len: 8: Ok PPC_PTRACE_SETHWDEBUG, MODE_EXACT, WO, len: 1: Ok PPC_PTRACE_SETHWDEBUG, MODE_EXACT, RO, len: 1: Ok PPC_PTRACE_SETHWDEBUG, MODE_EXACT, RW, len: 1: Ok PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW ALIGNED, WO, len: 6: Ok PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW ALIGNED, RO, len: 6: Ok PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW ALIGNED, RW, len: 6: Ok PPC_PTRACE_SETHWDEBUG failed: Invalid argument failure: ptrace-hwbreak Christophe
Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware
On Sat, Oct 12, 2019 at 02:17:26PM +0800, Yunsheng Lin wrote: > add pci and acpi maintainer > cc linux-...@vger.kernel.org and linux-a...@vger.kernel.org > > On 2019/10/11 19:15, Peter Zijlstra wrote: > > On Fri, Oct 11, 2019 at 11:27:54AM +0800, Yunsheng Lin wrote: > >> But I failed to see why the above is related to making > >> node_to_cpumask_map() > >> NUMA_NO_NODE aware? > > > > Your initial bug is for hns3, which is a PCI device, which really _MUST_ > > have a node assigned. > > > > It not having one, is a straight up bug. We must not silently accept > > NO_NODE there, ever. > > > > I suppose you mean reporting a lack of affinity when the node of a pcie > device is not set by "not silently accept NO_NODE". If the firmware of a pci device does not provide the node information, then yes, warn about that. > As Greg has asked about in [1]: > what is a user to do when the user sees the kernel reporting that? > > We may tell user to contact their vendor for info or updates about > that when they do not know about their system well enough, but their > vendor may get away with this by quoting ACPI spec as the spec > considering this optional. Should the user believe this is indeed a > fw bug or a misreport from the kernel? Say it is a firmware bug, if it is a firmware bug, that's simple. > If this kind of reporting is common pratice and will not cause any > misunderstanding, then maybe we can report that. Yes, please do so, that's the only way those boxes are ever going to get fixed. And go add the test to the "firmware testing" tool that is based on Linux that Intel has somewhere, to give vendors a chance to fix this before they ship hardware. This shouldn't be a big deal, we warn of other hardware bugs all the time. thanks, greg k-h
Re: [PATCH v4 0/5] Powerpc/Watchpoint: Few important fixes
Le 10/10/2019 à 08:25, Ravi Bangoria a écrit : On 10/10/19 10:14 AM, Ravi Bangoria wrote: @Christophe, Is patch5 works for you on 8xx? Getting the following : root@vgoip:~# ./ptrace-hwbreak test: ptrace-hwbreak tags: git_version:v5.4-rc2-710-gf0082e173fe4-dirty PTRACE_SET_DEBUGREG, WO, len: 1: Ok PTRACE_SET_DEBUGREG, WO, len: 2: Ok PTRACE_SET_DEBUGREG, WO, len: 4: Ok PTRACE_SET_DEBUGREG, WO, len: 8: Ok PTRACE_SET_DEBUGREG, RO, len: 1: Ok PTRACE_SET_DEBUGREG, RO, len: 2: Ok PTRACE_SET_DEBUGREG, RO, len: 4: Ok PTRACE_SET_DEBUGREG, RO, len: 8: Ok PTRACE_SET_DEBUGREG, RW, len: 1: Ok PTRACE_SET_DEBUGREG, RW, len: 2: Ok PTRACE_SET_DEBUGREG, RW, len: 4: Ok PTRACE_SET_DEBUGREG, RW, len: 8: Ok PPC_PTRACE_SETHWDEBUG, MODE_EXACT, WO, len: 1: Ok PPC_PTRACE_SETHWDEBUG, MODE_EXACT, RO, len: 1: Ok PPC_PTRACE_SETHWDEBUG, MODE_EXACT, RW, len: 1: Ok PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW ALIGNED, WO, len: 6: Ok PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW ALIGNED, RO, len: 6: Fail failure: ptrace-hwbreak Thanks Christophe. I don't have any 8xx box. I checked qemu and it seems qemu emulation for 8xx is not yet supported. So I can't debug this. Can you please check why it's failing? PPC_PTRACE_SETHWDEBUG internally uses DAWR register and probably 8xx does not emulate DAWR logic, it only uses DABR to emulate double-word watchpoint. In that case, all testcases that uses PPC_PTRACE_SETHWDEBUG should be disabled for 8xx. I'll change [PATCH 5] accordingly and resend. I think the MODE_EXACT ones are OK with the 8xx at the time being. Also, do you think I should fix hw_breakpoint_validate_len() from [PARCH 1] for 8xx? I re-checked you recent patch* to allow any address range size for 8xx. With that patch, hw_breakpoint_validate_len() won't get called at all for 8xx. At the time being, the 8xx emulates DABR so it has the same limitations as BOOK3S. My patch needs to be rebased on top of your series and I think it needs some modifications, as it seems it doesn't properly handle size 1 and size 2 breakpoints at least. So I think that you should leave your Patch1 as is, and I'll modify the validate_len() logic while rebasing my patch. Christophe
