linux-kernel - RE: [PATCH v4 10/24] crypto: x86/poly

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 6 Dec 2022 14:44:17 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Peter Lafreniere' <peter@...jl.ca>,
        Herbert Xu <herbert@...dor.apana.org.au>
CC:     "Elliott, Robert (Servers)" <elliott@....com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "tim.c.chen@...ux.intel.com" <tim.c.chen@...ux.intel.com>,
        "ap420073@...il.com" <ap420073@...il.com>,
        "ardb@...nel.org" <ardb@...nel.org>,
        "ebiggers@...nel.org" <ebiggers@...nel.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v4 10/24] crypto: x86/poly - limit FPU preemption

From: Peter Lafreniere
> Sent: 06 December 2022 14:04
>
> > > > BTW, just a minor nit but you can delete the cond_resched() call
> > > > because kernel_fpu_end()/preempt_enable() will do it anyway.
> > >
> > > That happens under
> > > CONFIG_PREEMPTION=y
> > > (from include/Linux/preempt.h and arch/x86/include/asm/preempt.h)
> > >
> > > Is calling cond_resched() still helpful if that is not the configuration?
> >
> >
> > Perhaps, but then again perhaps if preemption is off, maybe we
> > shouldn't even bother with the 4K split. Were the initial
> > warnings with or without preemption?
> >
> > Personally I don't really care since I always use preemption.
> >
> > The PREEMPT Kconfigs do provide a bit of nuance with the split
> > between PREEMPT_NONE vs. PREEMPT_VOLUNTARY. But perhaps that is
> > just overkill for our situation.
> 
> I was thinking about this a few days ago, and my 2¢ is that it's
> probably best to not preempt the kernel in the middle of a crypto
> operation under PREEMPT_VOLUNTARY. We're already not preempting during
> these operations, and there haven't been complaints of excessive latency
> because of these crypto operations.
...

Probably because the people who have been suffering from (and
looking for) latency issues aren't running crypto tests.

I've found some terrible pre-emption latency issues trying
to get RT processes scheduled in a sensible timeframe.
I wouldn't worry about 100us - I'm doing audio processing
every 10ms, but anything much longer causes problems when
trying to use 90+% of the cpu time for lots of audio channels.

I didn't try a CONFIG_RT kernel, the application needs to run
on a standard 'distro' kernel. In any case I suspect all the
extra processes switches (etc) the RT kernel adds will completely
kill performance.

I wonder how much it would cost to measure the time spent with
pre-empt disabled (and not checked) and to trace long intervals.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)