On Mon, Mar 19, 2018 at 11:31:24PM +0800, Ard Biesheuvel wrote:
>
> Apologies if this wasn't clear, but there are some cross dependencies
> with the arm64 tree, which receives non-trivial modifications in
> patches 10 and 11, which are subsequently depended upon by patches 12
> - 23.
>
> Without
On 16 March 2018 at 23:57, Herbert Xu wrote:
> On Sat, Mar 10, 2018 at 03:21:45PM +, Ard Biesheuvel wrote:
>> As reported by Sebastian, the way the arm64 NEON crypto code currently
>> keeps kernel mode NEON enabled across calls into skcipher_walk_xxx() is
>>
On Sat, Mar 10, 2018 at 03:21:45PM +, Ard Biesheuvel wrote:
> As reported by Sebastian, the way the arm64 NEON crypto code currently
> keeps kernel mode NEON enabled across calls into skcipher_walk_xxx() is
> causing problems with RT builds, given that the skcipher walk API may
> allocate and
us...@vger.kernel.org; Peter Zijlstra <pet...@infradead.org>; Catalin
>> Marinas <catalin.mari...@arm.com>; Will Deacon
>> <will.dea...@arm.com>; Steven Rostedt <rost...@goodmis.org>; Thomas
>> Gleixner <t...@linutronix.de>
>> Subject: [PATCH
lt;rost...@goodmis.org>; Thomas
> Gleixner <t...@linutronix.de>
> Subject: [PATCH v5 00/23] crypto: arm64 - play nice with CONFIG_PREEMPT
>
> As reported by Sebastian, the way the arm64 NEON crypto code currently
> keeps kernel mode NEON enabled across calls into skcipher_w
As reported by Sebastian, the way the arm64 NEON crypto code currently
keeps kernel mode NEON enabled across calls into skcipher_walk_xxx() is
causing problems with RT builds, given that the skcipher walk API may
allocate and free temporary buffers it uses to present the input and
output arrays to