a set of atomic_inc_return() looks more neater
Signed-off-by: Yejune Deng
---
drivers/crypto/hisilicon/trng/trng.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/hisilicon/trng/trng.c
b/drivers/crypto/hisilicon/trng/trng.c
index a5033cf..2971268 10064
On Mon, 30 Nov 2020 at 23:48, Ben Greear wrote:
>
> On 11/29/20 10:20 AM, Ard Biesheuvel wrote:
> > From: Steve deRosier
> >
> > Add ccm(aes) implementation from linux-wireless mailing list (see
> > http://permalink.gmane.org/gmane.linux.kernel.wireless.general/126679).
> >
> > This eliminates FP
Gustavo,
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
Applied 20-22,54,120-124 to 5.11/scsi-staging, thanks.
--
Martin K. Petersen Oracle Linux Engineering
On 11/29/20 10:20 AM, Ard Biesheuvel wrote:
From: Steve deRosier
Add ccm(aes) implementation from linux-wireless mailing list (see
http://permalink.gmane.org/gmane.linux.kernel.wireless.general/126679).
This eliminates FPU context store/restore overhead existing in more
general ccm_base(ctr(ae
On Mon, Nov 30, 2020 at 04:15:23PM +0100, Jason A. Donenfeld wrote:
> I am willing to maintain random.c and have intentions to have a
> formally verified RNG. I've mentioned this to Ted before.
>
> But I think Ted's reluctance to not accept the recent patches sent to
> this list is mostly justifie
I am willing to maintain random.c and have intentions to have a
formally verified RNG. I've mentioned this to Ted before.
But I think Ted's reluctance to not accept the recent patches sent to
this list is mostly justified, and I have no desire to see us rush
into replacing random.c with something
Hi Linus!
AFAIK it's legit to bother you directly with issues like this one?
I see certifications as the mere messengers here which tell us that
our /dev/random is technologically outdated. Input entropy amounts are
guesstimated in advance, obviously much too conservatively, compiled in
and never
Hi Ard,
On Mon, Nov 30, 2020 at 1:47 PM Ard Biesheuvel wrote:
> On Mon, 30 Nov 2020 at 13:42, Geert Uytterhoeven wrote:
> > On Mon, Nov 30, 2020 at 1:26 PM Ard Biesheuvel wrote:
> > > Geert reports that builds where CONFIG_CRYPTO_AEGIS128_SIMD is not set
> > > may still emit references to crypt
在 2020/11/27 22:26, Lukasz Stelmach 写道:
It was <2020-11-27 pią 17:44>, when Qinglang Miao wrote:
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to putting operation will result in a
reference leak here.
A new function pm_runtime_resume_and_get is introduced in
在 2020/11/27 17:44, Krzysztof Kozlowski 写道:
On Fri, Nov 27, 2020 at 05:44:46PM +0800, Qinglang Miao wrote:
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to putting operation will result in a
reference leak here.
A new function pm_runtime_resume_and_get is int
pm_runtime_get_sync will increment pm usage counter even
failed. Forgetting to putting operation will result in a
reference leak here.
Replace it with pm_runtime_resume_and_get to keep usage
counter balanced. I remove err_clock label at the same.
Fixes: 6cd225cc5d8a ("hwrng: exynos - add Samsung
On Mon, 30 Nov 2020 at 13:42, Geert Uytterhoeven wrote:
>
> Hi Ard,
>
> On Mon, Nov 30, 2020 at 1:26 PM Ard Biesheuvel wrote:
> > Geert reports that builds where CONFIG_CRYPTO_AEGIS128_SIMD is not set
> > may still emit references to crypto_aegis128_update_simd(), which
> > cannot be satisfied an
Hi Ard,
On Mon, Nov 30, 2020 at 1:26 PM Ard Biesheuvel wrote:
> Geert reports that builds where CONFIG_CRYPTO_AEGIS128_SIMD is not set
> may still emit references to crypto_aegis128_update_simd(), which
> cannot be satisfied and therefore break the build. These references
> only exist in function
Geert reports that builds where CONFIG_CRYPTO_AEGIS128_SIMD is not set
may still emit references to crypto_aegis128_update_simd(), which
cannot be satisfied and therefore break the build. These references
only exist in functions that can be optimized away, but apparently,
the compiler is not always
Hi Ard,
On Mon, Nov 30, 2020 at 10:45 AM Ard Biesheuvel wrote:
> On Mon, 30 Nov 2020 at 10:43, Ard Biesheuvel wrote:
> > On Mon, 30 Nov 2020 at 10:37, Geert Uytterhoeven
> > wrote:
> > > On Tue, Nov 17, 2020 at 2:38 PM Ard Biesheuvel wrote:
> > > > This series supersedes [0] '[PATCH] crypto:
I've taken Tianjia Zhang's patch for this.
Thanks,
David
On Mon, 30 Nov 2020 at 10:43, Ard Biesheuvel wrote:
>
> On Mon, 30 Nov 2020 at 10:37, Geert Uytterhoeven wrote:
> >
> > Hi Ard,
> >
> > On Tue, Nov 17, 2020 at 2:38 PM Ard Biesheuvel wrote:
> > > This series supersedes [0] '[PATCH] crypto: aegis128/neon - optimize tail
> > > block handling', whi
On Mon, 30 Nov 2020 at 10:37, Geert Uytterhoeven wrote:
>
> Hi Ard,
>
> On Tue, Nov 17, 2020 at 2:38 PM Ard Biesheuvel wrote:
> > This series supersedes [0] '[PATCH] crypto: aegis128/neon - optimize tail
> > block handling', which is included as patch #3 here, but hasn't been
> > modified substan
Hi Ard,
On Tue, Nov 17, 2020 at 2:38 PM Ard Biesheuvel wrote:
> This series supersedes [0] '[PATCH] crypto: aegis128/neon - optimize tail
> block handling', which is included as patch #3 here, but hasn't been
> modified substantially.
>
> Patch #1 should probably go to -stable, even though aegis1
Tobias Markus wrote:
> kernel: RIP: 0010:public_key_verify_signature+0x189/0x3f0
Is it possible for you to provide a disassembly of this function from the
kernel you were using? For this to occur on that line, it appears that sig
would need to be NULL - but that should trip an assertion at the
On 30/11/2020 03:40, Jarkko Sakkinen wrote:
> On Fri, Nov 20, 2020 at 07:04:17PM +0100, Mickaël Salaün wrote:
>> Hi,
>>
>> This patch series mainly add a new configuration option to enable the
>> root user to load signed keys in the blacklist keyring. This keyring is
>> useful to "untrust" certi
21 matches
Mail list logo