On Mon, Sep 21, 2020 at 01:34:35PM +0200, Pavel Machek wrote:
> Fix resource leak in error handling.
>
> Signed-off-by: Pavel Machek (CIP)
Acked-by: John Allen
>
> diff --git a/drivers/crypto/ccp/ccp-ops.c b/drivers/crypto/ccp/ccp-ops.c
> index bd270e66185e..40869ea1ed20 100644
> --- a/driver
On Mon, Sep 21, 2020 at 10:40:37AM +0200, Stephan Mueller wrote:
> Am Montag, 21. September 2020, 09:58:16 CEST schrieb Nicolai Stange:
>
> > - people dislike the approach of having two competing implementations for
> > what is basically the same functionality in the kernel.
>
> Is this really
On 9/21/20 6:34 AM, Pavel Machek wrote:
> Fix resource leak in error handling.
Does it need a Fixes: tag?
Thanks,
Tom
>
> Signed-off-by: Pavel Machek (CIP)
>
> diff --git a/drivers/crypto/ccp/ccp-ops.c b/drivers/crypto/ccp/ccp-ops.c
> index bd270e66185e..40869ea1ed20 100644
> --- a/drivers/cr
From: Andrei Botila
A hardware limitation exists for CAAM until Era 9 which restricts
the accelerator to IVs with only 8 bytes. When CAAM has a lower era
a fallback is necessary to process 16 bytes IV.
Fixes: c6415a6016bf ("crypto: caam - add support for acipher xts(aes)")
Cc: # v4.4+
Signed-of
From: Andrei Botila
This patch series fixes some problems in CAAM's implementation of xts(aes):
- CAAM until Era 9 can't process XTS with 16B IV
- CAAM can only process in hardware XTS key lengths of 16B and 32B
- These hardware limitations are resolved through a fallback
- CAAM used to retur
From: Andrei Botila
A hardware limitation exists for CAAM until Era 9 which restricts
the accelerator to IVs with only 8 bytes. When CAAM has a lower era
a fallback is necessary to process 16 bytes IV.
Fixes: b189817cf789 ("crypto: caam/qi - add ablkcipher and authenc algorithms")
Cc: # v4.12+
From: Andrei Botila
CAAM accelerator only supports XTS-AES-128 and XTS-AES-256 since
it adheres strictly to the standard. All the other key lengths
are accepted and processed through a fallback as long as they pass
the xts_verify_key() checks.
Fixes: c6415a6016bf ("crypto: caam - add support for
From: Andrei Botila
A hardware limitation exists for CAAM until Era 9 which restricts
the accelerator to IVs with only 8 bytes. When CAAM has a lower era
a fallback is necessary to process 16 bytes IV.
Fixes: 226853ac3ebe ("crypto: caam/qi2 - add skcipher algorithms")
Cc: # v4.20+
Signed-off-by
From: Andrei Botila
Newer CAAM versions (Era 9+) support 16B IVs. Since for these devices
the HW limitation is no longer present newer version should process the
requests containing 16B IVs directly in hardware without using a fallback.
Signed-off-by: Andrei Botila
---
drivers/crypto/caam/caam
From: Andrei Botila
CAAM accelerator only supports XTS-AES-128 and XTS-AES-256 since
it adheres strictly to the standard. All the other key lengths
are accepted and processed through a fallback as long as they pass
the xts_verify_key() checks.
Fixes: 226853ac3ebe ("crypto: caam/qi2 - add skciphe
From: Andrei Botila
XTS should not return succes when dealing with block length equal to zero.
This is different than the rest of the skcipher algorithms.
Fixes: 31bb2f0da1b50 ("crypto: caam - check zero-length input")
Cc: # v5.4+
Signed-off-by: Andrei Botila
---
drivers/crypto/caam/caamalg.c
From: Andrei Botila
CAAM accelerator only supports XTS-AES-128 and XTS-AES-256 since
it adheres strictly to the standard. All the other key lengths
are accepted and processed through a fallback as long as they pass
the xts_verify_key() checks.
Fixes: b189817cf789 ("crypto: caam/qi - add ablkciph
From: Andrei Botila
Newer CAAM versions (Era 9+) support 16B IVs. Since for these devices
the HW limitation is no longer present newer version should process the
requests containing 16B IVs directly in hardware without using a fallback.
Signed-off-by: Andrei Botila
---
drivers/crypto/caam/caam
From: Andrei Botila
Newer CAAM versions (Era 9+) support 16B IVs. Since for these devices
the HW limitation is no longer present newer version should process the
requests containing 16B IVs directly in hardware without using a fallback.
Signed-off-by: Andrei Botila
---
drivers/crypto/caam/caam
On Tue, Sep 22, 2020 at 03:23:44PM +0200, Torsten Duwe wrote:
> On Mon, Sep 21, 2020 at 10:40:37AM +0200, Stephan Mueller wrote:
> > Am Montag, 21. September 2020, 09:58:16 CEST schrieb Nicolai Stange:
> >
> > > - people dislike the approach of having two competing implementations for
> > > what
On Tue, 22 Sep 2020 18:21:52 +0200
Greg Kroah-Hartman wrote:
> On Tue, Sep 22, 2020 at 03:23:44PM +0200, Torsten Duwe wrote:
> > On Mon, Sep 21, 2020 at 10:40:37AM +0200, Stephan Mueller wrote:
> > > Am Montag, 21. September 2020, 09:58:16 CEST schrieb Nicolai
> > > Stange:
> > >
> > > > - peopl
On Mon, Sep 21, 2020 at 04:52:43PM -0700, Eric Biggers wrote:
> On Mon, Sep 21, 2020 at 04:26:39PM -0700, Paul E. McKenney wrote:
> > On Tue, Sep 22, 2020 at 08:11:04AM +1000, Herbert Xu wrote:
> > > On Mon, Sep 21, 2020 at 08:27:14AM -0700, Paul E. McKenney wrote:
> > > > On Mon, Sep 21, 2020 at 0
On Tue, Sep 22, 2020 at 09:51:36AM +1000, Herbert Xu wrote:
> On Mon, Sep 21, 2020 at 04:26:39PM -0700, Paul E. McKenney wrote:
> >
> > > But this reasoning could apply to any data structure that contains
> > > a spin lock, in particular ones that are dereferenced through RCU.
> >
> > I lost you o
On Tue, Sep 22, 2020 at 11:42:43AM -0700, Paul E. McKenney wrote:
> On Tue, Sep 22, 2020 at 09:51:36AM +1000, Herbert Xu wrote:
> > On Mon, Sep 21, 2020 at 04:26:39PM -0700, Paul E. McKenney wrote:
> > >
> > > > But this reasoning could apply to any data structure that contains
> > > > a spin lock,
On Tue, Sep 22, 2020 at 11:31:00AM -0700, Paul E. McKenney wrote:
> > Also, it's not just the p == &global_variable case. Consider:
> >
> > struct a { struct b *b; };
> > struct b { ... };
> >
> > Thread 1:
> >
> > /* one-time initialized data shared by all instances of b */
> > static
On Tue, Sep 22, 2020 at 11:59:31AM -0700, Eric Biggers wrote:
> On Tue, Sep 22, 2020 at 11:42:43AM -0700, Paul E. McKenney wrote:
> > On Tue, Sep 22, 2020 at 09:51:36AM +1000, Herbert Xu wrote:
> > > On Mon, Sep 21, 2020 at 04:26:39PM -0700, Paul E. McKenney wrote:
> > > >
> > > > > But this reason
On Tue, Sep 22, 2020 at 12:09:36PM -0700, Eric Biggers wrote:
> On Tue, Sep 22, 2020 at 11:31:00AM -0700, Paul E. McKenney wrote:
> > > Also, it's not just the p == &global_variable case. Consider:
> > >
> > > struct a { struct b *b; };
> > > struct b { ... };
> > >
> > > Thread 1:
> > >
> > >
From: Nick Terrell
Adds decompress_sources.h which includes every .c file necessary for
zstd decompression. This is used in decompress_unzstd.c so the internal
structure of the library isn't exposed.
This allows us to upgrade the zstd library version without modifying any
callers. Instead we jus
From: Nick Terrell
This patchset upgrades the zstd library to the latest upstream release. The
current zstd version in the kernel is a modified version of upstream zstd-1.3.1.
At the time it was integrated, zstd wasn't ready to be used in the kernel as-is.
But, it is now possible to use upstream
From: Nick Terrell
Adds zstd_compat.h which provides the necessary functions from the
current zstd.h API. It is only active for zstd versions 1.4.6 and newer.
That means it is disabled currently, but will become active when a later
patch in this series updates the zstd library in the kernel to 1.
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is functionally equivalent.
Signed-off-by: Nick Terrell
---
fs/btrfs/zstd.c | 48
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/fs/btr
From: Nick Terrell
All callers have been transitioned to the new zstd-1.4.6 API. There are
no more callers of the zstd compatibility wrapper, so delete it.
Signed-off-by: Nick Terrell
---
include/linux/zstd_compat.h | 116
1 file changed, 116 deletions(-)
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is functionally equivalent.
Signed-off-by: Nick Terrell
---
lib/decompress_unzstd.c | 40 ++--
1 file changed, 14 insertions(+), 26 deletions(-)
diff --git a/lib/de
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is functionally equivalent.
Signed-off-by: Nick Terrell
---
crypto/zstd.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/crypto/zstd.c b/crypto/zstd.c
in
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is more efficient because it uses the single-pass API instead of
the streaming API. The streaming API is not necessary because the whole
input and output buffers are available. This saves memory because w
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is functionally equivalent.
Signed-off-by: Nick Terrell
---
fs/squashfs/zstd_wrapper.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/fs/squashfs/zstd_wrapper.c b/fs/squas
On Tue, Sep 22, 2020 at 01:56:28PM -0700, Paul E. McKenney wrote:
> > You're missing the point here. b and c could easily be allocated by a
> > function
> > alloc_b() that's in another file.
>
> I am still missing something.
>
> If by "allocated" you mean something like kmalloc(), the compiler
On Mon, 14 Sep 2020 00:10:20 +0800, 周琰杰 (Zhou Yanjie) wrote:
> Add the TRNG bindings for the X1830 SoC from Ingenic.
>
> Signed-off-by: 周琰杰 (Zhou Yanjie)
> ---
> .../devicetree/bindings/rng/ingenic,trng.yaml | 43
> ++
> 1 file changed, 43 insertions(+)
> create mode 1
On Wed, Sep 16, 2020 at 10:19:49AM +0300, Gilad Ben-Yossef wrote:
> Document ccree driver supporting new optional parameters allowing to
> customize the DMA transactions cache parameters and ACE bus sharability
> properties.
>
> Signed-off-by: Gilad Ben-Yossef
> ---
> Documentation/devicetree/bi
FYI, as mentioned last time: clear NAK for letting these bad APIs
slip into the overall kernel code. Please provide proper kernel style
wrappers to avoid these kinds of updates and in the future just change
APIs on an as-needed basis.
On Mon, Sep 21, 2020 at 02:38:46PM +0300, Peter Ujfalusi wrote:
> Make sure that we call the dma_unmap_sg on the correct scatterlist on
> completion with the correct sg_nents.
>
> We also should be calling dma_sync_sg_for_device() on the tx buffer before
> giving it to the DMA and the dma_sync_sg_
36 matches
Mail list logo
