2016-02-04 12:28 GMT+09:00 Herbert Xu :
> On Thu, Feb 04, 2016 at 11:25:27AM +0800, Li, Weigang wrote:
>>
>> Please can you advise how to get the acomp patch accepted?
>
> Can you do a posting of these patches without scomp so we can
> evaluate the effects?
>
Do you think not to merge scomp? Pleas
On 2/4/2016 11:29 AM, Herbert Xu wrote:
On Thu, Feb 04, 2016 at 11:28:50AM +0800, Herbert Xu wrote:
On Thu, Feb 04, 2016 at 11:25:27AM +0800, Li, Weigang wrote:
Please can you advise how to get the acomp patch accepted?
Can you do a posting of these patches without scomp so we can
evaluate t
On Thu, Feb 04, 2016 at 11:28:50AM +0800, Herbert Xu wrote:
> On Thu, Feb 04, 2016 at 11:25:27AM +0800, Li, Weigang wrote:
> >
> > Please can you advise how to get the acomp patch accepted?
>
> Can you do a posting of these patches without scomp so we can
> evaluate the effects?
Of course you can
On Thu, Feb 04, 2016 at 11:25:27AM +0800, Li, Weigang wrote:
>
> Please can you advise how to get the acomp patch accepted?
Can you do a posting of these patches without scomp so we can
evaluate the effects?
Thanks!
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: h
On 2/1/2016 10:11 AM, Joonsoo Kim wrote:
On Fri, Jan 29, 2016 at 06:09:01PM +0800, Herbert Xu wrote:
On Thu, Jan 28, 2016 at 12:19:42PM +0900, Joonsoo Kim wrote:
I have tested asynchronous compression APIs in zram and I saw
regression. Atomic allocation and setting up SG lists are culprit
for
On Wed, Feb 03, 2016 at 02:48:57PM -0800, Greg KH wrote:
>
> This change breaks the build for me so I can't take this through my
> tree. I'm hoping you have a patch earlier in the series that adds these
> functions, if so, feel free to take this through your tree:
Sorry I should've CCed you on th
On Mon, Feb 01, 2016 at 09:36:53PM +0800, Herbert Xu wrote:
> This patch replaces uses of the long obsolete hash interface with
> ahash.
>
> Signed-off-by: Herbert Xu
> ---
>
> drivers/staging/lustre/lustre/libcfs/linux/linux-crypto.c | 92
> +++---
> 1 file changed, 52 insertions(+)
On 02/03/2016 05:39 AM, Herbert Xu wrote:
> The async path in algif_skcipher assumes that the crypto completion
> function will be called with the original request. This is not
> necessarily the case. In fact there is no need for this anyway
> since we already embed information into the request w
Any access to non-constant bits of the private context must be
done under the socket lock, in particular, this includes ctx->req.
This patch moves such accesses under the lock, and fetches the
tfm from the parent socket which is guaranteed to be constant,
rather than from ctx->req.
Signed-off-by:
The async path in algif_skcipher assumes that the crypto completion
function will be called with the original request. This is not
necessarily the case. In fact there is no need for this anyway
since we already embed information into the request with struct
skcipher_async_req.
This patch adds a
The async path cannot use MAY_BACKLOG because it is not meant to
block, which is what MAY_BACKLOG does. On the other hand, both
the sync and async paths can make use of MAY_SLEEP.
Signed-off-by: Herbert Xu
---
crypto/algif_skcipher.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-
On Mon, Feb 01, 2016 at 01:03:57PM -0800, Tadeusz Struk wrote:
>
> I think this should be:
> sreq = kzalloc(sizeof(*sreq) + reqsize + ivsize, GFP_KERNEL);
Good catch. Here is another spin.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apan
Currently the sahara driver fails to probe:
sahara: probe of 63ff8000.crypto failed with error -22
This happens since commit 8996eafdcbad ("crypto: ahash - ensure statesize
is non-zero"), which requires statesize to be filled.
Pass the statesize members for sha1 and sha256, so we can probe
the d
As pointed out by Herbert Xu we should not include the mutex in the
exported state, so let's just get rid of it.
Signed-off-by: Fabio Estevam
---
drivers/crypto/sahara.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 6c4f91c..7e814
Based on commit 434b421241f2d0 ("crypto: caam - avoid needlessly saving and
restoring caam_hash_ctx") from Russell King.
When exporting and importing the hash state, we will only export and
import into hashes which share the same struct crypto_ahash pointer.
(See hash_accept->af_alg_accept->hash_a
__test_aead() reads MAX_IVLEN bytes from template[i].iv, but the
actual length of the initialisation vector can be shorter.
The length of the IV is already calculated earlier in the
function. Let's just reuses that. Also the IV length is currently
calculated several time for no reason. Let's fix th
On Tue, Feb 02, 2016 at 03:18:47PM -0200, Fabio Estevam wrote:
> On Tue, Feb 2, 2016 at 12:43 PM, Herbert Xu
> wrote:
>
> > Preferably you shouldn't include the mutex in the exported state
> > at all.
>
> Ok, so would it be safe to completely remove the mutex like this?
Hmm, indeed the mutex s
On 01/02/16 22:41, Joshua Henderson wrote:
Add support for the hardware pseudo and true random number generator
peripheral found on PIC32.
Signed-off-by: Joshua Henderson
Signed-off-by: Purna Chandra Mandal
---
drivers/char/hw_random/Kconfig | 13 +++
drivers/char/hw_random/Makefile
Modify __test_hash() so that hash import/export can be tested
from within the kernel. The test is unconditionally done when
a struct hash_testvec has its .np > 1.
v3: make the test unconditional
v2: Leverage template[i].np as suggested by Tim Chen
Signed-off-by: Rui Wang
---
crypto/testmgr.c |
19 matches
Mail list logo
