Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 19 Jul 2018 13:56:30 -0700
From:   Paul Burton <paul.burton@mips.com>
To:     "Maciej W. Rozycki" <macro@mips.com>
Cc:     Alexander Viro <viro@zeniv.linux.org.uk>,
        James Hogan <jhogan@kernel.org>,
        Ralf Baechle <ralf@linux-mips.org>,
        linux-fsdevel@vger.kernel.org, linux-mips@linux-mips.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] MIPS: DSP ASE regset support
Message-ID: <20180719205630.osfdzk7gqv4djvqc@pburton-laptop>
References: <alpine.DEB.2.00.1804301557320.11756@tp.orcam.me.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1804301557320.11756@tp.orcam.me.uk>
User-Agent: NeoMutt/20180622
Received-SPF: None (protection.outlook.com: wavecomp.com does not designate
 permitted sender hosts)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jul 2018 20:56:34.8411 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0dd747d7-2a35-4344-49bc-08d5edba1d1a
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 463607d3-1db3-40a0-8a29-970c56230104
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR08MB4929
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Maciej,

On Tue, May 15, 2018 at 11:32:11PM +0100, Maciej W. Rozycki wrote:
>  For years, quite oddly, we have been missing DSP ASE register state from 
> core files.  These days regsets are used to define what goes into a core 
> file, so here's a change adding one.
> 
>  As a side effect ptrace(2) can now also access this regset, however no 
> complementing client implementation has been made.  Eventually that'll 
> have to change though so that DSP ASE registers can be correctly accessed 
> in n32 processes, which suffer from ptrace(2) 32-bit data types truncating 
> contents exchanged by PTRACE_PEEKUSR and PTRACE_POKEUSR requests with 
> 64-bit registers and no means defined to access partial registers via this 
> API.
> 
>  In the course of this implementation I came across two bugs affecting the 
> area being updated and hence this has become a small patch series with the 
> audience wider than originally expected.
> 
>  See individual commit descriptions for the details of changes made.  
> 
>  NB there is no strict functional dependency between 1/3 and 2/3-3/3, so 
> the order of commits does not have to be preserved as far as these two 
> subsets are concerned.  However 3/3 does trigger the problem addressed 
> with 1/3 (and gracefully handles it), hence the grouping in a series.
> 
>  Please apply.

Thanks - applied to mips-next for 4.19, though I removed the stable tags
on patches 1/3 & 3/3 & it's worth noting that the ELF note numbers are
changed to from 0x70X to 0x80X, since 0x700 has been used already.

If you really care about a stable backport for 3/3 let's talk, but I'm
doubtful as to its use when we've been missing this for so long.

Paul