android_kernel_zuk_msm8996.git/include, branch master

Merge remote-tracking branch 'msm8998/lineage-20'

2024-10-13T08:06:36+00:00

string: uninline memcpy_and_pad

2024-03-07T17:17:12+00:00

commit 5c4e0a21fae877a7ef89be6dcc6263ec672372b8 upstream.

When building m68k:allmodconfig, recent versions of gcc generate the
following error if the length of UTS_RELEASE is less than 8 bytes.

  In function 'memcpy_and_pad',
    inlined from 'nvmet_execute_disc_identify' at
      drivers/nvme/target/discovery.c:268:2: arch/m68k/include/asm/string.h:72:25: error:
	'__builtin_memcpy' reading 8 bytes from a region of size 7

Discussions around the problem suggest that this only happens if an
architecture does not provide strlen(), if -ffreestanding is provided as
compiler option, and if CONFIG_FORTIFY_SOURCE=n. All of this is the case
for m68k. The exact reasons are unknown, but seem to be related to the
ability of the compiler to evaluate the return value of strlen() and
the resulting execution flow in memcpy_and_pad(). It would be possible
to work around the problem by using sizeof(UTS_RELEASE) instead of
strlen(UTS_RELEASE), but that would only postpone the problem until the
function is called in a similar way. Uninline memcpy_and_pad() instead
to solve the problem for good.

Suggested-by: Linus Torvalds 
Reviewed-by: Geert Uytterhoeven 
Acked-by: Andy Shevchenko 
Change-Id: I21516b6de0b5f3d8af30ebbbfcac2d4a495658ac
Signed-off-by: Guenter Roeck 
Signed-off-by: Linus Torvalds 
Signed-off-by: Alexander Grund

string.h: un-fortify memcpy_and_pad

2024-03-07T17:16:51+00:00

commit 1359798f9d4082eb04575efdd19512fbd9c28464 upstream.

The way I'd implemented the new helper memcpy_and_pad  with
__FORTIFY_INLINE caused compiler warnings for certain kernel
configurations.

This helper is only used in a single place at this time, and thus
doesn't benefit much from fortification. So simplify the code
by dropping fortification support for now.

Fixes: 01f33c336e2d "string.h: add memcpy_and_pad()"
Change-Id: I8bb1ec4490e27d450ba2042074d6f228b102462a
Signed-off-by: Martin Wilck 
Acked-by: Arnd Bergmann 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Alexander Grund

BACKPORT: string.h: add memcpy_and_pad()

2024-03-07T17:16:35+00:00

commit 01f33c336e2d298ea5d4ce5d6e5bcd12865cc30f upstream.

This helper function is useful for the nvme subsystem, and maybe
others.

Note: the warnings reported by the kbuild test robot for this patch
are actually generated by the use of CONFIG_PROFILE_ALL_BRANCHES
together with __FORTIFY_INLINE.

Change-Id: I5f7e1e9143ce9df88af0afd02aef971d5172bd3e
Signed-off-by: Martin Wilck 
Reviewed-by: Sagi Grimberg 
Signed-off-by: Christoph Hellwig 
[AG: Backported to 4.4]
Signed-off-by: Alexander Grund

input: Drop INPUT_PROP_NO_DUMMY_RELEASE bit

2024-02-19T11:53:46+00:00

 * INPUT_PROP_NO_DUMMY_RELEASE definition in this kernel collides with
   INPUT_PROP_ACCELEROMETER definition in bionic and upstream kernel. As
   a result, Android recognizes normal input devices like accelerometers
   and causes strange behaviors. There are no references to this bit in
   userspace and it is not in 4.9+ kernels, so let's drop this CAF jank.

Change-Id: Id9b4ec8d31470e663f533249c4bc4b9e94fd38be

CHROMIUM: remove Android's cgroup generic permissions checks

2024-01-10T15:40:04+00:00

The implementation is utterly broken, resulting in all processes being
allows to move tasks between sets (as long as they have access to the
"tasks" attribute), and upstream is heading towards checking only
capability anyway, so let's get rid of this code.

BUG=b:31790445,chromium:647994
TEST=Boot android container, examine logcat

Change-Id: I2f780a5992c34e52a8f2d0b3557fc9d490da2779
Signed-off-by: Dmitry Torokhov 
Reviewed-on: https://chromium-review.googlesource.com/394967
Reviewed-by: Ricky Zhou 
Reviewed-by: John Stultz

bpf: add BPF_J{LT,LE,SLT,SLE} instructions

2024-01-10T14:16:43+00:00

Currently, eBPF only understands BPF_JGT (>), BPF_JGE (>=),
BPF_JSGT (s>), BPF_JSGE (s>=) instructions, this means that
particularly *JLT/*JLE counterparts involving immediates need
to be rewritten from e.g. X < [IMM] by swapping arguments into
[IMM] > X, meaning the immediate first is required to be loaded
into a register Y := [IMM], such that then we can compare with
Y > X. Note that the destination operand is always required to
be a register.

This has the downside of having unnecessarily increased register
pressure, meaning complex program would need to spill other
registers temporarily to stack in order to obtain an unused
register for the [IMM]. Loading to registers will thus also
affect state pruning since we need to account for that register
use and potentially those registers that had to be spilled/filled
again. As a consequence slightly more stack space might have
been used due to spilling, and BPF programs are a bit longer
due to extra code involving the register load and potentially
required spill/fills.

Thus, add BPF_JLT (<), BPF_JLE (<=), BPF_JSLT (s<), BPF_JSLE (s<=)
counterparts to the eBPF instruction set. Modifying LLVM to
remove the NegateCC() workaround in a PoC patch at [1] and
allowing it to also emit the new instructions resulted in
cilium's BPF programs that are injected into the fast-path to
have a reduced program length in the range of 2-3% (e.g.
accumulated main and tail call sections from one of the object
file reduced from 4864 to 4729 insns), reduced complexity in
the range of 10-30% (e.g. accumulated sections reduced in one
of the cases from 116432 to 88428 insns), and reduced stack
usage in the range of 1-5% (e.g. accumulated sections from one
of the object files reduced from 824 to 784b).

The modification for LLVM will be incorporated in a backwards
compatible way. Plan is for LLVM to have i) a target specific
option to offer a possibility to explicitly enable the extension
by the user (as we have with -m target specific extensions today
for various CPU insns), and ii) have the kernel checked for
presence of the extensions and enable them transparently when
the user is selecting more aggressive options such as -march=native
in a bpf target context. (Other frontends generating BPF byte
code, e.g. ply can probe the kernel directly for its code
generation.)

  [1] https://github.com/borkmann/llvm/tree/bpf-insns

Change-Id: Ic56500aaeaf5f3ebdfda094ad6ef4666c82e18c5
Signed-off-by: Daniel Borkmann 
Acked-by: Alexei Starovoitov 
Signed-off-by: David S. Miller

bpf: free up BPF_JMP | BPF_CALL | BPF_X opcode

2024-01-10T14:16:43+00:00

free up BPF_JMP | BPF_CALL | BPF_X opcode to be used by actual
indirect call by register and use kernel internal opcode to
mark call instruction into bpf_tail_call() helper.

Change-Id: I1a45b8e3c13848c9689ce288d4862935ede97fa7
Signed-off-by: Alexei Starovoitov 
Acked-by: Daniel Borkmann 
Signed-off-by: David S. Miller

bpf: remove stubs for cBPF from arch code

2024-01-10T14:16:43+00:00

Remove the dummy bpf_jit_compile() stubs for eBPF JITs and make
that a single __weak function in the core that can be overridden
similarly to the eBPF one. Also remove stale pr_err() mentions
of bpf_jit_compile.

Change-Id: Iac221c09e9ae0879acdd7064d710c4f7cb8f478d
Signed-off-by: Daniel Borkmann 
Acked-by: Alexei Starovoitov 
Signed-off-by: David S. Miller

{nl,mac}80211: add rssi to mesh candidates

2024-01-06T12:32:12+00:00

When peering is in userspace, some implementations may want to control
which peers are accepted based on RSSI in addition to the information
elements being sent today.  Add signal level so that info is available
to clients.

Change-Id: Iae29de6adcb51c2dff58c0ea17e74cd988949991
Signed-off-by: Bob Copeland 
Signed-off-by: Johannes Berg 
Backported: Alexander Grund