From: Herbert Xu
Date: Wed, 27 Jun 2012 14:51:44 +0800
> While using the NAPI concept definitely makes sense, I'm still
> unsure about using napi_struct directly in crypto code. Dave,
> did you have a chance to look at their patch to use NAPI in their
> crypto driver?
So I think using the exist
From: Herbert Xu
Date: Wed, 27 Jun 2012 14:51:44 +0800
> While using the NAPI concept definitely makes sense, I'm still
> unsure about using napi_struct directly in crypto code. Dave,
> did you have a chance to look at their patch to use NAPI in their
> crypto driver?
I'll take a look at it tom
From: Kent Yoder
Date: Tue, 10 Apr 2012 10:10:57 -0500
> These routines add the base device driver code supporting the Power7+
> in-Nest encryption accelerator (nx) device.
>
> Signed-off-by: Kent Yoder
This patch should be earlier in the series, so it can
appear before the drivers which use t
From: Alexey Dobriyan
Date: Wed, 15 Feb 2012 22:27:52 +0300
> On Wed, Feb 15, 2012 at 12:23:52AM -0500, David Miller wrote:
>> From: Herbert Xu
>> Date: Wed, 15 Feb 2012 16:16:08 +1100
>>
>> > OK, so we grew by 1136 - 888 = 248. Keep in mind that 128 of
>>
From: Herbert Xu
Date: Wed, 15 Feb 2012 16:16:08 +1100
> OK, so we grew by 1136 - 888 = 248. Keep in mind that 128 of
> that is expected since we moved W onto the stack.
Right.
> I guess we could go back to the percpu solution, what do you
> think?
I'm not entirely sure, we might have to.
sh
From: Herbert Xu
Date: Wed, 15 Feb 2012 15:01:28 +1100
> On Tue, Feb 14, 2012 at 10:58:33PM -0500, David Miller wrote:
>>
>> FYI, I just started seeing this on sparc32 after all those
>> sha512 "optimizations":
>>
>> crypto/sha512_generic.c
FYI, I just started seeing this on sparc32 after all those
sha512 "optimizations":
crypto/sha512_generic.c: In function 'sha512_transform':
crypto/sha512_generic.c:135:1: warning: the frame size of 1136 bytes is larger
than 1024 bytes [-Wframe-larger-than=]
--
To unsubscribe from this list: send
From: Daniil Stolnikov
Date: Wed, 9 Nov 2011 09:36:07 +0800
> I never imagined that it will cause some difficulties.
Ever feature has side effects and costs associated with it. Some of
which can be non-trivial.
Like I said, if you want address ranges, ask the userland IPSEC daemon
authors to s
From: Alexey Dobriyan
Date: Tue, 8 Nov 2011 14:08:24 +0200
> changing addr_match() is trivial for ipv4 and easy for ipv6. :-)
No, this is not happening. This added complexity screws up all the hash table
and lookup optimizations we have in the XFRM layer.
--
To unsubscribe from this list: send
From: Daniil Stolnikov
Date: Tue, 08 Nov 2011 12:40:13 +0400
> I turned to you, the developers, but rather to urge you to implement
> this feature using IP range.
This won't be implemented, the keys used for IPSEC rule lookups supported by
the kernel are already way too complex.
Ranges can be s
From: Steve Grubb
Date: Thu, 8 Sep 2011 07:48:27 -0400
> On Thursday, September 08, 2011 04:44:20 AM Christoph Hellwig wrote:
>> On Wed, Sep 07, 2011 at 11:27:12PM +0200, Stephan Mueller wrote:
>> > And exactly that is the concern from organizations like BSI. Their
>> > cryptographer's concern is
From: "Ted Ts'o"
Date: Wed, 7 Sep 2011 15:27:37 -0400
> On Wed, Sep 07, 2011 at 02:26:35PM -0400, Jarod Wilson wrote:
>> We're looking for a generic solution here that doesn't require
>> re-educating every single piece of userspace. And anything done in
>> userspace is going to be full of possibl
From: Nikos Mavrogiannopoulos
Date: Thu, 1 Sep 2011 17:06:06 +0200
> It would be interesting to have a partial kernel-space TLS
> implementation but I don't know whether such a thing could ever make
> it to kernel.
Herbert and I have discussed this several times and we plan on
implementing this
From: Nikos Mavrogiannopoulos
Date: Mon, 29 Aug 2011 09:32:19 +0200
> On 08/28/2011 10:35 PM, David Miller wrote:
>
>>> The benchmark idea was to test the speed of initialization, encryption
>>> and deinitiation, as well as the encryption speed alone. These are the
>
From: Nikos Mavrogiannopoulos
Date: Sun, 28 Aug 2011 15:17:00 +0200
> The benchmark idea was to test the speed of initialization, encryption
> and deinitiation, as well as the encryption speed alone. These are the
> most common use cases of the frameworks (i.e. how they would be used
> by a crypt
From: Thomas Meyer
Date: Sat, 06 Aug 2011 10:26:25 +0200
> From: Thomas Meyer
>
> Fix a get/put_cpu() imbalance in the error case when qp == NULL
>
> Signed-off-by: Thomas Meyer
Acked-by: David S. Miller
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body
From: Mathias Krause
Date: Thu, 7 Jul 2011 10:33:50 +0200
> In gf128mul_lle() and gf128mul_bbe() r isn't completely initialized with
> zero because the size argument passed to memset() is the size of the
> pointer, not the structure it points to.
>
> Luckily there are no in-kernel users of thos
From: Jesper Juhl
Date: Sun, 26 Jun 2011 23:23:06 +0200 (CEST)
> If af_alg_make_sg() returns <0 in hash_sendmsg() we'll jump to the
> 'unlock' label without having set 'err' to anything. At the 'unlock'
> label the value of 'err' is tested to determine return value of the
> function - not good to
From: Mandeep Singh Baines
Date: Wed, 25 May 2011 20:11:17 -0700
> Plus some other minor cleanup.
>
> Signed-off-by: Mandeep Singh Baines
The temp[] buffer is explicitly places inside the inner most
basic block so that the compiler doesn't allocate the stack
space unless that code path is take
From: Aditya Shevade
Date: Fri, 8 Apr 2011 10:46:57 -0700
> Oh, I see the problem. I forgot a semicolon in the commit file. Making
> the change.
I think it's even more important that you are submitting patches
you aren't even build testing.
--
To unsubscribe from this list: send the line "unsubs
From: Herbert Xu
Date: Sun, 13 Mar 2011 14:44:57 +0800
> On Tue, Mar 08, 2011 at 11:05:43AM +0100, Steffen Klassert wrote:
>> This patch adds the struct xfrm_replay_state_esn which will be
>> used to support IPsec extended sequence numbers and anti replay windows
>> bigger than 32 packets. Also w
From: Davidlohr Bueso
Date: Tue, 25 Jan 2011 13:27:45 -0300
> From: Davidlohr Bueso
>
> Signed-off-by: Davidlohr Bueso
Acked-by: David S. Miller
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
From: Herbert Xu
Date: Fri, 7 Jan 2011 11:14:59 +1100
> Anyway, here is a test program that does a set number (1024 * 1024)
> of 4096-byte (total 4GB) encryptions with libssl and kernel crypto.
> The result on my Core 2 (in a KVM VM FWIW) is:
>
> lenny0:~# time ./test_crypto > /dev/null
>
> re
From: Herbert Xu
Date: Fri, 7 Jan 2011 09:30:42 +1100
> On Thu, Jan 06, 2011 at 02:13:17PM -0800, Linus Torvalds wrote:
>>
>> But I'm still missing the part where you show that there is any actual
>> use case that makes sense, and that actually improves performance.
>> Maybe it's been posted som
From: Dennis Gilmore
Date: Wed, 5 Jan 2011 15:36:27 -0600
> From: dennis
>
> fixes fedora sparc build failure, thanks to kylem for helping with debugging
>
> Signed-off-by: Dennis Gilmore
Acked-by: David S. Miller
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" i
From: Herbert Xu
Date: Thu, 9 Dec 2010 20:47:32 +0800
> On Wed, Dec 08, 2010 at 03:37:48PM +0100, Martin Willi wrote:
>> The following patchset adds Traffic Flow Confidentiality padding. The
>> first patch introduces a new Netlink XFRM attribute to configure TFC via
>> userspace. Patch two and th
From: Herbert Xu
Date: Thu, 04 Nov 2010 12:36:20 -0500
> crypto: algif_skcipher - User-space interface for skcipher operations
>
> This patch adds the af_alg plugin for symmetric key ciphers,
> corresponding to the ablkcipher kernel operation type.
>
> Keys can optionally be set through the set
From: Herbert Xu
Date: Thu, 04 Nov 2010 12:36:19 -0500
> crypto: algif_hash - User-space interface for hash operations
>
> This patch adds the af_alg plugin for hash, corresponding to
> the ahash kernel operation type.
>
> Keys can optionally be set through the setsockopt interface.
>
> Each s
From: Herbert Xu
Date: Thu, 04 Nov 2010 12:36:19 -0500
> crypto: af_alg - User-space interface for Crypto API
>
> This patch creates the backbone of the user-space interface for
> the Crypto API, through a new socket family AF_ALG.
>
> Each session corresponds to one or more connections obtaine
From: Herbert Xu
Date: Thu, 04 Nov 2010 12:36:19 -0500
> net - Add AF_ALG macros
>
> This patch adds the socket family/level macros for the yet-to-be-born
> AF_ALG family. The AF_ALG family provides the user-space interface
> for the kernel crypto API.
>
> Signed-off-by: Herbert Xu
Acked-by:
From: Nicolas Kaiser
Date: Sun, 24 Oct 2010 15:05:56 +0200
> Looks like a copy-and-paste problem to me.
>
> Signed-off-by: Nicolas Kaiser
Acked-by: David S. Miller
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
From: Herbert Xu
Date: Tue, 19 Oct 2010 21:46:01 +0800
> net - Add AF_ALG macros
>
> This patch adds the socket family/level macros for the yet-to-be-born
> AF_ALG family. The AF_ALG family provides the user-space interface
> for the kernel crypto API.
>
> Signed-off-by: Herbert Xu
Acked-by:
Reported-by: Dennis Gilmore
Signed-off-by: David S. Miller
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index ea0b386..ad1cd59 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -172,6 +172,7 @@ config CRYPTO_DEV_MV_CESA
config CRYPTO_DEV_NIAGARA2
tri
From: Maurus Cuelenaere
Date: Fri, 13 Aug 2010 13:17:53 +0200
> Op 13-08-10 00:32, David Miller schreef:
>> From: Maurus Cuelenaere
>> Date: Thu, 12 Aug 2010 13:47:24 +0200
>>
>> tcrypt can validate async crypto algorithms, but cannot performance
>> test them
From: Maurus Cuelenaere
Date: Thu, 12 Aug 2010 13:47:24 +0200
> The main issues still remain (DMA not working at all and FIFO not
> working for some (T)DES transfers). Additionally, I couldn't get
> tcrypt to test the s3c-sss driver for some reason, it always picked
> the standard AES/TDES/DES dr
Kulikov, can you at least build test your patches? Casts are not
always incorrect, particularly when private cookies are "unsigned
long" as is the case here:
drivers/char/hw_random/n2-drv.c: In function ‘n2rng_data_read’:
drivers/char/hw_random/n2-drv.c:390: warning: initialization makes pointer
From: Herbert Xu
Date: Wed, 4 Aug 2010 21:48:51 +0800
> On Mon, Aug 02, 2010 at 02:45:37PM +0200, Szilveszter Ördög wrote:
>> If a scatterwalk chain contains an entry with an unaligned offset then
>> hash_walk_next() will cut off the next step at the next alignment point.
>>
>> However, if the e
From: Dan Carpenter
Date: Thu, 15 Jul 2010 09:57:36 +0200
> The intent was to return here. In the original an allocation failure
> would lead to a NULL dereference.
>
> Signed-off-by: Dan Carpenter
Acked-by: David S. Miller
--
To unsubscribe from this list: send the line "unsubscribe linux-c
From: Maurus Cuelenaere
Date: Sun, 27 Jun 2010 13:06:03 +0200
> I'd go with a threaded interrupt handler in that case then, or do
> you also consider this as too much overhead?
>
> I'll do some performance comparisons of threaded interrupt handler
> vs normal and go with the fastest.
Yes, best
From: Maurus Cuelenaere
Date: Fri, 11 Jun 2010 21:49:21 +0200
> This patch adds support for the Samsung crypto engine driver available in the
> S3C64XX and S5PC100 SoCs. Currently this supports AES and (T)DES with ECB and
> CBC block ciphers (also CTR for AES). Support for (HMAC)-SHA1 acceleratio
From: Wolfram Sang
Date: Thu, 3 Jun 2010 06:03:47 +0200
> Signed-off-by: Wolfram Sang
> Cc: Grant Likely
Herbert you really need to push your pending crypto tree stuff to
Linus, this is the second time this build fix has been posted just
today alone and it's in your tree since last week :-)
-
From: ag...@denx.de
Date: Thu, 3 Jun 2010 01:35:41 +0200
> From: Anatolij Gustschin
>
> Fixes build errors caused by the:
> - OF device_node pointer being moved into struct device
> - removal of the match_table and name fields from
> struct of_platform_driver
>
> Signed-off-by: Anatolij Gust
One note is that, unlike with non-HMAC hashes, we can't support
hmac(sha224) using the HMAC_SHA256 opcode.
Signed-off-by: David S. Miller
---
drivers/crypto/n2_core.c | 210 +-
1 files changed, 206 insertions(+), 4 deletions(-)
diff --git a/drivers/
All of the ahash ->digest() ops do essentially the same thing, just
using different parameters.
So instead, have a single n2_hash_async_digest() and use an
n2_ahash_alg container that provides the parameters.
Signed-off-by: David S. Miller
---
drivers/crypto/n2_core.c | 216 ++
Signed-off-by: David S. Miller
---
drivers/crypto/n2_core.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c
index 3a4eed4..77939e4 100644
--- a/drivers/crypto/n2_core.c
+++ b/drivers/crypto/n2_core.c
@@ -1277,8 +12
Unused, and we'll do this via the request context.
Signed-off-by: David S. Miller
---
drivers/crypto/n2_core.c | 15 +--
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c
index 23163fd..3a4eed4 100644
--- a/drivers/
Do this by putting the async fallback request at the end of an n2
specific ahash request context, then properly adjusting the request
private size in our ahash ->cra_init().
We also need to put the writable state bits into the n2 request
private instead of the n2 cra_ctx.
With help from Herbert
Both the CWQ and MAU caches unintentionally had that same name.
Signed-off-by: David S. Miller
---
drivers/crypto/n2_core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c
index 1a5b1e7..5613b8a 100644
--- a/drivers/c
Signed-off-by: David S. Miller
---
drivers/crypto/n2_core.c | 26 --
1 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c
index 8566be8..1a5b1e7 100644
--- a/drivers/crypto/n2_core.c
+++ b/drivers/crypto/n2
As we discussed side-band the n2crypto driver plumbed async hash
requests to fallbacks incorrectly. And along the way I found
several other bugs as well.
The recent of_device/of_platform_driver infrastructure changes
criss-crossed the n2_crypto driver addition, so some fixups
were needed to rest
From: FUJITA Tomonori
Date: Thu, 20 May 2010 12:38:01 +0900
> On Wed, 19 May 2010 12:33:25 -0700 (PDT)
> David Miller wrote:
>
>> From: Matt Mackall
>> Date: Wed, 19 May 2010 09:11:47 -0500
>>
>> > I still think we should add it to all of them as positiv
From: Christoph Lameter
Date: Wed, 19 May 2010 10:19:33 -0500 (CDT)
> The assumptions are not arbitrary. It is reasonable to assume that
> structures managed by the slab allocators may contain long long variables
> and that therefore a unsigned long long alignment is required by the
> allocator.
From: Herbert Xu
Date: Wed, 19 May 2010 22:59:03 +1000
> On Wed, May 19, 2010 at 03:54:43PM +0300, Pekka Enberg wrote:
>>
>> OK, I'll pick up David's patches and just wait for sparc changes to
>> hit Linus' tree first. Herbert, do I have your ACK for the crypto
>> patches?
>
> Of course:
>
> Ac
From: David Woodhouse
Date: Wed, 19 May 2010 12:16:45 +0100
> On Wed, 2010-05-19 at 14:08 +0300, Pekka Enberg wrote:
>>
>> Acked-by: Pekka Enberg
>>
>> Are you sending the patches to Linus or do you want me to pull them in
>> slab.git?
>
> I don't mind. Feel free to apply them to slab.git, b
From: Matt Mackall
Date: Wed, 19 May 2010 09:11:47 -0500
> I still think we should add it to all of them as positive documentation
> that this issue has been considered. And then make the kernel not
> compile without it so new arch implementors can't miss it.
I agree and would even go so far as
From: Herbert Xu
Date: Wed, 19 May 2010 14:05:13 +1000
> So I'm going to commit this patch instead. Let me know if you
> see any other issues with it.
Looks good:
Acked-by: David S. Miller
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to m
From: Paul Mundt
Date: Wed, 19 May 2010 07:35:10 +0900
> On Tue, May 18, 2010 at 02:20:21PM -0700, David Miller wrote:
>> So one of two things should happen:
>>
>> 1) SLOB conforms to SLAB/SLUB in it's test
>>
>> 2) SLAB/SLUB conforms to SLOB in it'
From: Pekka Enberg
Date: Wed, 19 May 2010 00:15:46 +0300
> On Tue, May 18, 2010 at 11:59 PM, David Miller wrote:
>> From: Matt Mackall
>> Date: Tue, 18 May 2010 14:33:55 -0500
>>
>>> SLOB honors ARCH_KMALLOC_MINALIGN. If your arch has alignment
>>> requir
From: Matt Mackall
Date: Tue, 18 May 2010 14:33:55 -0500
> SLOB honors ARCH_KMALLOC_MINALIGN. If your arch has alignment
> requirements, I recommend you set it.
I recommend that the alignment provided by the allocator is not
determined by which allocator I happen to have enabled.
The values and
From: Herbert Xu
Date: Tue, 18 May 2010 20:27:01 +1000
> I think the simplest fix is to revert this changeset.
If you revert then you'll break sparc.
Sparc needs long long alignment, so it's SLOB that needs to
change if it isn't providing at least that much alignment
by default.
--
To unsubscri
These are akin to the blkcipher_walk helpers.
The main differences in the async variant are:
1) Only physical walking is supported. We can't hold on to
kmap mappings across the async operation to support virtual
ablkcipher_walk operations anyways.
2) Bounce buffers used for async more ne
Extend testmgr such that it tests async hash algorithms,
and that for both sync and async hashes it tests both
->digest() and ->update()/->final() sequences.
Signed-off-by: David S. Miller
---
crypto/testmgr.c | 66 +++--
1 files changed, 48 ins
These are invoked in the 'mode' range of 400 to 499.
The cost of async vs. sync for the software algorithm implementations
varies. It can be as low as 16 cycles but as much as a couple hundred.
Here two runs of md5 testing, async then sync:
testing speed of async md5
test 0 ( 16 byte blocks
We are done with the scattergather entry when the walk offset goes
past sg->offset + sg->length, not when it crosses a page boundary.
There is a similarly queer test in the second half of
scatterwalk_pagedone() that probably needs some scrutiny.
Signed-off-by: David S. Miller
---
crypto/scatte
This is in preparation for the generic ablkcipher_walk helpers that
will be added to the crypto layer.
Signed-off-by: David S. Miller
---
drivers/crypto/hifn_795x.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/crypto/hifn_795x.c b/drivers/cry
These patches do the work necessary to add the Niagara2 crypto
driver.
The main enablers are a set of generic ablkcipher_walk helpers, and
testing support for async hash algorithms.
Some work still remains, in particular tcrypt still can't perf test
async ciphers :-/
These changes are also avai
From: Herbert Xu
Date: Sat, 20 Mar 2010 12:24:34 +0800
> On Fri, Mar 19, 2010 at 09:21:03PM -0700, Brandon Philips wrote:
>>
>> Do you see how it is getting stuck though with modprobe bnx2 and
>> modprobe libcrc32c going at the same time though?
>
> Yes I agree that's a bug. Something in those
From: Herbert Xu
Date: Sat, 20 Mar 2010 09:08:49 +0800
> On Sat, Mar 20, 2010 at 09:01:15AM +0800, Herbert Xu wrote:
>>
>> IIRC modprobe(8) in user-space is supposed to load all dependencies
>> prior to loading the main module. So something must've gone wrong
>> before bnx2/bnx2x was loaded. Pl
From: Avi Kivity
Date: Fri, 12 Mar 2010 10:44:58 +0200
> Strange, that people can install a new kernel, but not a new
> assembler.
Someone shouldn't have to upgrade their tools to build the
kernel.
And we work very hard to make sure this is the case except
in the most unavoidable situations.
--
From: Avi Kivity
Date: Fri, 12 Mar 2010 10:37:33 +0200
> Eventually you'll port the entire assembler into macros, as
> instructions are introduced more frequently that people upgrade their
> assemblers. Maybe we should disable the new features and warn people
> (and distros) to upgrade their too
From: roel kluin
Date: Thu, 25 Feb 2010 16:31:36 +0100
> On Thu, Feb 25, 2010 at 4:17 PM, David Miller wrote:
>> From: Roel Kluin
>> Date: Thu, 25 Feb 2010 16:10:27 +0100
>>
>>> Due to optimization A call to memset() may be removed as a dead store when
>&g
From: Roel Kluin
Date: Thu, 25 Feb 2010 16:10:27 +0100
> Due to optimization A call to memset() may be removed as a dead store when
> the buffer is not used after its value is overwritten.
>
> Signed-off-by: Roel Kluin
Solution is wrong and overkill in my mind.
It's overkill because the whole
From: Martin Willi
Date: Wed, 9 Dec 2009 17:11:15 +0100
> Commit 4447bb33f09444920a8f1d89e1540137429351b6 breaks installation of
> authentication algorithms via PF_KEY, as the state specific truncation
> length is not installed with the algorithms default truncation length.
> This patch initiali
From: Tobias Brunner
Date: Tue, 01 Dec 2009 17:49:28 +0100
> This patch adds the RFC4543 (GMAC) wrapper for GCM similar to the
> existing RFC4106 wrapper. The main differences between GCM and GMAC are
> the contents of the AAD and that the plaintext is empty for the latter.
>
> Signed-off-by: To
From: Herbert Xu
Date: Wed, 25 Nov 2009 20:11:40 +0800
> On Wed, Nov 25, 2009 at 11:58:39AM +0100, Martin Willi wrote:
>> These algorithms use a truncation of 192/256 bits, as specified
>> in RFC4868.
>>
>> Signed-off-by: Martin Willi
>
> Acked-by: Herbert Xu
Applied to net-next-2.6
--
To un
From: Martin Willi
Date: Wed, 25 Nov 2009 11:29:50 +0100
> The following patchset adds support for defining truncation lengths
> for authentication algorithms in userspace. The main purpose for this
> is to support SHA256 in IPsec using the standardized 128 bit
> instead of the currently used 96
From: Herbert Xu
Date: Fri, 30 Oct 2009 09:30:55 -0400
> On Fri, Oct 30, 2009 at 02:27:34PM +0100, Steffen Klassert wrote:
>> I'm going to send a workqueue based version of padata/pcrypt
>> within the next week.
>
> Awesome!
Thanks a lot for continuing this work Steffen.
--
To unsubscribe from
From: Steffen Klassert
Date: Thu, 8 Oct 2009 09:28:18 +0200
> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> index 1af1e4b..6bc5dde 100644
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -350,6 +350,8 @@ enum
> TASKLET_SOFTIRQ,
> SCHED_SO
From: Steffen Klassert
Date: Wed, 7 Oct 2009 16:22:41 +0200
> On Sat, Sep 19, 2009 at 04:19:59PM -0700, Herbert Xu wrote:
>> On Mon, Aug 31, 2009 at 11:12:49AM +0200, Steffen Klassert wrote:
>> > This patch introduces an interface to process data objects
>> > in parallel. On request it is possibl
From: Steffen Klassert
Date: Thu, 16 Jul 2009 13:17:47 +0200
> + /*
> + * head must be a scatterlist with two entries.
> + * We remove a potentially set termination bit
> + * on the first enty.
> + */
> + head->page_link &= ~0x02;
> +
> if (chain) {
>
From: Rik van Riel
Date: Sun, 31 May 2009 10:38:52 -0400
> David Miller wrote:
>> From: "Larry H."
>> Date: Sat, 30 May 2009 19:57:20 -0700
>>
>>> [PATCH] Use kzfree in crypto API context initialization and key/iv
>>> handling
>> Thanks f
From: "Larry H."
Date: Sat, 30 May 2009 19:57:20 -0700
> [PATCH] Use kzfree in crypto API context initialization and key/iv handling
Thanks for not CC:ing the crypto list, and also not CC:'ing the
crypto maintainer.
Your submissions leave a lot to be desired, on every level.
> This patch repla
From: Randy Dunlap
Date: Tue, 10 Mar 2009 13:08:31 -0700
> I'll have to let David or Herbert answer that. From my quick look
> at the code, I don't see much use for nlattr.c when CONFIG_NET
> is not enabled.
We want to use the netlink attribute parsers even in non-networking
code, that's what h
From: Geert Uytterhoeven
Date: Wed, 25 Feb 2009 14:43:09 +0100
> Netlink attribute parsing may be used even if CONFIG_NET is not set.
> Move it from net/netlink to lib and control its inclusion based on the new
> config symbol CONFIG_NLATTR, which is selected by CONFIG_NET.
>
> Signed-off-by: Ge
I already applied these patches, see my reply in that thread.
I was saying to submit these (individually, please!) next time
with netdev CC:'d.
Posting a ton all at once is pointless, they all get logged to
patchwork as one big blog and I cannot annotate them individually
and give you proper fee
From: Ingo Molnar <[EMAIL PROTECTED]>
Date: Tue, 25 Nov 2008 18:14:38 +0100
> fix warning in drivers/net/s2io.c
> fix warnings in drivers/net/niu.c
> fix warning in drivers/net/niu.c
> fix warning in drivers/net/qla3xxx.c
> fix warning in net/sunrpc/xprtrdma/svc_rdma_transport.
From: Ingo Molnar <[EMAIL PROTECTED]>
Date: Tue, 25 Nov 2008 18:14:38 +0100
> btw, on a related note, there's a couple of networking related warning
> fixes/annotations i've got queued up.
I see these now, but they would get properly logged and
tracked at:
http://patchwork.ozlabs.org/pr
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Wed, 24 Sep 2008 06:53:08 +0400
> Maybe, we need to check, since allocation of multiple smaller pages from
> 4 gb area, copy data between them, hardware crypto, backward copy and
> page freeing can be slower than software crypto. Although we can
> p
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Tue, 23 Sep 2008 22:18:42 +0400
> On Tue, Sep 23, 2008 at 08:06:32PM +0200, Dimitri Puzin ([EMAIL PROTECTED])
> wrote:
> > With this patch applied it still doesn't work as expected. The overflow
> > messages are gone however syslog shows
> > [ 120
From: Jean-Christophe Dubois <[EMAIL PROTECTED]>
Date: Tue, 12 Aug 2008 08:12:24 +0200
> Small fix removing an unnecessary intermediate variable.
>
> Signed-off-by: Jean-Christophe DUBOIS <[EMAIL PROTECTED]>
Your patch is whitespace mangled by your email client, the tab
characters have been cor
From: Jean-Christophe Dubois <[EMAIL PROTECTED]>
Date: Wed, 13 Aug 2008 07:50:16 +0200
> Le Wednesday 13 August 2008 03:16:04 Herbert Xu, vous avez écrit :
> > Jean-Christophe Dubois <[EMAIL PROTECTED]> wrote:
> > > Small fix removing an unnecessary intermediate variable.
> > >
> > > Signed-off-by
From: Sebastian Siewior <[EMAIL PROTECTED]>
Date: Wed, 25 Jun 2008 21:14:57 +0200
> http://www.mail-archive.com/linux-crypto@vger.kernel.org/
> or
> http://marc.info/?l=linux-crypto-vger&r=1&b=200806&w=2
I've added this to the vger list info for linux-crypto
as follows:
This
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Mon, 2 Jun 2008 20:41:07 +1000
> On Mon, Jun 02, 2008 at 11:33:09AM +0200, Adrian-Ken Rueegsegger wrote:
> > This patch fixes the usage of RIPEMD-160 in xfrm_algo which in turn
> > allows hmac(rmd160) to be used as authentication mechanism in IPsec
> > ES
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Mon, 26 May 2008 21:05:08 +1000
> On Tue, May 20, 2008 at 07:47:23PM -0700, David Miller wrote:
>
> > before patch
> >
> > [452862.338505] testing speed of rmd128
> > [45286
From: Sebastian Siewior <[EMAIL PROTECTED]>
Date: Wed, 21 May 2008 09:20:59 +0200
> Yes, that could be case. However a "manual" swap has three opcodes here,
> the le load has one. I should not end up with more code in the latter
> cases hould I?
You indeed can, because GCC has less information to
From: Sebastian Siewior <[EMAIL PROTECTED]>
Date: Wed, 21 May 2008 09:09:54 +0200
> That was, what I expected as well but the numbers were different. I
> checked the assembly code and I had the le loads but more code. I will
> check with different compiler maybe it will get better here as well.
Y
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 17 May 2008 17:56:25 +0800
> If you pull my cryptodev-2.6 tree then you'll be able to run
> the above test.
Performance is significantly increased on Niagara2 by using
the little-endian loads inside of the transformation loop, as
expected. The num
From: Sebastian Siewior <[EMAIL PROTECTED]>
Date: Sat, 17 May 2008 11:14:51 +0200
> * David Miller | 2008-05-17 02:01:22 [-0700]:
>
> >From: Sebastian Siewior <[EMAIL PROTECTED]>
> >Date: Sat, 17 May 2008 10:47:35 +0200
> >
> >> David: would you ple
From: Sebastian Siewior <[EMAIL PROTECTED]>
Date: Sat, 17 May 2008 10:47:35 +0200
> David: would you please be so kind to run a test on sparc machine?
How do I run the test?
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
Mo
From: Sebastian Siewior <[EMAIL PROTECTED]>
Date: Sat, 17 May 2008 10:10:03 +0200
> + ROUND(aa, bb, cc, dd, F1, K1, le32_to_cpu(in[ 0]), 11);
Not to nitpick, but if you use le32_to_cpup() this will allow the
use of little-endian load instructions on powerpc and sparc.
--
To unsubscribe from
201 - 300 of 331 matches
Mail list logo
