Re: linux/bitops.h
On May 6, 2016 1:07:13 PM PDT, Sasha Levin wrote: >On 05/04/2016 08:30 PM, H. Peter Anvin wrote: >> On 05/04/16 15:06, John Denker wrote: >>> On 05/04/2016 02:56 PM, H. Peter Anvin wrote: > Beware that shifting by an amount >= the number of bits in the > word remains Undefined Behavior. >>> This construct has been supported as a rotate since at least gcc2. >>> >>> How then should we understand the story told in commit d7e35dfa? >>> Is the story wrong? >>> >>> At the very least, something inconsistent is going on. There >>> are 8 functions. Why did d7e35dfa change one of them but >>> not the other 7? >> >> Yes. d7e35dfa is baloney IMNSHO. All it does is produce worse code, >and the description even says so. > >No, the description says that it produces worse code for *really >really* ancient >GCC versions. > >> As I said, gcc has treated the former code as idiomatic since gcc 2, >so that support is beyond ancient. > >Because something works in a specific way on one compiler isn't a >reason to >ignore this noncompliance with the standard. > > >Thanks, >Sasha When the compiler in question is our flagship target and our reference compiler, then yes, it matters. -- Sent from my Android device with K-9 Mail. Please excuse brevity and formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux/bitops.h
On May 6, 2016 1:07:13 PM PDT, Sasha Levin wrote: >On 05/04/2016 08:30 PM, H. Peter Anvin wrote: >> On 05/04/16 15:06, John Denker wrote: >>> On 05/04/2016 02:56 PM, H. Peter Anvin wrote: > Beware that shifting by an amount >= the number of bits in the > word remains Undefined Behavior. >>> This construct has been supported as a rotate since at least gcc2. >>> >>> How then should we understand the story told in commit d7e35dfa? >>> Is the story wrong? >>> >>> At the very least, something inconsistent is going on. There >>> are 8 functions. Why did d7e35dfa change one of them but >>> not the other 7? >> >> Yes. d7e35dfa is baloney IMNSHO. All it does is produce worse code, >and the description even says so. > >No, the description says that it produces worse code for *really >really* ancient >GCC versions. > >> As I said, gcc has treated the former code as idiomatic since gcc 2, >so that support is beyond ancient. > >Because something works in a specific way on one compiler isn't a >reason to >ignore this noncompliance with the standard. > > >Thanks, >Sasha 4.6.2 is not "really, really ancient." -- Sent from my Android device with K-9 Mail. Please excuse brevity and formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux/bitops.h
On 05/04/2016 08:48 PM, Linus Torvalds wrote: > That said, the fact that the other cases weren't changed > (rol64/ror64/ror32) does make that argument less interesting. Unless > there was some particular code that actively ended up using > "rol32(..0)" but not the other cases. Right, the others seemed wrong as well but I couldn't find any code that triggers that, and preferred to fix just the one I was hitting. I can go fix the rest if that's something we want to do? Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux/bitops.h
On 05/04/2016 08:30 PM, H. Peter Anvin wrote: > On 05/04/16 15:06, John Denker wrote: >> On 05/04/2016 02:56 PM, H. Peter Anvin wrote: Beware that shifting by an amount >= the number of bits in the word remains Undefined Behavior. >> >>> This construct has been supported as a rotate since at least gcc2. >> >> How then should we understand the story told in commit d7e35dfa? >> Is the story wrong? >> >> At the very least, something inconsistent is going on. There >> are 8 functions. Why did d7e35dfa change one of them but >> not the other 7? > > Yes. d7e35dfa is baloney IMNSHO. All it does is produce worse code, and the > description even says so. No, the description says that it produces worse code for *really really* ancient GCC versions. > As I said, gcc has treated the former code as idiomatic since gcc 2, so that > support is beyond ancient. Because something works in a specific way on one compiler isn't a reason to ignore this noncompliance with the standard. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [crypto / sparc64] cryptomgr_test OOPS
From: Herbert Xu Date: Thu, 5 May 2016 16:42:49 +0800 > Subject: crypto: testmgr - Use kmalloc memory for RSA input > > As akcipher uses an SG interface, you must not use vmalloc memory > as input for it. This patch fixes testmgr to copy the vmalloc > test vectors to kmalloc memory before running the test. > > This patch also removes a superfluous sg_virt call in do_test_rsa. > > Cc: > Reported-by: Anatoly Pugachev > Signed-off-by: Herbert Xu I'm really surprised this didn't trigger on non-sparc64 systems, but what do I know :-) -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND v5 6/6] crypto: AF_ALG - add support for key_id
Am Donnerstag, 5. Mai 2016, 12:51:20 schrieb Tadeusz Struk: Hi Tadeusz, > This patch adds support for asymmetric key type to AF_ALG. > It will work as follows: A new PF_ALG socket options are > added on top of existing ALG_SET_KEY and ALG_SET_PUBKEY, namely > ALG_SET_KEY_ID and ALG_SET_PUBKEY_ID for setting public and > private keys respectively. When these new options will be used > the user, instead of providing the key material, will provide a > key id and the key itself will be obtained from kernel keyring > subsystem. The user will use the standard tools (keyctl tool > or the keyctl syscall) for key instantiation and to obtain the > key id. The key id can also be obtained by reading the > /proc/keys file. > > When a key corresponding to the given keyid is found, it is stored > in the socket context and subsequent crypto operation invoked by the > user will use the new asymmetric accessor functions instead of akcipher > api. The asymmetric subtype can internally use akcipher api or > invoke operations defined by a given subtype, depending on the > key type. > > Signed-off-by: Tadeusz Struk > --- > crypto/af_alg.c | 10 ++ > crypto/algif_akcipher.c | 207 > ++- include/crypto/if_alg.h | > 1 > include/uapi/linux/if_alg.h |2 > 4 files changed, 215 insertions(+), 5 deletions(-) > > diff --git a/crypto/af_alg.c b/crypto/af_alg.c > index 24dc082..59c8244 100644 > --- a/crypto/af_alg.c > +++ b/crypto/af_alg.c > @@ -260,6 +260,16 @@ static int alg_setsockopt(struct socket *sock, int > level, int optname, > > err = alg_setkey(sk, optval, optlen, type->setpubkey); > break; > + > + case ALG_SET_KEY_ID: > + case ALG_SET_PUBKEY_ID: > + /* ALG_SET_KEY_ID is only for akcipher */ > + if (!strcmp(type->name, "akcipher") || > + sock->state == SS_CONNECTED) > + goto unlock; > + > + err = alg_setkey(sk, optval, optlen, type->setkeyid); > + break; > case ALG_SET_AEAD_AUTHSIZE: > if (sock->state == SS_CONNECTED) > goto unlock; > diff --git a/crypto/algif_akcipher.c b/crypto/algif_akcipher.c > index e00793d..f486b6d 100644 > --- a/crypto/algif_akcipher.c > +++ b/crypto/algif_akcipher.c > @@ -14,6 +14,8 @@ > #include > #include > #include > +#include > +#include > #include > #include > #include > @@ -29,6 +31,7 @@ struct akcipher_sg_list { > > struct akcipher_tfm { > struct crypto_akcipher *akcipher; > + char keyid[12]; > bool has_key; > }; > > @@ -37,6 +40,7 @@ struct akcipher_ctx { > struct af_alg_sgl rsgl[ALG_MAX_PAGES]; > > struct af_alg_completion completion; > + struct key *key; > > unsigned long used; > > @@ -322,6 +326,153 @@ unlock: > return err ? err : size; > } > > +static int asym_key_encrypt(const struct key *key, struct akcipher_request > *req) +{ > + struct kernel_pkey_params params = {0}; > + char *src = NULL, *dst = NULL, *in, *out; > + int ret; > + > + if (!sg_is_last(req->src)) { > + src = kmalloc(req->src_len, GFP_KERNEL); > + if (!src) > + return -ENOMEM; > + scatterwalk_map_and_copy(src, req->src, 0, req->src_len, 0); > + in = src; > + } else { > + in = sg_virt(req->src); > + } > + if (!sg_is_last(req->dst)) { > + dst = kmalloc(req->dst_len, GFP_KERNEL); > + if (!dst) { > + kfree(src); > + return -ENOMEM; > + } > + out = dst; > + } else { > + out = sg_virt(req->dst); > + } > + params.key = (struct key *)key; > + params.data_len = req->src_len; > + params.enc_len = req->dst_len; > + ret = encrypt_blob(¶ms, in, out); > + if (ret) > + goto free; > + > + if (dst) > + scatterwalk_map_and_copy(dst, req->dst, 0, req->dst_len, 1); > +free: > + kfree(src); > + kfree(dst); > + return ret; > +} > + > +static int asym_key_decrypt(const struct key *key, struct akcipher_request > *req) +{ > + struct kernel_pkey_params params = {0}; > + char *src = NULL, *dst = NULL, *in, *out; > + int ret; > + > + if (!sg_is_last(req->src)) { > + src = kmalloc(req->src_len, GFP_KERNEL); > + if (!src) > + return -ENOMEM; > + scatterwalk_map_and_copy(src, req->src, 0, req->src_len, 0); > + in = src; > + } else { > + in = sg_virt(req->src); > + } > + if (!sg_is_last(req->dst)) { > + dst = kmalloc(req->dst_len, GFP_KERNEL); > + if (!dst) { > + kfree(src); > + return -ENOMEM; > + } > + out = dst; > + } else { > + out = sg_virt(req->dst); > +
Re: [PATCH 3/3 v4] crypto: kpp - Add ECDH software support
Am Donnerstag, 5. Mai 2016, 10:17:37 schrieb Salvatore Benedetto: Hi Salvatore, > * Implement ECDH under kpp API > * Provide ECC software support for curve P-192 and >P-256. > * Add kpp test for ECDH with data generated by OpenSSL > > Signed-off-by: Salvatore Benedetto > --- > crypto/Kconfig |5 + > crypto/Makefile |3 + > crypto/ecc.c| 1038 > +++ crypto/ecc.h| > 70 > crypto/ecc_curve_defs.h | 57 +++ > crypto/ecdh.c | 171 > crypto/testmgr.c| 136 ++- > crypto/testmgr.h| 73 > include/crypto/ecdh.h | 24 ++ > 9 files changed, 1568 insertions(+), 9 deletions(-) > create mode 100644 crypto/ecc.c > create mode 100644 crypto/ecc.h > create mode 100644 crypto/ecc_curve_defs.h > create mode 100644 crypto/ecdh.c > create mode 100644 include/crypto/ecdh.h > > diff --git a/crypto/Kconfig b/crypto/Kconfig > index 89db25c..08a1a3b 100644 > --- a/crypto/Kconfig > +++ b/crypto/Kconfig > @@ -117,6 +117,11 @@ config CRYPTO_DH > help > Generic implementation of the Diffie-Hellman algorithm. > > +config CRYPTO_ECDH > + tristate "ECDH algorithm" > + select CRYTPO_KPP > + help > + Generic implementation of the ECDH algorithm > > config CRYPTO_MANAGER > tristate "Cryptographic algorithm manager" > diff --git a/crypto/Makefile b/crypto/Makefile > index 101f8fd..ba03079 100644 > --- a/crypto/Makefile > +++ b/crypto/Makefile > @@ -33,6 +33,9 @@ obj-$(CONFIG_CRYPTO_AKCIPHER2) += akcipher.o > obj-$(CONFIG_CRYPTO_KPP2) += kpp.o > > obj-$(CONFIG_CRYPTO_DH) += dh.o > +ecdh_generic-y := ecc.o > +ecdh_generic-y += ecdh.o > +obj-$(CONFIG_CRYPTO_ECDH) += ecdh_generic.o > > $(obj)/rsapubkey-asn1.o: $(obj)/rsapubkey-asn1.c $(obj)/rsapubkey-asn1.h > $(obj)/rsaprivkey-asn1.o: $(obj)/rsaprivkey-asn1.c $(obj)/rsaprivkey-asn1.h > diff --git a/crypto/ecc.c b/crypto/ecc.c > new file mode 100644 > index 000..c50f9c8 > --- /dev/null > +++ b/crypto/ecc.c > @@ -0,0 +1,1038 @@ > +/* > + * Copyright (c) 2013, Kenneth MacKay > + * All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions are > + * met: > + * * Redistributions of source code must retain the above copyright > + * notice, this list of conditions and the following disclaimer. > + * * Redistributions in binary form must reproduce the above copyright > + *notice, this list of conditions and the following disclaimer in the > + *documentation and/or other materials provided with the distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS > + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT > + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR > + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT > + * HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, > + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT > + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, > + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY > + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE > + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > + */ > + > +#include > +#include > +#include > +#include > + > +#include "ecc.h" > +#include "ecc_curve_defs.h" > + > +#define MAX_TRIES 16 > + > +typedef struct { > + u64 m_low; > + u64 m_high; > +} uint128_t; > + > +static inline const struct ecc_curve *ecc_get_curve(unsigned int curve_id) > +{ > + switch (curve_id) { > + case ECC_CURVE_NIST_P192: return &nist_p192; > + case ECC_CURVE_NIST_P256: return &nist_p256; > + default: return NULL; > + } > +} > + > +static u64 *ecc_alloc_digits_space(unsigned int ndigits) > +{ > + size_t len = ndigits * sizeof(u64); > + > + if (!len) > + return NULL; > + > + return kmalloc(len, GFP_KERNEL); > +} > + > +static void ecc_free_digits_space(u64 *space) > +{ > + kzfree(space); > +} > + > +static struct ecc_point *ecc_alloc_point(unsigned int ndigits) > +{ > + struct ecc_point *p = kmalloc(sizeof(*p), GFP_KERNEL); > + > + if (!p) > + return NULL; > + > + p->x = ecc_alloc_digits_space(ndigits); > + if (!p->x) > + goto err_alloc_x; > + > + p->y = ecc_alloc_digits_space(ndigits); > + if (!p->y) > + goto err_alloc_y; > + > + p->ndigits = ndigits; > + > + return p; > + > +err_alloc_y: > + ecc_free_digits_space(p->x); > +err_alloc_x: > + kfree(p); > + return NULL; > +} > + > +static void ecc_free_point(struct ecc_point *p) > +{ > + if (!p) > + return; > + > +
[PATCH] crypto: caam: fix caam_jr_alloc() ret code
caam_jr_alloc() used to return NULL if a JR device could not be allocated for a session. In turn, every user of this function used IS_ERR() function to verify if anything went wrong, which does NOT look for NULL values. This made the kernel crash if the sanity check failed, because the driver continued to think it had allocated a valid JR dev instance to the session and at some point it tries to do a caam_jr_free() on a NULL JR dev pointer. This patch is a fix for this issue. Signed-off-by: Catalin Vasile --- drivers/crypto/caam/jr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c index 6fd63a6..5ef4be2 100644 --- a/drivers/crypto/caam/jr.c +++ b/drivers/crypto/caam/jr.c @@ -248,7 +248,7 @@ static void caam_jr_dequeue(unsigned long devarg) struct device *caam_jr_alloc(void) { struct caam_drv_private_jr *jrpriv, *min_jrpriv = NULL; - struct device *dev = NULL; + struct device *dev = ERR_PTR(-ENODEV); int min_tfm_cnt = INT_MAX; int tfm_cnt; -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] crypto: caam: add backlogging support
caam_jr_enqueue() function returns -EBUSY once there are no more slots available in the JR, but it doesn't actually save the current request. This breaks the functionality of users that expect that even if there is no more space for the request, it is at least queued for later execution. In other words, all crypto transformations that request backlogging (i.e. have CRYPTO_TFM_REQ_MAY_BACKLOG set), will hang. Such an example is dm-crypt. The current patch solves this issue by setting a threshold after which caam_jr_enqueue() returns -EBUSY, but since the HW job ring isn't actually full, the job is enqueued. Signed-off-by: Alexandru Porosanu Tested-by: Catalin Vasile --- drivers/crypto/caam/caamalg.c | 88 -- drivers/crypto/caam/caamhash.c | 101 +++-- drivers/crypto/caam/intern.h | 7 ++ drivers/crypto/caam/jr.c | 196 + drivers/crypto/caam/jr.h | 5 ++ 5 files changed, 343 insertions(+), 54 deletions(-) diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c index ea8189f..62bce17 100644 --- a/drivers/crypto/caam/caamalg.c +++ b/drivers/crypto/caam/caamalg.c @@ -1921,6 +1921,9 @@ static void aead_encrypt_done(struct device *jrdev, u32 *desc, u32 err, edesc = container_of(desc, struct aead_edesc, hw_desc[0]); + if (err == -EINPROGRESS) + goto out_bklogged; + if (err) caam_jr_strstatus(jrdev, err); @@ -1928,6 +1931,7 @@ static void aead_encrypt_done(struct device *jrdev, u32 *desc, u32 err, kfree(edesc); +out_bklogged: aead_request_complete(req, err); } @@ -1943,6 +1947,9 @@ static void aead_decrypt_done(struct device *jrdev, u32 *desc, u32 err, edesc = container_of(desc, struct aead_edesc, hw_desc[0]); + if (err == -EINPROGRESS) + goto out_bklogged; + if (err) caam_jr_strstatus(jrdev, err); @@ -1956,6 +1963,7 @@ static void aead_decrypt_done(struct device *jrdev, u32 *desc, u32 err, kfree(edesc); +out_bklogged: aead_request_complete(req, err); } @@ -1974,6 +1982,9 @@ static void ablkcipher_encrypt_done(struct device *jrdev, u32 *desc, u32 err, edesc = (struct ablkcipher_edesc *)((char *)desc - offsetof(struct ablkcipher_edesc, hw_desc)); + if (err == -EINPROGRESS) + goto out_bklogged; + if (err) caam_jr_strstatus(jrdev, err); @@ -1989,6 +2000,7 @@ static void ablkcipher_encrypt_done(struct device *jrdev, u32 *desc, u32 err, ablkcipher_unmap(jrdev, edesc, req); kfree(edesc); +out_bklogged: ablkcipher_request_complete(req, err); } @@ -2006,6 +2018,10 @@ static void ablkcipher_decrypt_done(struct device *jrdev, u32 *desc, u32 err, edesc = (struct ablkcipher_edesc *)((char *)desc - offsetof(struct ablkcipher_edesc, hw_desc)); + + if (err == -EINPROGRESS) + goto out_bklogged; + if (err) caam_jr_strstatus(jrdev, err); @@ -2021,6 +2037,7 @@ static void ablkcipher_decrypt_done(struct device *jrdev, u32 *desc, u32 err, ablkcipher_unmap(jrdev, edesc, req); kfree(edesc); +out_bklogged: ablkcipher_request_complete(req, err); } @@ -2394,7 +2411,15 @@ static int gcm_encrypt(struct aead_request *req) #endif desc = edesc->hw_desc; - ret = caam_jr_enqueue(jrdev, desc, aead_encrypt_done, req); + if (req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG) { + ret = caam_jr_enqueue_bklog(jrdev, desc, aead_encrypt_done, + req); + if (ret == -EBUSY) + return ret; + } else { + ret = caam_jr_enqueue(jrdev, desc, aead_encrypt_done, req); + } + if (!ret) { ret = -EINPROGRESS; } else { @@ -2438,7 +2463,15 @@ static int aead_encrypt(struct aead_request *req) #endif desc = edesc->hw_desc; - ret = caam_jr_enqueue(jrdev, desc, aead_encrypt_done, req); + if (req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG) { + ret = caam_jr_enqueue_bklog(jrdev, desc, aead_encrypt_done, + req); + if (ret == -EBUSY) + return ret; + } else { + ret = caam_jr_enqueue(jrdev, desc, aead_encrypt_done, req); + } + if (!ret) { ret = -EINPROGRESS; } else { @@ -2473,7 +2506,15 @@ static int gcm_decrypt(struct aead_request *req) #endif desc = edesc->hw_desc; - ret = caam_jr_enqueue(jrdev, desc, aead_decrypt_done, req); + if (req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG) { + ret = caam_jr_enqueue_bklog(jrdev, desc, aead_decrypt_done, + req); + if (ret == -EBUSY) +
Re: [PATCH RESEND v5 1/6] crypto: AF_ALG -- add sign/verify API
Am Donnerstag, 5. Mai 2016, 12:50:54 schrieb Tadeusz Struk: Hi Tadeusz, David, > From: Stephan Mueller > > Add the flags for handling signature generation and signature > verification. > > Also, the patch adds the interface for setting a public key. > > Signed-off-by: Stephan Mueller > Signed-off-by: Tadeusz Struk All four patches from me: Acked-by: Stephan Mueller > --- > include/uapi/linux/if_alg.h |3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/include/uapi/linux/if_alg.h b/include/uapi/linux/if_alg.h > index f2acd2f..02e6162 100644 > --- a/include/uapi/linux/if_alg.h > +++ b/include/uapi/linux/if_alg.h > @@ -34,9 +34,12 @@ struct af_alg_iv { > #define ALG_SET_OP 3 > #define ALG_SET_AEAD_ASSOCLEN4 > #define ALG_SET_AEAD_AUTHSIZE5 > +#define ALG_SET_PUBKEY 6 > > /* Operations */ > #define ALG_OP_DECRYPT 0 > #define ALG_OP_ENCRYPT 1 > +#define ALG_OP_SIGN 2 > +#define ALG_OP_VERIFY3 > > #endif /* _LINUX_IF_ALG_H */ Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH v2 1/8] asm-generic/io.h: allow barriers in io{read,write}{16,32}be
While reviewing the addition of io{read,write}64be accessors, Arnd -finds a potential problem: "If an architecture overrides readq/writeq to have barriers but does not override ioread64be/iowrite64be, this will lack the barriers and behave differently from the little-endian version. I think the only affected architecture is ARC, since ARM and ARM64 both override the big-endian accessors to have the correct barriers, and all others don't use barriers at all." -suggests a fix for the same problem in existing code (16/32-bit accessors); the fix leads "to a double-swap on architectures that don't override the io{read,write}{16,32}be accessors, but it will work correctly on all architectures without them having to override these accessors." Suggested-by: Arnd Bergmann Signed-off-by: Horia Geantă --- Herbert, I forgot to add you and/or linux-crypto in the loop, so I am resending this patch. Apologies for the noise. Current patch got the Ack from Arnd: https://lkml.org/lkml/2016/5/5/376 As the cover letter mentions, I am looking to go with patches 1-4 through cryptodev tree. include/asm-generic/io.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h index eed3bbe88c8a..b79fb2c248a1 100644 --- a/include/asm-generic/io.h +++ b/include/asm-generic/io.h @@ -613,7 +613,7 @@ static inline void iowrite32(u32 value, volatile void __iomem *addr) #define ioread16be ioread16be static inline u16 ioread16be(const volatile void __iomem *addr) { - return __be16_to_cpu(__raw_readw(addr)); + return swab16(readw(addr)); } #endif @@ -621,7 +621,7 @@ static inline u16 ioread16be(const volatile void __iomem *addr) #define ioread32be ioread32be static inline u32 ioread32be(const volatile void __iomem *addr) { - return __be32_to_cpu(__raw_readl(addr)); + return swab32(readl(addr)); } #endif @@ -629,7 +629,7 @@ static inline u32 ioread32be(const volatile void __iomem *addr) #define iowrite16be iowrite16be static inline void iowrite16be(u16 value, void volatile __iomem *addr) { - __raw_writew(__cpu_to_be16(value), addr); + writew(swab16(value), addr); } #endif @@ -637,7 +637,7 @@ static inline void iowrite16be(u16 value, void volatile __iomem *addr) #define iowrite32be iowrite32be static inline void iowrite32be(u32 value, volatile void __iomem *addr) { - __raw_writel(__cpu_to_be32(value), addr); + writel(swab32(value), addr); } #endif -- 2.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html