Re: [PATCH 2/5] jffs2: Add LZO compression support to jffs2

On Wed, 2007-02-28 at 19:13 +, Richard Purdie wrote: Add LZO1X compression/decompression support to jffs2. LZO's interface doesn't entirely match that required by jffs2 so a buffer and memcpy is unavoidable. Signed-off-by: Richard Purdie [EMAIL PROTECTED] Index:

Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.

On Mon, 2008-08-04 at 12:25 +0200, Sebastian Siewior wrote: * David Woodhouse | 2008-08-04 11:12:05 [+0100]: And it would be nice if we could make libcrc32c use this too, rather than just the 'crypto' users. I'm not sure if I remeber correctly but I thing Herbert was planning to convert all

Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.

+ u32 *ptmp = (u32 *)p; +#endif You could perhaps just use 'unsigned long' here, to avoid the ifdef. And it would be nice if we could make libcrc32c use this too, rather than just the 'crypto' users. -- David WoodhouseOpen Source Technology Centre [EMAIL

Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.

On Mon, 2008-08-04 at 06:35 -0400, Austin Zhang wrote: On Mon, 2008-08-04 at 11:12 +0100, David Woodhouse wrote: You could perhaps just use 'unsigned long' here, to avoid the ifdef. Thanks. And it would be nice if we could make libcrc32c use this too, rather than just the 'crypto' users

Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.

. + Module will be crc32c-intel. + config CRYPTO_MD4 tristate MD4 digest algorithm select CRYPTO_ALGAPI I think that should depend on CONFIG_X86? -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED

Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.

per cpu and disable preempt while we use it, can we? The routines are allowed to sleep? (Although I have to admit I do like the fact that it'd only be available through EXPORT_SYMBOL_GPL if we do force people to use the crypto API...) -- David WoodhouseOpen Source

Re: [patch 1/3] crypto: Add a zlib crypto module

compression interface sucks for what you're trying to achieve :) The main thing that's missing for JFFS2 is Compress as much of this as you can into X bytes -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED] Intel Corporation

Re: [BUG] SLOB breaks Crypto

gets this right, and Dave has already said he's going to fix sparc. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- To unsubscribe from this list: send the line unsubscribe linux-crypto

Re: [BUG] SLOB breaks Crypto

git://git.infradead.org/users/dwmw2/minalign-2.6.git Should I include the SPARC patch in that too? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- To unsubscribe from this list: send the line

[PATCH 1/4] mm: Move ARCH_SLAB_MINALIGN and ARCH_KMALLOC_MINALIGN to linux/slab_def.h

Signed-off-by: David Woodhouse david.woodho...@intel.com --- include/linux/slab_def.h | 24 mm/slab.c| 24 2 files changed, 24 insertions(+), 24 deletions(-) diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h

[PATCH 2/4] mm: Move ARCH_SLAB_MINALIGN and ARCH_KMALLOC_MINALIGN to linux/slob_def.h

Signed-off-by: David Woodhouse david.woodho...@intel.com --- include/linux/slob_def.h |8 mm/slob.c|8 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/include/linux/slob_def.h b/include/linux/slob_def.h index 0ec00b3..62667f7 100644

[PATCH 4/4] crypto: Use ARCH_KMALLOC_MINALIGN for CRYPTO_MINALIGN now that it's exposed

Signed-off-by: David Woodhouse david.woodho...@intel.com --- include/linux/crypto.h |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/include/linux/crypto.h b/include/linux/crypto.h index 24d2e30..a6a7a1c 100644 --- a/include/linux/crypto.h +++ b/include/linux/crypto.h

[PATCH 3/4] mm: Move ARCH_SLAB_MINALIGN and ARCH_KMALLOC_MINALIGN to linux/slub_def.h

Signed-off-by: David Woodhouse david.woodho...@intel.com --- include/linux/slub_def.h |8 mm/slub.c|8 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h index 0249d41..55695c8 100644

Re: [BUG] SLOB breaks Crypto

sparc32 ARCH_SLAB_MINALIGN before the crypto one is applied. Although arguably SLOB was broken on sparc32 even before the crypto patch -- so perhaps that fix shouldn't _have_ to go in first? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com

Re: [BUG] SLOB breaks Crypto

On Wed, 2010-05-19 at 13:32 +0200, Geert Uytterhoeven wrote: Instead of having (different) defaults in sl[aou]b, perhaps we should just remove the defaults completely, to ensure all architectures set ARCH_SLAB_MINALIGN to the correct value? What is 'correct'? The architecture sets it to the

Re: [BUG] SLOB breaks Crypto

On Wed, 2010-05-19 at 21:26 +0900, FUJITA Tomonori wrote: Surely those architectures that have alignment constraints for DMA but which don't set ARCH_KMALLOC_MINALIGN are just buggy -- it _does_ mean that. Well, I thought so but seems that there isn't such agreement:

[PATCH 5/4] Provide __dma_aligned macro

to the cache line size isn't necessary on cache-coherent architectures. To avoid wasting space, the correct value to use for the alignment is ARCH_KMALLOC_MINALIGN. This patch provides a __dma_aligned macro which does the right thing. Signed-off-by: David Woodhouse david.woodho...@intel.com diff --git

Re: [PATCH 1/4] mm: Move ARCH_SLAB_MINALIGN and ARCH_KMALLOC_MINALIGN to linux/slab_def.h

On Wed, 2010-05-19 at 14:19 -0500, Christoph Lameter wrote: Maybe we can consolidate that into slab.h so that the alignment is the same for all allocators? Doing so at least for slub and slab would make sense. I wanted to move them first though, as a separate step. -- David Woodhouse

[PATCH] Fix x509_key_preparse() not to reject keys outside their validity time range

boot sequence, things *should* have started working. But they didn't... Signed-off-by: David Woodhouse david.woodho...@intel.com --- Arguably, for the specific case of module signing we shouldn't bother checking for a current time before the ValidFrom date *at all*. It's *always* going

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

On Tue, 2015-10-27 at 11:50 +0100, Stephan Mueller wrote: > > >expose that critically limited API to userspace. We need to expose an > >API which supports hardware keys, and basically that means using the > >kernel's key subsystem. > > Agreed. But at the same time, that interface should be able

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

On Wed, 2015-10-28 at 00:35 +0100, Stephan Mueller wrote: > Am Mittwoch, 28. Oktober 2015, 08:15:16 schrieb David Woodhouse: > > Hi David, > > > > Absolutely. The interface needs to support *both*. > > > > I've spent a lot of time chasing through userspace stac

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

On Wed, 2015-10-28 at 00:47 +0100, Stephan Mueller wrote: > > Ohh, I see. So, you are saying that there should not be a setpub/privkey for > the akcipher AF_ALG interface?! > > If somebody wants to use akcipher, he shall set the key via the keyring and > akcipher shall obtain it from the

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

On Wed, 2015-10-28 at 02:18 +0100, Stephan Mueller wrote: > > But having a tie between both, the kernel crypto API and the key system, that > cannot be cut any more is something I am not sure about. Both should and > would > work in isolation of each other as both serve different needs. Sure,

Re: [PATCH v3 7/7] crypto: AF_ALG - add support for key_id

> Tadeusz Struk wrote: > >> +keyring = request_key(_type_asymmetric, key_name, NULL); >> + >> +err = -ENOKEY; >> +if (IS_ERR(keyring)) >> +goto out; >> + >> +pkey = keyring->payload.data[asym_crypto]; > > NAK. This is liable to crash in

Re: [PATCH v3 7/7] crypto: AF_ALG - add support for key_id

> Tadeusz Struk wrote: > >> +keyring = request_key(_type_asymmetric, key_name, NULL); >> + >> +err = -ENOKEY; >> +if (IS_ERR(keyring)) >> +goto out; >> + >> +pkey = keyring->payload.data[asym_crypto]; > > NAK. This is liable to crash in

Re: [RFC PATCH 2/8] KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver 3]

*device*. So I'm not quite sure this 'password_id' makes much sense at all... unless the idea is that you load the (encrypted) key in advance and then request the password *later* on demand, in order to use it? Is that something we really need to support? -- David Woodhouse

Re: [RFC PATCH 8/8] KEYS: Implement PKCS#8 RSA Private Key parser [ver 3]

ed binary PKCS#8 (or PKCS#1). -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature

Re: [PATCH] iommu/vt-d: Fix scatterlist offset handling

On Tue, 2017-10-03 at 19:05 +0100, Robin Murphy wrote: > > Now, there are indeed plenty of drivers and subsystems which do work on > lists of explicitly single pages - anything doing some variant of > "addr = kmap_atomic(sg_page(sg)) + sg->offset;" is easy to spot - but I > don't think DMA API

Re: [PATCH] iommu/vt-d: Fix scatterlist offset handling

On Thu, 2017-09-28 at 15:14 +0100, Robin Murphy wrote: > The intel-iommu DMA ops fail to correctly handle scatterlists where > sg->offset is greater than PAGE_SIZE - the IOVA allocation is computed > appropriately based on the page-aligned portion of the offset, but the > mapping is set up

Re: DMA error when sg->offset value is greater than PAGE_SIZE in Intel IOMMU

On Wed, 2017-09-20 at 16:01 +0800, Herbert Xu wrote: > Harsh Jain wrote: > >  > > While debugging DMA mapping error in chelsio crypto driver we > observed that when scatter/gather list received by driver has some > entry with page->offset > 4096 (PAGE_SIZE). It starts giving