Re: MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS

[Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>]

On 01/09/2015 12:34 AM, Matthew Fortune wrote:
> Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> 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.