Re: net: Remove iocb argument from sendmsg and recvmsg
On 03/10/2015 09:02 PM, David Miller wrote: Because of the way you quoted the patch, it looked like a list posting looping back to the list again, because of the List-ID: email header. Therefore your posting was blocked and you'll have to resend your posting in a way such that this doesn't happen. Oops, sorry, here it is. Hi, After couple of attempts to implement an user space interface to crypto HW that would meet our performance requirements, and after discussion with Herbert, we have come to conclusion that using AF_ALG sockets and AIO interface is the way to go. Unfortunately it looks like AIO operations will no longer be supported on sockets because of the commit 1b784140474e4fc94281a49e96c67d29df0efbde. My question is why do we want to abandon AIO support in the socket layer? Is it not worth keeping it for scenarios like this? Do we have any alternative? Here is the mentioned patch. https://patchwork.kernel.org/patch/5971491/ Regards, Tadeusz -- 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 0/2] crypto: talitos: Add AES-XTS mode
On 3/9/2015 5:08 PM, Martin Hicks wrote: On Mon, Mar 9, 2015 at 6:16 AM, Horia Geantă horia.gea...@freescale.com wrote: On 3/3/2015 7:44 PM, Martin Hicks wrote: On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă horia.gea...@freescale.com wrote: For talitos, there are two cases: 1. request data size is = data unit / sector size talitos can handle any IV / tweak scheme 2. request data size sector size since talitos internally generates the IV for the next sector by incrementing the previous IV, only IV schemes that allocate consecutive IV to consecutive sectors will function correctly. it's not clear to me that #1 is right. I guess it could be, but the IV length would be limited to 8 bytes. Yes, there's a limitation in talitos wrt. XTS IV / tweak size - it's up to 8 bytes. So I guess ESSIV won't work with talitos-xts, since the encrypted IV output is 16 bytes. But as previously said, ESSIV breaks the XTS standard requirement for having a consecutive IV for consecutive blocks. ESSIV should really be used only with disk-level encryption schemes that require an unpredictable IV. Ok. I'll verify that the second half of the IV is zeroed. One last thing that I'm not sure of is what string to place in cra_ablkcipher.geniv field. eseqiv seems wrong if plain/plain64 are the IVs that XTS is designed for. Right. But since currently dm-crypt does not use .givencrypt and deals with IV generation by itself, we're safe. When dm-crypt IV generation will be moved to crypto, we'll have to revisit this. While here: note that xts-talitos supports only two key lengths - 256 and 512 bits. There are tcrypt speed tests that check also for 384-bit keys (which is out-of-spec, but still...), leading to a Key Size Error - see below (KSE bit in AESU Interrupt Status Register is set) testing speed of async xts(aes) (xts-aes-talitos) encryption [...] test 5 (384 bit key, 16 byte blocks): talitos ffe3.crypto: CDPR is NULL, giving up search for offending descriptor talitos ffe3.crypto: AESUISR 0x_0200 talitos ffe3.crypto: DESCBUF 0x64300011_ talitos ffe3.crypto: DESCBUF 0x_ talitos ffe3.crypto: DESCBUF 0x0010_ talitos ffe3.crypto: DESCBUF 0x0030_ talitos ffe3.crypto: DESCBUF 0x0010_ talitos ffe3.crypto: DESCBUF 0x0010_ talitos ffe3.crypto: DESCBUF 0x0010_ talitos ffe3.crypto: DESCBUF 0x_ encryption() failed flags=0 So for xts, driver must enforce 256/512 bit key lengths and return CRYPTO_TFM_RES_BAD_KEY_LEN in all other cases. Or a SW fallback could be used for the other cases, but I don't think it's worth the effort since these are non-standard. Horia -- 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 2/4] hwrng: omap - remove #ifdefery around PM methods
Hi Herbert,
On Wed, Mar 11, 2015 at 09:59:57PM +1100, Herbert Xu wrote:
On Mon, Mar 09, 2015 at 10:36:36AM -0700, Dmitry Torokhov wrote:
Instead of using #ifdefs let's mark suspend and resume methods as
__maybe_unused which will suppress compiler warnings about them being
unused and provide better compile coverage. This will not increase image
size.
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
drivers/char/hw_random/omap-rng.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c
b/drivers/char/hw_random/omap-rng.c
index 7f3597d..5c171b1 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -422,9 +422,7 @@ static int omap_rng_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM_SLEEP
-
-static int omap_rng_suspend(struct device *dev)
+static int __maybe_unused omap_rng_suspend(struct device *dev)
{
struct omap_rng_dev *priv = dev_get_drvdata(dev);
@@ -434,7 +432,7 @@ static int omap_rng_suspend(struct device *dev)
return 0;
}
-static int omap_rng_resume(struct device *dev)
+static int __maybe_unused omap_rng_resume(struct device *dev)
{
struct omap_rng_dev *priv = dev_get_drvdata(dev);
@@ -445,18 +443,11 @@ static int omap_rng_resume(struct device *dev)
}
static SIMPLE_DEV_PM_OPS(omap_rng_pm, omap_rng_suspend, omap_rng_resume);
-#defineOMAP_RNG_PM (omap_rng_pm)
-
-#else
-
-#defineOMAP_RNG_PM NULL
-
-#endif
static struct platform_driver omap_rng_driver = {
.driver = {
.name = omap_rng,
- .pm = OMAP_RNG_PM,
+ .pm = omap_rng_pm,
This will cause omap_rng_suspend/omap_rng_resume to be referenced
always, thus rendering the __maybe_unused moot, no?
SIMPLE_DEV_PM_OPS() produces an empty omap_rng_pm structure in case of
!CONFIG_PM_SLEEP so neither omap_rng_suspend nor omap_rng_resume will
end up being referenced.
Thanks.
--
Dmitry
--
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] mm: kill kmemcheck
From: Sasha Levin sasha.le...@oracle.com Date: Wed, 11 Mar 2015 09:39:33 -0400 On 03/11/2015 08:40 AM, Steven Rostedt wrote: On Wed, 11 Mar 2015 08:34:46 -0400 Sasha Levin sasha.le...@oracle.com wrote: Fair enough. We knew there are existing kmemcheck users, but KASan should be superior both in performance and the scope of bugs it finds. It also shouldn't impose new limitations beyond requiring gcc 4.9.2+. Ouch! OK, then I can't use it. I'm currently compiling with gcc 4.6.3. It will be a while before I upgrade my build farm to something newer. Are you actually compiling new kernels with 4.6.3, or are you using older kernels as well? There's no real hurry to kill kmemcheck right now, but we do want to stop supporting that in favour of KASan. Is the spectrum of CPU's supported by this GCC feature equal to all of the CPU's supported by the kernel right now? If not, removing kmemcheck will always be a regression for someone. -- 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 0/15] don't export static symbol
These patches remove EXPORT_SYMBOL or EXPORT_SYMBOL_GPL declarations on
static functions.
This was done using the following semantic patch:
(http://coccinelle.lip6.fr/)
// smpl
@r@
type T;
identifier f;
@@
static T f (...) { ... }
@@
identifier r.f;
declarer name EXPORT_SYMBOL;
@@
-EXPORT_SYMBOL(f);
@@
identifier r.f;
declarer name EXPORT_SYMBOL_GPL;
@@
-EXPORT_SYMBOL_GPL(f);
// /smpl
--
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: net: Remove iocb argument from sendmsg and recvmsg
On 03/10/2015 09:06 PM, David Miller wrote: From: Ying Xue ying@windriver.com Date: Wed, 11 Mar 2015 11:18:01 +0800 Sorry, I did not realize the case when I created the commit. However, although I don't understand its scenario, in my opinion, adding one redundant argument for all sockets to satisfy the special case seems unreasonable for us. And the AIO socket mechanism was buggy and references freed up stack objects. That whole set of problems would need to be addressed fully before we could even think of adding AIO support back to the socket layer. Maybe we can add new sock_aio_read_iter() and sock_aio_write_iter() functions in socket.c, and set the aio_read() and aio_write() ptrs to these in the socket_file_ops struct. Then we can add new async_sendmsg() and async_recvmsg() to struct proto_ops that will still take the struct kiocb. These new async_sendmsg() and async_recvmsg() functions will be called from the sock_aio_read_iter() and sock_aio_write_iter()? Do you want me to put a patch together? -- 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 4/15] crypto: don't export static symbol
From: Julia Lawall julia.law...@lip6.fr
The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@r@
type T;
identifier f;
@@
static T f (...) { ... }
@@
identifier r.f;
declarer name EXPORT_SYMBOL_GPL;
@@
-EXPORT_SYMBOL_GPL(f);
// /smpl
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
arch/x86/crypto/glue_helper.c |1 -
1 file changed, 1 deletion(-)
diff -u -p a/arch/x86/crypto/glue_helper.c b/arch/x86/crypto/glue_helper.c
--- a/arch/x86/crypto/glue_helper.c
+++ b/arch/x86/crypto/glue_helper.c
@@ -232,7 +232,6 @@ static void glue_ctr_crypt_final_128bit(
le128_to_be128((be128 *)walk-iv, ctrblk);
}
-EXPORT_SYMBOL_GPL(glue_ctr_crypt_final_128bit);
static unsigned int __glue_ctr_crypt_128bit(const struct common_glue_ctx *gctx,
struct blkcipher_desc *desc,
--
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] mm: kill kmemcheck
From: Andrey Ryabinin ryabinin@gmail.com Date: Wed, 11 Mar 2015 23:01:00 +0300 2015-03-11 21:44 GMT+03:00 David Miller da...@davemloft.net: From: Sasha Levin sasha.le...@oracle.com Date: Wed, 11 Mar 2015 13:25:47 -0400 You're probably wondering why there are changes to SPARC in that patchset? :) Libsanitizer doesn't even build have the time on sparc, the release manager has to hand patch it into building again every major release because of the way ASAN development is done out of tree and local commits to the gcc tree are basically written over during the next merge. Libsanitizer is userspace lib it's for userspace ASan, KASan doesn't use it. We have our own 'libsanitzer' in kernel. I was speaking about ASAN development in general, of which the libsanitizer issue is a byproduct. -- 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 2/4] hwrng: omap - remove #ifdefery around PM methods
On Wed, Mar 11, 2015 at 08:44:07AM -0700, Dmitry Torokhov wrote: SIMPLE_DEV_PM_OPS() produces an empty omap_rng_pm structure in case of !CONFIG_PM_SLEEP so neither omap_rng_suspend nor omap_rng_resume will end up being referenced. OK, could you please resend this patch? Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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] hwrng: omap - remove #ifdefery around PM methods
Instead of using #ifdefs let's mark suspend and resume methods as
__maybe_unused which will suppress compiler warnings about them being
unused and provide better compile coverage.
Because SIMPLE_DEV_PM_OPS() produces an empty omap_rng_pm structure in
case of !CONFIG_PM_SLEEP neither omap_rng_suspend nor omap_rng_resume
will end up being referenced and the change will not result in
increasing image size.
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
drivers/char/hw_random/omap-rng.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c
b/drivers/char/hw_random/omap-rng.c
index 7f3597d..5c171b1 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -422,9 +422,7 @@ static int omap_rng_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM_SLEEP
-
-static int omap_rng_suspend(struct device *dev)
+static int __maybe_unused omap_rng_suspend(struct device *dev)
{
struct omap_rng_dev *priv = dev_get_drvdata(dev);
@@ -434,7 +432,7 @@ static int omap_rng_suspend(struct device *dev)
return 0;
}
-static int omap_rng_resume(struct device *dev)
+static int __maybe_unused omap_rng_resume(struct device *dev)
{
struct omap_rng_dev *priv = dev_get_drvdata(dev);
@@ -445,18 +443,11 @@ static int omap_rng_resume(struct device *dev)
}
static SIMPLE_DEV_PM_OPS(omap_rng_pm, omap_rng_suspend, omap_rng_resume);
-#defineOMAP_RNG_PM (omap_rng_pm)
-
-#else
-
-#defineOMAP_RNG_PM NULL
-
-#endif
static struct platform_driver omap_rng_driver = {
.driver = {
.name = omap_rng,
- .pm = OMAP_RNG_PM,
+ .pm = omap_rng_pm,
.of_match_table = of_match_ptr(omap_rng_of_match),
},
.probe = omap_rng_probe,
--
2.2.0.rc0.207.ga3a616c
--
Dmitry
--
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 2/4] hwrng: omap - remove #ifdefery around PM methods
On Thu, Mar 12, 2015 at 08:00:35AM +1100, Herbert Xu wrote: On Wed, Mar 11, 2015 at 08:44:07AM -0700, Dmitry Torokhov wrote: SIMPLE_DEV_PM_OPS() produces an empty omap_rng_pm structure in case of !CONFIG_PM_SLEEP so neither omap_rng_suspend nor omap_rng_resume will end up being referenced. OK, could you please resend this patch? Done. Thanks! -- Dmitry -- 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] mm: kill kmemcheck
On 03/11/2015 01:20 PM, David Miller wrote: From: Sasha Levin sasha.le...@oracle.com Date: Wed, 11 Mar 2015 09:39:33 -0400 On 03/11/2015 08:40 AM, Steven Rostedt wrote: On Wed, 11 Mar 2015 08:34:46 -0400 Sasha Levin sasha.le...@oracle.com wrote: Fair enough. We knew there are existing kmemcheck users, but KASan should be superior both in performance and the scope of bugs it finds. It also shouldn't impose new limitations beyond requiring gcc 4.9.2+. Ouch! OK, then I can't use it. I'm currently compiling with gcc 4.6.3. It will be a while before I upgrade my build farm to something newer. Are you actually compiling new kernels with 4.6.3, or are you using older kernels as well? There's no real hurry to kill kmemcheck right now, but we do want to stop supporting that in favour of KASan. Is the spectrum of CPU's supported by this GCC feature equal to all of the CPU's supported by the kernel right now? If not, removing kmemcheck will always be a regression for someone. You're probably wondering why there are changes to SPARC in that patchset? :) I don't really know. Both kmemcheck and KASan run only on x86. I've also asked Vegard, who didn't know either... I guess it got copy-pasted from a different code. As far as I know the only regression is requiring newer GCC. 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: [PATCH] mm: kill kmemcheck
From: Sasha Levin sasha.le...@oracle.com Date: Wed, 11 Mar 2015 13:25:47 -0400 You're probably wondering why there are changes to SPARC in that patchset? :) Libsanitizer doesn't even build have the time on sparc, the release manager has to hand patch it into building again every major release because of the way ASAN development is done out of tree and local commits to the gcc tree are basically written over during the next merge. So I'm a little bit bitter about this, as you can see. :) -- 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] mm: kill kmemcheck
2015-03-11 21:44 GMT+03:00 David Miller da...@davemloft.net: From: Sasha Levin sasha.le...@oracle.com Date: Wed, 11 Mar 2015 13:25:47 -0400 You're probably wondering why there are changes to SPARC in that patchset? :) Libsanitizer doesn't even build have the time on sparc, the release manager has to hand patch it into building again every major release because of the way ASAN development is done out of tree and local commits to the gcc tree are basically written over during the next merge. Libsanitizer is userspace lib it's for userspace ASan, KASan doesn't use it. We have our own 'libsanitzer' in kernel. So I'm a little bit bitter about this, as you can see. :) -- Best regards, Andrey Ryabinin -- 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 RFC 2/4] aio: prefer aio_op op over iter_op
AIO interface should prefer AIO operations over iter_op
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
fs/aio.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index f8e52a1..389f4dd 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1449,11 +1449,15 @@ rw_common:
if (rw == WRITE)
file_start_write(file);
- if (iter_op) {
+ if (rw_op) {
+ ret = rw_op(req, iovec, nr_segs, req-ki_pos);
+ } else if (iter_op) {
iov_iter_init(iter, rw, iovec, nr_segs,
req-ki_nbytes);
ret = iter_op(req, iter);
} else {
- ret = rw_op(req, iovec, nr_segs, req-ki_pos);
+ if (iovec != inline_vecs)
+ kfree(iovec);
+ return -EINVAL;
}
if (rw == WRITE)
--
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 RFC 3/4] crypto: af_alg - Allow to link sgl
From: Tadeusz Struk tadeusz.st...@intel.com
Allow to link af_alg sgls.
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
crypto/af_alg.c | 18 +-
include/crypto/if_alg.h |4 +++-
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 7f8b7edc..26089d1 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -358,8 +358,8 @@ int af_alg_make_sg(struct af_alg_sgl *sgl, struct iov_iter
*iter, int len)
npages = (off + n + PAGE_SIZE - 1) PAGE_SHIFT;
if (WARN_ON(npages == 0))
return -EINVAL;
-
- sg_init_table(sgl-sg, npages);
+ /* Add one extra for linking */
+ sg_init_table(sgl-sg, npages + 1);
for (i = 0, len = n; i npages; i++) {
int plen = min_t(int, len, PAGE_SIZE - off);
@@ -369,18 +369,26 @@ int af_alg_make_sg(struct af_alg_sgl *sgl, struct
iov_iter *iter, int len)
off = 0;
len -= plen;
}
+ sg_mark_end(sgl-sg + npages - 1);
+ sgl-npages = npages;
+
return n;
}
EXPORT_SYMBOL_GPL(af_alg_make_sg);
+void af_alg_link_sg(struct af_alg_sgl *sgl_prev, struct af_alg_sgl *sgl_new)
+{
+ sg_unmark_end(sgl_prev-sg + sgl_prev-npages - 1);
+ sg_chain(sgl_prev-sg, sgl_prev-npages + 1, sgl_new-sg);
+}
+EXPORT_SYMBOL(af_alg_link_sg);
+
void af_alg_free_sg(struct af_alg_sgl *sgl)
{
int i;
- i = 0;
- do {
+ for (i = 0; i sgl-npages; i++)
put_page(sgl-pages[i]);
- } while (!sg_is_last(sgl-sg + (i++)));
}
EXPORT_SYMBOL_GPL(af_alg_free_sg);
diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
index 178525e..018afb2 100644
--- a/include/crypto/if_alg.h
+++ b/include/crypto/if_alg.h
@@ -58,8 +58,9 @@ struct af_alg_type {
};
struct af_alg_sgl {
- struct scatterlist sg[ALG_MAX_PAGES];
+ struct scatterlist sg[ALG_MAX_PAGES + 1];
struct page *pages[ALG_MAX_PAGES];
+ unsigned int npages;
};
int af_alg_register_type(const struct af_alg_type *type);
@@ -70,6 +71,7 @@ int af_alg_accept(struct sock *sk, struct socket *newsock);
int af_alg_make_sg(struct af_alg_sgl *sgl, struct iov_iter *iter, int len);
void af_alg_free_sg(struct af_alg_sgl *sgl);
+void af_alg_link_sg(struct af_alg_sgl *sgl_prev, struct af_alg_sgl *sgl_new);
int af_alg_cmsg_send(struct msghdr *msg, struct af_alg_control *con);
--
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 RFC 1/4] net: socket: add support for async operations
Add support for async operations.
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
include/linux/net.h |6 +
net/socket.c| 64 +++
2 files changed, 70 insertions(+)
diff --git a/include/linux/net.h b/include/linux/net.h
index e74114b..8330936 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -25,6 +25,7 @@
#include linux/kmemcheck.h
#include linux/rcupdate.h
#include linux/jump_label.h
+#include linux/aio.h
#include uapi/linux/net.h
struct poll_table_struct;
@@ -173,6 +174,11 @@ struct proto_ops {
*/
int (*recvmsg) (struct socket *sock, struct msghdr *m,
size_t total_len, int flags);
+ int (*aio_sendmsg)(struct kiocb *iocb, struct socket *sock,
+ struct msghdr *m, size_t total_len);
+ int (*aio_recvmsg)(struct kiocb *iocb, struct socket *sock,
+ struct msghdr *m, size_t total_len,
+ int flags);
int (*mmap) (struct file *file, struct socket *sock,
struct vm_area_struct * vma);
ssize_t (*sendpage) (struct socket *sock, struct page *page,
diff --git a/net/socket.c b/net/socket.c
index 95d3085..fe55112 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -132,6 +132,11 @@ static ssize_t sock_splice_read(struct file *file, loff_t
*ppos,
struct pipe_inode_info *pipe, size_t len,
unsigned int flags);
+static ssize_t sock_aio_read(struct kiocb *iocb, const struct iovec *iov,
+unsigned long nr_segs, loff_t loff);
+static ssize_t sock_aio_write(struct kiocb *iocb, const struct iovec *iov,
+ unsigned long nr_segs, loff_t loff);
+
/*
* Socket files have a set of 'special' operations as well as the generic
file ones. These don't appear
* in the operation structures but are done directly via the socketcall()
multiplexor.
@@ -144,6 +149,8 @@ static const struct file_operations socket_file_ops = {
.write =new_sync_write,
.read_iter =sock_read_iter,
.write_iter = sock_write_iter,
+ .aio_read = sock_aio_read,
+ .aio_write =sock_aio_write,
.poll = sock_poll,
.unlocked_ioctl = sock_ioctl,
#ifdef CONFIG_COMPAT
@@ -836,6 +843,63 @@ static ssize_t sock_write_iter(struct kiocb *iocb, struct
iov_iter *from)
return res;
}
+static ssize_t sock_aio_read(struct kiocb *iocb, const struct iovec *iov,
+unsigned long nr_segs, loff_t loff)
+{
+ struct file *file = iocb-ki_filp;
+ struct socket *sock = file-private_data;
+ struct iov_iter iter;
+ struct msghdr msg = {0};
+ ssize_t res;
+
+ if (file-f_flags O_NONBLOCK)
+ msg.msg_flags = MSG_DONTWAIT;
+
+ if (iocb-ki_pos != 0)
+ return -ESPIPE;
+
+ if (iocb-ki_nbytes == 0)
+ return 0;
+
+ if (sock-ops-aio_recvmsg) {
+ iov_iter_init(iter, READ, iov, nr_segs, iocb-ki_nbytes);
+ msg.msg_iter = iter;
+ res = sock-ops-aio_recvmsg(iocb, sock, msg,
+iocb-ki_nbytes, msg.msg_flags);
+ } else {
+ res = -EOPNOTSUPP;
+ }
+ return res;
+}
+
+static ssize_t sock_aio_write(struct kiocb *iocb, const struct iovec *iov,
+ unsigned long nr_segs, loff_t loff)
+{
+ struct file *file = iocb-ki_filp;
+ struct socket *sock = file-private_data;
+ struct iov_iter iter;
+ struct msghdr msg = {0};
+ ssize_t res;
+
+ if (iocb-ki_pos != 0)
+ return -ESPIPE;
+
+ if (file-f_flags O_NONBLOCK)
+ msg.msg_flags = MSG_DONTWAIT;
+
+ if (sock-type == SOCK_SEQPACKET)
+ msg.msg_flags |= MSG_EOR;
+
+ if (sock-ops-aio_sendmsg) {
+ iov_iter_init(iter, WRITE, iov, nr_segs, iocb-ki_nbytes);
+ msg.msg_iter = iter;
+ res = sock-ops-aio_sendmsg(iocb, sock, msg, iocb-ki_nbytes);
+ } else {
+ res = -EOPNOTSUPP;
+ }
+ return res;
+}
+
/*
* Atomic setting of ioctl hooks to avoid race
* with module unload.
--
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 RFC 4/4] crypto: algif - change algif_skcipher to be asynchronous
From: Tadeusz Struk tadeusz.st...@intel.com
The way the algif_skcipher works currently is that on sendmsg/sendpage it
builds an sgl for the input data and then on read/recvmsg it sends the job
for encryption putting the user to sleep till the data is processed.
This way it can only handle one job at a given time.
This patch changes it to be asynchronous by adding AIO support.
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
crypto/algif_skcipher.c | 224 ++-
1 file changed, 218 insertions(+), 6 deletions(-)
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index b9743dc..b259cbd 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -39,6 +39,7 @@ struct skcipher_ctx {
struct af_alg_completion completion;
+ atomic_t inflight;
unsigned used;
unsigned int len;
@@ -49,9 +50,65 @@ struct skcipher_ctx {
struct ablkcipher_request req;
};
+struct skcipher_async_rsgl {
+ struct af_alg_sgl sgl;
+ struct list_head list;
+};
+
+struct skcipher_async_req {
+ struct kiocb *iocb;
+ struct skcipher_async_rsgl first_sgl;
+ struct list_head list;
+ struct scatterlist *tsg;
+ char iv[];
+};
+
+#define GET_SREQ(areq, ctx) (struct skcipher_async_req *)((char *)areq + \
+ crypto_ablkcipher_reqsize(crypto_ablkcipher_reqtfm(ctx-req)))
+
+#define GET_REQ_SIZE(ctx) \
+ crypto_ablkcipher_reqsize(crypto_ablkcipher_reqtfm(ctx-req))
+
+#define GET_IV_SIZE(ctx) \
+ crypto_ablkcipher_ivsize(crypto_ablkcipher_reqtfm(ctx-req))
+
#define MAX_SGL_ENTS ((4096 - sizeof(struct skcipher_sg_list)) / \
sizeof(struct scatterlist) - 1)
+static void skcipher_free_async_sgls(struct skcipher_async_req *sreq)
+{
+ struct skcipher_async_rsgl *rsgl, *tmp;
+ struct scatterlist *sgl;
+ struct scatterlist *sg;
+ int i, n;
+
+ list_for_each_entry_safe(rsgl, tmp, sreq-list, list) {
+ af_alg_free_sg(rsgl-sgl);
+ if (rsgl != sreq-first_sgl)
+ kfree(rsgl);
+ }
+ sgl = sreq-tsg;
+ n = sg_nents(sgl);
+ for_each_sg(sgl, sg, n, i)
+ put_page(sg_page(sg));
+
+ kfree(sreq-tsg);
+}
+
+static void skcipher_async_cb(struct crypto_async_request *req, int err)
+{
+ struct sock *sk = req-data;
+ struct alg_sock *ask = alg_sk(sk);
+ struct skcipher_ctx *ctx = ask-private;
+ struct skcipher_async_req *sreq = GET_SREQ(req, ctx);
+ struct kiocb *iocb = sreq-iocb;
+
+ atomic_dec(ctx-inflight);
+ skcipher_free_async_sgls(sreq);
+ kfree(req);
+ aio_complete(iocb, err, err);
+}
+
static inline int skcipher_sndbuf(struct sock *sk)
{
struct alg_sock *ask = alg_sk(sk);
@@ -96,7 +153,7 @@ static int skcipher_alloc_sgl(struct sock *sk)
return 0;
}
-static void skcipher_pull_sgl(struct sock *sk, int used)
+static void skcipher_pull_sgl(struct sock *sk, int used, int put)
{
struct alg_sock *ask = alg_sk(sk);
struct skcipher_ctx *ctx = ask-private;
@@ -123,8 +180,8 @@ static void skcipher_pull_sgl(struct sock *sk, int used)
if (sg[i].length)
return;
-
- put_page(sg_page(sg + i));
+ if (put)
+ put_page(sg_page(sg + i));
sg_assign_page(sg + i, NULL);
}
@@ -143,7 +200,7 @@ static void skcipher_free_sgl(struct sock *sk)
struct alg_sock *ask = alg_sk(sk);
struct skcipher_ctx *ctx = ask-private;
- skcipher_pull_sgl(sk, ctx-used);
+ skcipher_pull_sgl(sk, ctx-used, 1);
}
static int skcipher_wait_for_wmem(struct sock *sk, unsigned flags)
@@ -424,6 +481,147 @@ unlock:
return err ?: size;
}
+static int skcipher_all_sg_nents(struct skcipher_ctx *ctx)
+{
+ struct skcipher_sg_list *sgl;
+ struct scatterlist *sg;
+ int nents = 0;
+
+ list_for_each_entry(sgl, ctx-tsgl, list) {
+ sg = sgl-sg;
+
+ while (!sg-length)
+ sg++;
+
+ nents += sg_nents(sg);
+ }
+ return nents;
+}
+
+static int skcipher_recvmsg_async(struct kiocb *iocb, struct socket *sock,
+ struct msghdr *msg, size_t ignored, int flags)
+{
+ struct sock *sk = sock-sk;
+ struct alg_sock *ask = alg_sk(sk);
+ struct skcipher_ctx *ctx = ask-private;
+ struct skcipher_sg_list *sgl;
+ struct scatterlist *sg;
+ struct skcipher_async_req *sreq;
+ struct ablkcipher_request *req;
+ struct skcipher_async_rsgl *last_rsgl = NULL;
+ unsigned int len = 0, tx_nents = skcipher_all_sg_nents(ctx);
+ unsigned int reqlen = sizeof(struct skcipher_async_req) +
+ GET_REQ_SIZE(ctx) + GET_IV_SIZE(ctx);
+ int
[PATCH RFC 0/4] Add support for async socket operations
After the iocb parameter has been removed from sendmsg() and recvmsg() ops the socket layer, and the network stack no longer support async operations. This patch set adds support for asynchronous operations on sockets back. -- Tadeusz Struk (4): net: socket: add support for async operations aio: prefer aio_op op over inter_op crypto: af_alg - Allow to link sgl crypto: algif - change algif_skcipher to be asynchronous crypto/af_alg.c | 18 +++- crypto/algif_skcipher.c | 224 ++- fs/aio.c|8 +- include/crypto/if_alg.h |4 + include/linux/net.h |8 ++ net/socket.c| 64 + 6 files changed, 312 insertions(+), 14 deletions(-) -- -- 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: algif_rng - zeroize buffer holding random data
Due to the change to RNGs to always return zero in success case, the RNG interface must zeroize the buffer with the length provided by the caller. Signed-off-by: Stephan Mueller smuel...@chronox.de --- crypto/algif_rng.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crypto/algif_rng.c b/crypto/algif_rng.c index 67f612c..a346173 100644 --- a/crypto/algif_rng.c +++ b/crypto/algif_rng.c @@ -87,7 +87,7 @@ static int rng_recvmsg(struct kiocb *unused, struct socket *sock, return genlen; err = memcpy_to_msg(msg, result, len); - memzero_explicit(result, genlen); + memzero_explicit(result, len); return err ? err : len; } -- 2.1.0 -- 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 2/4] hwrng: omap - remove #ifdefery around PM methods
On Mon, Mar 09, 2015 at 10:36:36AM -0700, Dmitry Torokhov wrote:
Instead of using #ifdefs let's mark suspend and resume methods as
__maybe_unused which will suppress compiler warnings about them being
unused and provide better compile coverage. This will not increase image
size.
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
drivers/char/hw_random/omap-rng.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c
b/drivers/char/hw_random/omap-rng.c
index 7f3597d..5c171b1 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -422,9 +422,7 @@ static int omap_rng_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM_SLEEP
-
-static int omap_rng_suspend(struct device *dev)
+static int __maybe_unused omap_rng_suspend(struct device *dev)
{
struct omap_rng_dev *priv = dev_get_drvdata(dev);
@@ -434,7 +432,7 @@ static int omap_rng_suspend(struct device *dev)
return 0;
}
-static int omap_rng_resume(struct device *dev)
+static int __maybe_unused omap_rng_resume(struct device *dev)
{
struct omap_rng_dev *priv = dev_get_drvdata(dev);
@@ -445,18 +443,11 @@ static int omap_rng_resume(struct device *dev)
}
static SIMPLE_DEV_PM_OPS(omap_rng_pm, omap_rng_suspend, omap_rng_resume);
-#define OMAP_RNG_PM (omap_rng_pm)
-
-#else
-
-#define OMAP_RNG_PM NULL
-
-#endif
static struct platform_driver omap_rng_driver = {
.driver = {
.name = omap_rng,
- .pm = OMAP_RNG_PM,
+ .pm = omap_rng_pm,
This will cause omap_rng_suspend/omap_rng_resume to be referenced
always, thus rendering the __maybe_unused moot, no?
Cheers,
--
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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] mm: kill kmemcheck
On Wed, 11 Mar 2015 08:34:46 -0400 Sasha Levin sasha.le...@oracle.com wrote: Fair enough. We knew there are existing kmemcheck users, but KASan should be superior both in performance and the scope of bugs it finds. It also shouldn't impose new limitations beyond requiring gcc 4.9.2+. Ouch! OK, then I can't use it. I'm currently compiling with gcc 4.6.3. It will be a while before I upgrade my build farm to something newer. -- Steve -- 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] mm: kill kmemcheck
On 03/11/2015 08:40 AM, Steven Rostedt wrote: On Wed, 11 Mar 2015 08:34:46 -0400 Sasha Levin sasha.le...@oracle.com wrote: Fair enough. We knew there are existing kmemcheck users, but KASan should be superior both in performance and the scope of bugs it finds. It also shouldn't impose new limitations beyond requiring gcc 4.9.2+. Ouch! OK, then I can't use it. I'm currently compiling with gcc 4.6.3. It will be a while before I upgrade my build farm to something newer. Are you actually compiling new kernels with 4.6.3, or are you using older kernels as well? There's no real hurry to kill kmemcheck right now, but we do want to stop supporting that in favour of KASan. 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: [PATCH] mm: kill kmemcheck
On 03/11/2015 08:19 AM, Steven Rostedt wrote: I removed the Cc list as it was so large, I'm sure that it exceeded the LKML Cc size limit, and your email probably didn't make it to the list (or any of them). Thanks. I'll resend in a bit if it doesn't show up on lkml.org. On Wed, 11 Mar 2015 07:43:59 -0400 Sasha Levin sasha.le...@oracle.com wrote: As discussed on LSF/MM, kill kmemcheck. KASan is a replacement that is able to work without the limitation of kmemcheck (single CPU, slow). KASan is already upstream. We are also not aware of any users of kmemcheck (or users who don't consider KASan as a suitable replacement). I use kmemcheck and I am unaware of KASan. I'll try to play with KASan and see if it suites my needs. Fair enough. We knew there are existing kmemcheck users, but KASan should be superior both in performance and the scope of bugs it finds. It also shouldn't impose new limitations beyond requiring gcc 4.9.2+. 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
[PATCH] crypto: testmgr - fix RNG return code enforcement
From 0c7233769665f03e9f91342770dba7279f928c23 Mon Sep 17 00:00:00 2001
From: Stephan Mueller smuel...@chronox.de
Date: Tue, 10 Mar 2015 17:00:36 +0100
Subject: [PATCH] crypto: testmgr - fix RNG return code enforcement
Due to the change to RNGs to always return zero in success case, the
invocation of the RNGs in the test manager must be updated as otherwise
the RNG self tests are not properly executed any more.
Signed-off-by: Stephan Mueller smuel...@chronox.de
Signed-off-by: Alexander Bergmann abergm...@suse.com
---
crypto/testmgr.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index f4ed6d4..1f879ad 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1474,11 +1474,11 @@ static int test_cprng(struct crypto_rng *tfm, struct
cprng_testvec *template,
for (j = 0; j template[i].loops; j++) {
err = crypto_rng_get_bytes(tfm, result,
template[i].rlen);
- if (err != template[i].rlen) {
+ if (err 0) {
printk(KERN_ERR alg: cprng: Failed to obtain
the correct amount of random data for
- %s (requested %d, got %d)\n, algo,
- template[i].rlen, err);
+ %s (requested %d)\n, algo,
+ template[i].rlen);
goto out;
}
}
@@ -1759,7 +1759,7 @@ static int drbg_cavs_test(struct drbg_testvec *test, int
pr,
ret = crypto_drbg_get_bytes_addtl(drng,
buf, test-expectedlen, addtl);
}
- if (ret = 0) {
+ if (ret 0) {
printk(KERN_ERR alg: drbg: could not obtain random data for
driver %s\n, driver);
goto outbuf;
@@ -1774,7 +1774,7 @@ static int drbg_cavs_test(struct drbg_testvec *test, int
pr,
ret = crypto_drbg_get_bytes_addtl(drng,
buf, test-expectedlen, addtl);
}
- if (ret = 0) {
+ if (ret 0) {
printk(KERN_ERR alg: drbg: could not obtain random data for
driver %s\n, driver);
goto outbuf;
--
1.8.1.4
--
Alexander Bergmann abergm...@suse.com, Security Engineer,
SUSE Linux GmbH,
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton, HRB 21284 (AG Nürnberg)
signature.asc
Description: Digital signature
[PATCH V4 0/2] crypto: Add Imagination Technologies hw hash accelerator
This adds support for the Imagination Technologies hash accelerator which provides hardware acceleration for SHA1 SHA244 SHA256 and MD5 hashes. Tested on silicon, using testmgr. Changes from V3: * Standardised the cra_priorities to 300, sufficient to be chosen ahead of software / assembly implementations. * Addressed Andrew Bresticker's review comments, except for two items that I will leave for when I have some more bandwidth if possible as I don't think they are required: -Runtime PM -Threaded IRQ handler instead of a tasklet Changes from V2: * This hardware does not support importing a partial hash state, so the init, update, final and finup have been reworked to use a fallback driver; only digest remains as hardware accelerated. * Simplified the driver as a result of the above rework Changes from V1: * Addressed review comments from Andrew Bresticker and Vladimir Zapolskiy * rebased to current linux-next James Hartley (2): This adds support for the Imagination Technologies hash accelerator which provides hardware acceleration for SHA1 SHA224 SHA256 and MD5 hashes. This adds the binding documentation for the Imagination Technologies hash accelerator that provides hardware acceleration for SHA1/SHA224/SHA256/MD5 hashes. This hardware will be present in the upcoming pistachio SoC. .../devicetree/bindings/crypto/img-hash.txt| 27 + drivers/crypto/Kconfig | 14 + drivers/crypto/Makefile|1 + drivers/crypto/img-hash.c | 1026 4 files changed, 1068 insertions(+) create mode 100644 Documentation/devicetree/bindings/crypto/img-hash.txt create mode 100644 drivers/crypto/img-hash.c -- 1.7.9.5 -- 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-next: Tree for Mar 11 (powerpc build failure due to vmx crypto code)
On Wed, Mar 11, 2015 at 07:43:22PM -0700, Guenter Roeck wrote:
It looks like the perl scripts do run - I see the .S files, and I do see .o
files created.
But I still get the error.
Looking into the object files, I see
$ nm vmx-crypto.o | grep aes_p8_cbc_encrypt
0680 t .aes_p8_cbc_encrypt
U .aes_p8_cbc_encrypt
00a8 D aes_p8_cbc_encrypt
Ugh, does this patch help?
Thanks,
--8--
crypto: vmx - Fix assembler perl to use _GLOBAL
Rather than doing things by hand for global symbols to deal with
different calling conventions we already have a macro _GLOBAL in
Linux to handle this.
Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
diff --git a/drivers/crypto/vmx/aesp8-ppc.pl b/drivers/crypto/vmx/aesp8-ppc.pl
old mode 100755
new mode 100644
index 3ee8979..6c5c20c
--- a/drivers/crypto/vmx/aesp8-ppc.pl
+++ b/drivers/crypto/vmx/aesp8-ppc.pl
@@ -85,8 +85,6 @@ Lconsts:
.asciz AES for PowerISA 2.07, CRYPTOGAMS by appro\@openssl.org
.globl .${prefix}_set_encrypt_key
-.align 5
-.${prefix}_set_encrypt_key:
Lset_encrypt_key:
mflrr11
$PUSH r11,$LRSAVE($sp)
@@ -348,8 +346,6 @@ Lenc_key_abort:
.size .${prefix}_set_encrypt_key,.-.${prefix}_set_encrypt_key
.globl .${prefix}_set_decrypt_key
-.align 5
-.${prefix}_set_decrypt_key:
$STU$sp,-$FRAME($sp)
mflrr10
$PUSH r10,$FRAME+$LRSAVE($sp)
@@ -405,8 +401,6 @@ my ($inp,$out,$key,$rounds,$idx)=map(r$_,(3..7));
$code.=___;
.globl .${prefix}_${dir}crypt
-.align 5
-.${prefix}_${dir}crypt:
lwz $rounds,240($key)
lis r0,0xfc00
mfspr $vrsave,256
@@ -484,8 +478,6 @@ my
($ivec,$inptail,$inpperm,$outhead,$outperm,$outmask,$keyperm)=
map(v$_,(4..10));
$code.=___;
.globl .${prefix}_cbc_encrypt
-.align 5
-.${prefix}_cbc_encrypt:
${UCMP}i$len,16
bltlr-
@@ -1243,8 +1235,6 @@ my $dat=$tmp;
$code.=___;
.globl .${prefix}_ctr32_encrypt_blocks
-.align 5
-.${prefix}_ctr32_encrypt_blocks:
${UCMP}i$len,1
bltlr-
diff --git a/drivers/crypto/vmx/ghashp8-ppc.pl
b/drivers/crypto/vmx/ghashp8-ppc.pl
old mode 100755
new mode 100644
index e76a58c..0a6f899
--- a/drivers/crypto/vmx/ghashp8-ppc.pl
+++ b/drivers/crypto/vmx/ghashp8-ppc.pl
@@ -54,8 +54,6 @@ $code=___;
.text
.globl .gcm_init_p8
-.align 5
-.gcm_init_p8:
lis r0,0xfff0
li r8,0x10
mfspr $vrsave,256
@@ -98,8 +96,6 @@ $code=___;
.size .gcm_init_p8,.-.gcm_init_p8
.globl .gcm_gmult_p8
-.align 5
-.gcm_gmult_p8:
lis r0,0xfff8
li r8,0x10
mfspr $vrsave,256
@@ -148,8 +144,6 @@ $code=___;
.size .gcm_gmult_p8,.-.gcm_gmult_p8
.globl .gcm_ghash_p8
-.align 5
-.gcm_ghash_p8:
lis r0,0xfff8
li r8,0x10
mfspr $vrsave,256
diff --git a/drivers/crypto/vmx/ppc-xlate.pl b/drivers/crypto/vmx/ppc-xlate.pl
old mode 100755
new mode 100644
index f89e814..a591884
--- a/drivers/crypto/vmx/ppc-xlate.pl
+++ b/drivers/crypto/vmx/ppc-xlate.pl
@@ -27,25 +27,13 @@ my $globl = sub {
/osx/do { $name = _$name;
last;
};
- /linux.*(32|64le)/
-do { $ret .= .globl $name\n;
- $ret .= .type $name,\@function;
- last;
- };
- /linux.*64/ do { $ret .= .globl $name\n;
- $ret .= .type $name,\@function\n;
- $ret .= .section \.opd\,\aw\\n;
- $ret .= .align 3\n;
- $ret .= $name:\n;
- $ret .= .quad .$name,.TOC.\@tocbase,0\n;
- $ret .= .previous\n;
-
- $name = .$name;
+ /linux/
+do { $ret = _GLOBAL($name);
last;
};
}
-$ret = .globl $name if (!$ret);
+$ret = .globl $name\nalign 5\n$name: if (!$ret);
$$global = $name;
$ret;
};
@@ -187,6 +175,8 @@ my $mtsle = sub {
.long .sprintf 0x%X,(3126)|($arg21)|(147*2);
};
+print #include asm/ppc_asm.h\n if $flavour =~ /linux/;
+
while($line=) {
$line =~ s|[#!;].*$||; # get rid of asm-style comments...
@@ -200,15 +190,6 @@ while($line=) {
}
{
- $line =~ s|(^[\.\w]+)\:\s*||;
- my $label = $1;
- if ($label) {
- printf %s:,($GLOBALS{$label} or $label);
- printf \n.localentry\t$GLOBALS{$label},0 if ($GLOBALS{$label}
$flavour =~ /linux.*64le/);
- }
-}
-
-{
$line =~ s|^\s*(\.?)(\w+)([\.\+\-]?)\s*||;
my $c = $1; $c
RE: [PATCH V3 1/2] crypto: Add Imagination Technologies hw hash accelerator
Hi Andrew,
-Original Message-
From: abres...@google.com [mailto:abres...@google.com] On Behalf Of
Andrew Bresticker
Sent: 10 March 2015 18:02
To: James Hartley
Cc: linux-crypto@vger.kernel.org
Subject: Re: [PATCH V3 1/2] crypto: Add Imagination Technologies hw hash
accelerator
Hi James,
+static irqreturn_t img_irq_handler(int irq, void *dev_id) {
+ struct img_hash_dev *hdev = dev_id;
+ u32 reg;
+
+ reg = img_hash_read(hdev, CR_INTSTAT);
+ img_hash_write(hdev, CR_INTCLEAR, reg);
+
+ if (reg CR_INT_NEW_RESULTS_SET) {
+ dev_dbg(hdev-dev, IRQ CR_INT_NEW_RESULTS_SET\n);
+ if (DRIVER_FLAGS_BUSY hdev-flags) {
+ hdev-flags |= DRIVER_FLAGS_OUTPUT_READY;
+ if (!(DRIVER_FLAGS_CPU hdev-flags))
+ hdev-flags |= DRIVER_FLAGS_DMA_READY;
+ tasklet_schedule(hdev-done_task);
Since this done_task only gets scheduled from here, why not make this
a threaded IRQ handler and just do the work here instead of
separating it between a hard IRQ handler and a tasklet?
What is the advantage of doing that? i.e is this simple case worth setting
up
an extra thread?
I believe threaded IRQ handlers are now preferred to using a hard IRQ
handler + tasklet when possible, partly because people tend to screw up
tasklet usage.
Fair enough, but I'd like to leave this as an enhancement for when I have some
extra bandwidth if it's not essential (same for the runtime PM).
+ err = PTR_ERR(hdev-io_base);
+ goto hash_io_err;
+ }
+
+ /* Write port (DMA or CPU) */
+ hash_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!hash_res) {
+ dev_err(dev, no write port resource info\n);
+ err = -ENODEV;
+ goto res_err;
+ }
+ hdev-bus_addr = hash_res-start;
Maybe set this after devm_ioremap_resource() succeeds and avoid the
extra error check?
Not quite following you here - which check are you saying can be removed?
You can remove the if (hash_res) check if you set hdev-bus_addr after
devm_ioremap_resource().
I see what you mean - done.
Thanks,
Andrew
Thanks,
James.
N�r��yb�X��ǧv�^�){.n�+{�r����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
Re: linux-next: Tree for Mar 11 (powerpc build failure due to vmx crypto code)
On Wed, Mar 11, 2015 at 08:51:32PM -0700, Guenter Roeck wrote: Yes, this helps. Feel free to add Tested-by: Guenter Roeck li...@roeck-us.net Thanks for testing and the quick feedback. -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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] mm: kill kmemcheck
On 03/11/2015 10:26 AM, Steven Rostedt wrote: There's no real hurry to kill kmemcheck right now, but we do want to stop supporting that in favour of KASan. Understood, but the kernel is suppose to support older compilers. Perhaps we can keep kmemcheck for now and say it's obsoleted if you have a newer compiler. Because it will be a while before I upgrade my compilers. I don't upgrade unless I have a good reason to do so. Not sure KASan fulfills that requirement. It's not that there's a performance overhead with kmemcheck, it's the maintenance effort that we want to get rid of. The kernel should keep supporting old kernels, and after this kmemcheck removal your kernel will still keep working - this is more of a removal of a mostly unused feature that had hooks everywhere in the kernel. Did you actually find anything recently with kmemcheck? How do you deal with the 1 CPU limit and the massive performance hit? Could you try KASan for your use case and see if it potentially uncovers anything new? 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: [PATCH] crypto: qat - remove incorrect __exit markup
On Mon, Mar 09, 2015 at 01:25:49PM -0700, Dmitry Torokhov wrote: PCI bus is hot-pluggable, and even if it wasn't one can still unbind the device from driver via sysfs, so we should not make driver's remove method as __exit. Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com Applied. -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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] crypto: tcrypt - fix uninit sg entries in test_acipher_speed
On Mon, Mar 09, 2015 at 04:14:58PM +0200, Horia Geanta wrote: Commit 5be4d4c94b1f (crypto: replace scatterwalk_sg_next with sg_next) did not consider the fact that scatterwalk_sg_next() was looking at sg entry length, while sg_next() looks at the chained sg bit. This should have no effect in theory. However in practice, there are cases where the sg table is initialized to a number of entries and some of them are not properly configured. While scatterwalk_sg_next() would have returned NULL (since sg length = 0 and sg page_link = 0), sg_next() happily returns the next unconfigured sg entry. insmod tcrypt.ko mode=500 sec=1 testing speed of async cbc(aes) (cbc-aes-talitos) encryption test 0 (128 bit key, 16 byte blocks): Unable to handle kernel paging request for data at address 0x Faulting instruction address: 0xc00d79e4 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=8 P1022 DS Modules linked in: tcrypt(+) talitos CPU: 0 PID: 2670 Comm: insmod Not tainted 4.0.0-rc1-QorIQ-SDK-V1.6+g904f1ca82209 #1 task: e8de3200 ti: e70bc000 task.ti: e70bc000 NIP: c00d79e4 LR: f92d223c CTR: c00d79c8 REGS: e70bda00 TRAP: 0300 Not tainted (4.0.0-rc1-QorIQ-SDK-V1.6+g904f1ca82209) MSR: 00029000 CE,EE,ME CR: 84428f22 XER: DEAR: ESR: GPR00: f92d223c e70bdab0 e8de3200 e70bdbb8 0001 GPR08: c08b0380 27282010 c00d79c8 1003a634 e70bdf1c GPR16: e70bdef0 0020 c08c 0010 e70bdbb8 0010 GPR24: e976d3a8 0010 e70bdbd8 e8961010 0001 c086e560 NIP [c00d79e4] page_address+0x1c/0x110 LR [f92d223c] talitos_map_sg+0x130/0x184 [talitos] Call Trace: [e70bdab0] [0010] 0x10 (unreliable) [e70bdad0] [f92d223c] talitos_map_sg+0x130/0x184 [talitos] [e70bdb00] [f92d30d8] common_nonsnoop.constprop.13+0xc0/0x304 [talitos] [e70bdb30] [f933fd90] test_acipher_speed+0x434/0x7dc [tcrypt] [e70bdcc0] [f934318c] do_test+0x2478/0x306c [tcrypt] [e70bdd80] [f11fe058] tcrypt_mod_init+0x58/0x100 [tcrypt] [e70bdda0] [c0002354] do_one_initcall+0x90/0x1f4 [e70bde10] [c061fe00] do_init_module+0x60/0x1ac [e70bde30] [c00a79f0] load_module+0x185c/0x1f88 [e70bdee0] [c00a82b0] SyS_finit_module+0x7c/0x98 [e70bdf40] [c000e8b0] ret_from_syscall+0x0/0x3c --- interrupt: c01 at 0xff1985c LR = 0x10012df0 Instruction dump: 54ea402e 7d494b78 55292834 7c634a14 4e800020 9421ffe0 7c0802a6 3d40c08b 394a0380 bf61000c 7c7f1b78 90010024 8123 552917be 1d290320 7d295214 ---[ end trace ff191e5b504b4671 ]--- Signed-off-by: Horia Geanta horia.gea...@freescale.com Applied. Thanks! -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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 1/4] hwrng: omap - remove incorrect __exit markups
On Mon, Mar 09, 2015 at 10:36:35AM -0700, Dmitry Torokhov wrote: Even if bus is not hot-pluggable, the devices can be unbound from the driver via sysfs, so we should not be using __exit annotations on remove() methods. The only exception is drivers registered with platform_driver_probe() which specifically disables sysfs bind/unbind attributes. Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com Patches 1/3/4 applied. -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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] mm: kill kmemcheck
On Wed, Mar 11, 2015 at 09:39:33AM -0400, Sasha Levin wrote: On 03/11/2015 08:40 AM, Steven Rostedt wrote: On Wed, 11 Mar 2015 08:34:46 -0400 Sasha Levin sasha.le...@oracle.com wrote: Fair enough. We knew there are existing kmemcheck users, but KASan should be superior both in performance and the scope of bugs it finds. It also shouldn't impose new limitations beyond requiring gcc 4.9.2+. Ouch! OK, then I can't use it. I'm currently compiling with gcc 4.6.3. It will be a while before I upgrade my build farm to something newer. Are you actually compiling new kernels with 4.6.3, or are you using older kernels as well? There's no real hurry to kill kmemcheck right now, but we do want to stop supporting that in favour of KASan. Another question is is kmemcheck actually finding anything right now? I've personally not hit anything with it in quite a while. Dave -- 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 V4 1/2] crypto: Add Imagination Technologies hw hash accelerator
This adds support for the Imagination Technologies hash accelerator which
provides hardware acceleration for SHA1 SHA224 SHA256 and MD5 hashes.
Signed-off-by: James Hartley james.hart...@imgtec.com
---
drivers/crypto/Kconfig| 14 +
drivers/crypto/Makefile |1 +
drivers/crypto/img-hash.c | 1028 +
3 files changed, 1043 insertions(+)
create mode 100644 drivers/crypto/img-hash.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 2fb0fdf..c72223e 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -436,4 +436,18 @@ config CRYPTO_DEV_QCE
hardware. To compile this driver as a module, choose M here. The
module will be called qcrypto.
+config CRYPTO_DEV_IMGTEC_HASH
+ depends on MIPS || COMPILE_TEST
+ tristate Imagination Technologies hardware hash accelerator
+ select CRYPTO_ALG_API
+ select CRYPTO_MD5
+ select CRYPTO_SHA1
+ select CRYPTO_SHA224
+ select CRYPTO_SHA256
+ select CRYPTO_HASH
+ help
+ This driver interfaces with the Imagination Technologies
+ hardware hash accelerator. Supporting MD5/SHA1/SHA224/SHA256
+ hashing algorithms.
+
endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 3924f93..1c34fff 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_CRYPTO_DEV_CCP) += ccp/
obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM) += caam/
obj-$(CONFIG_CRYPTO_DEV_GEODE) += geode-aes.o
obj-$(CONFIG_CRYPTO_DEV_HIFN_795X) += hifn_795x.o
+obj-$(CONFIG_CRYPTO_DEV_IMGTEC_HASH) += img-hash.o
obj-$(CONFIG_CRYPTO_DEV_IXP4XX) += ixp4xx_crypto.o
obj-$(CONFIG_CRYPTO_DEV_MV_CESA) += mv_cesa.o
obj-$(CONFIG_CRYPTO_DEV_MXS_DCP) += mxs-dcp.o
diff --git a/drivers/crypto/img-hash.c b/drivers/crypto/img-hash.c
new file mode 100644
index 000..5c19905
--- /dev/null
+++ b/drivers/crypto/img-hash.c
@@ -0,0 +1,1028 @@
+/*
+ * Copyright (c) 2014 Imagination Technologies
+ * Authors: Will Thomas, James Hartley
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ *
+ * Interface structure taken from omap-sham driver
+ */
+
+#include linux/clk.h
+#include linux/dmaengine.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/scatterlist.h
+
+#include crypto/internal/hash.h
+#include crypto/md5.h
+#include crypto/sha.h
+
+#define CR_RESET 0
+#define CR_RESET_SET 1
+#define CR_RESET_UNSET 0
+
+#define CR_MESSAGE_LENGTH_H0x4
+#define CR_MESSAGE_LENGTH_L0x8
+
+#define CR_CONTROL 0xc
+#define CR_CONTROL_BYTE_ORDER_3210 0
+#define CR_CONTROL_BYTE_ORDER_0123 1
+#define CR_CONTROL_BYTE_ORDER_2310 2
+#define CR_CONTROL_BYTE_ORDER_1032 3
+#define CR_CONTROL_BYTE_ORDER_SHIFT8
+#define CR_CONTROL_ALGO_MD50
+#define CR_CONTROL_ALGO_SHA1 1
+#define CR_CONTROL_ALGO_SHA224 2
+#define CR_CONTROL_ALGO_SHA256 3
+
+#define CR_INTSTAT 0x10
+#define CR_INTENAB 0x14
+#define CR_INTCLEAR0x18
+#define CR_INT_RESULTS_AVAILABLE BIT(0)
+#define CR_INT_NEW_RESULTS_SET BIT(1)
+#define CR_INT_RESULT_READ_ERR BIT(2)
+#define CR_INT_MESSAGE_WRITE_ERROR BIT(3)
+#define CR_INT_STATUS BIT(8)
+
+#define CR_RESULT_QUEUE0x1c
+#define CR_RSD00x40
+#define CR_CORE_REV0x50
+#define CR_CORE_DES1 0x60
+#define CR_CORE_DES2 0x70
+
+#define DRIVER_FLAGS_BUSY BIT(0)
+#define DRIVER_FLAGS_FINAL BIT(1)
+#define DRIVER_FLAGS_DMA_ACTIVEBIT(2)
+#define DRIVER_FLAGS_OUTPUT_READY BIT(3)
+#define DRIVER_FLAGS_INIT BIT(4)
+#define DRIVER_FLAGS_CPU BIT(5)
+#define DRIVER_FLAGS_DMA_READY BIT(6)
+#define DRIVER_FLAGS_ERROR BIT(7)
+#define DRIVER_FLAGS_SGBIT(8)
+#define DRIVER_FLAGS_SHA1 BIT(18)
+#define DRIVER_FLAGS_SHA224BIT(19)
+#define DRIVER_FLAGS_SHA256BIT(20)
+#define DRIVER_FLAGS_MD5 BIT(21)
+
+#define IMG_HASH_QUEUE_LENGTH 20
+#define IMG_HASH_DMA_THRESHOLD 64
+
+#ifdef __LITTLE_ENDIAN
+#define IMG_HASH_BYTE_ORDERCR_CONTROL_BYTE_ORDER_3210
+#else
+#define IMG_HASH_BYTE_ORDERCR_CONTROL_BYTE_ORDER_0123
+#endif
+
+struct img_hash_dev;
+
+struct img_hash_request_ctx {
+ struct img_hash_dev *hdev;
+ u8 digest[SHA256_DIGEST_SIZE] __aligned(sizeof(u32));
+ unsigned long flags;
+ size_t digsize;
+
+
[PATCH V4 2/2] Documentation: crypto: Add DT binding info for the img hw hash accelerator
This adds the binding documentation for the Imagination Technologies hash
accelerator that provides hardware acceleration for SHA1/SHA224/SHA256/MD5
hashes. This hardware will be present in the upcoming pistachio SoC.
Signed-off-by: James Hartley james.hart...@imgtec.com
---
.../devicetree/bindings/crypto/img-hash.txt| 27
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/img-hash.txt
diff --git a/Documentation/devicetree/bindings/crypto/img-hash.txt
b/Documentation/devicetree/bindings/crypto/img-hash.txt
new file mode 100644
index 000..91a3d75
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/img-hash.txt
@@ -0,0 +1,27 @@
+Imagination Technologies hardware hash accelerator
+
+The hash accelerator provides hardware hashing acceleration for
+SHA1, SHA224, SHA256 and MD5 hashes
+
+Required properties:
+
+- compatible : img,hash-accelerator
+- reg : Offset and length of the register set for the module, and the DMA port
+- interrupts : The designated IRQ line for the hashing module.
+- dmas : DMA specifier as per Documentation/devicetree/bindings/dma/dma.txt
+- dma-names : Should be tx
+- clocks : Clock specifiers
+- clock-names : sys Used to clock the hash block registers
+ hash Used to clock data through the accelerator
+
+Example:
+
+ hash: hash@18149600 {
+ compatible = img,hash-accelerator;
+ reg = 0x18149600 0x100, 0x18101100 0x4;
+ interrupts = GIC_SHARED 59 IRQ_TYPE_LEVEL_HIGH;
+ dmas = dma 8 0x 0;
+ dma-names = tx;
+ clocks = cr_periph SYS_CLK_HASH, clk_periph
PERIPH_CLK_ROM;
+ clock-names = sys, hash;
+ };
--
1.7.9.5
--
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-next: Tree for Mar 11 (powerpc build failure due to vmx crypto code)
On 03/11/2015 06:23 PM, Herbert Xu wrote: On Wed, Mar 11, 2015 at 08:47:17AM -0700, Guenter Roeck wrote: Building powerpc:allmodconfig: ERROR: .aes_p8_cbc_encrypt [drivers/crypto/vmx/vmx-crypto.ko] undefined! ERROR: .aes_p8_set_encrypt_key [drivers/crypto/vmx/vmx-crypto.ko] undefined! ERROR: .aes_p8_set_decrypt_key [drivers/crypto/vmx/vmx-crypto.ko] undefined! ERROR: .gcm_init_p8 [drivers/crypto/vmx/vmx-crypto.ko] undefined! ERROR: .aes_p8_decrypt [drivers/crypto/vmx/vmx-crypto.ko] undefined! ERROR: .aes_p8_encrypt [drivers/crypto/vmx/vmx-crypto.ko] undefined! ERROR: .gcm_ghash_p8 [drivers/crypto/vmx/vmx-crypto.ko] undefined! ERROR: .aes_p8_ctr32_encrypt_blocks [drivers/crypto/vmx/vmx-crypto.ko] undefined! Those functions are called but don't seem to be defined anywhere. They are meant to be generated by the perl scripts in that directory. Can you take a look at why those perl scripts didn't run or didn't function correctly? It looks like the perl scripts do run - I see the .S files, and I do see .o files created. But I still get the error. Looking into the object files, I see $ nm vmx-crypto.o | grep aes_p8_cbc_encrypt 0680 t .aes_p8_cbc_encrypt U .aes_p8_cbc_encrypt 00a8 D aes_p8_cbc_encrypt $ nm aesp8-ppc.o | grep aes_p8_cbc_encrypt 0680 t .aes_p8_cbc_encrypt 0060 D aes_p8_cbc_encrypt In the assembler source, I see .globl aes_p8_cbc_encrypt but no .globl for .aes_p8_cbc_encrypt. Does that tell you anything ? I also notice is that the .S files are not removed with make mrproper but left behind. Seems to me that those files should be removed. Guenter -- 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
