Re: math_state_restore and kernel_fpu_end disable interrupts?

["George Spelvin" <linux@horizon.com>]

Nate Eldredge wrote:
> On Sun, 19 Jan 2014, George Spelvin wrote:
>>> It's credited to Suresh Siddha, whom I've cc'ed (along with others who
>>> signed off).  Suresh, if you're still around, could you comment on why
>>> math_state_restore always leaves interrupts disabled, regardless of their
>>> state on entry?  Is there a deep reason or is it a bug?
>>
>> What the comments seemed to be implying was that it was a bug to enter
>> this code with interrupts enabled.  So the problem may be a little bit
>> more systemic; expert counsel is required.
>
> It would be kind of weird for code that requires disabled interrupts on 
> entry to turn around and enable interrupts itself.  I agree that it would 
> really help for a guru to take a look...

Actually, on second look, it appears the comments are just confused.
Suresh's patch appears to have just failed to consider the possibility
of calling math_state_restore with interrupts enabled, rather than
having made a deliberate choice.

> On which note, Suresh's email bounced :-(

I found a newer address.  Let's see if this works.  Suresh, here's
Nate's proposed patch:

--- linux-source-3.11.0/arch/x86/kernel/traps.c	2013-09-02 14:46:10.000000000 -0600
+++ linux-source-3.11.0-nate/arch/x86/kernel/traps.c	2014-01-19 11:25:32.977221476 -0700
@@ -624,6 +624,9 @@ asmlinkage void math_state_restore(void)
  	struct task_struct *tsk = current;

  	if (!tsk_used_math(tsk)) {
+		unsigned long flags;
+
+		local_save_flags(flags);
  		local_irq_enable();
  		/*
  		 * does a slab alloc which can sleep
@@ -635,7 +638,7 @@
  			do_group_exit(SIGKILL);
  			return;
  		}
-		local_irq_disable();
+		local_irq_restore(flags);
  	}

  	__thread_fpu_begin(tsk);


BTW, my test case to reliably trigger the fault is Firefox crashing.
It usually takes a few days for it to run out of memory.  It happened
once, with no problem, but I'd like to get one more before passing
judgement.  Still, feel free to consider this:

Tested-by: George Spelvin <linux@horizon.com>

It's the
Cc: <stable@vger.kernel.org> # 2.6.26+
I'm a bit anxious about.