If STM32 CRC device is already in use, calculate CRC by software.
This will release CPU constraint for a concurrent access to the
hardware, and avoid masking irqs during the whole block processing.
Fixes: 7795c0baf5ac ("crypto: stm32/crc32 - protect from concurrent accesses")
Signed-off-by: Nico
The mutex adf_ctl_lock is initialized statically. It is
unnecessary to initialize by mutex_init().
Signed-off-by: Qinglang Miao
---
drivers/crypto/qat/qat_common/adf_ctl_drv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/adf_ctl_drv.c
b/drivers/crypto/qat/q
The ADRL pseudo instruction is not an architectural construct, but a
convenience macro that was supported by the ARM proprietary assembler
and adopted by binutils GAS as well, but only when assembling in 32-bit
ARM mode. Therefore, it can only be used in assembler code that is known
to assemble in
The ADRL pseudo instruction is not an architectural construct, but a
convenience macro that was supported by the ARM proprietary assembler
and adopted by binutils GAS as well, but only when assembling in 32-bit
ARM mode. Therefore, it can only be used in assembler code that is known
to assemble in
Remove some occurrences of ADRL in the SHA NEON code adopted from the
OpenSSL project.
I will leave it to the Clang folks to decide whether this needs to be
backported and how far, but a Cc stable seems reasonable here.
Cc: Nick Desaulniers
Cc: Stefan Agner
Cc: Peter Smith
Ard Biesheuvel (2):
On Wed, 16 Sep 2020 at 02:55, Nick Desaulniers wrote:
>
> On Tue, Sep 15, 2020 at 2:32 PM Ard Biesheuvel wrote:
> >
> > On Tue, 15 Sep 2020 at 21:50, Nick Desaulniers
> > wrote:
> > >
> > > On Tue, Sep 15, 2020 at 2:46 AM Ard Biesheuvel wrote:
> > > >
> > > > The ADRL pseudo instruction is not
From: Eric Biggers
On big endian CPUs, the ChaCha20-based CRNG is using the wrong
endianness for the ChaCha20 constants.
This doesn't matter cryptographically, but technically it means it's not
ChaCha20 anymore. Fix it to always use the standard constants.
Cc: linux-crypto@vger.kernel.org
Sign
From: Eric Biggers
Remove some dead code that was left over following commit 90ea1c6436d2
("random: remove the blocking pool").
Signed-off-by: Eric Biggers
---
drivers/char/random.c | 17 ++-
include/trace/events/random.h | 83 ---
2 files changed, 3
From: Eric Biggers
The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which
doesn't make sense. Reseed it from the input_pool instead.
Fixes: d848e5f8e1eb ("random: add new ioctl RNDRESEEDCRNG")
Cc: sta...@vger.kernel.org
Signed-off-by: Eric Biggers
---
drivers/char/random.c | 2 +-
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 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 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
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 | 112
1 file changed, 112 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
---
fs/btrfs/zstd.c | 48
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/fs/btr
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
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
Use DEFINE_SEQ_ATTRIBUTE macro to simplify the code.
Signed-off-by: Liu Shixin
---
drivers/crypto/qat/qat_common/adf_cfg.c | 19 +
.../qat/qat_common/adf_transport_debug.c | 42 ++-
2 files changed, 5 insertions(+), 56 deletions(-)
diff --git a/drivers/crypto/
The Secure Boot Forbidden Signature Database, dbx, contains a list of now
revoked signatures and keys previously approved to boot with UEFI Secure
Boot enabled. The dbx is capable of containing any number of
EFI_CERT_X509_SHA256_GUID, EFI_CERT_SHA256_GUID, and EFI_CERT_X509_GUID
entries.
Currentl
On 9/14/2020 9:38 AM, Richard Weinberger wrote:
> On Thu, Jul 16, 2020 at 4:12 PM Richard Weinberger
> wrote:
>>
>> On Mon, Jul 13, 2020 at 12:09 AM Iuliana Prodan
>> wrote:
>>>
>>> Tagged keys are keys that contain metadata indicating what
>>> they are and how to handle them using tag_object AP
From: Daniel Jordan
[ Upstream commit 1b0df11fde0f14a269a181b3b7f5122415bc5ed7 ]
syzbot reports,
WARNING: inconsistent lock state
5.9.0-rc2-syzkaller #0 Not tainted
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
syz-executor.0/26715 takes:
(pad
Hello Herbert,
On 9/11/20 6:28 AM, Herbert Xu wrote:
> On Fri, Sep 04, 2020 at 01:25:27PM +0200, Nicolas Toromanoff wrote:
>> If STM32 CRC device is already in use, calculate CRC by software.
>>
>> This will release CPU constraint for a concurrent access to the
>> hardware, and avoid masking irqs
- Ursprüngliche Mail -
> Von: "horia geanta"
>>> How to use it with cryptsetup?
>>> I'm asking because it is not clear to me why you are not implementing
>>> a new kernel key type (KEYS subsystem)
>>> to utilize tagged keys.
>>> Many tools already support the keyctl userspace interface (cr
On Tue, 15 Sep 2020 at 21:50, Nick Desaulniers wrote:
>
> On Tue, Sep 15, 2020 at 2:46 AM Ard Biesheuvel wrote:
> >
> > The ADRL pseudo instruction is not an architectural construct, but a
> > convenience macro that was supported by the ARM proprietary assembler
> > and adopted by binutils GAS as
On Tue, Sep 15 2020 at 20:10, Herbert Xu wrote:
> On Tue, Sep 15, 2020 at 01:08:31PM +0300, Ard Biesheuvel wrote:
>>
>> But making atomic kmap preemptible/sleepable creates the exact same
>> problem, i.e., that we have no idea which existing callers are
>> currently relying on those preemption disa
On Tue, 15 Sep 2020 at 15:45, Horia Geantă wrote:
>
> On 9/15/2020 1:26 PM, Ard Biesheuvel wrote:
> > On Tue, 15 Sep 2020 at 13:02, Horia Geantă wrote:
> >>
> >> On 9/14/2020 9:20 PM, Ard Biesheuvel wrote:
> >>> On Mon, 14 Sep 2020 at 20:12, Horia Geantă wrote:
>
> On 9/14/2020 7:28 PM
On 9/15/2020 1:26 PM, Ard Biesheuvel wrote:
> On Tue, 15 Sep 2020 at 13:02, Horia Geantă wrote:
>>
>> On 9/14/2020 9:20 PM, Ard Biesheuvel wrote:
>>> On Mon, 14 Sep 2020 at 20:12, Horia Geantă wrote:
On 9/14/2020 7:28 PM, Ard Biesheuvel wrote:
> On Mon, 14 Sep 2020 at 19:24, Horia G
On Tue, 15 Sep 2020 at 13:02, Horia Geantă wrote:
>
> On 9/14/2020 9:20 PM, Ard Biesheuvel wrote:
> > On Mon, 14 Sep 2020 at 20:12, Horia Geantă wrote:
> >>
> >> On 9/14/2020 7:28 PM, Ard Biesheuvel wrote:
> >>> On Mon, 14 Sep 2020 at 19:24, Horia Geantă wrote:
>
> On 9/9/2020 1:10 AM,
On Tue, Sep 15, 2020 at 01:08:31PM +0300, Ard Biesheuvel wrote:
>
> But making atomic kmap preemptible/sleepable creates the exact same
> problem, i.e., that we have no idea which existing callers are
> currently relying on those preemption disabling semantics, so we can't
> just take them away. Or
On Tue, 15 Sep 2020 at 13:05, Herbert Xu wrote:
>
> On Tue, Sep 15, 2020 at 01:02:10PM +0300, Ard Biesheuvel wrote:
> >
> > > I'd rather go for a preemptible/sleepable version of highmem mapping
> > > which is in itself consistent for both highmen and not highmem.
> >
> > I don't think we need to
On Tue, Sep 15, 2020 at 01:02:10PM +0300, Ard Biesheuvel wrote:
>
> > I'd rather go for a preemptible/sleepable version of highmem mapping
> > which is in itself consistent for both highmen and not highmem.
>
> I don't think we need to obsess about highmem, although we should
> obviously take care
On 9/14/2020 9:20 PM, Ard Biesheuvel wrote:
> On Mon, 14 Sep 2020 at 20:12, Horia Geantă wrote:
>>
>> On 9/14/2020 7:28 PM, Ard Biesheuvel wrote:
>>> On Mon, 14 Sep 2020 at 19:24, Horia Geantă wrote:
On 9/9/2020 1:10 AM, Herbert Xu wrote:
> On Tue, Sep 08, 2020 at 01:35:04PM +0300,
On Tue, 15 Sep 2020 at 12:34, Thomas Gleixner wrote:
>
> On Tue, Sep 15 2020 at 17:05, Herbert Xu wrote:
> > On Mon, Sep 14, 2020 at 11:55:53PM -0700, Linus Torvalds wrote:
> >>
> >> Maybe we could hide it behind a debug option, at least.
> >>
> >> Or, alterantively, introduce a new "debug_preempt
The ADRL pseudo instruction is not an architectural construct, but a
convenience macro that was supported by the ARM proprietary assembler
and adopted by binutils GAS as well, but only when assembling in 32-bit
ARM mode. Therefore, it can only be used in assembler code that is known
to assemble in
On Tue, Sep 15 2020 at 17:05, Herbert Xu wrote:
> On Mon, Sep 14, 2020 at 11:55:53PM -0700, Linus Torvalds wrote:
>>
>> Maybe we could hide it behind a debug option, at least.
>>
>> Or, alterantively, introduce a new "debug_preempt_count" that doesn't
>> actually disable preemption, but warns abou
Hi Joe,
For MTD:
> drivers/mtd/nand/raw/nandsim.c| 2 +-
Reviewed-by: Miquel Raynal
Thanks,
Miquèl
On Wed, 09 Sep 2020, Joe Perches wrote:
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index 5ac0dbf0e03d..35ac539cc2b1 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@
On Tue, 15 Sep 2020 at 10:05, Herbert Xu wrote:
>
> On Mon, Sep 14, 2020 at 11:55:53PM -0700, Linus Torvalds wrote:
> >
> > Maybe we could hide it behind a debug option, at least.
> >
> > Or, alterantively, introduce a new "debug_preempt_count" that doesn't
> > actually disable preemption, but war
On Tue, 15 Sep 2020 at 09:56, Linus Torvalds
wrote:
>
> On Mon, Sep 14, 2020 at 11:45 PM Linus Torvalds
> wrote:
> >
> > I mean, I did find one case that didn't set it (cb710-mmc.c), but
> > pattern-matching to the other mmc cases, that one looks like it
> > _should_ have set the atomic flag like
On Mon, Sep 14, 2020 at 11:55:53PM -0700, Linus Torvalds wrote:
>
> Maybe we could hide it behind a debug option, at least.
>
> Or, alterantively, introduce a new "debug_preempt_count" that doesn't
> actually disable preemption, but warns about actual sleeping
> operations..
I'm more worried abou
41 matches
Mail list logo
