02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
30 Apr, 2013
1 commit
-
It can accidentally happen that the faulting insn (the exact instruction
bytes) is repeated a little further on in the trace. This causes that
same instruction to be tagged twice, see example below.What we want to do, however, is to track back from the end of the whole
disassembly so many lines as the slice which starts with the faulting
instruction is long. This leads us to the actual faulting instruction
and *then* we tag it.While we're at it, we can drop the sed "g" flag because we address only
this one line.Also, if we point to an instruction which changes decoding depending on
the slice being objdumped, like a Jcc insn, for example, we do not even
tag it as a faulting instruction because the instruction decode changes
in the second slice but we use that second format as a regex on the
fsrst disassembled buffer and more often than not that instruction
doesn't match.Again, simply tag the line which is deduced from the original "<>"
marking we've received from the kernel.This also solves the pathologic issue of multiple tagging like this:
29:* 0f 0b ud2 39 48 08 75 0e eb 2a 66 90 48 8b 40 f0 48 39 48 08 74 1e 48
All code
========
0: 34 dd xor $0xdd,%al
2: 40 30 ad 81 48 c7 c0 xor %bpl,-0x3f38b77f(%rbp)
9: 80 f6 00 xor $0x0,%dh
c: 00 48 8b add %cl,-0x75(%rax)
f: 3c 30 cmp $0x30,%al
11: 48 01 c6 add %rax,%rsi
14: b8 ff ff ff ff mov $0xffffffff,%eax
19: 48 8d 57 f0 lea -0x10(%rdi),%rdx
1d: 48 39 f7 cmp %rsi,%rdi
20: 74 2f je 0x51
22: 49 8b 4c 24 08 mov 0x8(%r12),%rcx
27: 48 8b 47 f0 mov -0x10(%rdi),%rax
2b:* 48 39 48 08 cmp %rcx,0x8(%rax)
Cc: "H. Peter Anvin"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Aug, 2012
1 commit
-
When dumping "Code: " sections from an oops, the trapping instruction
%rip points to can be a string copy2b:* f3 a5 rep movsl %ds:(%rsi),%es:(%rdi)
and the line contain a bunch of ":". Current "cut" selects only the and
the second field output looks funnily overlaid this:2b:* f3 a5 rep movsl %ds
Cc: Linus Torvalds
Cc: linux-kbuild@vger.kernel.org
Signed-off-by: Borislav Petkov
Signed-off-by: Linus Torvalds
04 Jun, 2010
1 commit
-
Remove bashisms to make scripts/decodecode work with other shells.
Signed-off-by: Rabin Vincent
Reviewed-by: WANG Cong
Signed-off-by: Michal Marek
02 Feb, 2010
1 commit
-
This patch adds support for decoding ARM oopses to scripts/decodecode.
The following things are handled:- ARCH and CROSS_COMPILE environment variables are respected.
- The Code: in x86 oopses is in bytes, while it is in either words (4
bytes) or halfwords for ARM.- Some versions of ARM objdump refuse to disassemble instructions
generated by literal constants (".word 0x..."). The workaround is to
strip the object file first.- The faulting instruction is marked (liked so) in ARM, but
in x86.- ARM mnemonics may include characters such as [] which need to be
escaped before being passed to sed for the "
Signed-off-by: Michal Marek
04 Dec, 2008
1 commit
-
kerneloops.org has been using an improved "decodecode" script,
specifically it has a special marker that shows which line in the assembly
the oops happened at, like this:20: 83 e0 03 and $0x3,%eax
23: 09 d8 or %ebx,%eax
25: 85 db test %ebx,%ebx
27: 89 02 mov %eax,(%edx)
29: 74 0f je 0x3a
2b:* 3b 73 04 cmp 0x4(%ebx),%esi
Reviewed-by: WANG Cong
Signed-off-by: Andrew Morton
Signed-off-by: Sam Ravnborg
31 May, 2008
1 commit
-
.. because it is.
Signed-off-by: Linus Torvalds
29 Jan, 2008
1 commit
-
Remove the tmp file when exiting. Noticed by Arjan van de Ven.
Catch mktemp failure and exit with message.
Trap kill or other signals and exit cleanly.Signed-off-by: Randy Dunlap
Signed-off-by: Sam Ravnborg
17 Jul, 2007
1 commit
-
Add info that the Code: bytes line contains or (wxyz) in some
architecture oops reports and what that means.Add a script by Andi Kleen that reads the Code: line from an Oops report
file and generates assembly code from the hex bytes.Signed-off-by: Randy Dunlap
Cc: Andi Kleen
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds