Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state changes

[Suresh Siddha <suresh.b.siddha@intel.com>]

On Sat, Aug 09, 2008 at 08:57:32AM -0700, Wolfgang Walter wrote:
> On Saturday 09 August 2008, Herbert Xu wrote:
> > On Fri, Aug 08, 2008 at 04:11:21PM -0700, Suresh Siddha wrote:
> > >
> > > With out the recent dynamic fpu allocation changes, while we don't see
> oops,
> > > there is a possible race still present in older kernels(for example,
> > > while kernel is using kernel_fpu_begin() in some optimized clear/copy
> > > page and an interrupt/softirq happens which uses these padlock
> > > instructions generating DNA fault).
> >
> > No this wasn't a problem because kernel_fpu_begin clears TS and
> > therefore we don't get faults on SSE instructions.
> >
> > However, with your patch it will become a problem due to the
> > fact that it wasn't designed to be nested.
> >
> I don't exactly understand this. You think that
> 
> kernel_fpu_begin();
> XCRYPT....
> kernel_fpu_end();
> 
> is a problem and wasn't before?

Wolf, kernel_fpu_begin() and kernel_fpu_end() only saves the user
state from getting corrupted with the kernel state. But it doesn't
help if kernel has nesting fpu usage.

In this padlock case with the patch, we may encounter a nested
kernel_fpu_begin() and end()
but this is ok, as the padlock is not actually touching fpu/sse registers.

Yes, we do have a problem when the interrupt handlers also use SSE
registers and if there is a nesting inside the kernel. Today we don't
have any such usage.

> If XCRYPT may be interrupted and the interrupt code again uses this optimized
> memcpy implementation and so nesting kernel_fpu_begin then why should this
> not happen with the other alg.
> 
> How could any kernel code use MMX/SSE/FPU when the interrupt case isn't
> handled?

Today we don't have any nesting, for example, fast memcpy, if in interrupt
will use the slow version and doesnt use the optimized version.

thanks,
suresh