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:   Tue, 28 Nov 2017 11:31:33 -0800
From:   Paul Burton <paul.burton@mips.com>
To:     "Maciej W. Rozycki" <macro@mips.com>
CC:     Ralf Baechle <ralf@linux-mips.org>,
        James Hogan <james.hogan@mips.com>,
        <linux-mips@linux-mips.org>, <linux-kernel@vger.kernel.org>,
        <stable@vger.kernel.org>
Subject: Re: [PATCH] MIPS: Validate PR_SET_FP_MODE prctl(2) requests against
 the ABI of the task
Message-ID: <20171128193133.ip6weo4tgstqun44@pburton-laptop>
References: <alpine.DEB.2.00.1711251259130.3865@tp.orcam.me.uk>
 <20171127184642.ny2lad4y6zz6am2b@pburton-laptop>
 <alpine.DEB.2.00.1711272105460.31156@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.1711272105460.31156@tp.orcam.me.uk>
User-Agent: NeoMutt/20171013
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Maciej,

On Mon, Nov 27, 2017 at 09:39:10PM +0000, Maciej W. Rozycki wrote:
> > > Always succeed however without taking any further action if the mode 
> > > requested is the same as one already in effect, regardless of whether 
> > > any mode change, should it be requested, would actually be allowed for 
> > > the task concerned.
> > 
> > This seems like a distinct change that I think would be worth splitting
> > out to a separate patch.
> 
>  I've been thinking about it before posting and decided it's inherent.  
> 
>  Indeed in developing this fix this part was the last one I realised that 
> had to be done for the change to be overall self-consistent, following a 
> principle typically applied to hardware registers where the programmer is 
> architecturally allowed to write individual bits with the values 
> previously read from them even if these bits are undefined in the 
> specification of hardware concerned.
> 
>  So here you'll be able to issue a PR_SET_FP_MODE request with a value 
> previously obtained with PR_GET_FP_MODE and it will succeed, even if all 
> the bits are actually read-only for the ABI in effect.  This is important 
> as GDB will soon be using these calls and expect PR_SET_FP_MODE not to 
> fail if an attempt is made to write back a value previously obtained with 
> PR_GET_FP_MODE.
> 
>  I could have buried this check in the two conditions that follow, making 
> execution fall through if the mode remains unchanged, however I have 
> realised that making the check upfront makes the resulting code cleaner.
> 
>  That written, I could make it 1/2 with the ABI checks becoming 2/2, but 
> then 1/2 wouldn't make sense on its own (except perhaps as a 
> microoptimisation, but that would be an entirely different purpose) and 
> would have to be considered in conjunction with 2/2 anyway.

Ah - OK, I see. Prior to this patch the value returned by PR_GET_FP_MODE
would always be one accepted by PR_SET_FP_MODE anyway, but with the
patch that will cease to be true for non-o32 ABIs without the special
case. Gotcha.

> > Both changes look good to me though, so feel free to add:
> > 
> >     Reviewed-by: Paul Burton <paul.burton@mips.com>
> 
>  Thanks for your review.  Do you feel convinced with the justification I 
> gave?

Yes - I follow, please consider the Reviewed-by tag valid for the patch
as-is.

Thanks,
    Paul

From 1585257001366260489@xxx Mon Nov 27 21:41:27 +0000 2017
X-GM-THRID: 1585211647942183839
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread