linux-kernel - Re: [PATCH 01/11] ftrace: handle generic arch calls

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]

Date:	Wed, 29 Oct 2008 20:00:45 +0100
From:	Sam Ravnborg <sam@...nborg.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Abhishek Sagar <sagar.abhishek@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Steven Rostedt <srostedt@...hat.com>
Subject: Re: [PATCH 01/11] ftrace: handle generic arch calls

On Mon, Oct 27, 2008 at 01:41:41PM -0400, Steven Rostedt wrote:
> 
> [
>   Resending patch.
> 
>   Sam, can you Ack this?
> 
>   -- Steve
> ]
> 
> From: Steven Rostedt <srostedt@...hat.com>
> Subject: ftrace: handle generic arch calls
> 
> The recordmcount script requires that the actual arch is passed in.
> This works well when ARCH=i386 or ARCH=x86_64 but does not handle the
> case of ARCH=x86.
> 
> This patch adds a parameter to the function to pass in the number of
> bits of the architecture. So that it can determine if x86 should be
> run for x86_64 or i386 archs.
> 
> Signed-off-by: Steven Rostedt <srostedt@...hat.com>
> ---
>  scripts/Makefile.build  |   10 ++++++++--
>  scripts/recordmcount.pl |   11 ++++++++++-
>  2 files changed, 18 insertions(+), 3 deletions(-)
> 
> Index: linux-compile.git/scripts/Makefile.build
> ===================================================================
> --- linux-compile.git.orig/scripts/Makefile.build	2008-10-22 15:09:04.000000000 -0400
> +++ linux-compile.git/scripts/Makefile.build	2008-10-22 15:09:07.000000000 -0400
> @@ -198,10 +198,16 @@ cmd_modversions =							\
>  	fi;
>  endif
>  
> +ifdef CONFIG_64BIT
> +arch_bits = 64
> +else
> +arch_bits = 32
> +endif
> +
>  ifdef CONFIG_FTRACE_MCOUNT_RECORD
>  cmd_record_mcount = perl $(srctree)/scripts/recordmcount.pl \
> -	"$(ARCH)" "$(OBJDUMP)" "$(OBJCOPY)" "$(CC)" "$(LD)" "$(NM)" "$(RM)" \
> -	"$(MV)" "$(@)";
> +	"$(ARCH)" "$(arch_bits)" "$(OBJDUMP)" "$(OBJCOPY)" "$(CC)" "$(LD)" \
> +	"$(NM)" "$(RM)" "$(MV)" "$(@)";
>  endif

A simple $(if $(CONFIG_64BIT),64,32) in the command would be more dense.

>  
>  define rule_cc_o_c
> Index: linux-compile.git/scripts/recordmcount.pl
> ===================================================================
> --- linux-compile.git.orig/scripts/recordmcount.pl	2008-10-22 15:09:04.000000000 -0400
> +++ linux-compile.git/scripts/recordmcount.pl	2008-10-22 15:09:45.000000000 -0400
> @@ -106,7 +106,8 @@ if ($#ARGV < 6) {
>  	exit(1);
>  }
>  
> -my ($arch, $objdump, $objcopy, $cc, $ld, $nm, $rm, $mv, $inputfile) = @ARGV;
> +my ($arch, $bits, $objdump, $objcopy, $cc,
> +    $ld, $nm, $rm, $mv, $inputfile) = @ARGV;
>  
>  $objdump = "objdump" if ((length $objdump) == 0);
>  $objcopy = "objcopy" if ((length $objcopy) == 0);
> @@ -129,6 +130,14 @@ my $function_regex;	# Find the name of a
>  			#    (return offset and func name)
>  my $mcount_regex;	# Find the call site to mcount (return offset)
>  
> +if ($arch eq "x86") {
> +    if ($bits == 64) {
> +	$arch = "x86_64";
> +    } else {
> +	$arch = "i386";
> +    }
> +}
> +
>  if ($arch eq "x86_64") {
>      $section_regex = "Disassembly of section";
>      $function_regex = "^([0-9a-fA-F]+)\\s+<(.*?)>:";
> 

This looks strange to my eyes.
Why not do the more obvious:
if ($arch eq "x86" && $bits == 64) {

The change above is like trying to stick to the old i386/x86_64
notation.

	Sam

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/