Re: Possible race in copy of fpu->state in copy_process against the exeve'ing parent?

[Oleg Nesterov <oleg@redhat.com>]

On 04/13, Jianyu Zhan wrote:
>
> From the panic stack trace, we can infer the call path before panic:
>
>
>         sys_clone
>           do_fork
>              copy_process
>                 dup_task_struct(current)
>                    prepare_to_copy(current)
>                       unlazy_fpu(current)
>                          __save_init_fpu(current)
>                            fpu_save_init(current)
>                              fpu_xsave(&current->thread.fpu) <---- PANIC
>
>
> In this case , &thread.fpu.state is NULL, so it caused a write to
> NULL address fault,

Yes, but iirc fpu.state == NULL is not a problem. The problem is that
TS_USEDFPU is set while it should not.

>       sys_execve
>          do_execve
>            do_execve_common
>              search_binary_handler
>                 load_elf_binary
>                   start_thread
>                     start_thread_common
>                        free_thread_xstate(current)
>                          fpu_free(&current->thread.fpu)
>                             fpu->state = NULL

Yes, but note that exec path also calls flush_thread() which clears TS_USEDFPU.

Yes, this is confusing, and we had a lot bugs in this area. To be honest I didn't
even try to recall how this (very old) code works, sorry... So I can't say what
exactly could explain the wrong TS_USEDFPU.

Oleg.