linux-kernel - Re: [PATCH] recordmcount.pl: look for jgnop instruction as well as bcrl on s390

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LSU.2.21.2112101310080.5704@pobox.suse.cz>
Date:   Fri, 10 Dec 2021 13:16:28 +0100 (CET)
From:   Miroslav Benes <mbenes@...e.cz>
To:     Heiko Carstens <hca@...ux.ibm.com>
cc:     Jerome Marchand <jmarchan@...hat.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] recordmcount.pl: look for jgnop instruction as well as
 bcrl on s390

On Fri, 10 Dec 2021, Heiko Carstens wrote:

> On Fri, Dec 10, 2021 at 10:57:00AM +0100, Miroslav Benes wrote:
> > On Fri, 10 Dec 2021, Jerome Marchand wrote:
> > 
> > > On s390, recordmcount.pl is looking for "bcrl 0,<xxx>" instructions in
> > > the objdump -d outpout. However since binutils 2.37, objdump -d
> > > display "jgnop <xxx>" for the same instruction. Update the
> > > mcount_regex so that it accepts both.
> > > 
> > > Signed-off-by: Jerome Marchand <jmarchan@...hat.com>
> > 
> > Yes, we ran into exactly this issue too...
> > 
> > > ---
> > >  scripts/recordmcount.pl | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
> > > index 7d631aaa0ae1..52a000b057a5 100755
> > > --- a/scripts/recordmcount.pl
> > > +++ b/scripts/recordmcount.pl
> > > @@ -219,7 +219,7 @@ if ($arch eq "x86_64") {
> > >  
> > >  } elsif ($arch eq "s390" && $bits == 64) {
> > >      if ($cc =~ /-DCC_USING_HOTPATCH/) {
> > > -	$mcount_regex = "^\\s*([0-9a-fA-F]+):\\s*c0 04 00 00 00 00\\s*brcl\\s*0,[0-9a-f]+ <([^\+]*)>\$";
> > > +	$mcount_regex = "^\\s*([0-9a-fA-F]+):\\s*c0 04 00 00 00 00\\s*(bcrl\\s*0,|jgnop\\s*)[0-9a-f]+ <([^\+]*)>\$";
> > >  	$mcount_adjust = 0;
> > >      }
> > >      $alignment = 8;
> > 
> > ...and we have exactly the same fix in SLES. I haven't got to submit it 
> > to upstream yet :(, many thanks for doing it.
> > 
> > So at least
> > 
> > Reviewed-by: Miroslav Benes <mbenes@...e.cz>
> 
> Just out of curiosity: am I right if I assume that both of you have
> kernel sources without upstream commit
> d983c89cc96a ("s390/ftrace: Add -mfentry and -mnop-mcount support")
> and the commits directly preceding that one?

Unfortunately, it was reported also on 5.3-based kernels which have the 
commits.
 
> Otherwise I would be surprised that this would make any difference.

How come? I mean, s390 does not define HAVE_C_RECORDMCOUNT which implies 
that recordmcount.pl is used (see scripts/Makefile.build and 
BUILD_C_RECORDMCOUNT definition in Makefile).

> Applied to s390 tree + added a stable tag.

Thanks.

Miroslav