From patchwork Mon Dec 10 22:13:28 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aurelien Jarno X-Patchwork-Id: 10722683 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 3E082159A for ; Mon, 10 Dec 2018 22:14:16 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 28CEC2A910 for ; Mon, 10 Dec 2018 22:14:16 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1CCCE2A915; Mon, 10 Dec 2018 22:14:16 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id AAD962A910 for ; Mon, 10 Dec 2018 22:14:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: MIME-Version:Message-ID:Subject:To:From:Date:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Owner; bh=7Ryv9/BI4S0a/VbMz7bSwYTFbF1E0wWMf/+QdX1qKts=; b=sRL X0eBALcrlW6Q5opKk+YLxK5XnND5q9AI5cEX9ZioQnyVyNCnue8MGbAXYd1ixlps42dlTMvqgPA7B 9LomlyTvgq+cwfOjMA8DlKIfJ8NUWaLVn/WYnce5NsQPsp7gQlT+6BShXb0cuLMnipiq7OOBECqZP Q4iGPqaRs5zKikEkcDNf63ZGoJeL8VhzQlgJV6zI9gerDPlwzn+pQoXpyvp0AHifJviWsydVQt0+O IR1qtRI6pICr7B8HZ8JHKtWO10urUDvdIYheFjwwpg2OmjE2murBOYpAAnVV7VjQlc0H77WBv6ggH L+GsBrFf09i37Dy4NAX/13e8SI/SkNQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gWToa-0005YZ-5P; Mon, 10 Dec 2018 22:14:12 +0000 Received: from hall.aurel32.net ([2001:bc8:30d7:100::1]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gWToE-00059D-Gi for linux-riscv@lists.infradead.org; Mon, 10 Dec 2018 22:13:53 +0000 Received: from aurel32 by hall.aurel32.net with local (Exim 4.89) (envelope-from ) id 1gWTns-0001aO-VS for linux-riscv@lists.infradead.org; Mon, 10 Dec 2018 23:13:28 +0100 Date: Mon, 10 Dec 2018 23:13:28 +0100 From: Aurelien Jarno To: linux-riscv@lists.infradead.org Subject: BUG: FP registers leak across execve Message-ID: <20181210221328.fdl2eoe5cqxudgfs@aurel32.net> MIME-Version: 1.0 User-Agent: NeoMutt/20170113 (1.7.2) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20181210_141350_686584_EEF6760F X-CRM114-Status: UNSURE ( 5.65 ) X-CRM114-Notice: Please train this message. X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-riscv" Errors-To: linux-riscv-bounces+patchwork-linux-riscv=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP Hi all, Debugging some glibc testsuite math failures, I have found out that most of the time, the FP status register and the FP registers are not zeroed as they should. This can be tested with the attached code. The best way to reproduce it is to execute from Python (i guess Perl or another interpreted language that support FP computation should work). When running an FP computation before calling the program, the result of the computation can be seen in f10. The zeroing of the FP status happens in kernel/process.c in the flush_thread function. It seems that the kernel restore that state only if a context switch happens between flush_thread and the first FP instruction of the executed program. A possible workaround is to restore of the FP registers in flush_thread, but that's probably not the best way to do that: Aurelien --- a/arch/riscv/kernel/process.c +++ b/arch/riscv/kernel/process.c @@ -93,6 +93,7 @@ void flush_thread(void) * fflags: accrued exceptions cleared */ memset(¤t->thread.fstate, 0, sizeof(current->thread.fstate)); + fstate_restore(current, task_pt_regs(current)); #endif }