Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756371AbcJ1HTX (ORCPT ); Fri, 28 Oct 2016 03:19:23 -0400 Received: from mailapp01.imgtec.com ([195.59.15.196]:59486 "EHLO mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752022AbcJ1HTW (ORCPT ); Fri, 28 Oct 2016 03:19:22 -0400 Date: Fri, 28 Oct 2016 08:19:10 +0100 From: "Maciej W. Rozycki" To: Ralf Baechle CC: Paul Burton , James Hogan , , Subject: [PATCH 0/2] More FCSR handling fixes Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [10.20.78.229] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1896 Lines: 40 Hi, Here are some further fixes to our FCSR handling. Just 2 changes at this time. The first, very small one, closes an issue where a write made with ptrace(PTRACE_POKEUSR, ...) to FCSR does not mark the FP context as used. This is the legacy interface, seldom used these days, having been largely replaced with ptrace(PTRACE_SETFPREGS, ...), so the problem may have escaped easily. Fixed now. The second, larger one, addresses the handling of the Cause bits, by letting them remain set in some cases, making their semantics more consistent with what hardware does when undisturbed; a SIGFPE signal is sent if appropriate where previously it was missed. This change is not final as in some cases, specifically in the FP context of SIGFPE's signal frame, active Cause bits that match Enable bits will still be recorded as clear even though they were originally set, being the reason for the signal. Consequently the signal will not retrigger if the handler returns with the FP context unchanged in the signal frame. This is unlike with other signals triggered by a hardware exception which do require a corrective action if a return is intended rather than an escape via `longjmp' or suchlike and which is what one would expect here as well. I plan to address this final issue with a further change in the future, however I have not started this effort yet and I don't have a schedule set. Meanwhile this change is I believe a step in the right direction. Details of both changes have been provided with individual patch descriptions. While making these changes I have noticed a bunch of bitrot issues we have with the handling of the FP context in signal frames with MIPS I-II processors. I will submit corrections as a separate patch series. Questions or comments are welcome, as usually, and otherwise please queue for the next merge cycle. Maciej