treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 373

Based on 1 normalized pattern(s):

this program file is free software you can redistribute it and or
modify it under the terms

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 373

Based on 1 normalized pattern(s):

this program file is free software you can redistribute it and or
modify it under the terms of the gnu general public license as
published by the free software foundation version 2 of the license

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-only

has been chosen to replace the boilerplate/reference in 1 file(s).

Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Allison Randal <[email protected]>
Reviewed-by: Armijn Hemel <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

scripts: Switch to more portable Perl shebang

The default NetBSD package manager is pkgsrc and it installs Perl
along other third party programs under custom and configurable prefix.
The default pre

scripts: Switch to more portable Perl shebang

The default NetBSD package manager is pkgsrc and it installs Perl
along other third party programs under custom and configurable prefix.
The default prefix for binary prebuilt packages is /usr/pkg, and the
Perl executable lands in /usr/pkg/bin/perl.

This change switches "/usr/bin/perl" to "/usr/bin/env perl" as it's
the most portable solution that should work for almost everybody.
Perl's executable is detected automatically.

This change switches -w option passed to the executable with more
modern "use warnings;" approach. There is no functional change to the
default behavior.

While there, drop "require 5" from scripts/namespace.pl (Perl from 1994?).

Signed-off-by: Kamil Rytarowski <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: Make scripts executable

The Makefiles call the respective interpreter explicitly, but this makes
it easier to use the scripts manually.

Signed-off-by: Michal Marek <[email protected]>

kbuild: trivial - remove trailing empty lines

Signed-off-by: Masahiro Yamada <[email protected]>

markup_oops.pl: minor fixes

1. Fix a little format issue.
2. Check the return of "Getopt::Long::GetOptions". Output usage and
exit if it get error.
3. Change $ARGV[$#ARGV] to $ARGV[0].
4. Change

markup_oops.pl: minor fixes

1. Fix a little format issue.
2. Check the return of "Getopt::Long::GetOptions". Output usage and
exit if it get error.
3. Change $ARGV[$#ARGV] to $ARGV[0].
4. Change the code which get $modulefile from modinfo. Replace the
pipeline with `modinfo -F filename $module`.
4. Change usage from "Specify the module directory name" to "Specify the
module filename".

Signed-off-by: Hui Zhu <[email protected]>
Signed-off-by: Michal Marek <[email protected]>

show more ...

markup_oops.pl: add options to improve cross-sompilation environments

The markup_oops.pl have 3 troubles to support cross-compiler environment:
1. It use objdump directly.
2. It use modinfo to get

markup_oops.pl: add options to improve cross-sompilation environments

The markup_oops.pl have 3 troubles to support cross-compiler environment:
1. It use objdump directly.
2. It use modinfo to get the message of module.
3. It use hex function that cannot support 64-bit number in 32-bit arch.

This patch add 3 options to markup_oops.pl:
1. -c CROSS_COMPILE Specify the prefix used for toolchain.
2. -m MODULE_DIRNAME Specify the module directory name.
3. Change hex function to Math::BigInt->from_hex.

After this patch, parse the x8664 oops in x86, we can:
cat amd64m | perl ~/kernel/tmp/m.pl -c /home/teawater/kernel/bin/x8664- -m ./e.ko vmlinux

Thanks,
Hui

Signed-off-by: Hui Zhu <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Arjan van de Ven <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Cc: [email protected]
Cc: Matthew Wilcox <[email protected]>
Acked-by: WANG Cong <[email protected]>
Signed-off-by: Michal Marek <[email protected]>

show more ...

markup_oops.pl: fix $func_offset error with x86_64

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.

markup_oops.pl: fix $func_offset error with x86_64

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 <[email protected]>
Cc: Arjan van de Ven <[email protected]>
Cc: Michal Marek <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

markup_oops.pl: fix for faulting instruction in the first line of a range

I got a "No matching code found" when I use markup_oops.pl parse a error
in a x86_64 module.

cat e.c

int init_module(void)

markup_oops.pl: fix for faulting instruction in the first line of a range

I got a "No matching code found" when I use markup_oops.pl parse a error
in a x86_64 module.

cat e.c

int init_module(void)
{
char *buf = 0;

buf[0] = 3;

return 0;
}

void cleanup_module(void)
{
//char *buf = 0;

//buf[0] = 3;
}

MODULE_AUTHOR("Hui Zhu");
MODULE_LICENSE("GPL");

0000000000000000 <init_module>:
init_module():
/home/teawater/study/kernel/stack2core/example/e.c:10
0: c6 04 25 00 00 00 00 movb $0x3,0x0
7: 03
/home/teawater/study/kernel/stack2core/example/e.c:13
8: 31 c0 xor %eax,%eax
a: c3 retq
b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)

0000000000000010 <cleanup_module>:
cleanup_module():
/home/teawater/study/kernel/stack2core/example/e.c:20
10: f3 c3 repz retq
12: 90 nop
13: 90 nop
Disassembly of section .modinfo:

This is because the faulting instruction "movb $0x3,0x0" is the first
line of the range.

In the markup_oops.pl:
main::(./scripts/markup_oops.pl:245):
245: if (InRange($1, $target)) {
DB<2> p $line
ffffffffa001b000: c6 04 25 00 00 00 00 movb $0x3,0x0
DB<3> p $counter
0

It just set $center in next loop. So it cannot get the $center.

And even if $center is set to the right value 0.
if ($center == 0) {
print "No matching code found \n";
exit;
}
The first line $center will be 0, so I change the default value to -1.

Signed-off-by: Hui Zhu <[email protected]>
Signed-off-by: Michal Marek <[email protected]>

show more ...

markup_oops.pl: fix error with x86

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

Thi

markup_oops.pl: fix error with x86

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 <[email protected]>
Acked-by: Arjan van de Ven <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

markup_oops: use modinfo to avoid confusion with underscored module names

When EIP is at a module having an underscore in its name, the current code
fails to find it because the module filenames has

markup_oops: use modinfo to avoid confusion with underscored module names

When EIP is at a module having an underscore in its name, the current code
fails to find it because the module filenames has '-' instead of '_'. Use
modinfo for a better path finding.

Signed-off-by: Ozan Çaglayan <[email protected]>
Acked-by: WANG Cong <[email protected]>
Cc: Arjan van de Ven <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Sam Ravnborg <[email protected]>

show more ...

markup_oops: fix it with 32-bit userspace on a 64-bit kernel

A 32-bit perl can't handle 64-bit addresses without using the BigInt
package.

Signed-off-by: Matthew Wilcox <[email protected]>
Acke

markup_oops: fix it with 32-bit userspace on a 64-bit kernel

A 32-bit perl can't handle 64-bit addresses without using the BigInt
package.

Signed-off-by: Matthew Wilcox <[email protected]>
Acked-by: Arjan van de Ven <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts: add x86 64 bit support to the markup_oops.pl script

Signed-off-by: Arjan van de Ven <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Sam Ravnb

scripts: add x86 64 bit support to the markup_oops.pl script

Signed-off-by: Arjan van de Ven <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Sam Ravnborg <[email protected]>

show more ...

scripts: add x86 register parser to markup_oops.pl

An oops dump also contains the register values.

This patch parses these for (32 bit) x86, and then annotates the
disassembly with these values; th

scripts: add x86 register parser to markup_oops.pl

An oops dump also contains the register values.

This patch parses these for (32 bit) x86, and then annotates the
disassembly with these values; this helps in analysis of the oops by the
developer, for example, NULL pointer or other pointer bugs show up clearly
this way.

Signed-off-by: Arjan van de Ven <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Sam Ravnborg <[email protected]>

show more ...

script: improve markup_oops.pl to also decode oopses in modules

There has been some light flamewar on lkml about decoding oopses
in modules (as part of the crashdump flamewar).

Now this isn't rocke

script: improve markup_oops.pl to also decode oopses in modules

There has been some light flamewar on lkml about decoding oopses
in modules (as part of the crashdump flamewar).

Now this isn't rocket science, just the markup_oops.pl script
cheaped out and didn't handle modules. But really; a flamewar
all about that?? What happened to C++ in the kernel or reading
files from inside the kernel?

This patch adds module support to markup_oops.pl; it's not the
most pretty perl but it works for my testcases...

Signed-off-by: Arjan van de Ven <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts: script from kerneloops.org to pretty print oops dumps

We're struggling all the time to figure out where the code came from that
oopsed.. The script below (a adaption from a script used by

scripts: script from kerneloops.org to pretty print oops dumps

We're struggling all the time to figure out where the code came from that
oopsed.. The script below (a adaption from a script used by
kerneloops.org) can help developers quite a bit, at least for non-module
cases.

It works and looks like this:

[/home/arjan/linux]$ dmesg | perl scripts/markup_oops.pl vmlinux
{
struct agp_memory *memory;

memory = agp_allocate_memory(agp_bridge, pg_count, type);
c055c10f: 89 c2 mov %eax,%edx
if (memory == NULL)
c055c111: 74 19 je c055c12c <agp_allocate_memory_wrap+0x30>
/* This function must only be called when current_controller != NULL */
static void agp_insert_into_pool(struct agp_memory * temp)
{
struct agp_memory *prev;

prev = agp_fe.current_controller->pool;
c055c113: a1 ec dc 8f c0 mov 0xc08fdcec,%eax
*c055c118: 8b 40 10 mov 0x10(%eax),%eax <----- faulting instruction

if (prev != NULL) {
c055c11b: 85 c0 test %eax,%eax
c055c11d: 74 05 je c055c124 <agp_allocate_memory_wrap+0x28>
prev->prev = temp;
c055c11f: 89 50 04 mov %edx,0x4(%eax)
temp->next = prev;
c055c122: 89 02 mov %eax,(%edx)
}
agp_fe.current_controller->pool = temp;
c055c124: a1 ec dc 8f c0 mov 0xc08fdcec,%eax
c055c129: 89 50 10 mov %edx,0x10(%eax)
if (memory == NULL)
return NULL;

agp_insert_into_pool(memory);

so in this case, we faulted while dereferencing agp_fe.current_controller
pointer, and we get to see exactly which function and line it affects...
Personally I find this very useful, and I can see value for having this
script in the kernel for more-than-just-me to use.

Caveats:
* It only works for oopses not-in-modules
* It only works nicely for kernels compiled with CONFIG_DEBUG_INFO
* It's not very fast.
* It only works on x86

Signed-off-by: Arjan van de Ven <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...