On Tue, 15 Jul 2014, Peter Zijlstra wrote:
> On Tue, Jul 15, 2014 at 11:50:45AM +0200, Peter Zijlstra wrote:
> > So you already have an idle notifier (which is x86 only, we should fix
> > that I suppose), and you then double check there really isn't anything
> > else running.
>
> Note that we've
On Tue, 15 Jul 2014, Tim Chen wrote:
> On Tue, 2014-07-15 at 14:59 +0200, Thomas Gleixner wrote:
> > On Tue, 15 Jul 2014, Peter Zijlstra wrote:
> >
> > > On Tue, Jul 15, 2014 at 11:50:45AM +0200, Peter Zijlstra wrote:
> > > > So you already have an idle notifi
On Wed, 9 Nov 2016, Russell King - ARM Linux wrote:
> Please include Thomas in this.
Thanks!
> On Wed, Nov 09, 2016 at 10:46:21AM +0200, Horia Geantă wrote:
> > This reverts commit 66d2e2028091a074aa1290d2eeda5ddb1a6c329c.
> >
> > Quoting from Russell's findings:
> > https://www.mail-archive.co
On Thu, 10 Nov 2016, Thomas Gleixner wrote:
> > > which corresponds to an 8% slowdown for the threaded IRQ case. So,
> > > tasklets are indeed faster than threaded IRQs.
Forgot to say, that this should be:
So, tasklets are indeed faster than threaded IRQs for this particula
On Thu, 19 Jan 2017, Denys Vlasenko wrote:
> A lot of asm-optimized routines in arch/x86/crypto/ keep its
> constants in .data. This is wrong, they should be on .rodata.
>
> Mnay of these constants are the same in different modules.
> For example, 128-bit shuffle mask 0x000102030405060708090A0B0C
On Tue, 20 Sep 2016, Russell King - ARM Linux wrote:
> which corresponds to an 8% slowdown for the threaded IRQ case. So,
> tasklets are indeed faster than threaded IRQs.
Fair enough.
> I've tried to perf it, but...
>
> So, sorry, I'm not going to bother trying to get any further with th
On Tue, 20 Sep 2016, Russell King - ARM Linux wrote:
> each of those places where af_alg_wait_for_completion() called, we
> end up submitting a bunch of data and then immediately waiting for
> the operation to complete... and this can be seen in the perf
> trace logs.
That'd explain it.
> So, un
On Wed, 14 Oct 2015, LABBE Corentin wrote:
> The sha x86 crypto code use two define for the same thing:
> NUM_SHA1_DIGEST_WORDS and SHA1_DIGEST_LENGTH
> Replace them by SHA1_DIGEST_SIZE/4
That's wrong. Use only one for the number of words and make the define
so it's derived from the LENGTH.
Than
s for that
thread resulting in code executing on the wrong CPU and overwriting the
new affinity setting.
Replace it by using work_on_cpu_safe() which guarantees to run the code on
the requested CPU or to fail in case the CPU is offline.
Signed-off-by: Thomas Gleixner
Cc: Herbert Xu
Cc: "David
s for that
thread resulting in code executing on the wrong CPU and overwriting the
new affinity setting.
Replace it by using work_on_cpu_safe() which guarantees to run the code on
the requested CPU or to fail in case the CPU is offline.
Signed-off-by: Thomas Gleixner
Acked-by: Herbert Xu
Cc: &qu
No users outside of padata.c
Signed-off-by: Thomas Gleixner
Cc: Steffen Klassert
Cc: linux-crypto@vger.kernel.org
---
include/linux/padata.h |3 ---
kernel/padata.c| 34 +-
2 files changed, 17 insertions(+), 20 deletions(-)
--- a/include/linux
padata_alloc_possible() is pcrypt_init_padata() which
calls from a get_online_cpus() protected region as well.
Remove the get_online_cpus() call in padata_alloc() and document the
calling convention.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Cc: Steffen Klassert
Cc
On Sun, 16 Apr 2017, Jason A. Donenfeld wrote:
> I rather like this option of padata, which, since it lives in
> kernel/padata.c and linux/padata.h, should be generic and useful for
> other components. Seems like the ability to allocate it for a
> particular set of worker CPUs and callback CPUs co
No users outside of padata.c
Signed-off-by: Thomas Gleixner
Cc: Steffen Klassert
Cc: linux-crypto@vger.kernel.org
---
include/linux/padata.h |3 ---
kernel/padata.c| 32
2 files changed, 16 insertions(+), 19 deletions(-)
--- a/include/linux
padata_alloc_possible() is pcrypt_init_padata() which
calls from a get_online_cpus() protected region as well.
Remove the get_online_cpus() call in padata_alloc() and document the
calling convention.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Cc: Steffen Klassert
Cc
On Sun, 21 May 2017, Corentin Labbe wrote:
> Since linux-next-20170517 at least I got the following DEADLOCK warning:
> [4.311614]
> [4.316919] WARNING: possible recursive locking detected
> [4.37] 4.12.0-rc1-next-20170517+ #273 Not taint
No users outside of padata.c
Signed-off-by: Thomas Gleixner
Cc: Steffen Klassert
Cc: Peter Zijlstra
Cc: Sebastian Siewior
Cc: Steven Rostedt
Cc: linux-crypto@vger.kernel.org
---
include/linux/padata.h |3 ---
kernel/padata.c| 32
2 files
padata_alloc_possible() is pcrypt_init_padata() which
calls from a cpus_read_lock() protected region as well.
Remove the cpus_read_lock() call in padata_alloc() and document the
calling convention.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Cc: Steffen Klassert
Cc: Peter
On Mon, 13 Jun 2011, Jarod Wilson wrote:
> Add a new function pointer to struct clocksource that can optionally be
> filled in by clocksources deemed to be high enough resolution to feed
> the random number generator entropy pool.
Uurrg.
> + * @entropy: random entropy pool addition funct
On Mon, 13 Jun 2011, Venkatesh Pallipadi wrote:
> On Mon, Jun 13, 2011 at 3:06 PM, Jarod Wilson wrote:
> > TSC is high enough resolution that we can use its low-order byte to
> > stir new data into the random number generator entropy pool.
>
> >From what I vaguely remember from years past, rdt
On Mon, 13 Jun 2011, Jarod Wilson wrote:
> This is a fairly simple driver that just starts up a kernel thread that
> periodically calls the active clocksource's entropy-gathering function,
> if it has one. The default interval of 100us between polls doesn't show
> any measurable impact to cpu usage
On Fri, 9 Sep 2011, Steve Grubb wrote:
> But what I was trying to say is that we can't depend on these supplemental
> hardware
> devices like TPM because we don't have access to the proprietary technical
> details
> that would be necessary to supplement the analysis. And when it comes to TPM
>
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
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 Thu, 4 Jul 2019, Sebastian Andrzej Siewior wrote:
Polite reminder...
> For spinlocks the type spinlock_t should be used instead of "struct
> spinlock".
>
> Use spinlock_t for spinlock's definition.
>
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Cc: linux-crypto@vger.kernel.org
> Signed-off-b
it's a stub which the compiler optimizes out.
Remove the whole conditional.
No functional change.
Signed-off-by: Thomas Gleixner
Cc: linux-crypto@vger.kernel.org
Cc: Herbert Xu
Cc: "David S. Miller"
---
include/crypto/algapi.h |2 --
1 file changed, 2 deletions(-)
--- a
On Tue, Dec 01 2020 at 14:01, Corentin Labbe wrote:
> +[ 213.050152] [ cut here ]
> +[ 213.050207] WARNING: CPU: 0 PID: 18430 at mm/highmem.c:581
> kunmap_local_indexed+0x194/0x1d4
> +[ 213.050214] Modules linked in: sm4_generic authenc vmac xcbc hmac
> streebog_generic
On Tue, Dec 01 2020 at 14:52, Corentin Labbe wrote:
> On Tue, Dec 01, 2020 at 02:28:54PM +0100, Thomas Gleixner wrote:
> The patch made the board too busy logging and fail to boot until the test.
Stupid me. Of course this wants to be conditional.
Thanks,
tglx
---
diff --gi
On Tue, Dec 01 2020 at 15:45, Corentin Labbe wrote:
> On Tue, Dec 01, 2020 at 03:16:36PM +0100, Thomas Gleixner wrote:
> In fact the warn was a bit later so I added:
>preempt_disable();
> idx = arch_kmap_local_unmap_idx(kmap_local_idx(), addr);
> - WA
On Wed, Dec 02 2020 at 20:55, Corentin Labbe wrote:
> On Tue, Dec 01, 2020 at 04:15:08PM +0100, Thomas Gleixner wrote:
>
> The result could be seen at http://kernel.montjoie.ovh/129768.log
> The log is 9Mb, but the ftrace dump seems not terminated, tell me if you need
> more
On Thu, Dec 03 2020 at 18:38, Corentin Labbe wrote:
> On Wed, Dec 02, 2020 at 09:59:36PM +0100, Thomas Gleixner wrote:
>> On Wed, Dec 02 2020 at 20:55, Corentin Labbe wrote:
>> > On Tue, Dec 01, 2020 at 04:15:08PM +0100, Thomas Gleixner wrote:
>> >
>> &
On Fri, Dec 04 2020 at 14:26, Corentin Labbe wrote:
> On Fri, Dec 04, 2020 at 12:34:05AM +0100, Thomas Gleixner wrote:
>> The unmap comes from sg_miter_stop() and looking at the previous
>> map/unmap cycles there are never nested maps.
>>
>> [ 996.943030] cryptset
On Fri, Dec 04 2020 at 20:27, Corentin Labbe wrote:
> On Fri, Dec 04, 2020 at 04:08:27PM +0100, Thomas Gleixner wrote:
>> On Fri, Dec 04 2020 at 14:26, Corentin Labbe wrote:
>> > On Fri, Dec 04, 2020 at 12:34:05AM +0100, Thomas Gleixner wrote:
>> >> The unmap comes fr
Corentin,
On Sat, Dec 05 2020 at 19:43, Corentin Labbe wrote:
> On Fri, Dec 04, 2020 at 09:58:21PM +0100, Thomas Gleixner wrote:
>> Can you please replace the debug patch with the one below and try again?
>> That stops the trace right on the condition.
>
> Hello, the result c
On Sun, Dec 06 2020 at 22:40, Corentin Labbe wrote:
> On Sat, Dec 05, 2020 at 08:48:15PM +0100, Thomas Gleixner wrote:
>> So this maps two pages and unmaps the first one. That's all called from
>> sun4i_ss_opti_poll() and the bug is clearly visible there:
>>
On Mon, Dec 07 2020 at 13:18, Corentin Labbe wrote:
> On Mon, Dec 07, 2020 at 01:15:49AM +0100, Thomas Gleixner wrote:
> So if I understand correctly, basicly I cannot have two atomic kmap at
> the same time since it made unmapping them in the right order complex.
You can, but the ord
On Sun, 24 Jun 2018, Ingo Molnar wrote:
> * Borislav Petkov wrote:
>
> > Lemme send a proper patch now...
> >
> > ---
> > From: Borislav Petkov
> > Date: Sun, 17 Jun 2018 13:57:42 +0200
> > Subject: [PATCH] x86/crypto: Add missing RETs
> >
> > Add explicit RETs to the tail calls of AEGIS and M
On Mon, 10 Sep 2018, Jason A. Donenfeld wrote:
> lib/zinc/Makefile|4 +
> lib/zinc/chacha20/chacha20-x86_64-glue.h | 102 +
> lib/zinc/chacha20/chacha20-x86_64.S | 2632 ++
Just a stupid question. What's the rationale of putting that into lib/z
On Tue, 11 Sep 2018, Samuel Neves wrote:
> On Tue, Sep 11, 2018 at 9:22 AM, Thomas Gleixner wrote:
> > On Mon, 10 Sep 2018, Jason A. Donenfeld wrote:
> >> lib/zinc/Makefile|4 +
> >> lib/zinc/chacha20/chacha20-x86_64-glue.h | 102 +
>
On Tue, 11 Sep 2018, Jason A. Donenfeld wrote:
> Hey Thomas,
>
> On Tue, Sep 11, 2018 at 3:09 AM Thomas Gleixner wrote:
> > > This is covered on the 02/17 commit message, whose relevant paragraph
> > > follows:
> > Well, being only cc'ed on only ha
Jason,
On Tue, 18 Sep 2018, Jason A. Donenfeld wrote:
> This provides SSSE3, AVX-2, AVX-512F, and AVX-512VL implementations for
> ChaCha20. The AVX-512F implementation is disabled on Skylake, due to
> throttling, and the VL ymm implementation is used instead. These come
> from Andy Polyakov's imp
Jason,
On Wed, 19 Sep 2018, Jason A. Donenfeld wrote:
> On Wed, Sep 19, 2018 at 12:30 AM Thomas Gleixner wrote:
> >
> > > +++ b/lib/zinc/chacha20/chacha20-x86_64-glue.h
> > > @@ -0,0 +1,100 @@
> > > +/* SPDX-License-Identifier: MIT
> >
> > Please
later,
it's assumed that the boiler plate code is correct, but the SPDX license
identifier is wrong.
Fix the SPDX identifier and remove the boiler plate as it is redundant.
Fixes: f606a88e5823 ("crypto: aegis - Add generic AEGIS AEAD implementations")
Signed-off-by: Thomas Gleix
The license boiler plate text is not ideal for machine parsing. The kernel
uses SPDX license identifiers for that purpose, which replace the boiler
plate text.
Signed-off-by: Thomas Gleixner
Cc: Ondrej Mosnacek
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: linux-crypto@vger.kernel.or
;crypto: morus - Add generic MORUS AEAD implementations")
Signed-off-by: Thomas Gleixner
Cc: Ondrej Mosnacek
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: linux-crypto@vger.kernel.org
---
P.S.: This patch is part of a larger cleanup, but independent of other
patches and is intende
The license boiler plate text is not ideal for machine parsing. The kernel
uses SPDX license identifiers for that purpose, which replace the boiler
plate text.
Signed-off-by: Thomas Gleixner
Cc: Ondrej Mosnacek
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: linux-crypto@vger.kernel.or
46 matches
Mail list logo
