On Sat, Oct 03, 2020 at 07:15:53PM +0200, Christophe Leroy wrote:
>
> The following changes fix the sparse warnings with less churn:
Yes that works too. Can you please submit this patch?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.o
On Tue, 6 Oct 2020 at 21:59, Nathan Chancellor wrote:
>
> Clang warns:
>
> crypto/xor.c:101:4: warning: variable 'count' is uninitialized when used
> here [-Wuninitialized]
> count++;
> ^
> crypto/xor.c:86:17: note: initialize the variable 'count
On Sat, Oct 03, 2020 at 09:17:40AM +0800, kernel test robot wrote:
> tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
> master
> head: ed4424f2fb02497b0ea92bf58c533c598c0da1d3
> commit: 215525639631ade1d67e879fe2c3d7195daa9f59 [169/199] X.509: support
> OSCCA
Am Mittwoch, 7. Oktober 2020, 06:24:09 CEST schrieb Eric Biggers:
Hi Eric,
>
> Note that having multiple RNG implementations would cause fragmentation,
> more maintenance burden, etc. So IMO, that should be a last resort.
> Instead we should try to find an implementation that works for everyone
On Fri, Oct 02, 2020 at 02:38:36PM +0200, Torsten Duwe wrote:
> Almost two weeks passed and these are the "relevant" replies:
>
> Jason personally does not like FIPS, and is afraid of
> "subpar crypto". Albeit this patch set strictly isn't about
> crypto at all; the crypto subsystem is in the unlu
On Fri, Sep 18, 2020 at 02:57:05PM -0700, Eric Biggers wrote:
> On Fri, Sep 18, 2020 at 04:42:07PM -0400, Theodore Y. Ts'o wrote:
Ted, any further feedback on this? Are you planning to apply this patch?
- Eric
On Tue, Sep 15, 2020 at 09:19:08PM -0700, Eric Biggers wrote:
> 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...@vg
On Tue, Sep 15, 2020 at 09:36:52PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Remove some dead code that was left over following commit 90ea1c6436d2
> ("random: remove the blocking pool").
>
> Signed-off-by: Eric Biggers
Ping?
Hi,
On Tue, Oct 6, 2020 at 12:59 PM Nathan Chancellor
wrote:
>
> Clang warns:
>
> crypto/xor.c:101:4: warning: variable 'count' is uninitialized when used
> here [-Wuninitialized]
> count++;
> ^
> crypto/xor.c:86:17: note: initialize the variabl
Clang warns:
crypto/xor.c:101:4: warning: variable 'count' is uninitialized when used
here [-Wuninitialized]
count++;
^
crypto/xor.c:86:17: note: initialize the variable 'count' to silence
this warning
int i, j, count;
On Tue, 6 Oct 2020 11:33:26 -0500, Jeremy Linton wrote:
> The AES code uses a 'br x7' as part of a function called by
> a macro. That branch needs a bti_j as a target. This results
> in a panic as seen below. Using x16 (or x17) with an indirect
> branch keeps the target bti_c.
>
> Bad mode in Sy
On Tue, Oct 06, 2020 at 11:33:26AM -0500, Jeremy Linton wrote:
> The AES code uses a 'br x7' as part of a function called by
> a macro. That branch needs a bti_j as a target. This results
> in a panic as seen below. Using x16 (or x17) with an indirect
> branch keeps the target bti_c.
Reviewed-by:
On Tue, 6 Oct 2020 at 18:33, Jeremy Linton wrote:
>
> The AES code uses a 'br x7' as part of a function called by
> a macro. That branch needs a bti_j as a target. This results
> in a panic as seen below. Using x16 (or x17) with an indirect
> branch keeps the target bti_c.
>
> Bad mode in Synchr
The AES code uses a 'br x7' as part of a function called by
a macro. That branch needs a bti_j as a target. This results
in a panic as seen below. Using x16 (or x17) with an indirect
branch keeps the target bti_c.
Bad mode in Synchronous Abort handler detected on CPU1, code 0x3403 -- BTI
C
Hi,
On 10/6/20 7:33 AM, Catalin Marinas wrote:
On Tue, Oct 06, 2020 at 11:43:14AM +0100, Dave P Martin wrote:
On Tue, Oct 06, 2020 at 11:25:11AM +0100, Catalin Marinas wrote:
On Tue, Oct 06, 2020 at 11:01:21AM +0100, Dave P Martin wrote:
On Tue, Oct 06, 2020 at 09:27:48AM +0100, Will Deacon w
On Tue, 6 Oct 2020 at 14:33, Catalin Marinas wrote:
>
> On Tue, Oct 06, 2020 at 11:43:14AM +0100, Dave P Martin wrote:
> > On Tue, Oct 06, 2020 at 11:25:11AM +0100, Catalin Marinas wrote:
> > > On Tue, Oct 06, 2020 at 11:01:21AM +0100, Dave P Martin wrote:
> > > > On Tue, Oct 06, 2020 at 09:27:48A
On Tue, Oct 06, 2020 at 11:43:14AM +0100, Dave P Martin wrote:
> On Tue, Oct 06, 2020 at 11:25:11AM +0100, Catalin Marinas wrote:
> > On Tue, Oct 06, 2020 at 11:01:21AM +0100, Dave P Martin wrote:
> > > On Tue, Oct 06, 2020 at 09:27:48AM +0100, Will Deacon wrote:
> > > > On Mon, Oct 05, 2020 at 10:
On Tue, Oct 06, 2020 at 11:25:11AM +0100, Catalin Marinas wrote:
> On Tue, Oct 06, 2020 at 11:01:21AM +0100, Dave P Martin wrote:
> > On Tue, Oct 06, 2020 at 09:27:48AM +0100, Will Deacon wrote:
> > > On Mon, Oct 05, 2020 at 10:48:54PM -0500, Jeremy Linton wrote:
> > > > The AES code uses a 'br x7'
On Mon, Oct 05, 2020 at 10:48:54PM -0500, Jeremy Linton wrote:
> The AES code uses a 'br x7' as part of a function called by
> a macro. That branch needs a bti_j as a target. This results
> in a panic as seen below. Instead of trying to replace the branch
> target with a bti_jc, lets replace the in
On Tue, Oct 06, 2020 at 11:01:21AM +0100, Dave P Martin wrote:
> On Tue, Oct 06, 2020 at 09:27:48AM +0100, Will Deacon wrote:
> > On Mon, Oct 05, 2020 at 10:48:54PM -0500, Jeremy Linton wrote:
> > > The AES code uses a 'br x7' as part of a function called by
> > > a macro. That branch needs a bti_j
On Tue, Oct 06, 2020 at 11:01:21AM +0100, Dave Martin wrote:
> On Tue, Oct 06, 2020 at 09:27:48AM +0100, Will Deacon wrote:
> > On Mon, Oct 05, 2020 at 10:48:54PM -0500, Jeremy Linton wrote:
> > > The AES code uses a 'br x7' as part of a function called by
> > > a macro. That branch needs a bti_j a
On Tue, Oct 06, 2020 at 09:27:48AM +0100, Will Deacon wrote:
> On Mon, Oct 05, 2020 at 10:48:54PM -0500, Jeremy Linton wrote:
> > The AES code uses a 'br x7' as part of a function called by
> > a macro. That branch needs a bti_j as a target. This results
> > in a panic as seen below. Instead of try
On Tue, 6 Oct 2020 at 11:38, Dave Martin wrote:
>
> On Mon, Oct 05, 2020 at 02:24:47PM -0500, Jeremy Linton wrote:
> > Hi,
> >
> > On 10/5/20 1:54 PM, Ard Biesheuvel wrote:
> > >On Mon, 5 Oct 2020 at 20:18, Jeremy Linton wrote:
> > >>
> > >>The AES code uses a 'br x7' as part of a function called
On Mon, Oct 05, 2020 at 02:24:47PM -0500, Jeremy Linton wrote:
> Hi,
>
> On 10/5/20 1:54 PM, Ard Biesheuvel wrote:
> >On Mon, 5 Oct 2020 at 20:18, Jeremy Linton wrote:
> >>
> >>The AES code uses a 'br x7' as part of a function called by
> >>a macro, that ends up needing a BTI_J as a target.
> >
>
On Mon, Oct 05, 2020 at 10:48:54PM -0500, Jeremy Linton wrote:
> The AES code uses a 'br x7' as part of a function called by
> a macro. That branch needs a bti_j as a target. This results
> in a panic as seen below. Instead of trying to replace the branch
> target with a bti_jc, lets replace the in
note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Jeremy-Linton/arm64-bti-fix-BTI-to-handle-local-indirect-branches/20201006-021958
base: https://git.kernel.org/pub
26 matches
Mail list logo
