On 01/09/2015 12:34 AM, Matthew Fortune wrote:
Leonid Yegoshin <Leonid.Yegoshin@xxxxxxxxxx> writes:
This piece of thread walking seems to be not thread safe for newly
created thread.
Thread creation is not locked between points of copy_thread which copies
task thread flags and makeing thread visible to walking via
"for_each_thread".
So it is possible in environment with two threads - one is creating an
another thread, another one switching FPU mode and waiting and race
condition may causes a newly thread in old mode but the rest of thread
group is in new mode.
Besides that, it looks like in kernel with tickless mode a scheduler may
no come a long time in idle system, in extreme case - forever.
Only commenting on the tickless issue... The requirement for the
PR_SET_FP_MODE call is that all threads in the current thread group switch
to the new mode prior to it returning. I believe that simply means there
is no alternative other than for the tickless case to wait as long as it
has to wait? If the prctl failed in tickless mode (or timed out) then that
is likely to lead to a program failing to load its libraries and aborting.
There is another design, which doesn't use walk through all thread group
and any scheduler wait.
It is based on IPI call to kick off threads-from-this-memory-map from
FPU usage in all CPUs and keeping/updating the real FPU mode flag in
memory map "context".
I have it and will post it to internal IMG mail list (currently, it
doesn't use "prctl" but "sysmips" syscall, and is designed around 3.10
kernel).
- Leonid.
