All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Jinyang He <hejinyang@loongson.cn>,
	Jiaxun Yang <jiaxun.yang@flygoat.com>,
	linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
	Paul Burton <paulburton@kernel.org>,
	Jun-Ru Chang <jrjang@realtek.com>
Subject: Re: [PATCH v2 2/4] MIPS: microMIPS: Fix the judgment of mm_jr16_op and mm_jalr_op
Date: Tue, 9 Feb 2021 17:14:20 +0100	[thread overview]
Message-ID: <20210209161420.GA15428@alpha.franken.de> (raw)
In-Reply-To: <alpine.DEB.2.21.2102072200300.35623@angie.orcam.me.uk>

On Sun, Feb 07, 2021 at 10:31:38PM +0100, Maciej W. Rozycki wrote:
> On Thu, 21 Jan 2021, Jinyang He wrote:
> 
> > mm16_r5_format.rt is 5 bits, so directly judge the value if equal or not.
> > mm_jalr_op requires 7th to 16th bits. These 10 which bits generated by
> 
>  The minor opcode extension field is comprised of bits 15:6, not 16:7 as 
> your description suggests.  Please be accurate with statements.
> 
> > shifting u_format.uimmediate by 6 may be affected by sign extension.
> 
>  Why?  The `uimmediate' bit-field member is unsigned for a reason.  No 
> sign-extension is made on unsigned data with the right-shift operation.
> 
> > Thus, take out the 10 bits for comparison.
> > 
> > Without this patch, errors may occur, such as these bits are all ones.
> 
>  How did you come to this conclusion?
> 
> > diff --git a/arch/mips/kernel/process.c b/arch/mips/kernel/process.c
> > index d737234..74d7fd8 100644
> > --- a/arch/mips/kernel/process.c
> > +++ b/arch/mips/kernel/process.c
> > @@ -292,8 +292,8 @@ static inline int is_jump_ins(union mips_instruction *ip)
> >  	 * microMIPS is kind of more fun...
> >  	 */
> >  	if (mm_insn_16bit(ip->word >> 16)) {
> > -		if ((ip->mm16_r5_format.opcode == mm_pool16c_op &&
> > -		    (ip->mm16_r5_format.rt & mm_jr16_op) == mm_jr16_op))
> > +		if (ip->mm16_r5_format.opcode == mm_pool16c_op &&
> > +		    ip->mm16_r5_format.rt == mm_jr16_op)
> >  			return 1;
> >  		return 0;
> >  	}
> 
>  Code style changes should be submitted on their own as separate patches.
> 
> > @@ -305,7 +305,7 @@ static inline int is_jump_ins(union mips_instruction *ip)
> >  	if (ip->r_format.opcode != mm_pool32a_op ||
> >  			ip->r_format.func != mm_pool32axf_op)
> >  		return 0;
> > -	return ((ip->u_format.uimmediate >> 6) & mm_jalr_op) == mm_jalr_op;
> > +	return ((ip->u_format.uimmediate >> 6) & GENMASK(9, 0)) == mm_jalr_op;
> 
>  You've now excluded JALR.HB, JALRS, and JALRS.HB instructions.  The mask 
> was there for a reason.  If you can't be bothered to verify microMIPS 
> changes say with QEMU, then at the very least please check documentation.  
> The intent of this code is clear and these instructions are even spelled 
> out explicitly in the comment at the top.
> 
>  Thomas, please revert this change as I can see you've already taken it.  
> It's plain wrong.

It's now reverted in mips-next.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

  parent reply	other threads:[~2021-02-09 16:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-21  5:31 [PATCH v2 0/4] MIPS: process: Some fixes and improvements about get_frame_info() Jinyang He
2021-01-21  5:31 ` [PATCH v2 1/4] MIPS: process: Remove unnecessary headers inclusion Jinyang He
2021-01-21  9:28   ` Huacai Chen
2021-01-21  5:31 ` [PATCH v2 2/4] MIPS: microMIPS: Fix the judgment of mm_jr16_op and mm_jalr_op Jinyang He
2021-02-07 21:31   ` Maciej W. Rozycki
2021-02-08  1:13     ` Jinyang He
2021-02-09 16:14     ` Thomas Bogendoerfer [this message]
2021-01-21  5:31 ` [PATCH v2 3/4] MIPS: Fix get_frame_info() handing of function size Jinyang He
2021-01-21  5:31 ` [PATCH v2 4/4] MIPS: Add is_jr_ra_ins() to end the loop early Jinyang He
2021-01-25 11:24 ` [PATCH v2 0/4] MIPS: process: Some fixes and improvements about get_frame_info() Thomas Bogendoerfer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210209161420.GA15428@alpha.franken.de \
    --to=tsbogend@alpha.franken.de \
    --cc=hejinyang@loongson.cn \
    --cc=jiaxun.yang@flygoat.com \
    --cc=jrjang@realtek.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=macro@orcam.me.uk \
    --cc=paulburton@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.