Re: [PATCH 0/5] crypto: arm64 - disable NEON across scatterwalk API calls

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 > >

Re: [PATCH 0/5] crypto: arm64 - disable NEON across scatterwalk API calls

On Sat, Dec 02, 2017 at 09:11:46AM +, Ard Biesheuvel wrote: > On 2 December 2017 at 09:01, Peter Zijlstra <pet...@infradead.org> wrote: > > On Fri, Dec 01, 2017 at 09:19:22PM +, Ard Biesheuvel wrote: > >> Note that the remaining crypto drivers simply operate on fixe

Re: [PATCH 0/5] crypto: arm64 - disable NEON across scatterwalk API calls

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

Re: [PATCH 6/7] md/raid10, LLVM: get rid of variable length array

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

Re: [PATCH 6/7] md/raid10, LLVM: get rid of variable length array

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

Re: [PATCH 6/7] md/raid10, LLVM: get rid of variable length array

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.

Re: [PATCH 6/7] md/raid10, LLVM: get rid of variable length array

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

Re: [PATCH 6/7] md/raid10, LLVM: get rid of variable length array

On Fri, Mar 17, 2017 at 11:52:01AM -0700, Michael Davidson wrote: > On Fri, Mar 17, 2017 at 5:44 AM, Peter Zijlstra <pet...@infradead.org> wrote: > > > > Be that as it may; what you construct above is disgusting. Surely the > > code can be refactored to not look like d

Re: [PATCH 6/7] md/raid10, LLVM: get rid of variable length array

On Fri, Mar 17, 2017 at 01:31:23PM +0100, Alexander Potapenko wrote: > On Fri, Mar 17, 2017 at 1:08 PM, Peter Zijlstra <pet...@infradead.org> wrote: > > On Thu, Mar 16, 2017 at 05:15:19PM -0700, Michael Davidson wrote: > >> Replace a variable length array in a struct by al

Re: [PATCH 6/7] md/raid10, LLVM: get rid of variable length array

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

Re: [PATCH 5/7] x86, boot, LLVM: Use regparm=0 for memcpy and memset

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

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

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

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

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

Re: single_task_running() vs. preemption warnings (was Re: [PATCH] kvm: fix preemption warnings in kvm_vcpu_block)

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.

Re: randconfig build error with next-20150529, in crypto/jitterentropy.c

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 jim.ep...@gmail.com wrote: Building with the attached random configuration file, Hit the very same

Re: [PATCH v5 2/7] crypto: SHA1 multibuffer crypto hash infrastructure

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 other

Re: [PATCH v5 2/7] crypto: SHA1 multibuffer crypto hash infrastructure

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 reason?

Re: [PATCH v5 3/7] crypto: SHA1 multibuffer crypto opportunistic flush

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,

Re: [PATCH v5 2/7] crypto: SHA1 multibuffer crypto hash infrastructure

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 from

Re: [PATCH v4 6/7] sched: add function nr_running_cpu to expose number of tasks running on cpu

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

Re: [PATCH v4 6/7] sched: add function nr_running_cpu to expose number of tasks running on cpu

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 expense of going idle

Re: [PATCH v4 6/7] sched: add function nr_running_cpu to expose number of tasks running on cpu

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

Re: [PATCH v4 6/7] sched: add function nr_running_cpu to expose number of tasks running on cpu

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 delayed, to accumulate more tasks

Re: [PATCH v4 6/7] sched: add function nr_running_cpu to expose number of tasks running on cpu

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

Re: [PATCH v4 6/7] sched: add function nr_running_cpu to expose number of tasks running on cpu

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 published for encryption and other

Re: [PATCH] random: add blocking facility to urandom

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 entropy

Re: [PATCH 1/2] mm: convert k{un}map_atomic(p, KM_type) to k{un}map_atomic(p)

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