On Sun, Nov 24, 2013 at 10:36:28PM -0800, Shawn Landden wrote:
> Commit 35f9c09fe (tcp: tcp_sendpages() should call tcp_push() once)
> added an internal flag MSG_SENDPAGE_NOTLAST, similar to
> MSG_MORE.
>
> algif_hash, algif_skcipher, and udp used MSG_MORE from tcp_sendpages()
> and need to see th
On Thu, Nov 28, 2013 at 07:16:27PM +0200, Cristian Stoica wrote:
> Signed-off-by: Cristian Stoica
> ---
> crypto/authenc.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/crypto/authenc.c b/crypto/authenc.c
> index 1875e70..7d4bfaa 100644
> --- a/crypto/authenc.c
> +++ b/crypto/authen
On Thu, Nov 28, 2013 at 04:39:43PM +0100, Harald Freudenberger wrote:
>
> > You can't use mutex_lock because you may be in a non-sleepable
> > context. Perhaps just fall back to doing it block-by-block, like
> > we do in aesni-intel on x86?
>
> The first attempt to lock the mutex is done with mut
Two small RCU related fixes, lockdep complained about.
Please apply!
Mathias Krause (2):
crypto: pcrypt - Fix wrong usage of rcu_dereference()
padata: Fix wrong usage of rcu_dereference()
crypto/pcrypt.c |2 +-
kernel/padata.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
A kernel with enabled lockdep complains about the wrong usage of
rcu_dereference() under a rcu_read_lock_bh() protected region.
===
[ INFO: suspicious RCU usage. ]
3.13.0-rc1+ #126 Not tainted
---
linux/crypto/pcrypt.c:81 suspicious
A kernel with enabled lockdep complains about the wrong usage of
rcu_dereference() under a rcu_read_lock_bh() protected region.
===
[ INFO: suspicious RCU usage. ]
3.13.0-rc1+ #126 Not tainted
---
linux/kernel/padata.c:115 suspiciou
Commit 35f9c09fe (tcp: tcp_sendpages() should call tcp_push() once)
added an internal flag MSG_SENDPAGE_NOTLAST.
We have to check for MSG_SENDPAGE_NOTLAST too to find out whether more data
is available.
Cc: Tom Herbert
Cc: Eric Dumazet
Cc: David S. Miller
Cc: # 3.2.x
Reported-and-tested-by: Sh
Signed-off-by: Cristian Stoica
---
crypto/authenc.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/crypto/authenc.c b/crypto/authenc.c
index 1875e70..7d4bfaa 100644
--- a/crypto/authenc.c
+++ b/crypto/authenc.c
@@ -17,11 +17,8 @@
#include
#include
#include
-#include
#include
#inc
On Thu, 2013-11-28 at 22:00 +0800, Herbert Xu wrote:
> On Tue, Nov 19, 2013 at 11:22:12AM +0100, Harald Freudenberger wrote:
> > The aes-ctr mode used one preallocated page without any concurrency
> > protection. When multiple threads run aes-ctr encryption or decryption
> > this could lead to data
On Fri, Nov 22, 2013 at 02:57:56PM +0100, Gerald Schaefer wrote:
> On Tue, 19 Nov 2013 17:12:47 +0100
> Gerald Schaefer wrote:
>
> > Some s390 crypto algorithms incorrectly use the crypto_tfm structure
> > to store private data. As the tfm can be shared among multiple
> > threads, this can result
On Thu, Nov 28, 2013 at 03:11:15PM +0200, Horia Geanta wrote:
> There are cases when cryptlen can be zero in crypto_ccm_auth():
> -encryptiom: input scatterlist length is zero (no plaintext)
> -decryption: input scatterlist contains only the mac
> plus the condition of having different source and d
On Tue, Nov 19, 2013 at 02:57:49PM +0200, Horia Geanta wrote:
> talitos does not handle well zero-length assoc data. From dmesg:
> talitos ffe3.crypto: master data transfer error
> talitos ffe3.crypto: gather return/length error
>
> Check whether assoc data is provided by inspecting assocl
On Tue, Nov 12, 2013 at 11:46:10AM -0600, Tom Lendacky wrote:
> The scatterwalk_crypto_chain function invokes the scatterwalk_sg_chain
> function to chain two scatterlists, but the chain pointer indication
> bit is not set. When the resulting scatterlist is used, for example,
> by sg_nents to coun
On Tue, Nov 12, 2013 at 11:46:04AM -0600, Tom Lendacky wrote:
> When performing an asynchronous ablkcipher operation the authenc
> completion callback routine is invoked, but it does not locate and use
> the proper IV.
>
> The callback routine, crypto_authenc_encrypt_done, is updated to use
> the
On Tue, Nov 19, 2013 at 11:22:12AM +0100, Harald Freudenberger wrote:
> The aes-ctr mode used one preallocated page without any concurrency
> protection. When multiple threads run aes-ctr encryption or decryption
> this could lead to data corruption.
>
> The patch introduces locking for the preall
On Fri, Nov 15, 2013 at 10:31:25AM +0800, Jeff Liu wrote:
> From: Jie Liu
>
> In skcipher_alloc_sgl(), there is a potential null pointer dereference
> issue to retrieve the last item from ctx->tsgl list if the list is empty.
>
> This patch fix it by checking if the list is empty or not at first.
Commit d8a32ac25698cd60b02bed2100379803c7f964e3 (crypto: testmgr - make
test_aead also test 'dst != src' code paths) added support for different
source and destination buffers in test_aead.
This patch modifies the source and destination buffer lengths accordingly:
the lengths are not equal since e
There are cases when cryptlen can be zero in crypto_ccm_auth():
-encryptiom: input scatterlist length is zero (no plaintext)
-decryption: input scatterlist contains only the mac
plus the condition of having different source and destination buffers
(or else scatterlist length = max(plaintext_len, ci
For aead case when source and destination buffers are different,
there is an incorrect assumption that the source length includes the ICV
length. Fix this, since it leads to an oops when using sg_count() to
find the number of nents in the scatterlist:
Unable to handle kernel paging request for dat
For aead case when source and destination buffers are different,
there is an incorrect assumption that the source length includes the ICV
length. Fix this, since it leads to an oops when using sg_count() to
find the number of nents in the scatterlist:
Unable to handle kernel paging request for dat
20 matches
Mail list logo
