From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S966257AbcDML1e (ORCPT <rfc822;w@1wt.eu>);
	Wed, 13 Apr 2016 07:27:34 -0400
Received: from mx1.redhat.com ([209.132.183.28]:49074 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S964912AbcDML1d (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 13 Apr 2016 07:27:33 -0400
Date: Wed, 13 Apr 2016 12:25:56 +0200
From: Oleg Nesterov <oleg@redhat.com>
To: Jianyu Zhan <nasa4836@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>, mingo@redhat.com,
        "H. Peter Anvin" <hpa@zytor.com>, suresh.b.siddha@intel.com,
        x86@kernel.org, LKML <linux-kernel@vger.kernel.org>,
        Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>,
        Thomas Gleixner <tglx@linutronix.de>, Dave Hansen <dave@sr71.net>
Subject: Re: Possible race in copy of fpu->state in copy_process against
	the exeve'ing parent?
Message-ID: <20160413102556.GA21962@redhat.com>
References: <CAHz2CGXb1AW5DaGd9=vzkLdP2X9fep36H913ChyJEtd6UUtzVA@mail.gmail.com> <20160413060943.GA4705@gmail.com> <CAHz2CGVtLwWE8gEQB14wtYbX4w46+bHfJA3Qr5PmGzeY4d1jhA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHz2CGVtLwWE8gEQB14wtYbX4w46+bHfJA3Qr5PmGzeY4d1jhA@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.