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 imp
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 relative
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 DMA
> error. Without
to unlock the *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
ndate unencrypted binary PKCS#8 (or PKCS#1).
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
> Tadeusz Struk wrote:
>
>> +keyring = request_key(&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 future. You may not assume
> Tadeusz Struk wrote:
>
>> +keyring = request_key(&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 future. You may not assume
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,
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 keyrin
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
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 t
On Tue, 2015-10-27 at 10:12 +0100, Stephan Mueller wrote:
>
> >after having discussions with David Howells and David Woodhouse, I don't
> >think we should expose akcipher via AF_ALG at all. I think the akcipher
> >operations for sign/verify/encrypt/decrypt should operat
in he boot sequence, things *should* have started working. But
they didn't...
Signed-off-by: David Woodhouse
---
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 to be a scr
On Tue, 2012-09-25 at 16:30 +0100, Alan Cox wrote:
> On Tue, 25 Sep 2012 16:09:54 +0100
> David Howells wrote:
>
> >
> > The X.509 certificate has a pair of times in it that delineate the valid
> > period of the cert, and I'm checking that the system clock is within the
> > bounds they define be
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
On Wed, 2010-05-19 at 20:03 +0200, Manfred Spraul wrote:
> Is this text better?
Not really...
> * Unless debug options are enabled, the kernel uses cache_line_size()
> automatically.
... that's a lie.
--
David WoodhouseOpen Source Technology Centr
ligning 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
diff --git a/in
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:
>
> ht
On Wed, 2010-05-19 at 21:02 +0900, FUJITA Tomonori wrote:
> On Wed, 19 May 2010 12:40:36 +0100
> David Woodhouse wrote:
>
> > On Wed, 2010-05-19 at 13:32 +0200, Geert Uytterhoeven wrote:
> > > Instead of having (different) defaults in sl[aou]b, perhaps we should
> &
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
patch fixing 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
Signed-off-by: David Woodhouse
---
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
--- a/include/linux/slub_def.h
Signed-off-by: David Woodhouse
---
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
@@ -99,13 +99,7
Signed-off-by: David Woodhouse
---
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
--- a/include/linux/slob_def.h
Signed-off-by: David Woodhouse
---
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
index ca6b2b3..1812dac
2/minalign-2.6.git
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
LAB_MINALIGN is for.
ARM 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 &
appens to vary with the phase of the
moon, that's your problem.
It would be better if the minimum alignment was exposed to generic code
though -- you're right that the CPP tests in linux/crypto.h really
shouldn't have to exist. If it wasn't for that, then the crypto problem
gt; I think we can safely conclude that our current 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 Woodhouse
l compared with just calling into
libcrc32c.
We can't even set up one context 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
27;crc32c-intel' module,
> + which will enable any routine to use the CRC32 instruction to
> + gain performance compared with software implementation.
> + Module will be crc32c-intel.
> +
> config CRYPTO_MD4
> tristate "MD4 digest alg
On Mon, 2008-08-04 at 06:58 -0400, Austin Zhang wrote:
> BTW, why did I always got each email on this thread twice:(? (the same
> email twice)
You're probably subscribed to the linux-kernel list, and you're also
being Cc'd directly.
Normally, your filters should notice the copy which has a Retur
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, rath
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
u64 *ptmp = (u64 *)p;
> +#else
> + 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 Woodhouse
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: linux/fs/jff
On Wed, 2007-02-28 at 19:13 +, Richard Purdie wrote:
> Allow selection of the compression mode for jffs2 via a sysfs
> attribute. This establishes a sysfs presence for jffs2 through
> which other compression options could easily be exported too.
And other options like GC threshold and other
37 matches
Mail list logo
