mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-07 12:25:00 -04:00
No description
- C 98.2%
- Assembly 1%
- Makefile 0.3%
- Shell 0.2%
- Python 0.1%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
0f4fbaea97Introduce BPF trampoline concept to allow kernel code to call into BPF programs with practically zero overhead. The trampoline generation logic is architecture dependent. It's converting native calling convention into BPF calling convention. BPF ISA is 64-bit (even on 32-bit architectures). The registers R1 to R5 are used to pass arguments into BPF functions. The main BPF program accepts only single argument "ctx" in R1. Whereas CPU native calling convention is different. x86-64 is passing first 6 arguments in registers and the rest on the stack. x86-32 is passing first 3 arguments in registers. sparc64 is passing first 6 in registers. And so on. The trampolines between BPF and kernel already exist. BPF_CALL_x macros in include/linux/filter.h statically compile trampolines from BPF into kernel helpers. They convert up to five u64 arguments into kernel C pointers and integers. On 64-bit architectures this BPF_to_kernel trampolines are nops. On 32-bit architecture they're meaningful. The opposite job kernel_to_BPF trampolines is done by CAST_TO_U64 macros and __bpf_trace_##call() shim functions in include/trace/bpf_probe.h. They convert kernel function arguments into array of u64s that BPF program consumes via R1=ctx pointer. This patch set is doing the same job as __bpf_trace_##call() static trampolines, but dynamically for any kernel function. There are ~22k global kernel functions that are attachable via nop at function entry. The function arguments and types are described in BTF. The job of btf_distill_func_proto() function is to extract useful information from BTF into "function model" that architecture dependent trampoline generators will use to generate assembly code to cast kernel function arguments into array of u64s. For example the kernel function eth_type_trans has two pointers. They will be casted to u64 and stored into stack of generated trampoline. The pointer to that stack space will be passed into BPF program in R1. On x86-64 such generated trampoline will consume 16 bytes of stack and two stores of %rdi and %rsi into stack. The verifier will make sure that only two u64 are accessed read-only by BPF program. The verifier will also recognize the precise type of the pointers being accessed and will not allow typecasting of the pointer to a different type within BPF program. The tracing use case in the datacenter demonstrated that certain key kernel functions have (like tcp_retransmit_skb) have 2 or more kprobes that are always active. Other functions have both kprobe and kretprobe. So it is essential to keep both kernel code and BPF programs executing at maximum speed. Hence generated BPF trampoline is re-generated every time new program is attached or detached to maintain maximum performance. To avoid the high cost of retpoline the attached BPF programs are called directly. __bpf_prog_enter/exit() are used to support per-program execution stats. In the future this logic will be optimized further by adding support for bpf_stats_enabled_key inside generated assembly code. Introduction of preemptible and sleepable BPF programs will completely remove the need to call to __bpf_prog_enter/exit(). Detach of a BPF program from the trampoline should not fail. To avoid memory allocation in detach path the half of the page is used as a reserve and flipped after each attach/detach. 2k bytes is enough to call 40+ BPF programs directly which is enough for BPF tracing use cases. This limit can be increased in the future. BPF_TRACE_FENTRY programs have access to raw kernel function arguments while BPF_TRACE_FEXIT programs have access to kernel return value as well. Often kprobe BPF program remembers function arguments in a map while kretprobe fetches arguments from a map and analyzes them together with return value. BPF_TRACE_FEXIT accelerates this typical use case. Recursion prevention for kprobe BPF programs is done via per-cpu bpf_prog_active counter. In practice that turned out to be a mistake. It caused programs to randomly skip execution. The tracing tools missed results they were looking for. Hence BPF trampoline doesn't provide builtin recursion prevention. It's a job of BPF program itself and will be addressed in the follow up patches. BPF trampoline is intended to be used beyond tracing and fentry/fexit use cases in the future. For example to remove retpoline cost from XDP programs. Change-Id: I839d8da5c0731a71bc6aad70d25a187eba0daa99 Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Andrii Nakryiko <andriin@fb.com> Acked-by: Song Liu <songliubraving@fb.com> Link: https://lore.kernel.org/bpf/20191114185720.1641606-5-ast@kernel.org |
||
| android | ||
| arch | ||
| block | ||
| certs | ||
| crypto | ||
| Documentation | ||
| drivers | ||
| fs | ||
| include | ||
| init | ||
| ipc | ||
| kernel | ||
| lib | ||
| LICENSES | ||
| mm | ||
| net | ||
| samples | ||
| scripts | ||
| security | ||
| sound | ||
| techpack | ||
| tools | ||
| usr | ||
| virt | ||
| .clang-format | ||
| .cocciconfig | ||
| .get_maintainer.ignore | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| Android.mk | ||
| Androidbp | ||
| build.config.aarch64 | ||
| build.config.allmodconfig | ||
| build.config.allmodconfig.aarch64 | ||
| build.config.allmodconfig.arm | ||
| build.config.allmodconfig.x86_64 | ||
| build.config.arm | ||
| build.config.common | ||
| build.config.db845c | ||
| build.config.gki | ||
| build.config.gki-debug.aarch64 | ||
| build.config.gki-debug.x86_64 | ||
| build.config.gki.aarch64 | ||
| build.config.gki.x86_64 | ||
| build.config.gki_kasan | ||
| build.config.gki_kasan.aarch64 | ||
| build.config.gki_kasan.x86_64 | ||
| build.config.gki_kprobes | ||
| build.config.gki_kprobes.aarch64 | ||
| build.config.gki_kprobes.x86_64 | ||
| build.config.hikey960 | ||
| build.config.msm.common | ||
| build.config.msm.gki | ||
| build.config.msm.lahaina | ||
| build.config.x86_64 | ||
| build.targets | ||
| COPYING | ||
| CREDITS | ||
| gen_headers_arm.bp | ||
| gen_headers_arm64.bp | ||
| gen_headers_arm64_auto.bp | ||
| gen_headers_arm_auto.bp | ||
| Kbuild | ||
| Kconfig | ||
| kernel_headers.py | ||
| LICENSE | ||
| MAINTAINERS | ||
| Makefile | ||
| modules.list.msm.lahaina | ||
| OWNERS | ||
| README | ||
| README.md | ||
How do I submit patches to Android Common Kernels
-
BEST: Make all of your changes to upstream Linux. If appropriate, backport to the stable releases. These patches will be merged automatically in the corresponding common kernels. If the patch is already in upstream Linux, post a backport of the patch that conforms to the patch requirements below.
-
LESS GOOD: Develop your patches out-of-tree (from an upstream Linux point-of-view). Unless these are fixing an Android-specific bug, these are very unlikely to be accepted unless they have been coordinated with kernel-team@android.com. If you want to proceed, post a patch that conforms to the patch requirements below.
Common Kernel patch requirements
- All patches must conform to the Linux kernel coding standards and pass
script/checkpatch.pl - Patches shall not break gki_defconfig or allmodconfig builds for arm, arm64, x86, x86_64 architectures (see https://source.android.com/setup/build/building-kernels)
- If the patch is not merged from an upstream branch, the subject must be tagged with the type of patch:
UPSTREAM:,BACKPORT:,FROMGIT:,FROMLIST:, orANDROID:. - All patches must have a
Change-Id:tag (see https://gerrit-review.googlesource.com/Documentation/user-changeid.html) - If an Android bug has been assigned, there must be a
Bug:tag. - All patches must have a
Signed-off-by:tag by the author and the submitter
Additional requirements are listed below based on patch type
Requirements for backports from mainline Linux: UPSTREAM:, BACKPORT:
- If the patch is a cherry-pick from Linux mainline with no changes at all
- tag the patch subject with
UPSTREAM:. - add upstream commit information with a
(cherry-picked from ...)line - Example:
- if the upstream commit message is
- tag the patch subject with
important patch from upstream
This is the detailed description of the important patch
Signed-off-by: Fred Jones <fred.jones@foo.org>
- then Joe Smith would upload the patch for the common kernel as
UPSTREAM: important patch from upstream
This is the detailed description of the important patch
Signed-off-by: Fred Jones <fred.jones@foo.org>
Bug: 135791357
Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
(cherry-picked from c31e73121f4c1ec41143423ac6ce3ce6dafdcec1)
Signed-off-by: Joe Smith <joe.smith@foo.org>
- If the patch requires any changes from the upstream version, tag the patch with
BACKPORT:instead ofUPSTREAM:.- use the same tags as
UPSTREAM: - add comments about the changes under the
(cherry-picked from ...)line - Example:
- use the same tags as
BACKPORT: important patch from upstream
This is the detailed description of the important patch
Signed-off-by: Fred Jones <fred.jones@foo.org>
Bug: 135791357
Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
(cherry-picked from c31e73121f4c1ec41143423ac6ce3ce6dafdcec1)
[ Resolved minor conflict in drivers/foo/bar.c ]
Signed-off-by: Joe Smith <joe.smith@foo.org>
Requirements for other backports: FROMGIT:, FROMLIST:,
- If the patch has been merged into an upstream maintainer tree, but has not yet
been merged into Linux mainline
- tag the patch subject with
FROMGIT: - add info on where the patch came from as
(cherry picked from commit <sha1> <repo> <branch>). This must be a stable maintainer branch (not rebased, so don't uselinux-nextfor example). - if changes were required, use
BACKPORT: FROMGIT: - Example:
- if the commit message in the maintainer tree is
- tag the patch subject with
important patch from upstream
This is the detailed description of the important patch
Signed-off-by: Fred Jones <fred.jones@foo.org>
- then Joe Smith would upload the patch for the common kernel as
FROMGIT: important patch from upstream
This is the detailed description of the important patch
Signed-off-by: Fred Jones <fred.jones@foo.org>
Bug: 135791357
(cherry picked from commit 878a2fd9de10b03d11d2f622250285c7e63deace
https://git.kernel.org/pub/scm/linux/kernel/git/foo/bar.git test-branch)
Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
Signed-off-by: Joe Smith <joe.smith@foo.org>
- If the patch has been submitted to LKML, but not accepted into any maintainer tree
- tag the patch subject with
FROMLIST: - add a
Link:tag with a link to the submittal on lore.kernel.org - if changes were required, use
BACKPORT: FROMLIST: - Example:
- tag the patch subject with
FROMLIST: important patch from upstream
This is the detailed description of the important patch
Signed-off-by: Fred Jones <fred.jones@foo.org>
Bug: 135791357
Link: https://lore.kernel.org/lkml/20190619171517.GA17557@someone.com/
Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
Signed-off-by: Joe Smith <joe.smith@foo.org>
Requirements for Android-specific patches: ANDROID:
- If the patch is fixing a bug to Android-specific code
- tag the patch subject with
ANDROID: - add a
Fixes:tag that cites the patch with the bug - Example:
- tag the patch subject with
ANDROID: fix android-specific bug in foobar.c
This is the detailed description of the important fix
Fixes: 1234abcd2468 ("foobar: add cool feature")
Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
Signed-off-by: Joe Smith <joe.smith@foo.org>
- If the patch is a new feature
- tag the patch subject with
ANDROID: - add a
Bug:tag with the Android bug (required for android-specific features)
- tag the patch subject with
Vibrator driver for HHG device
How to merge the driver into kernel source tree
-
Copy ${this_project}/drivers/hid/hid-aksys.c into ${your_kernel_root}/drivers/hid/
-
Compare and merge ${this_project}/drivers/hid/hid-ids.h into ${your_kernel_root}/drivers/hid/hid-ids.h : Add the following code before the last line of this file
#define USB_VENDER_ID_QUALCOMM 0x0a12 #define USB_VENDER_ID_TEMP_HHG_AKSY 0x1234 #define USB_PRODUCT_ID_AKSYS_HHG 0x1000 -
Merge ${this_project}/drivers/hid/Kconfig into ${your_kernel_root}/drivers/hid/Kconfig : Add the following code before the last line of this file
config HID_AKSYS_QRD tristate "AKSys gamepad USB adapter support" depends on HID ---help--- Support for AKSys gamepad USB adapter config AKSYS_QRD_FF bool "AKSys gamepad USB adapter force feedback support" depends on HID_AKSYS_QRD select INPUT_FF_MEMLESS ---help--- Say Y here if you have a AKSys gamepad USB adapter and want to enable force feedback support for it. -
Merge ${this_project}/drivers/hid/Makefile into ${your_kernel_root}/drivers/hid/Makefile : Add the following code at the end of this file
obj-$(CONFIG_HID_AKSYS_QRD) += hid-aksys.o -
Modify your kernel's default build configuration file. Add the following two lines:
CONFIG_HID_AKSYS_QRD=m CONFIG_AKSYS_QRD_FF=y