License cleanup: add SPDX GPL-2.0 license identifier to files with no license
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 <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 21:07:57 +07:00
|
|
|
# SPDX-License-Identifier: GPL-2.0
|
2008-01-30 19:32:27 +07:00
|
|
|
#
|
|
|
|
# Makefile for the linux kernel.
|
|
|
|
#
|
|
|
|
|
2016-04-14 07:04:34 +07:00
|
|
|
extra-y := head_$(BITS).o
|
|
|
|
extra-y += head$(BITS).o
|
2016-04-14 07:04:43 +07:00
|
|
|
extra-y += ebda.o
|
2016-04-14 07:04:34 +07:00
|
|
|
extra-y += platform-quirks.o
|
|
|
|
extra-y += vmlinux.lds
|
2008-01-30 19:32:27 +07:00
|
|
|
|
|
|
|
CPPFLAGS_vmlinux.lds += -U$(UTS_MACHINE)
|
2008-02-14 14:38:49 +07:00
|
|
|
|
2008-10-07 06:06:12 +07:00
|
|
|
ifdef CONFIG_FUNCTION_TRACER
|
2008-07-09 20:42:09 +07:00
|
|
|
# Do not profile debug and lowlevel utilities
|
2011-05-28 10:11:24 +07:00
|
|
|
CFLAGS_REMOVE_tsc.o = -pg
|
2008-07-24 03:28:58 +07:00
|
|
|
CFLAGS_REMOVE_paravirt-spinlocks.o = -pg
|
2010-09-23 07:07:27 +07:00
|
|
|
CFLAGS_REMOVE_pvclock.o = -pg
|
2010-09-23 09:22:25 +07:00
|
|
|
CFLAGS_REMOVE_kvmclock.o = -pg
|
2008-10-23 20:33:08 +07:00
|
|
|
CFLAGS_REMOVE_ftrace.o = -pg
|
2008-11-04 16:42:23 +07:00
|
|
|
CFLAGS_REMOVE_early_printk.o = -pg
|
2017-06-27 18:59:48 +07:00
|
|
|
CFLAGS_REMOVE_head64.o = -pg
|
2020-09-08 19:38:16 +07:00
|
|
|
CFLAGS_REMOVE_sev-es.o = -pg
|
2008-05-15 08:30:32 +07:00
|
|
|
endif
|
|
|
|
|
2016-02-29 11:22:34 +07:00
|
|
|
KASAN_SANITIZE_head$(BITS).o := n
|
|
|
|
KASAN_SANITIZE_dumpstack.o := n
|
|
|
|
KASAN_SANITIZE_dumpstack_$(BITS).o := n
|
2017-09-29 21:08:18 +07:00
|
|
|
KASAN_SANITIZE_stacktrace.o := n
|
|
|
|
KASAN_SANITIZE_paravirt.o := n
|
2020-09-08 19:38:16 +07:00
|
|
|
KASAN_SANITIZE_sev-es.o := n
|
2016-02-29 11:22:34 +07:00
|
|
|
|
2019-11-15 01:03:03 +07:00
|
|
|
# With some compiler versions the generated code results in boot hangs, caused
|
|
|
|
# by several compilation units. To be safe, disable all instrumentation.
|
|
|
|
KCSAN_SANITIZE := n
|
|
|
|
|
2016-02-29 11:22:34 +07:00
|
|
|
OBJECT_FILES_NON_STANDARD_test_nx.o := y
|
2019-04-24 20:41:17 +07:00
|
|
|
OBJECT_FILES_NON_STANDARD_paravirt_patch.o := y
|
2015-02-14 05:39:25 +07:00
|
|
|
|
2018-01-23 11:07:46 +07:00
|
|
|
ifdef CONFIG_FRAME_POINTER
|
|
|
|
OBJECT_FILES_NON_STANDARD_ftrace_$(BITS).o := y
|
|
|
|
endif
|
|
|
|
|
kernel: add kcov code coverage
kcov provides code coverage collection for coverage-guided fuzzing
(randomized testing). Coverage-guided fuzzing is a testing technique
that uses coverage feedback to determine new interesting inputs to a
system. A notable user-space example is AFL
(http://lcamtuf.coredump.cx/afl/). However, this technique is not
widely used for kernel testing due to missing compiler and kernel
support.
kcov does not aim to collect as much coverage as possible. It aims to
collect more or less stable coverage that is function of syscall inputs.
To achieve this goal it does not collect coverage in soft/hard
interrupts and instrumentation of some inherently non-deterministic or
non-interesting parts of kernel is disbled (e.g. scheduler, locking).
Currently there is a single coverage collection mode (tracing), but the
API anticipates additional collection modes. Initially I also
implemented a second mode which exposes coverage in a fixed-size hash
table of counters (what Quentin used in his original patch). I've
dropped the second mode for simplicity.
This patch adds the necessary support on kernel side. The complimentary
compiler support was added in gcc revision 231296.
We've used this support to build syzkaller system call fuzzer, which has
found 90 kernel bugs in just 2 months:
https://github.com/google/syzkaller/wiki/Found-Bugs
We've also found 30+ bugs in our internal systems with syzkaller.
Another (yet unexplored) direction where kcov coverage would greatly
help is more traditional "blob mutation". For example, mounting a
random blob as a filesystem, or receiving a random blob over wire.
Why not gcov. Typical fuzzing loop looks as follows: (1) reset
coverage, (2) execute a bit of code, (3) collect coverage, repeat. A
typical coverage can be just a dozen of basic blocks (e.g. an invalid
input). In such context gcov becomes prohibitively expensive as
reset/collect coverage steps depend on total number of basic
blocks/edges in program (in case of kernel it is about 2M). Cost of
kcov depends only on number of executed basic blocks/edges. On top of
that, kernel requires per-thread coverage because there are always
background threads and unrelated processes that also produce coverage.
With inlined gcov instrumentation per-thread coverage is not possible.
kcov exposes kernel PCs and control flow to user-space which is
insecure. But debugfs should not be mapped as user accessible.
Based on a patch by Quentin Casasnovas.
[akpm@linux-foundation.org: make task_struct.kcov_mode have type `enum kcov_mode']
[akpm@linux-foundation.org: unbreak allmodconfig]
[akpm@linux-foundation.org: follow x86 Makefile layout standards]
Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: syzkaller <syzkaller@googlegroups.com>
Cc: Vegard Nossum <vegard.nossum@oracle.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Tavis Ormandy <taviso@google.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: Kostya Serebryany <kcc@google.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Kees Cook <keescook@google.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: David Drysdale <drysdale@google.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Kirill A. Shutemov <kirill@shutemov.name>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-03-23 04:27:30 +07:00
|
|
|
# If instrumentation of this dir is enabled, boot hangs during first second.
|
|
|
|
# Probably could be more selective here, but note that files related to irqs,
|
|
|
|
# boot, dumpstack/stacktrace, etc are either non-interesting or can lead to
|
|
|
|
# non-deterministic coverage.
|
|
|
|
KCOV_INSTRUMENT := n
|
|
|
|
|
2020-10-09 02:16:23 +07:00
|
|
|
CFLAGS_head$(BITS).o += -fno-stack-protector
|
|
|
|
|
2019-05-13 13:22:16 +07:00
|
|
|
CFLAGS_irq.o := -I $(srctree)/$(src)/../include/asm/trace
|
2013-06-21 21:29:05 +07:00
|
|
|
|
2015-06-03 18:37:36 +07:00
|
|
|
obj-y := process_$(BITS).o signal.o
|
2015-06-22 18:55:10 +07:00
|
|
|
obj-$(CONFIG_COMPAT) += signal_compat.o
|
2017-08-28 13:47:43 +07:00
|
|
|
obj-y += traps.o idt.o irq.o irq_$(BITS).o dumpstack_$(BITS).o
|
2015-07-31 04:31:34 +07:00
|
|
|
obj-y += time.o ioport.o dumpstack.o nmi.o
|
|
|
|
obj-$(CONFIG_MODIFY_LDT_SYSCALL) += ldt.o
|
2018-12-30 22:14:15 +07:00
|
|
|
obj-y += setup.o x86_init.o i8259.o irqinit.o
|
|
|
|
obj-$(CONFIG_JUMP_LABEL) += jump_label.o
|
2010-10-14 13:01:34 +07:00
|
|
|
obj-$(CONFIG_IRQ_WORK) += irq_work.o
|
2011-03-09 01:36:19 +07:00
|
|
|
obj-y += probe_roms.o
|
2020-03-14 02:51:41 +07:00
|
|
|
obj-$(CONFIG_X86_32) += sys_ia32.o
|
|
|
|
obj-$(CONFIG_IA32_EMULATION) += sys_ia32.o
|
2017-03-23 21:33:53 +07:00
|
|
|
obj-$(CONFIG_X86_64) += sys_x86_64.o
|
2014-05-05 00:00:49 +07:00
|
|
|
obj-$(CONFIG_X86_ESPFIX64) += espfix_64.o
|
2013-12-20 17:02:21 +07:00
|
|
|
obj-$(CONFIG_SYSFS) += ksysfs.o
|
2008-06-17 09:58:28 +07:00
|
|
|
obj-y += bootflag.o e820.o
|
2011-03-23 06:34:57 +07:00
|
|
|
obj-y += pci-dma.o quirks.o topology.o kdebugfs.o
|
2018-03-19 17:38:15 +07:00
|
|
|
obj-y += alternative.o i8253.o hw_breakpoint.o
|
2013-10-21 23:16:33 +07:00
|
|
|
obj-y += tsc.o tsc_msr.o io_delay.o rtc.o
|
2010-08-27 00:57:58 +07:00
|
|
|
obj-y += pci-iommu_table.o
|
2010-12-17 00:38:51 +07:00
|
|
|
obj-y += resource.o
|
2018-06-21 23:23:24 +07:00
|
|
|
obj-y += irqflags.o
|
2020-08-18 20:57:44 +07:00
|
|
|
obj-y += static_call.o
|
2008-01-30 19:32:27 +07:00
|
|
|
|
2008-03-11 05:28:04 +07:00
|
|
|
obj-y += process.o
|
2015-04-22 15:39:11 +07:00
|
|
|
obj-y += fpu/
|
2008-01-30 19:32:27 +07:00
|
|
|
obj-y += ptrace.o
|
|
|
|
obj-$(CONFIG_X86_32) += tls.o
|
|
|
|
obj-$(CONFIG_IA32_EMULATION) += tls.o
|
|
|
|
obj-y += step.o
|
x86, intel_txt: Intel TXT boot support
This patch adds kernel configuration and boot support for Intel Trusted
Execution Technology (Intel TXT).
Intel's technology for safer computing, Intel Trusted Execution
Technology (Intel TXT), defines platform-level enhancements that
provide the building blocks for creating trusted platforms.
Intel TXT was formerly known by the code name LaGrande Technology (LT).
Intel TXT in Brief:
o Provides dynamic root of trust for measurement (DRTM)
o Data protection in case of improper shutdown
o Measurement and verification of launched environment
Intel TXT is part of the vPro(TM) brand and is also available some
non-vPro systems. It is currently available on desktop systems based on
the Q35, X38, Q45, and Q43 Express chipsets (e.g. Dell Optiplex 755, HP
dc7800, etc.) and mobile systems based on the GM45, PM45, and GS45
Express chipsets.
For more information, see http://www.intel.com/technology/security/.
This site also has a link to the Intel TXT MLE Developers Manual, which
has been updated for the new released platforms.
A much more complete description of how these patches support TXT, how to
configure a system for it, etc. is in the Documentation/intel_txt.txt file
in this patch.
This patch provides the TXT support routines for complete functionality,
documentation for TXT support and for the changes to the boot_params structure,
and boot detection of a TXT launch. Attempts to shutdown (reboot, Sx) the system
will result in platform resets; subsequent patches will support these shutdown modes
properly.
Documentation/intel_txt.txt | 210 +++++++++++++++++++++
Documentation/x86/zero-page.txt | 1
arch/x86/include/asm/bootparam.h | 3
arch/x86/include/asm/fixmap.h | 3
arch/x86/include/asm/tboot.h | 197 ++++++++++++++++++++
arch/x86/kernel/Makefile | 1
arch/x86/kernel/setup.c | 4
arch/x86/kernel/tboot.c | 379 +++++++++++++++++++++++++++++++++++++++
security/Kconfig | 30 +++
9 files changed, 827 insertions(+), 1 deletion(-)
Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
Signed-off-by: Shane Wang <shane.wang@intel.com>
Signed-off-by: Gang Wei <gang.wei@intel.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2009-07-01 09:30:59 +07:00
|
|
|
obj-$(CONFIG_INTEL_TXT) += tboot.o
|
2011-03-23 06:34:57 +07:00
|
|
|
obj-$(CONFIG_ISA_DMA_API) += i8237.o
|
2008-01-30 19:32:27 +07:00
|
|
|
obj-$(CONFIG_STACKTRACE) += stacktrace.o
|
|
|
|
obj-y += cpu/
|
|
|
|
obj-y += acpi/
|
2009-01-27 23:17:55 +07:00
|
|
|
obj-y += reboot.o
|
2008-01-30 19:32:27 +07:00
|
|
|
obj-$(CONFIG_X86_MSR) += msr.o
|
|
|
|
obj-$(CONFIG_X86_CPUID) += cpuid.o
|
|
|
|
obj-$(CONFIG_PCI) += early-quirks.o
|
2008-02-04 22:47:55 +07:00
|
|
|
apm-y := apm_32.o
|
|
|
|
obj-$(CONFIG_APM) += apm.o
|
2009-01-27 23:07:08 +07:00
|
|
|
obj-$(CONFIG_SMP) += smp.o
|
2011-03-11 14:02:35 +07:00
|
|
|
obj-$(CONFIG_SMP) += smpboot.o
|
2016-11-19 20:47:36 +07:00
|
|
|
obj-$(CONFIG_X86_TSC) += tsc_sync.o
|
2009-01-27 10:56:47 +07:00
|
|
|
obj-$(CONFIG_SMP) += setup_percpu.o
|
2008-04-05 02:43:18 +07:00
|
|
|
obj-$(CONFIG_X86_MPPARSE) += mpparse.o
|
2009-02-18 05:12:48 +07:00
|
|
|
obj-y += apic/
|
2008-01-30 19:32:27 +07:00
|
|
|
obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups_32.o
|
ftrace: dynamic enabling/disabling of function calls
This patch adds a feature to dynamically replace the ftrace code
with the jmps to allow a kernel with ftrace configured to run
as fast as it can without it configured.
The way this works, is on bootup (if ftrace is enabled), a ftrace
function is registered to record the instruction pointer of all
places that call the function.
Later, if there's still any code to patch, a kthread is awoken
(rate limited to at most once a second) that performs a stop_machine,
and replaces all the code that was called with a jmp over the call
to ftrace. It only replaces what was found the previous time. Typically
the system reaches equilibrium quickly after bootup and there's no code
patching needed at all.
e.g.
call ftrace /* 5 bytes */
is replaced with
jmp 3f /* jmp is 2 bytes and we jump 3 forward */
3:
When we want to enable ftrace for function tracing, the IP recording
is removed, and stop_machine is called again to replace all the locations
of that were recorded back to the call of ftrace. When it is disabled,
we replace the code back to the jmp.
Allocation is done by the kthread. If the ftrace recording function is
called, and we don't have any record slots available, then we simply
skip that call. Once a second a new page (if needed) is allocated for
recording new ftrace function calls. A large batch is allocated at
boot up to get most of the calls there.
Because we do this via stop_machine, we don't have to worry about another
CPU executing a ftrace call as we modify it. But we do need to worry
about NMI's so all functions that might be called via nmi must be
annotated with notrace_nmi. When this code is configured in, the NMI code
will not call notrace.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-13 02:20:42 +07:00
|
|
|
obj-$(CONFIG_DYNAMIC_FTRACE) += ftrace.o
|
2017-03-23 21:33:53 +07:00
|
|
|
obj-$(CONFIG_FUNCTION_TRACER) += ftrace_$(BITS).o
|
2009-03-13 23:02:17 +07:00
|
|
|
obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o
|
|
|
|
obj-$(CONFIG_FTRACE_SYSCALLS) += ftrace.o
|
2012-11-14 03:18:21 +07:00
|
|
|
obj-$(CONFIG_X86_TSC) += trace_clock.o
|
2019-12-20 23:22:49 +07:00
|
|
|
obj-$(CONFIG_CRASH_CORE) += crash_core_$(BITS).o
|
2015-09-10 05:38:55 +07:00
|
|
|
obj-$(CONFIG_KEXEC_CORE) += machine_kexec_$(BITS).o
|
|
|
|
obj-$(CONFIG_KEXEC_CORE) += relocate_kernel_$(BITS).o crash.o
|
2014-08-30 05:18:46 +07:00
|
|
|
obj-$(CONFIG_KEXEC_FILE) += kexec-bzimage64.o
|
2008-01-30 19:32:27 +07:00
|
|
|
obj-$(CONFIG_CRASH_DUMP) += crash_dump_$(BITS).o
|
2012-09-28 15:15:22 +07:00
|
|
|
obj-y += kprobes/
|
2009-06-04 08:46:19 +07:00
|
|
|
obj-$(CONFIG_MODULES) += module.o
|
2020-04-04 06:33:05 +07:00
|
|
|
obj-$(CONFIG_X86_32) += doublefault_32.o
|
2008-04-18 01:05:37 +07:00
|
|
|
obj-$(CONFIG_KGDB) += kgdb.o
|
2008-01-30 19:32:27 +07:00
|
|
|
obj-$(CONFIG_VM86) += vm86_32.o
|
|
|
|
obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
|
|
|
|
|
|
|
|
obj-$(CONFIG_HPET_TIMER) += hpet.o
|
2009-09-02 21:37:17 +07:00
|
|
|
obj-$(CONFIG_APB_TIMER) += apb_timer.o
|
2007-10-18 03:06:30 +07:00
|
|
|
|
2010-09-17 23:03:43 +07:00
|
|
|
obj-$(CONFIG_AMD_NB) += amd_nb.o
|
2011-10-14 02:14:26 +07:00
|
|
|
obj-$(CONFIG_DEBUG_NMI_SELFTEST) += nmi_selftest.o
|
2008-01-30 19:32:27 +07:00
|
|
|
|
2012-08-17 03:00:19 +07:00
|
|
|
obj-$(CONFIG_KVM_GUEST) += kvm.o kvmclock.o
|
2019-04-24 20:41:17 +07:00
|
|
|
obj-$(CONFIG_PARAVIRT) += paravirt.o paravirt_patch.o
|
x86: Fix performance regression caused by paravirt_ops on native kernels
Xiaohui Xin and some other folks at Intel have been looking into what's
behind the performance hit of paravirt_ops when running native.
It appears that the hit is entirely due to the paravirtualized
spinlocks introduced by:
| commit 8efcbab674de2bee45a2e4cdf97de16b8e609ac8
| Date: Mon Jul 7 12:07:51 2008 -0700
|
| paravirt: introduce a "lock-byte" spinlock implementation
The extra call/return in the spinlock path is somehow
causing an increase in the cycles/instruction of somewhere around 2-7%
(seems to vary quite a lot from test to test). The working theory is
that the CPU's pipeline is getting upset about the
call->call->locked-op->return->return, and seems to be failing to
speculate (though I haven't seen anything definitive about the precise
reasons). This doesn't entirely make sense, because the performance
hit is also visible on unlock and other operations which don't involve
locked instructions. But spinlock operations clearly swamp all the
other pvops operations, even though I can't imagine that they're
nearly as common (there's only a .05% increase in instructions
executed).
If I disable just the pv-spinlock calls, my tests show that pvops is
identical to non-pvops performance on native (my measurements show that
it is actually about .1% faster, but Xiaohui shows a .05% slowdown).
Summary of results, averaging 10 runs of the "mmperf" test, using a
no-pvops build as baseline:
nopv Pv-nospin Pv-spin
CPU cycles 100.00% 99.89% 102.18%
instructions 100.00% 100.10% 100.15%
CPI 100.00% 99.79% 102.03%
cache ref 100.00% 100.84% 100.28%
cache miss 100.00% 90.47% 88.56%
cache miss rate 100.00% 89.72% 88.31%
branches 100.00% 99.93% 100.04%
branch miss 100.00% 103.66% 107.72%
branch miss rt 100.00% 103.73% 107.67%
wallclock 100.00% 99.90% 102.20%
The clear effect here is that the 2% increase in CPI is
directly reflected in the final wallclock time.
(The other interesting effect is that the more ops are
out of line calls via pvops, the lower the cache access
and miss rates. Not too surprising, but it suggests that
the non-pvops kernel is over-inlined. On the flipside,
the branch misses go up correspondingly...)
So, what's the fix?
Paravirt patching turns all the pvops calls into direct calls, so
_spin_lock etc do end up having direct calls. For example, the compiler
generated code for paravirtualized _spin_lock is:
<_spin_lock+0>: mov %gs:0xb4c8,%rax
<_spin_lock+9>: incl 0xffffffffffffe044(%rax)
<_spin_lock+15>: callq *0xffffffff805a5b30
<_spin_lock+22>: retq
The indirect call will get patched to:
<_spin_lock+0>: mov %gs:0xb4c8,%rax
<_spin_lock+9>: incl 0xffffffffffffe044(%rax)
<_spin_lock+15>: callq <__ticket_spin_lock>
<_spin_lock+20>: nop; nop /* or whatever 2-byte nop */
<_spin_lock+22>: retq
One possibility is to inline _spin_lock, etc, when building an
optimised kernel (ie, when there's no spinlock/preempt
instrumentation/debugging enabled). That will remove the outer
call/return pair, returning the instruction stream to a single
call/return, which will presumably execute the same as the non-pvops
case. The downsides arel 1) it will replicate the
preempt_disable/enable code at eack lock/unlock callsite; this code is
fairly small, but not nothing; and 2) the spinlock definitions are
already a very heavily tangled mass of #ifdefs and other preprocessor
magic, and making any changes will be non-trivial.
The other obvious answer is to disable pv-spinlocks. Making them a
separate config option is fairly easy, and it would be trivial to
enable them only when Xen is enabled (as the only non-default user).
But it doesn't really address the common case of a distro build which
is going to have Xen support enabled, and leaves the open question of
whether the native performance cost of pv-spinlocks is worth the
performance improvement on a loaded Xen system (10% saving of overall
system CPU when guests block rather than spin). Still it is a
reasonable short-term workaround.
[ Impact: fix pvops performance regression when running native ]
Analysed-by: "Xin Xiaohui" <xiaohui.xin@intel.com>
Analysed-by: "Li Xin" <xin.li@intel.com>
Analysed-by: "Nakajima Jun" <jun.nakajima@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Cc: Nick Piggin <npiggin@suse.de>
Cc: Xen-devel <xen-devel@lists.xensource.com>
LKML-Reference: <4A0B62F7.5030802@goop.org>
[ fixed the help text ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-05-14 07:16:55 +07:00
|
|
|
obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= paravirt-spinlocks.o
|
2008-06-03 21:17:29 +07:00
|
|
|
obj-$(CONFIG_PARAVIRT_CLOCK) += pvclock.o
|
2015-08-19 11:34:34 +07:00
|
|
|
obj-$(CONFIG_X86_PMEM_LEGACY_DEVICE) += pmem.o
|
2008-01-30 19:33:18 +07:00
|
|
|
|
2017-11-27 15:11:46 +07:00
|
|
|
obj-$(CONFIG_JAILHOUSE_GUEST) += jailhouse.o
|
|
|
|
|
2017-08-28 13:47:20 +07:00
|
|
|
obj-$(CONFIG_EISA) += eisa.o
|
2008-05-07 17:39:56 +07:00
|
|
|
obj-$(CONFIG_PCSPKR_PLATFORM) += pcspeaker.o
|
2008-01-30 19:32:27 +07:00
|
|
|
|
2008-10-06 02:21:32 +07:00
|
|
|
obj-$(CONFIG_X86_CHECK_BIOS_CORRUPTION) += check.o
|
|
|
|
|
2009-01-23 17:56:16 +07:00
|
|
|
obj-$(CONFIG_SWIOTLB) += pci-swiotlb.o
|
2011-02-23 03:07:37 +07:00
|
|
|
obj-$(CONFIG_OF) += devicetree.o
|
uprobes, mm, x86: Add the ability to install and remove uprobes breakpoints
Add uprobes support to the core kernel, with x86 support.
This commit adds the kernel facilities, the actual uprobes
user-space ABI and perf probe support comes in later commits.
General design:
Uprobes are maintained in an rb-tree indexed by inode and offset
(the offset here is from the start of the mapping). For a unique
(inode, offset) tuple, there can be at most one uprobe in the
rb-tree.
Since the (inode, offset) tuple identifies a unique uprobe, more
than one user may be interested in the same uprobe. This provides
the ability to connect multiple 'consumers' to the same uprobe.
Each consumer defines a handler and a filter (optional). The
'handler' is run every time the uprobe is hit, if it matches the
'filter' criteria.
The first consumer of a uprobe causes the breakpoint to be
inserted at the specified address and subsequent consumers are
appended to this list. On subsequent probes, the consumer gets
appended to the existing list of consumers. The breakpoint is
removed when the last consumer unregisters. For all other
unregisterations, the consumer is removed from the list of
consumers.
Given a inode, we get a list of the mms that have mapped the
inode. Do the actual registration if mm maps the page where a
probe needs to be inserted/removed.
We use a temporary list to walk through the vmas that map the
inode.
- The number of maps that map the inode, is not known before we
walk the rmap and keeps changing.
- extending vm_area_struct wasn't recommended, it's a
size-critical data structure.
- There can be more than one maps of the inode in the same mm.
We add callbacks to the mmap methods to keep an eye on text vmas
that are of interest to uprobes. When a vma of interest is mapped,
we insert the breakpoint at the right address.
Uprobe works by replacing the instruction at the address defined
by (inode, offset) with the arch specific breakpoint
instruction. We save a copy of the original instruction at the
uprobed address.
This is needed for:
a. executing the instruction out-of-line (xol).
b. instruction analysis for any subsequent fixups.
c. restoring the instruction back when the uprobe is unregistered.
We insert or delete a breakpoint instruction, and this
breakpoint instruction is assumed to be the smallest instruction
available on the platform. For fixed size instruction platforms
this is trivially true, for variable size instruction platforms
the breakpoint instruction is typically the smallest (often a
single byte).
Writing the instruction is done by COWing the page and changing
the instruction during the copy, this even though most platforms
allow atomic writes of the breakpoint instruction. This also
mirrors the behaviour of a ptrace() memory write to a PRIVATE
file map.
The core worker is derived from KSM's replace_page() logic.
In essence, similar to KSM:
a. allocate a new page and copy over contents of the page that
has the uprobed vaddr
b. modify the copy and insert the breakpoint at the required
address
c. switch the original page with the copy containing the
breakpoint
d. flush page tables.
replace_page() is being replicated here because of some minor
changes in the type of pages and also because Hugh Dickins had
plans to improve replace_page() for KSM specific work.
Instruction analysis on x86 is based on instruction decoder and
determines if an instruction can be probed and determines the
necessary fixups after singlestep. Instruction analysis is done
at probe insertion time so that we avoid having to repeat the
same analysis every time a probe is hit.
A lot of code here is due to the improvement/suggestions/inputs
from Peter Zijlstra.
Changelog:
(v10):
- Add code to clear REX.B prefix as suggested by Denys Vlasenko
and Masami Hiramatsu.
(v9):
- Use insn_offset_modrm as suggested by Masami Hiramatsu.
(v7):
Handle comments from Peter Zijlstra:
- Dont take reference to inode. (expect inode to uprobe_register to be sane).
- Use PTR_ERR to set the return value.
- No need to take reference to inode.
- use PTR_ERR to return error value.
- register and uprobe_unregister share code.
(v5):
- Modified del_consumer as per comments from Peter.
- Drop reference to inode before dropping reference to uprobe.
- Use i_size_read(inode) instead of inode->i_size.
- Ensure uprobe->consumers is NULL, before __uprobe_unregister() is called.
- Includes errno.h as recommended by Stephen Rothwell to fix a build issue
on sparc defconfig
- Remove restrictions while unregistering.
- Earlier code leaked inode references under some conditions while
registering/unregistering.
- Continue the vma-rmap walk even if the intermediate vma doesnt
meet the requirements.
- Validate the vma found by find_vma before inserting/removing the
breakpoint
- Call del_consumer under mutex_lock.
- Use hash locks.
- Handle mremap.
- Introduce find_least_offset_node() instead of close match logic in
find_uprobe
- Uprobes no more depends on MM_OWNER; No reference to task_structs
while inserting/removing a probe.
- Uses read_mapping_page instead of grab_cache_page so that the pages
have valid content.
- pass NULL to get_user_pages for the task parameter.
- call SetPageUptodate on the new page allocated in write_opcode.
- fix leaking a reference to the new page under certain conditions.
- Include Instruction Decoder if Uprobes gets defined.
- Remove const attributes for instruction prefix arrays.
- Uses mm_context to know if the application is 32 bit.
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Also-written-by: Jim Keniston <jkenisto@us.ibm.com>
Reviewed-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Roland McGrath <roland@hack.frob.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
Cc: Anton Arapov <anton@redhat.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Denys Vlasenko <vda.linux@googlemail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linux-mm <linux-mm@kvack.org>
Link: http://lkml.kernel.org/r/20120209092642.GE16600@linux.vnet.ibm.com
[ Made various small edits to the commit log ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2012-02-09 16:26:42 +07:00
|
|
|
obj-$(CONFIG_UPROBES) += uprobes.o
|
x86: provide platform-devices for boot-framebuffers
The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
x86 causes troubles when loading multiple fbdev drivers. The global
"struct screen_info" does not provide any state-tracking about which
drivers use the FBs. request_mem_region() theoretically works, but
unfortunately vesafb/efifb ignore it due to quirks for broken boards.
Avoid this by creating a platform framebuffer devices with a pointer
to the "struct screen_info" as platform-data. Drivers can now create
platform-drivers and the driver-core will refuse multiple drivers being
active simultaneously.
We keep the screen_info available for backwards-compatibility. Drivers
can be converted in follow-up patches.
Different devices are created for VGA/VESA/EFI FBs to allow multiple
drivers to be loaded on distro kernels. We create:
- "vesa-framebuffer" for VBE/VESA graphics FBs
- "efi-framebuffer" for EFI FBs
- "platform-framebuffer" for everything else
This allows to load vesafb, efifb and others simultaneously and each
picks up only the supported FB types.
Apart from platform-framebuffer devices, this also introduces a
compatibility option for "simple-framebuffer" drivers which recently got
introduced for OF based systems. If CONFIG_X86_SYSFB is selected, we
try to match the screen_info against a simple-framebuffer supported
format. If we succeed, we create a "simple-framebuffer" device instead
of a platform-framebuffer.
This allows to reuse the simplefb.c driver across architectures and also
to introduce a SimpleDRM driver. There is no need to have vesafb.c,
efifb.c, simplefb.c and more just to have architecture specific quirks
in their setup-routines.
Instead, we now move the architecture specific quirks into x86-setup and
provide a generic simple-framebuffer. For backwards-compatibility (if
strange formats are used), we still allow vesafb/efifb to be loaded
simultaneously and pick up all remaining devices.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Link: http://lkml.kernel.org/r/1375445127-15480-4-git-send-email-dh.herrmann@gmail.com
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-08-02 19:05:22 +07:00
|
|
|
obj-y += sysfb.o
|
|
|
|
obj-$(CONFIG_X86_SYSFB) += sysfb_simplefb.o
|
2013-08-02 19:05:23 +07:00
|
|
|
obj-$(CONFIG_EFI) += sysfb_efi.o
|
2008-12-17 03:17:36 +07:00
|
|
|
|
2012-08-07 20:20:36 +07:00
|
|
|
obj-$(CONFIG_PERF_EVENTS) += perf_regs.o
|
x86, trace: Add irq vector tracepoints
[Purpose of this patch]
As Vaibhav explained in the thread below, tracepoints for irq vectors
are useful.
http://www.spinics.net/lists/mm-commits/msg85707.html
<snip>
The current interrupt traces from irq_handler_entry and irq_handler_exit
provide when an interrupt is handled. They provide good data about when
the system has switched to kernel space and how it affects the currently
running processes.
There are some IRQ vectors which trigger the system into kernel space,
which are not handled in generic IRQ handlers. Tracing such events gives
us the information about IRQ interaction with other system events.
The trace also tells where the system is spending its time. We want to
know which cores are handling interrupts and how they are affecting other
processes in the system. Also, the trace provides information about when
the cores are idle and which interrupts are changing that state.
<snip>
On the other hand, my usecase is tracing just local timer event and
getting a value of instruction pointer.
I suggested to add an argument local timer event to get instruction pointer before.
But there is another way to get it with external module like systemtap.
So, I don't need to add any argument to irq vector tracepoints now.
[Patch Description]
Vaibhav's patch shared a trace point ,irq_vector_entry/irq_vector_exit, in all events.
But there is an above use case to trace specific irq_vector rather than tracing all events.
In this case, we are concerned about overhead due to unwanted events.
So, add following tracepoints instead of introducing irq_vector_entry/exit.
so that we can enable them independently.
- local_timer_vector
- reschedule_vector
- call_function_vector
- call_function_single_vector
- irq_work_entry_vector
- error_apic_vector
- thermal_apic_vector
- threshold_apic_vector
- spurious_apic_vector
- x86_platform_ipi_vector
Also, introduce a logic switching IDT at enabling/disabling time so that a time penalty
makes a zero when tracepoints are disabled. Detailed explanations are as follows.
- Create trace irq handlers with entering_irq()/exiting_irq().
- Create a new IDT, trace_idt_table, at boot time by adding a logic to
_set_gate(). It is just a copy of original idt table.
- Register the new handlers for tracpoints to the new IDT by introducing
macros to alloc_intr_gate() called at registering time of irq_vector handlers.
- Add checking, whether irq vector tracing is on/off, into load_current_idt().
This has to be done below debug checking for these reasons.
- Switching to debug IDT may be kicked while tracing is enabled.
- On the other hands, switching to trace IDT is kicked only when debugging
is disabled.
In addition, the new IDT is created only when CONFIG_TRACING is enabled to avoid being
used for other purposes.
Signed-off-by: Seiji Aguchi <seiji.aguchi@hds.com>
Link: http://lkml.kernel.org/r/51C323ED.5050708@hds.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
2013-06-20 22:46:53 +07:00
|
|
|
obj-$(CONFIG_TRACING) += tracepoint.o
|
2016-11-30 01:43:27 +07:00
|
|
|
obj-$(CONFIG_SCHED_MC_PRIO) += itmt.o
|
2019-11-06 04:25:32 +07:00
|
|
|
obj-$(CONFIG_X86_UMIP) += umip.o
|
2012-08-07 20:20:36 +07:00
|
|
|
|
2017-10-14 03:02:00 +07:00
|
|
|
obj-$(CONFIG_UNWINDER_ORC) += unwind_orc.o
|
|
|
|
obj-$(CONFIG_UNWINDER_FRAME_POINTER) += unwind_frame.o
|
|
|
|
obj-$(CONFIG_UNWINDER_GUESS) += unwind_guess.o
|
x86/unwind: Add new unwind interface and implementations
The x86 stack dump code is a bit of a mess. dump_trace() uses
callbacks, and each user of it seems to have slightly different
requirements, so there are several slightly different callbacks floating
around.
Also there are some upcoming features which will need more changes to
the stack dump code, including the printing of stack pt_regs, reliable
stack detection for live patching, and a DWARF unwinder. Each of those
features would at least need more callbacks and/or callback interfaces,
resulting in a much bigger mess than what we have today.
Before doing all that, we should try to clean things up and replace
dump_trace() with something cleaner and more flexible.
The new unwinder is a simple state machine which was heavily inspired by
a suggestion from Andy Lutomirski:
https://lkml.kernel.org/r/CALCETrUbNTqaM2LRyXGRx=kVLRPeY5A3Pc6k4TtQxF320rUT=w@mail.gmail.com
It's also similar to the libunwind API:
http://www.nongnu.org/libunwind/man/libunwind(3).html
Some if its advantages:
- Simplicity: no more callback sprawl and less code duplication.
- Flexibility: it allows the caller to stop and inspect the stack state
at each step in the unwinding process.
- Modularity: the unwinder code, console stack dump code, and stack
metadata analysis code are all better separated so that changing one
of them shouldn't have much of an impact on any of the others.
Two implementations are added which conform to the new unwind interface:
- The frame pointer unwinder which is used for CONFIG_FRAME_POINTER=y.
- The "guess" unwinder which is used for CONFIG_FRAME_POINTER=n. This
isn't an "unwinder" per se. All it does is scan the stack for kernel
text addresses. But with no frame pointers, guesses are better than
nothing in most cases.
Suggested-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Byungchul Park <byungchul.park@lge.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Nilay Vaish <nilayvaish@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/6dc2f909c47533d213d0505f0a113e64585bec82.1474045023.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-09-17 02:18:12 +07:00
|
|
|
|
2020-09-07 20:15:39 +07:00
|
|
|
obj-$(CONFIG_AMD_MEM_ENCRYPT) += sev-es.o
|
2008-01-30 19:32:27 +07:00
|
|
|
###
|
|
|
|
# 64 bit specific files
|
|
|
|
ifeq ($(CONFIG_X86_64),y)
|
2009-02-18 00:09:24 +07:00
|
|
|
obj-$(CONFIG_AUDIT) += audit_64.o
|
|
|
|
|
2011-05-10 22:22:06 +07:00
|
|
|
obj-$(CONFIG_GART_IOMMU) += amd_gart_64.o aperture_64.o
|
2009-02-18 00:09:24 +07:00
|
|
|
|
2018-03-07 14:39:17 +07:00
|
|
|
obj-$(CONFIG_MMCONF_FAM10H) += mmconf-fam10h_64.o
|
2009-03-24 13:14:29 +07:00
|
|
|
obj-y += vsmp_64.o
|
2008-01-30 19:32:27 +07:00
|
|
|
endif
|
2018-10-10 00:30:33 +07:00
|
|
|
|
2020-03-09 07:57:51 +07:00
|
|
|
obj-$(CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT) += ima_arch.o
|