On Tue, May 05, 2020 at 03:53:45PM +0200, Arnd Bergmann wrote:
> When building for ARMv7-M, clang-9 or higher tries to unroll some loops,
> which ends up confusing the register allocator to the point of generating
> rather bad code and using more than the warning limit for stack frames:
>
> warnin
Hi Linus:
This push fixes a potential scheduling latency problem for the
algorithms used by WireGuard.
The following changes since commit 55b3209acbb01cb02b1ee6b1afe80d83b1aab36d:
crypto: caam - fix the address of the last entry of S/G (2020-04-16 16:48:56
+1000)
are available in the Git rep
On Tue, May 05, 2020 at 04:36:49PM -0700, Nick Desaulniers wrote:
> On Tue, May 5, 2020 at 4:22 PM Jason A. Donenfeld wrote:
> >
> > On Tue, May 5, 2020 at 5:19 PM Kees Cook wrote:
> > >
> > > (Though as was mentioned, it's likely that FORTIFY_SOURCE isn't working
> > > _at all_ under Clang, so I
On Tue, May 5, 2020 at 5:22 PM Jason A. Donenfeld wrote:
>
> On Tue, May 5, 2020 at 5:19 PM Kees Cook wrote:
> >
> > On Tue, May 05, 2020 at 04:37:38PM -0600, Jason A. Donenfeld wrote:
> > > On Tue, May 5, 2020 at 4:25 PM Nathan Chancellor
> > > wrote:
> > > > I believe these issues are one in t
On Tue, May 5, 2020 at 5:19 PM Kees Cook wrote:
>
> On Tue, May 05, 2020 at 04:37:38PM -0600, Jason A. Donenfeld wrote:
> > On Tue, May 5, 2020 at 4:25 PM Nathan Chancellor
> > wrote:
> > > I believe these issues are one in the same. I did a reverse bisect with
> > > Arnd's test case and converge
On Tue, May 05, 2020 at 04:37:38PM -0600, Jason A. Donenfeld wrote:
> On Tue, May 5, 2020 at 4:25 PM Nathan Chancellor
> wrote:
> > I believe these issues are one in the same. I did a reverse bisect with
> > Arnd's test case and converged on George's first patch:
> >
> > https://github.com/llvm/ll
This code generated by Clang here is the unfortunate side-effect of a
bug introduced during Clang-10's development phase. From discussion
with Kees on the links Nick mentioned, I surmise that FORTIFY in the
kernel never worked as well for Clang as it does for GCC today. In
many cases, it'd compile
On Tue, May 5, 2020 at 4:25 PM Nathan Chancellor
wrote:
> I believe these issues are one in the same. I did a reverse bisect with
> Arnd's test case and converged on George's first patch:
>
> https://github.com/llvm/llvm-project/commit/2dd17ff08165e6118e70f00e22b2c36d2d4e0a9a
>
> I think that in l
On Tue, May 05, 2020 at 03:02:16PM -0700, 'Nick Desaulniers' via Clang Built
Linux wrote:
> On Tue, May 5, 2020 at 2:55 PM Jason A. Donenfeld wrote:
> >
> > clang-10 has a broken optimization stage that doesn't enable the
> > compiler to prove at compile time that certain memcpys are within
> > b
Am Dienstag, 5. Mai 2020, 09:58:35 CEST schrieb Herbert Xu:
Hi Herbert,
Issue is fixed in libkcapi with https://github.com/smuellerDD/libkcapi/commit/
2fdd3738c77b0db825b4bb94eef9a932aa5077de
Thanks.
Ciao
Stephan
clang-10 has a broken optimization stage that doesn't enable the
compiler to prove at compile time that certain memcpys are within
bounds, and thus the outline memcpy is always called, resulting in
horrific performance, and in some cases, excessive stack frame growth.
Here's a simple reproducer:
On Tue, May 5, 2020 at 3:48 PM Nick Desaulniers wrote:
>
> + Kees, George, who have started looking into this, too.
I have a smaller reproducer and analysis I'll send out very shortly.
As discussed on IRC, this issue here isn't specific to this file, but
rather fortify source has some serious issues on clang-10, everywhere
in the kernel, and we should probably disable it globally for this
clang version. I'll follow up with some more info in a different
patch.
On Tue, May 5, 2020 at 10:07 PM Jason A. Donenfeld wrote:
> On Tue, May 5, 2020 at 8:13 AM Arnd Bergmann wrote:
> >
> > clang points out a harmless use of uninitialized variables that
> > get passed into a local function but are ignored there:
> >
> > In file included from drivers/net/wireguard/r
On Tue, May 5, 2020 at 8:13 AM Arnd Bergmann wrote:
>
> clang points out a harmless use of uninitialized variables that
> get passed into a local function but are ignored there:
>
> In file included from drivers/net/wireguard/ratelimiter.c:223:
> drivers/net/wireguard/selftest/ratelimiter.c:173:34
On Mon, May 4, 2020 at 5:54 PM Daniel Jordan wrote:
>
> On Mon, May 04, 2020 at 03:10:46PM -0700, Alexander Duyck wrote:
> > So we cannot stop in the middle of a max order block. That shouldn't
> > be possible as part of the issue is that the buddy allocator will
> > attempt to access the buddy fo
On Mon, May 4, 2020 at 7:11 PM Daniel Jordan wrote:
>
> On Mon, May 04, 2020 at 09:48:44PM -0400, Daniel Jordan wrote:
> > On Mon, May 04, 2020 at 05:40:19PM -0700, Alexander Duyck wrote:
> > > On Mon, May 4, 2020 at 4:44 PM Josh Triplett
> > > wrote:
> > > >
> > > > On May 4, 2020 3:33:58 PM PD
clang points out a harmless use of uninitialized variables that
get passed into a local function but are ignored there:
In file included from drivers/net/wireguard/ratelimiter.c:223:
drivers/net/wireguard/selftest/ratelimiter.c:173:34: error: variable 'skb6' is
uninitialized when used here [-Werr
On Fri, May 01, 2020 at 10:31:13PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Instead of manually allocating a 'struct shash_desc' on the stack and
> calling crypto_shash_digest(), switch to using the new helper function
> crypto_shash_tfm_digest() which does this for us.
>
> Cc: Krzysz
clang-10 produces a warning about excessive stack usage, as well
as rather unoptimized object code when CONFIG_FORTIFY_SOURCE is
set:
lib/crypto/curve25519-hacl64.c:759:6: error: stack frame size of 2400 bytes in
function 'curve25519_generic' [-Werror,-Wframe-larger-than=]
Jason Donenfeld manage
When building for ARMv7-M, clang-9 or higher tries to unroll some loops,
which ends up confusing the register allocator to the point of generating
rather bad code and using more than the warning limit for stack frames:
warning: stack frame size of 1200 bytes in function 'blake2b_compress'
[-Wfram
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/crypto/xilinx/zynqmp-aes-gcm.c: In function 'zynqmp_aes_aead_cipher':
drivers/crypto/xilinx/zynqmp-aes-gcm.c:83:30: warning:
variable 'drv_ctx' set but not used [-Wunused-but-set-variable]
commit bc86f9c54616 ("firmware: xilinx: Remove eemi
Am Dienstag, 5. Mai 2020, 09:58:35 CEST schrieb Herbert Xu:
Hi Herbert,
> On Tue, Apr 21, 2020 at 10:08:14AM +0200, Ondrej Mosnáček wrote:
> > Hi all,
> >
> > the libkcapi [1] tests are failing on kernels 5.5-rc1 and above [2].
> > All encryption/decryption tests that use 'ctr(aes)' and a messag
On Tue, Apr 21, 2020 at 10:08:14AM +0200, Ondrej Mosnáček wrote:
> Hi all,
>
> the libkcapi [1] tests are failing on kernels 5.5-rc1 and above [2].
> All encryption/decryption tests that use 'ctr(aes)' and a message size
> that is not a multiple of 16 fail due to kcapi-enc returning different
> ou
24 matches
Mail list logo
