linux-stable.git/scripts, branch linux-2.6.33.y

fixes for using make 3.82

2011-05-23T18:23:00+00:00

commit 3c955b407a084810f57260d61548cc92c14bc627 upstream.

It doesn't like pattern and explicit rules to be on the same line,
and it seems to be more picky when matching file (or really directory)
names with different numbers of trailing slashes.

Signed-off-by: Jan Beulich 
Acked-by: Sam Ravnborg 
Andrew Benton 
Signed-off-by: Michal Marek 
Signed-off-by: John Kacur 
Signed-off-by: Greg Kroah-Hartman

kconfig: Avoid buffer underrun in choice input

2011-05-09T23:04:37+00:00

commit 3ba41621156681afcdbcd624e3191cbc65eb94f4 upstream.

Commit 40aee729b350 ('kconfig: fix default value for choice input')
fixed some cases where kconfig would select the wrong option from a
choice with a single valid option and thus enter an infinite loop.

However, this broke the test for user input of the form 'N?', because
when kconfig selects the single valid option the input is zero-length
and the test will read the byte before the input buffer.  If this
happens to contain '?' (as it will in a mips build on Debian unstable
today) then kconfig again enters an infinite loop.

Signed-off-by: Ben Hutchings 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

kbuild: Fix modpost segfault

2010-08-02T17:26:50+00:00

commit 1c938663d58b5b2965976a6f54cc51b5d6f691aa upstream.

Alan  writes:

> program: /home/alan/GitTrees/linux-2.6-mid-ref/scripts/mod/modpost -o
> Module.symvers -S vmlinux.o
>
> Program received signal SIGSEGV, Segmentation fault.

It just hit me.
It's the offset calculation in reloc_location() which overflows:
        return (void *)elf->hdr + sechdrs[section].sh_offset +
               (r->r_offset - sechdrs[section].sh_addr);

E.g. for the first rodata r entry:
r->r_offset < sechdrs[section].sh_addr
and the expression in the parenthesis produces 0xFFFFFFE0 or something
equally wise.

Reported-by: Alan 
Signed-off-by: Krzysztof Hałasa 
Tested-by: Alan 
Signed-off-by: Michal Marek 
Signed-off-by: Greg Kroah-Hartman

gconfig: fix build failure on fedora 13

2010-07-05T18:15:59+00:00

commit cbab05f041a4cff6ca15856bdd35238b282b64eb upstream.

Making gconfig fails on fedora 13 as the linker cannot resolve dlsym.

Adding libdl to the link command fixes this.

make shows this error :-
    /usr/bin/ld: scripts/kconfig/kconfig_load.o: undefined reference to symbol 'dlsym@@GLIBC_2.2.5'
    /usr/bin/ld: note: 'dlsym@@GLIBC_2.2.5' is defined in DSO /lib64/libdl.so.2 so try adding it to the linker command line
    /lib64/libdl.so.2: could not read symbols: Invalid operation

tested on x86_64 fedora 13.

Signed-off-by: Richard Kennedy 
Reviewed-by: WANG Cong 
Signed-off-by: Andrew Morton 
Signed-off-by: Michal Marek 
Signed-off-by: Greg Kroah-Hartman

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