On Wed, Mar 05, 2025 at 07:27:32AM -0800, Bart Van Assche wrote:
> On 3/5/25 3:20 AM, Peter Zijlstra wrote:
> > diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> > index 248416ecd01c..d27607d9c2dc 100644
> > --- a/include/linux/blkdev.h
> > +++ b/include/l
Right, so since this is all awesome, I figured I should try and have it
compile kernel/sched/, see how far I get.
I know I can't use the __guarded_by() things, they're just too primitive
for that I need, but I figured I should try and have it track the
lock/unlock thingies at least.
I've had t
On Tue, Mar 04, 2025 at 10:21:01AM +0100, Marco Elver wrote:
> +# define __asserts_cap(var)
> __attribute__((assert_capability(var)))
> +# define __asserts_shared_cap(var)
> __attribute__((assert_shared_capability(var)))
> + static __always_inline void __assert_ca
On Tue, Mar 04, 2025 at 10:21:07AM +0100, Marco Elver wrote:
> To avoid warnings in constructors, the initialization functions mark a
> capability as acquired when initialized before guarded variables.
Right, took me a bit, but OMG that's a horrific hack :-)
On Tue, Mar 04, 2025 at 10:21:05AM +0100, Marco Elver wrote:
> Due to the scoped cleanup helpers used for lock guards wrapping
> acquire/release around their own constructors/destructors that store
> pointers to the passed locks in a separate struct, we currently cannot
> accurately annotate *destr
On Tue, Mar 04, 2025 at 10:20:59AM +0100, Marco Elver wrote:
> === Initial Uses ===
>
> With this initial series, the following synchronization primitives are
> supported: `raw_spinlock_t`, `spinlock_t`, `rwlock_t`, `mutex`,
> `seqlock_t`, `bit_spinlock`, RCU, SRCU (`srcu_struct`), `rw_semaphore`
On Fri, Feb 21, 2025 at 08:46:45PM +0100, Marco Elver wrote:
> Anything else you see as urgent? Re-entrant locks support a deal breaker?
Most actual locks are not recursive -- RCU being the big exception here.
As to this being deal breakers, I don't think so. We should just start
with the bits w
On Fri, Feb 21, 2025 at 10:08:06AM -0800, Paul E. McKenney wrote:
> > ... unfortunately even for shared locks, the compiler does not like
> > re-entrancy yet. It's not yet supported, and to fix that I'd have to go
> > and implement that in Clang first before coming back to this.
>
> This would be
On Fri, Feb 07, 2025 at 10:32:25AM +0100, Marco Elver wrote:
> On Fri, Feb 07, 2025 at 09:28AM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 06, 2025 at 07:09:56PM +0100, Marco Elver wrote:
> > > Just like the pairing of attribute __acquires() with a matching
> > > fu
On Thu, Feb 06, 2025 at 07:48:38PM +0100, Marco Elver wrote:
> On Thu, 6 Feb 2025 at 19:40, Bart Van Assche wrote:
> >
> > On 2/6/25 10:09 AM, Marco Elver wrote:
> > > +/* Sparse context/lock checking support. */
> > > +# define __must_hold(x) __attribute__((context(x,1,1)))
> > > +#
On Thu, Feb 06, 2025 at 07:10:05PM +0100, Marco Elver wrote:
> extern int __must_check mutex_lock_interruptible_nested(struct mutex *lock,
> + unsigned int subclass)
> __cond_acquires(0, lock);
> extern int __must_check mutex_lock_killable_nested(struct mutex
On Thu, Feb 06, 2025 at 07:09:56PM +0100, Marco Elver wrote:
> Just like the pairing of attribute __acquires() with a matching
> function-like macro __acquire(), the attribute __cond_acquires() should
> have a matching function-like macro __cond_acquire().
>
> To be consistent, rename __cond_lock(
arch/x86/crypto/sha512-ssse3-asm.S | 41 +--
> tools/objtool/check.c| 14 ++-
> 11 files changed, 98 insertions(+), 111 deletions(-)
One nit, there's lots and lots of:
mov %rbp, %rsp
pop %rbp
and we have this 'leave' instruction that does exactly that, should we
be using it?
Otherwise:
Acked-by: Peter Zijlstra (Intel)
On Wed, Feb 24, 2021 at 10:29:17AM -0600, Josh Poimboeuf wrote:
> Use RBP instead of R14 for saving the old stack pointer before
> realignment. This resembles what compilers normally do.
>
> This enables ORC unwinding by allowing objtool to understand the stack
> realignment.
>
> Signed-off-by:
On Fri, Dec 18, 2020 at 06:01:01PM +0100, Ard Biesheuvel wrote:
> [ TL;DR for the non-ARM folks on CC: disabling softirq processing when using
> SIMD in kernel mode could reduce complexity and improve performance, but we
> need to decide whether we can do this, and how much softirq processing
>
On Mon, Jan 11, 2021 at 07:36:20PM +0100, Ard Biesheuvel wrote:
> On Mon, 11 Jan 2021 at 18:27, Ard Biesheuvel wrote:
> > On Mon, 11 Jan 2021 at 17:52, Ard Biesheuvel wrote:
> > > Special request to Peter to take a look at patch #2, and in particular,
> > > whether synchronize_rcu_tasks() is suf
On Fri, Dec 18, 2020 at 10:34:28AM +, Bae, Chang Seok wrote:
>
> > On Dec 18, 2020, at 19:11, Peter Zijlstra wrote:
> >
> > *groan*, so what actual version of binutils is needed and why is this
> > driver important enough to build on ancient crud to warrant all
On Wed, Dec 16, 2020 at 09:41:45AM -0800, Chang S. Bae wrote:
> diff --git a/arch/x86/include/asm/inst.h b/arch/x86/include/asm/inst.h
> index bd7f02480ca1..b719a11a2905 100644
> --- a/arch/x86/include/asm/inst.h
> +++ b/arch/x86/include/asm/inst.h
> @@ -122,9 +122,62 @@
> #endif
> .endm
>
On Wed, Dec 16, 2020 at 09:41:44AM -0800, Chang S. Bae wrote:
> + /* ENCODEKEY128 %EAX */
> + asm volatile (".byte 0xf3, 0xf, 0x38, 0xfa, 0xc0");
This is lacking a binutils version number. Boris, didn't you do a
checkpatch.pl thing for that?
On Thu, Dec 17, 2020 at 12:58:34PM -0800, Dave Hansen wrote:
> On 12/16/20 9:41 AM, Chang S. Bae wrote:
> > +config CRYPTO_AES_KL
> > + tristate "AES cipher algorithms (AES-KL)"
> > + depends on X86_KEYLOCKER
> > + select CRYPTO_AES_NI_INTEL
> > + help
> > + Use AES Key Locker instructi
On Mon, Dec 14, 2020 at 11:59:52AM +0800, Tony W Wang-oc wrote:
Didn't I mention something about a comment?
> static const struct x86_cpu_id crc32c_cpu_id[] = {
> + X86_MATCH_VENDOR_FAM_FEATURE(ZHAOXIN, 0x6, X86_FEATURE_XMM4_2, 1),
> + X86_MATCH_VENDOR_FAM_MODEL_FEATURE(ZHAOXIN, 0x7, 0x1
On Fri, Dec 11, 2020 at 07:29:04PM +0800, Tony W Wang-oc wrote:
> The driver crc32c-intel match CPUs supporting X86_FEATURE_XMM4_2.
> On platforms with Zhaoxin CPUs supporting this X86 feature, When
> crc32c-intel and crc32c-generic are both registered, system will
> use crc32c-intel because its .c
On Wed, Oct 21, 2020 at 11:58:25AM -0700, Joe Perches wrote:
> Like the __section macro, the __alias macro uses
> macro # stringification to create quotes around
> the section name used in the __attribute__.
>
> Remove the stringification and add quotes or a
> stringification to the uses instead.
On Tue, Aug 06, 2019 at 05:43:47PM +0200, Borislav Petkov wrote:
> On Tue, Jul 30, 2019 at 12:12:44PM -0700, Thomas Garnier wrote:
> > These patches make some of the changes necessary to build the kernel as
> > Position Independent Executable (PIE) on x86_64. Another patchset will
> > add the PIE o
Xu
Cc: "David S. Miller"
Cc: linux-crypto@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Thomas Gleixner
Signed-off-by: Peter Zijlstra (Intel)
---
crypto/crypto_engine.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/crypto/crypto_engine.c
+++ b/crypto/crypt
On Tue, Jul 16, 2019 at 09:18:07PM +0800, Herbert Xu wrote:
> On Tue, Jul 16, 2019 at 03:15:20PM +0200, Peter Zijlstra wrote:
> >
> > > @@ -367,7 +368,7 @@ void padata_do_serial(struct padata_priv *padata)
> > > struct parallel_data *pd;
> > > int re
On Tue, Jul 16, 2019 at 08:57:04PM +0800, Herbert Xu wrote:
> On Tue, Jul 16, 2019 at 01:14:10PM +0200, Steffen Klassert wrote:
> >
> > Maybe we can fix it if we call padata_free_pd() from
> > padata_serial_worker() when it sent out the last object.
>
> How about using RCU?
>
> We still need to f
On Tue, Jul 16, 2019 at 02:53:09PM +0200, Andrea Parri wrote:
> C daniel-padata
>
> { }
>
> P0(atomic_t *reorder_objects, spinlock_t *pd_lock)
> {
> int r0;
>
> spin_lock(pd_lock);
> spin_unlock(pd_lock);
> smp_mb();
> r0 = atomic_read(reorder_objects);
> }
>
> P1
On Fri, Oct 05, 2018 at 10:13:25AM +0200, Ard Biesheuvel wrote:
> diff --git a/include/linux/ffp.h b/include/linux/ffp.h
> new file mode 100644
> index ..8fc3b4c9b38f
> --- /dev/null
> +++ b/include/linux/ffp.h
> @@ -0,0 +1,43 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef
On Fri, Oct 05, 2018 at 10:13:25AM +0200, Ard Biesheuvel wrote:
> Add a function pointer abstraction that can be implemented by the arch
> in a manner that avoids the downsides of function pointers, i.e., the
> fact that they are typically located in a writable data section, and
> their vulnerabili
On Sat, Dec 02, 2017 at 11:15:14AM +, Ard Biesheuvel wrote:
> On 2 December 2017 at 09:11, Ard Biesheuvel wrote:
> > They consume the entire input in a single go, yes. But making it more
> > granular than that is going to hurt performance, unless we introduce
> > some kind of kernel_neon_yiel
On Sat, Dec 02, 2017 at 09:11:46AM +, Ard Biesheuvel wrote:
> On 2 December 2017 at 09:01, Peter Zijlstra wrote:
> > On Fri, Dec 01, 2017 at 09:19:22PM +, Ard Biesheuvel wrote:
> >> Note that the remaining crypto drivers simply operate on fixed buffers, so
> >
On Fri, Dec 01, 2017 at 09:19:22PM +, Ard Biesheuvel wrote:
> Note that the remaining crypto drivers simply operate on fixed buffers, so
> while the RT crowd may still feel the need to disable those (and the ones
> below as well, perhaps), they don't call back into the crypto layer like
> the o
On Fri, Mar 24, 2017 at 02:50:24PM +0100, Dmitry Vyukov wrote:
> OK, I guess should not have referenced the llvm-linux page.
> So here are reasons on our side that I am ready to vouch:
>
> - clang make it possible to implement KMSAN (dynamic detection of
> uses of uninit memory)
How does GCC mak
On Fri, Mar 24, 2017 at 02:47:15PM +0100, Dmitry Vyukov wrote:
> > Seriously, you should have taken the hack the first time that this
> > needs to be fixed. Just because this is a fairly uncommon construct
> > in the kernel doesn't mean it is not in userspace.
>
> There is a reason why it is fair
On Fri, Mar 17, 2017 at 08:05:16PM +0100, Dmitry Vyukov wrote:
> You can also find some reasons in the Why section of LLVM-Linux project:
> http://llvm.linuxfoundation.org/index.php/Main_Page
>From that:
- LLVM/Clang is a fast moving project with many things fixed quickly
and features added.
On Fri, Mar 17, 2017 at 08:26:42PM +0100, Peter Zijlstra wrote:
> On Fri, Mar 17, 2017 at 08:05:16PM +0100, Dmitry Vyukov wrote:
> > You can also find some reasons in the Why section of LLVM-Linux project:
> > http://llvm.linuxfoundation.org/index.php/Main_Page
>
> From tha
On Fri, Mar 17, 2017 at 11:52:01AM -0700, Michael Davidson wrote:
> On Fri, Mar 17, 2017 at 5:44 AM, Peter Zijlstra wrote:
> >
> > Be that as it may; what you construct above is disgusting. Surely the
> > code can be refactored to not look like dog vomit?
> >
> >
On Fri, Mar 17, 2017 at 01:31:23PM +0100, Alexander Potapenko wrote:
> On Fri, Mar 17, 2017 at 1:08 PM, Peter Zijlstra wrote:
> > On Thu, Mar 16, 2017 at 05:15:19PM -0700, Michael Davidson wrote:
> >> Replace a variable length array in a struct by allocating
> >> the m
On Thu, Mar 16, 2017 at 05:15:19PM -0700, Michael Davidson wrote:
> Replace a variable length array in a struct by allocating
> the memory for the entire struct in a char array on the stack.
>
> Signed-off-by: Michael Davidson
> ---
> drivers/md/raid10.c | 9 -
> 1 file changed, 4 insert
On Thu, Mar 16, 2017 at 05:15:18PM -0700, Michael Davidson wrote:
> Use the standard regparm=0 calling convention for memcpy and
> memset when building with clang.
>
> This is a work around for a long standing clang bug
> (see https://llvm.org/bugs/show_bug.cgi?id=3997) where
> clang always uses t
On Thu, Dec 15, 2016 at 09:43:04PM +0100, Jason A. Donenfeld wrote:
> On Thu, Dec 15, 2016 at 9:31 PM, Hannes Frederic Sowa
> wrote:
> > ARM64 and x86-64 have memory operations that are not vector operations
> > that operate on 128 bit memory.
>
> Fair enough. imull I guess.
imull is into rdx:ra
On Thu, Dec 15, 2016 at 07:50:36PM +0100, Jason A. Donenfeld wrote:
> There's no 32-bit platform
> that will trap on a 64-bit unaligned access because there's no such
> thing as a 64-bit access there. In short, we're fine.
ARMv7 LPAE is a 32bit architecture that has 64bit load/stores IIRC.
x86 ha
On Thu, Sep 17, 2015 at 01:32:55PM -0700, Tim Chen wrote:
> I have no objection to change single_task_running to use
> raw_smp_processor_id. The worker in mcryptd is bound to
> the cpu so it has no migration/preemption issue. So it shouldn't care
> which smp_processor_id version is being used. Y
On Mon, 2015-06-08 at 17:52 +0200, Stephan Mueller wrote:
> Am Monday 08 June 2015, 14:36:30 schrieb Peter Zijlstra:
>
> Hi Peter,
> >
> >Would something like
> >
> >#pragma GCC push_options
> >#pragma GCC optimize ("-O0")
> >stati
Adding Stephan to Cc.
On Mon, 2015-06-08 at 20:25 +0800, Herbert Xu wrote:
> On Mon, Jun 08, 2015 at 03:21:09PM +0300, Andy Shevchenko wrote:
> > On Fri, May 29, 2015 at 10:14 PM, Jim Davis wrote:
> > > Building with the attached random configuration file,
> >
> > Hit the very same error against
On Tue, Jul 29, 2014 at 03:28:25PM -0700, Tim Chen wrote:
> Peter,
>
> Is my explanation adequate or you still have objection to the implementation?
> I'm
> trying to decide here whether to extend our batch processing by
> the crypto daemon (prolong our busy period)
> based on whether there are
On Tue, Jul 22, 2014 at 03:09:32PM -0700, Tim Chen wrote:
> This patch introduces the multi-buffer crypto daemon which is responsible
> for submitting crypto jobs in a work queue to the responsible multi-buffer
> crypto algorithm. The idea of the multi-buffer algorihtm is to put
> data streams fro
On Tue, Jul 22, 2014 at 03:09:35PM -0700, Tim Chen wrote:
> The crypto daemon can take advantage of available cpu
> cycles to flush any unfinished jobs if it is the
> only task running on the cpu, and there are no more crypto
> jobs to process.
You conveniently forgot to mention energy efficiency,
On Tue, Jul 22, 2014 at 03:09:32PM -0700, Tim Chen wrote:
> +/* Called in workqueue context, do one real cryption work (via
> + * req->complete) and reschedule itself if there are more work to
> + * do. */
You seem to manage the 'normal' comment style in other places, this one
'special' for a reas
On Tue, Jul 15, 2014 at 08:06:55PM +0200, Mike Galbraith wrote:
> On Tue, 2014-07-15 at 16:53 +0200, Peter Zijlstra wrote:
> > On Tue, Jul 15, 2014 at 04:45:25PM +0200, Mike Galbraith wrote:
> > >
> > > 3.0.101-default3.753363 usecs/loop -- avg 3.7707
On Tue, Jul 15, 2014 at 11:21:49AM -0400, Tejun Heo wrote:
> On Tue, Jul 15, 2014 at 03:36:27PM +0200, Peter Zijlstra wrote:
> > So, just to expand on this, we're already getting 'bug' reports because
> > worker threads are not cgroup aware. If work gets generat
On Tue, Jul 15, 2014 at 04:45:25PM +0200, Mike Galbraith wrote:
>
> 3.0.101-default3.753363 usecs/loop -- avg 3.770737 530.4 KHz 1.000
> 3.14.10-default4.145348 usecs/loop -- avg 4.139987 483.1 KHz.910
>1.000
> 3.15.4-default 4.355594 usecs/loop -- avg 4.351961
On Mon, Jul 14, 2014 at 09:15:04PM +0200, Peter Zijlstra wrote:
> I still loathe all the async work, because it makes a mockery of
> accounting etc.. but that's a story for another day I suppose :-(
So, just to expand on this, we're already getting 'bug' reports beca
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 already done a large part of the ex
On Mon, Jul 14, 2014 at 12:50:50PM -0700, Tim Chen wrote:
> There is a generic multi-buffer infrastructure portion that manages
> pulling and queuing jobs on the crypto workqueue, and it is separated out
> in patch 1 of the patchset.
There's one very weird multi-line comment in that patch.
> The
On Mon, Jul 14, 2014 at 12:08:28PM -0700, Tim Chen wrote:
> On Mon, 2014-07-14 at 20:17 +0200, Peter Zijlstra wrote:
> > Your multi-buffer thing isn't generic either, it seems lmiited to sha1.
>
> We actually have many other multi-buffer crypto algorithms already
> publi
On Mon, Jul 14, 2014 at 10:05:34AM -0700, Tim Chen wrote:
> I was trying to explain why the algorithm is implemented this way
> because of its batching nature.
>
> There is a whole class of async algorithm that can provide
> substantial speedup by doing batch processing and uses workqueue.
> The m
On Mon, Jul 14, 2014 at 09:10:14AM -0700, Tim Chen wrote:
> On Mon, 2014-07-14 at 12:16 +0200, Peter Zijlstra wrote:
> > On Fri, Jul 11, 2014 at 01:33:04PM -0700, Tim Chen wrote:
> > > This function will help a thread decide if it wants to to do work
> > > that can be
On Fri, Jul 11, 2014 at 01:33:04PM -0700, Tim Chen wrote:
> This function will help a thread decide if it wants to to do work
> that can be delayed, to accumulate more tasks for more efficient
> batch processing later.
>
> However, if no other tasks are running on the cpu, it can take
> advantgae
On Mon, 2011-09-12 at 09:56 -0400, Jarod Wilson wrote:
> Thomas Gleixner wrote:
> > Well, there is enough prove out there that the hardware you're using
> > is a perfect random number generator by itself.
> >
> > So stop complaining about not having access to TPM chips if you can
> > create an ent
On Fri, 2011-08-26 at 12:42 -0700, Andrew Morton wrote:
> Perhaps you could dust off your old patch and we'll bring it up to date?
most of it would be doing what mlin just did, so I took his patch and
went from there, the resulting delta is something like the below.
Completely untested... crypto
62 matches
Mail list logo
