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  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:	Wed, 10 Dec 2014 17:53:44 -0800
From:	Andy Lutomirski <>
To:	Rik van Riel <>
Cc:	Daniel J Blueman <>,
	Linux Kernel <>,
	Linus Torvalds <>,
	"H. Peter Anvin" <>
Subject: Re: [PATCH, 3.18] sleeping function called from invalid context

On Wed, Dec 10, 2014 at 5:32 PM, Rik van Riel <> wrote:
> Hash: SHA1
> On 12/10/2014 07:51 PM, Andy Lutomirski wrote:
>> On Wed, Dec 10, 2014 at 4:49 PM, Rik van Riel <>
>> wrote: On 12/10/2014 07:46 PM, Daniel J Blueman wrote:
>>>>> Gah. I had some non-temporal copy changes in the wrong tree.
>>>>> I'll check with a definitely clean tree and follow up if it
>>>>> still occurs.
>> The exception handlers should definitely allow sleeping, so I
>> suspect those changes may be related.
>>> It would be really, really nice if we could arrange for
>>> kernel_fpu_begin to be unconditionally usable in anything except
>>> NMI context.  The crypto code would be much less scary, we could
>>> make non-temporal copies safe, etc.  Can we have ponies, too?
> Isn't it already?
> I see nothing in __kernel_fpu_begin that looks like it would
> ever need to sleep.

It never needs to sleep, but it does need somewhere to save the
previous state.  See irq_fpu_usable.

FWIW, I don't understand what the comments above
interrupted_kernel_fpu_idle are talking about.  The issue that I
understand is:


  use xstate

we're screwed now :(


IOW we need somewhere to put the state from the thing we interrupted.
This gets extra fun if some thread does something that takes a page
fault that uses fpu that gets interrupted, etc.  Fortunately, I think
that can't happen -- kernel_fpu_begin disables preemption.  So I think
we have a maximum of one active FPU context per thread plus some
number per cpu.  Maybe we could have a percpu array of ten or twenty
xstates to handle all possible nesting.

Also, can we just delete the non-eager code some day?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists