accepted
padlock is
created
With the patch? I don't think so:
With the patch the following changes compared with 2.6.25:
* processes which do not use FPU/SSE will not start saving and loading there
xstate any more (and will not allocate xstate memory) if kernel is using
padlock with the crypto-framework. Its similar to other places where the
kernel uses MMX/SSE and protects them with kernel_fpu_begin();
kernel_fpu_end(); isn't it?
* if user space uses FPU/SSE its xstate will be saved though it is not really
necessary.
* the crypto-framework using padlock can not be preempted any more while
executing padlock-opcodes.
This is what Hebert fears.
What I'm not really understand - and Suresh probably could tell us - if with
2.6.25 and earlier the following could happen:
1) a process is using FPU/SSE so it has a saved xstate BUT its not loaded
because of lazy loading of FPU state (didn't use FPU/SSE for some time).
2) padlock usage by kernel without kernel_fpu_begin() kernel_fpu_end() sets
TS_USEDFPU of this task but its not loaded
3) in __switch_to() the process then saves its FPU/SSE state overwriting its
real xstate.
If I understand Suresh explanations correctly this could not happen.
The problem only exists at task creation time: a race between initialising
TS_USEDFPU, used_math()) and setting the xstate pointer to NULL.
So wouldn't this help:
* a flag TS_INITIALISING is set for this task bevor used_math and TS_USEDFPU
is set
* then math-state of the new task is initialisied including setting xstate to
NULL
* then the flag is cleared
* math_state_restore() in trap_32.c does nothing if this flag is set.
Another possibility would be to use xstate for tracking if math has ever be
used by this task and made TS_USEDFPU only valid if xtate != NULL
Both would only reestablish 2.6.25 behaviour.
But even if one or both would work its no solution for 2.6.26 (and probably
2.6.27). My trust in 2.6.26 increased enough to use it on desktops and I
would be a little bit nervous with such changes :-).
Yes that would be perfect. But fixing the race between math-state
initialisation and setting xtsate to NULL would be good enough. With ipsec
traffic some tasks would save and restore unecessarily its xstate (as it is
the case with 2.6.25 and earlier).
There is no way to know if it was the kernel who caused a math fault?
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
--
