litmus-rt.git/scripts, branch v2.6.33.2

scripts/get_maintainer.pl: fix possible infinite loop

2010-03-15T16:07:05+00:00

commit 3c840c18bcd8efb37f1a565e83a9509e1ea5d105 upstream.

If MAINTAINERS section entries are misformatted, it was possible to have
an infinite loop.

Correct the defect by always moving the index to the end of section + 1

Also, exit check for exclude as soon as possible.

Signed-off-by: Joe Perches 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

markup_oops.pl: fix $func_offset error with x86_64

2010-02-03T02:11:22+00:00

When I use markup_oops.pl parse a x8664 oops, I got:

objdump: --start-address: bad number: NaN
No matching code found
This is because:
main::(./m.pl:228):	open(FILE, "objdump -dS --adjust-vma=$vmaoffset --start-address=$decodestart --stop-address=$decodestop $filename |") || die "Cannot start objdump";
  DB<3> p $decodestart
NaN

This NaN is from:
main::(./m.pl:176):	my $decodestart = Math::BigInt->from_hex("0x$target") - Math::BigInt->from_hex("0x$func_offset");
  DB<2> p $func_offset
0x175

There is already a "0x" in $func_offset, another 0x makes it a NaN.

The $func_offset is from line:

	if ($line =~ /RIP: 0010:\[\<[0-9a-f]+\>\]  \[\<[0-9a-f]+\>\] ([a-zA-Z0-9\_]+)\+(0x[0-9a-f]+)\/0x[a-f0-9]/) {
		$function = $1;
		$func_offset = $2;
	}

I make a patch to change "(0x[0-9a-f]+)\/0x[a-f0-9]/)" to "0x([0-9a-f]+)\/0x[a-f0-9]/)".

Signed-off-by: Hui Zhu 
Cc: Arjan van de Ven 
Cc: Michal Marek 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

get_maintainer.pl: teach git log to use --no-color

2010-02-03T02:11:22+00:00

When git has been set to always use color in .gitconfig then I get the
warning message

        Bad divisor in main::vcs_assign: 0

This is caused by vcs_file_signoffs not matching any commits due to the
pattern not understand the colour codes.  Fix this by telling git log to
never use colour.

Signed-off-by: Richard Kennedy 
Acked-by: Joe Perches 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

modpost: fix segfault in sym_is() with prefixed arches

2010-01-17T19:00:53+00:00

The sym_is() compares a symbol in an attempt to automatically skip symbol
prefixes.  It does this first by searching the real symbol with the normal
unprefixed symbol.  But then it uses the length of the original symbol to
check the end of the substring instead of the length of the symbol it is
looking for.  On non-prefixed arches, this is effectively the same thing,
so there is no problem.  On prefixed-arches, since this is exceeds by just
one byte, a crash is rare and it is usually a NUL byte anyways.  But every
once in a blue moon, you get the right page alignment and it segfaults.

For example, on the Blackfin arch, sym_is() will be called with the real
symbol "___mod_usb_device_table" as "symbol" when looking for the normal
symbol "__mod_usb_device_table" as "name".  The substring will thus return
one byte into "symbol" and store it into "match".  But then "match" will
be indexed with the length of "symbol" instead of "name" and so we will
exceed the storage.  i.e. the code ends up doing:
	char foo[] = "abc"; return foo[strlen(foo)+1] == '\0';

Signed-off-by: Mike Frysinger 
Signed-off-by: Rusty Russell 
Signed-off-by: Linus Torvalds

Merge branch 'tracing-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

2010-01-16T20:27:25+00:00

* 'tracing-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  tracing/filters: Add comment for match callbacks
  tracing/filters: Fix MATCH_FULL filter matching for PTR_STRING
  tracing/filters: Fix MATCH_MIDDLE_ONLY filter matching
  lib: Introduce strnstr()
  tracing/filters: Fix MATCH_END_ONLY filter matching
  tracing/filters: Fix MATCH_FRONT_ONLY filter matching
  ftrace: Fix MATCH_END_ONLY function filter
  tracing/x86: Derive arch from bits argument in recordmcount.pl
  ring-buffer: Add rb_list_head() wrapper around new reader page next field
  ring-buffer: Wrap a list.next reference with rb_list_head()

markup_oops.pl: fix error with x86

2010-01-16T20:15:37+00:00

When I try to use markup_oops.pl in x86, I always get:

cat 1 | perl markup_oops.pl ./vmlinux
objdump: --start-address: bad number: NaN
No matching code found

This is because in line:
	if ($line =~ /EIP is at ([a-zA-Z0-9\_]+)\+0x([0-9a-f]+)\/[a-f0-9]/) {
 		$function = $1;
 		$func_offset = $2;
 	}

$func_offset will get a number like "0x2"

But in follow code:

my $decodestart = Math::BigInt->from_hex("0x$target") -
Math::BigInt->from_hex("0x$func_offset");

It add other ox to ox2.  Then this value will be set to NaN.

So I made a small patch to fix it.

Signed-off-by: Hui Zhu 
Acked-by: Arjan van de Ven 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kbuild: really fix bzImage build with non-bash sh

2010-01-13T12:27:24+00:00

In an x86 build with CONFIG_KERNEL_LZMA enabled and dash as sh,
arch/x86/boot/compressed/vmlinux.bin.lzma ends with
'\xf0\x7d\x39\x00' (16 bytes) instead of the 4 bytes intended and
the resulting vmlinuz fails to boot.  This improves on the
previous behavior, in which the file contained the characters
'-ne ' as well, but not by much.

Previous commits replaced "echo -ne" first with "/bin/echo -ne",
then "printf" in the hope of improving portability, but none of
these commands is guaranteed to support hexadecimal escapes on
POSIX systems.  So use the shell to convert from hexadecimal to
octal.

With this change, an LZMA-compressed kernel built with dash as sh
boots correctly again.

Reported-by: Sebastian Dalfuß 
Reported-by: Oliver Hartkopp 
Reported-by: Michael Guntsche 
Signed-off-by: Jonathan Nieder 
Cc: Michael Tokarev 
Cc: Alek Du 
Cc: Andrew Morton 
Signed-off-by: Michal Marek

remove my email address from checkpatch.

2010-01-13T04:56:52+00:00

Maybe this will stop people emailing me about it.

Signed-off-by: Dave Jones 
Signed-off-by: Linus Torvalds

tracing/x86: Derive arch from bits argument in recordmcount.pl

2010-01-12T04:49:35+00:00

Let the arch argument be overruled by bits. Otherwise, building of
external modules against a i386 target on a x86-64 host (and likely vice
versa as well) fails unless ARCH=i386 is explicitly passed to make.

Signed-off-by: Jan Kiszka 
LKML-Reference: <4B4AFE10.8050109@siemens.com>
Signed-off-by: Steven Rostedt

scripts/get_maintainer.pl: fix file exclusion X: logic

2010-01-11T17:34:05+00:00

The following command doesn't generate any output.
`./scripts/get_maintainer.pl --no-git -f drivers/net/wireless/wl12xx/wl1271_acx.c`

An excluded "X:" pattern match in any section would cause a file not to
match any other section.

Signed-off-by: Joe Perches 
Reported-by: Dan Carpenter 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds