Add a hook in irqtime_account_process_tick, which helps to get
information about the high load task.
Bug: 187904818
Change-Id: I644f7d66b09d047ca6b0a0fbd2915a6387c8c007
Signed-off-by: Liangliang Li <liliangliang@vivo.com>
With CONFIG_LTO_CLANG_FULL, LLVM drops all CFI jump table symbols
from vmlinux, which doesn't affect kernel functionality, but can
make stack traces and other kernel output that prints out jump
table addresses harder to read.
This change works around the issue for now by adding a script that
tells kallsyms about the missing jump table symbols, even though
they don't actually exist in the symbol table, and generates a
linker script to add the missing symbols to kernel modules.
Bug: 186152035
Bug: 187415564
Change-Id: Ic3c51751c756f2f5fb2a31229e16c3397eb6e666
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
This reverts commit fb4c1c2e9f.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I7b12040440bc2bedfbabc71d60339cb843e59570
This reverts commit 22163a8ec8.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ie256b7f1ed5b19f4600ff4c3681efaea5046adda
This reverts commit 1bbcc985d1.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I88427586de4df897c39bb3d48e8cba86ebf5c4bb
This reverts commit 1f2ef5a0f7.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I461f44ec54102dcf06ba73959a79172615cdb8fa
This reverts commit 9efd5df078.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ia22b608e4d017c6056e481d2ec819074b35810cf
This reverts commit 25ed8827cf.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9928cdc06a26b9db3052b93067c557011e53f735
This reverts commit 85a5a6875c.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ibe7639f73acc11b356f6b2f8f76011844c7f451b
This reverts commit f8e71c667e.
Fixes the ABI issues in 5.10.35 that at the moment, we can't handle due
to the KABI freeze. These are not patches that mean much for android
systems, and will be reverted the next KABI "reset" point.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I6684b40d913a86b79899220cba823a74aea5923f
Changes in 5.10.35
mips: Do not include hi and lo in clobber list for R6
netfilter: conntrack: Make global sysctls readonly in non-init netns
net: usb: ax88179_178a: initialize local variables before use
igb: Enable RSS for Intel I211 Ethernet Controller
bpf: Fix masking negation logic upon negative dst register
bpf: Fix leakage of uninitialized bpf stack under speculation
net: qrtr: Avoid potential use after free in MHI send
perf data: Fix error return code in perf_data__create_dir()
capabilities: require CAP_SETFCAP to map uid 0
perf ftrace: Fix access to pid in array when setting a pid filter
tools/cgroup/slabinfo.py: updated to work on current kernel
driver core: add a min_align_mask field to struct device_dma_parameters
swiotlb: add a IO_TLB_SIZE define
swiotlb: factor out an io_tlb_offset helper
swiotlb: factor out a nr_slots helper
swiotlb: clean up swiotlb_tbl_unmap_single
swiotlb: refactor swiotlb_tbl_map_single
swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single
swiotlb: respect min_align_mask
nvme-pci: set min_align_mask
ovl: fix leaked dentry
ovl: allow upperdir inside lowerdir
ALSA: usb-audio: Add MIDI quirk for Vox ToneLab EX
USB: Add LPM quirk for Lenovo ThinkPad USB-C Dock Gen2 Ethernet
USB: Add reset-resume quirk for WD19's Realtek Hub
platform/x86: thinkpad_acpi: Correct thermal sensor allocation
perf/core: Fix unconditional security_locked_down() call
vfio: Depend on MMU
Linux 5.10.35
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iff7d5abe7b821f453bbe4d9dad94dfd35fe0a082
commit 08ef1af4de upstream.
Currently, the lockdown state is queried unconditionally, even though
its result is used only if the PERF_SAMPLE_REGS_INTR bit is set in
attr.sample_type. While that doesn't matter in case of the Lockdown LSM,
it causes trouble with the SELinux's lockdown hook implementation.
SELinux implements the locked_down hook with a check whether the current
task's type has the corresponding "lockdown" class permission
("integrity" or "confidentiality") allowed in the policy. This means
that calling the hook when the access control decision would be ignored
generates a bogus permission check and audit record.
Fix this by checking sample_type first and only calling the hook when
its result would be honored.
Fixes: b0c8fdc7fd ("lockdown: Lock down perf when in confidentiality mode")
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Paul Moore <paul@paul-moore.com>
Link: https://lkml.kernel.org/r/20210224215628.192519-1-omosnace@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit: 1f221a0d0d
swiotlb: respect min_align_mask
Respect the min_align_mask in struct device_dma_parameters in swiotlb.
There are two parts to it:
1) for the lower bits of the alignment inside the io tlb slot, just
extent the size of the allocation and leave the start of the slot
empty
2) for the high bits ensure we find a slot that matches the high bits
of the alignment to avoid wasting too much memory
Based on an earlier patch from Jianxiong Gao <jxgao@google.com>.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jianxiong Gao <jxgao@google.com>
Tested-by: Jianxiong Gao <jxgao@google.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jianxiong Gao <jxgao@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit: 16fc3cef33
swiotlb_tbl_map_single currently nevers sets a tlb_addr that is not
aligned to the tlb bucket size. But we're going to add such a case
soon, for which this adjustment would be bogus.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jianxiong Gao <jxgao@google.com>
Tested-by: Jianxiong Gao <jxgao@google.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jianxiong Gao <jxgao@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit: ca10d0f8e5
swiotlb: clean up swiotlb_tbl_unmap_single
Remove a layer of pointless indentation, replace a hard to follow
ternary expression with a plain if/else.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jianxiong Gao <jxgao@google.com>
Tested-by: Jianxiong Gao <jxgao@google.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jianxiong Gao <jxgao@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit db2e718a47 ]
cap_setfcap is required to create file capabilities.
Since commit 8db6c34f1d ("Introduce v3 namespaced file capabilities"),
a process running as uid 0 but without cap_setfcap is able to work
around this as follows: unshare a new user namespace which maps parent
uid 0 into the child namespace.
While this task will not have new capabilities against the parent
namespace, there is a loophole due to the way namespaced file
capabilities are represented as xattrs. File capabilities valid in
userns 1 are distinguished from file capabilities valid in userns 2 by
the kuid which underlies uid 0. Therefore the restricted root process
can unshare a new self-mapping namespace, add a namespaced file
capability onto a file, then use that file capability in the parent
namespace.
To prevent that, do not allow mapping parent uid 0 if the process which
opened the uid_map file does not have CAP_SETFCAP, which is the
capability for setting file capabilities.
As a further wrinkle: a task can unshare its user namespace, then open
its uid_map file itself, and map (only) its own uid. In this case we do
not have the credential from before unshare, which was potentially more
restricted. So, when creating a user namespace, we record whether the
creator had CAP_SETFCAP. Then we can use that during map_write().
With this patch:
1. Unprivileged user can still unshare -Ur
ubuntu@caps:~$ unshare -Ur
root@caps:~# logout
2. Root user can still unshare -Ur
ubuntu@caps:~$ sudo bash
root@caps:/home/ubuntu# unshare -Ur
root@caps:/home/ubuntu# logout
3. Root user without CAP_SETFCAP cannot unshare -Ur:
root@caps:/home/ubuntu# /sbin/capsh --drop=cap_setfcap --
root@caps:/home/ubuntu# /sbin/setcap cap_setfcap=p /sbin/setcap
unable to set CAP_SETFCAP effective capability: Operation not permitted
root@caps:/home/ubuntu# unshare -Ur
unshare: write failed /proc/self/uid_map: Operation not permitted
Note: an alternative solution would be to allow uid 0 mappings by
processes without CAP_SETFCAP, but to prevent such a namespace from
writing any file capabilities. This approach can be seen at [1].
Background history: commit 95ebabde38 ("capabilities: Don't allow
writing ambiguous v3 file capabilities") tried to fix the issue by
preventing v3 fscaps to be written to disk when the root uid would map
to the same uid in nested user namespaces. This led to regressions for
various workloads. For example, see [2]. Ultimately this is a valid
use-case we have to support meaning we had to revert this change in
3b0c2d3eaa ("Revert 95ebabde38 ("capabilities: Don't allow writing
ambiguous v3 file capabilities")").
Link: https://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux.git/log/?h=2021-04-15/setfcap-nsfscaps-v4 [1]
Link: https://github.com/containers/buildah/issues/3071 [2]
Signed-off-by: Serge Hallyn <serge@hallyn.com>
Reviewed-by: Andrew G. Morgan <morgan@kernel.org>
Tested-by: Christian Brauner <christian.brauner@ubuntu.com>
Reviewed-by: Christian Brauner <christian.brauner@ubuntu.com>
Tested-by: Giuseppe Scrivano <gscrivan@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 801c6058d1 upstream.
The current implemented mechanisms to mitigate data disclosure under
speculation mainly address stack and map value oob access from the
speculative domain. However, Piotr discovered that uninitialized BPF
stack is not protected yet, and thus old data from the kernel stack,
potentially including addresses of kernel structures, could still be
extracted from that 512 bytes large window. The BPF stack is special
compared to map values since it's not zero initialized for every
program invocation, whereas map values /are/ zero initialized upon
their initial allocation and thus cannot leak any prior data in either
domain. In the non-speculative domain, the verifier ensures that every
stack slot read must have a prior stack slot write by the BPF program
to avoid such data leaking issue.
However, this is not enough: for example, when the pointer arithmetic
operation moves the stack pointer from the last valid stack offset to
the first valid offset, the sanitation logic allows for any intermediate
offsets during speculative execution, which could then be used to
extract any restricted stack content via side-channel.
Given for unprivileged stack pointer arithmetic the use of unknown
but bounded scalars is generally forbidden, we can simply turn the
register-based arithmetic operation into an immediate-based arithmetic
operation without the need for masking. This also gives the benefit
of reducing the needed instructions for the operation. Given after
the work in 7fedb63a83 ("bpf: Tighten speculative pointer arithmetic
mask"), the aux->alu_limit already holds the final immediate value for
the offset register with the known scalar. Thus, a simple mov of the
immediate to AX register with using AX as the source for the original
instruction is sufficient and possible now in this case.
Reported-by: Piotr Krysiuk <piotras@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Piotr Krysiuk <piotras@gmail.com>
Reviewed-by: Piotr Krysiuk <piotras@gmail.com>
Reviewed-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b9b34ddbe2 upstream.
The negation logic for the case where the off_reg is sitting in the
dst register is not correct given then we cannot just invert the add
to a sub or vice versa. As a fix, perform the final bitwise and-op
unconditionally into AX from the off_reg, then move the pointer from
the src to dst and finally use AX as the source for the original
pointer arithmetic operation such that the inversion yields a correct
result. The single non-AX mov in between is possible given constant
blinding is retaining it as it's not an immediate based operation.
Fixes: 979d63d50c ("bpf: prevent out of bounds speculation on pointer arithmetic")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Piotr Krysiuk <piotras@gmail.com>
Reviewed-by: Piotr Krysiuk <piotras@gmail.com>
Reviewed-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We already applied the 'vendor hook' for Dtask Debugging Information
in below issue.
(https://issuetracker.google.com/issues/162776704)
There are vendor hook call in mutex and rw_semaphore, but not for rt_mutex
Please refer to description in details as below,
1. Description
This feature writes rt mutex lock waiting information
on the task_struct structure. We can check mutex information and
mutex owner through the kernel log and custom analysis tools.
Like the previous feature in mutex and rw semaphore,
added data can be checked by ramdump analysis.
2. Vendor Hook Position
1) VENDOR_DATA
- struct task_struct in sched.h
VENDOR_DATA_ARRAY(2)
[0] : type // RTmutex (Mutex, Rwsem, ...)
[1] : pointer // address of lock
2) VENDOR_HOOKs
- __rt_mutex_slowlock() in kernel/locking/rtmutex.c
3. Example
- SysRq-w in kernel log
...
[ 54.164463] [3: kworker/u16:3: 253] kworker/3:2 D12736 418 2 0x00000228
[ 54.164497] [3: kworker/u16:3: 253] RTmutex: 0xffffffc051fa3ae8: owner[sh :9003]
[ 54.167812] [3: kworker/u16:3: 253] sh D12848 9003 6900 0x04000200
[ 54.167824] [3: kworker/u16:3: 253] RTmutex: 0xffffffc051fa3b08: owner[kworker/3:2 :418]
...
Bug: 186567468
Signed-off-by: JINHO LIM <jordan.lim@samsung.com>
Change-Id: I93f9753be0b2c1fa1a6eaea09379d54c31d1ebcf
(cherry picked from commit e289faa9f1)
Vendor kernel modules may implement irq balancers, which could
take irq desc lock of an irq and then based on current affinity
mask or affinity hint, reconfigure the affinity of that irq.
For example : For an irq, for which affinity is broken i.e. all
the cpus in its affinity mask have gone offline. For such irqs,
we might want to reset the affinity, when the original set of
affined cpus, come back online. desc->affinity_hint can be used
for figuring out the original affinity. So, the sequence for doing
this becomes:
desc = irq_to_desc(i);
raw_spin_lock(&desc->lock);
affinity = desc->affinity_hint;
raw_spin_unlock(&desc->lock);
irq_set_affinity_hint(i, affinity);
Here, we need to release the desc lock before calling the exported
api irq_set_affinity_hint(). This creates a window where, after
unlocking desc lock and before calling irq_set_affinity_hint(),
where this setting can race with other irq_set_affinity_hint()
callers. So, export irq_do_set_affinity() symbol to provide an
api, which can be called with desc lock held.
Bug: 187157600
Change-Id: Ifad88bfaa1e7eec09c3fe5a9dd7d1d421362b41e
Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
In Android GKI, CONFIG_FAIR_GROUP_SCHED is enabled [1] to help
prioritize important work. Given that CPU shares of root cgroup
can't be changed, leaving the tasks inside root cgroup will give
them higher share compared to the other tasks inside important
cgroups. This is mitigated by moving all tasks inside root cgroup to
a different cgroup after Android is booted. However, there are many
kernel tasks stuck in the root cgroup after the boot.
It is possible to relax kernel threads and kworkers migrations under
certain scenarios. However the patch [2] posted at upstream is not
accepted. Hence add a restricted vendor hook to notify modules when a
kernel thread is requested for cgroup migration. The modules can relax
the restrictions forced by the kernel and allow the cgroup migration.
[1] f08f049de1
[2] https://lore.kernel.org/lkml/1617714261-18111-1-git-send-email-pkondeti@codeaurora.org
Bug: 184594949
Change-Id: I445a170ba797c8bece3b4b59b7a42cdd85438f1f
Signed-off-by: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
Util-clamp places tasks in different buckets based on their clamp values
for performance reasons. However, the size of buckets is currently
computed using a rounding division, which can lead to an off-by-one
error in some configurations.
For instance, with 20 buckets, the bucket size will be 1024/20=51. A
task with a clamp of 1024 will be mapped to bucket id 1024/51=20. Sadly,
correct indexes are in range [0,19], hence leading to an out of bound
memory access.
Clamp the bucket id to fix the issue.
Bug: 186415778
Fixes: 69842cba9a ("sched/uclamp: Add CPU's clamp buckets refcounting")
Suggested-by: Qais Yousef <qais.yousef@arm.com>
Signed-off-by: Quentin Perret <qperret@google.com>
Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Link: https://lore.kernel.org/r/20210430151412.160913-1-qperret@google.com
Change-Id: Ibc28662de5554f80f97533b60e747f8a6e871c56
Changes in 5.10.33
vhost-vdpa: protect concurrent access to vhost device iotlb
gpio: omap: Save and restore sysconfig
KEYS: trusted: Fix TPM reservation for seal/unseal
vdpa/mlx5: Set err = -ENOMEM in case dma_map_sg_attrs fails
pinctrl: lewisburg: Update number of pins in community
block: return -EBUSY when there are open partitions in blkdev_reread_part
pinctrl: core: Show pin numbers for the controllers with base = 0
arm64: dts: allwinner: Revert SD card CD GPIO for Pine64-LTS
bpf: Permits pointers on stack for helper calls
bpf: Allow variable-offset stack access
bpf: Refactor and streamline bounds check into helper
bpf: Tighten speculative pointer arithmetic mask
locking/qrwlock: Fix ordering in queued_write_lock_slowpath()
perf/x86/intel/uncore: Remove uncore extra PCI dev HSWEP_PCI_PCU_3
perf/x86/kvm: Fix Broadwell Xeon stepping in isolation_ucodes[]
perf auxtrace: Fix potential NULL pointer dereference
perf map: Fix error return code in maps__clone()
HID: google: add don USB id
HID: alps: fix error return code in alps_input_configured()
HID cp2112: fix support for multiple gpiochips
HID: wacom: Assign boolean values to a bool variable
soc: qcom: geni: shield geni_icc_get() for ACPI boot
dmaengine: xilinx: dpdma: Fix descriptor issuing on video group
dmaengine: xilinx: dpdma: Fix race condition in done IRQ
ARM: dts: Fix swapped mmc order for omap3
net: geneve: check skb is large enough for IPv4/IPv6 header
dmaengine: tegra20: Fix runtime PM imbalance on error
s390/entry: save the caller of psw_idle
arm64: kprobes: Restore local irqflag if kprobes is cancelled
xen-netback: Check for hotplug-status existence before watching
cavium/liquidio: Fix duplicate argument
kasan: fix hwasan build for gcc
csky: change a Kconfig symbol name to fix e1000 build error
ia64: fix discontig.c section mismatches
ia64: tools: remove duplicate definition of ia64_mf() on ia64
x86/crash: Fix crash_setup_memmap_entries() out-of-bounds access
net: hso: fix NULL-deref on disconnect regression
USB: CDC-ACM: fix poison/unpoison imbalance
Linux 5.10.33
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I638db3c919ad938eaaaac3d687175252edcd7990
If the timestamp of the .config file is updated, config_data.gz is
regenerated, then vmlinux is re-linked. This occurs even if the content
of the .config has not changed at all.
This issue was mitigated by commit 67424f61f8 ("kconfig: do not write
.config if the content is the same"); Kconfig does not update the
.config when it ends up with the identical configuration.
The issue is remaining when the .config is created by *_defconfig with
some config fragment(s) applied on top.
This is typical for powerpc and mips, where several *_defconfig targets
are constructed by using merge_config.sh.
One workaround is to have the copy of the .config. The filechk rule
updates the copy, kernel/config_data, by checking the content instead
of the timestamp.
With this commit, the second run with the same configuration avoids
the needless rebuilds.
$ make ARCH=mips defconfig all
[ snip ]
$ make ARCH=mips defconfig all
*** Default configuration is based on target '32r2el_defconfig'
Using ./arch/mips/configs/generic_defconfig as base
Merging arch/mips/configs/generic/32r2.config
Merging arch/mips/configs/generic/el.config
Merging ./arch/mips/configs/generic/board-boston.config
Merging ./arch/mips/configs/generic/board-ni169445.config
Merging ./arch/mips/configs/generic/board-ocelot.config
Merging ./arch/mips/configs/generic/board-ranchu.config
Merging ./arch/mips/configs/generic/board-sead-3.config
Merging ./arch/mips/configs/generic/board-xilfpga.config
#
# configuration written to .config
#
SYNC include/config/auto.conf
CALL scripts/checksyscalls.sh
CALL scripts/atomic/check-atomics.sh
CHK include/generated/compile.h
CHK include/generated/autoksyms.h
Reported-by: Elliot Berman <eberman@codeaurora.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Bug: 179648610
(cherry picked from commit b33976d90d1ea7652fff662dcc2234f352346a33
https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
kbuild)
[eberman: Fixed minor conflicts in kernel/.gitignore]
Change-Id: I8c93147c8d5a48d0f5e9abf855870b10c1a24efc
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Currently, the sched code checks if the rq clock has been
updated after its lock has been held when CONFIG_SCHED_DEBUG
is enabled. It tracks this by clearing the RQCF_UPDATED bit
when a lock is acquired and setting it upon a subsequent
update_rq_clock() call. It warns if rq clock is read without
RQCF_UPDATED flag indicating the code path missed updating
the clock.
When migrate_tasks() is called during a pause_cpus() event,
the local variable orf is updated with the contents of *rf,
prior to the call to update_rq_clock(). As a result, when
migrate_tasks() restores *rf from the local variable the
RQCF_UPDATED flag is lost. This clearing out of the
RQCF_UPDATED flag leads to a warning when the next task
is being pushed out.
For example in migrate_tasks()
orf = rf; // save flags, RQCF_UPDATE cleared
update_rq_clock() // set RQCF_UPDATE
for()
...
__migrate_task(dead_rq, new_cpu)
...
--> if migration, restore dead_rq's flags with orf.
--> We loose RQCF_UPDATE
rq_relock(dead_rq, orf)
This leaves the current cpu's rq clock_update_flags with the
RQCF_UPDATED flag cleared, an error condition with
CONFIG_SCHED_DEBUG enabled.
Fix the issue for by ensuring that the local variable orf
has the RQCF_UPDATED flag set, allowing the current
CPU's rq to have the flag set and leaving it in a good state
for future usage.
pause_cpus() is currently Android specific. As cpu_pause does
not rely on stop_machine_cpuslocked() like the regular
hotunplug path does, there's a risk for another CPU to
read the rq_clock, after we cleared RQCF_UPDATE, when using
pause_cpus(). This change will have little or no impact outside
of Android currently. If pause_cpus() or drain_rq_cpu_stop()
are merged upstream this change should be merged as well.
Bug: 186222712
Change-Id: Id241122e1449cdd4dcd15f94eb68735b40e3d6f5
Signed-off-by: Stephen Dickey <dickey@codeaurora.org>
[ Upstream commit 84a24bf8c5 ]
While this code is executed with the wait_lock held, a reader can
acquire the lock without holding wait_lock. The writer side loops
checking the value with the atomic_cond_read_acquire(), but only truly
acquires the lock when the compare-and-exchange is completed
successfully which isn’t ordered. This exposes the window between the
acquire and the cmpxchg to an A-B-A problem which allows reads
following the lock acquisition to observe values speculatively before
the write lock is truly acquired.
We've seen a problem in epoll where the reader does a xchg while
holding the read lock, but the writer can see a value change out from
under it.
Writer | Reader
--------------------------------------------------------------------------------
ep_scan_ready_list() |
|- write_lock_irq() |
|- queued_write_lock_slowpath() |
|- atomic_cond_read_acquire() |
| read_lock_irqsave(&ep->lock, flags);
--> (observes value before unlock) | chain_epi_lockless()
| | epi->next = xchg(&ep->ovflist, epi);
| | read_unlock_irqrestore(&ep->lock, flags);
| |
| atomic_cmpxchg_relaxed() |
|-- READ_ONCE(ep->ovflist); |
A core can order the read of the ovflist ahead of the
atomic_cmpxchg_relaxed(). Switching the cmpxchg to use acquire
semantics addresses this issue at which point the atomic_cond_read can
be switched to use relaxed semantics.
Fixes: b519b56e37 ("locking/qrwlock: Use atomic_cond_read_acquire() when spinning in qrwlock")
Signed-off-by: Ali Saidi <alisaidi@amazon.com>
[peterz: use try_cmpxchg()]
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Steve Capper <steve.capper@arm.com>
Acked-by: Will Deacon <will@kernel.org>
Acked-by: Waiman Long <longman@redhat.com>
Tested-by: Steve Capper <steve.capper@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7fedb63a83 ]
This work tightens the offset mask we use for unprivileged pointer arithmetic
in order to mitigate a corner case reported by Piotr and Benedict where in
the speculative domain it is possible to advance, for example, the map value
pointer by up to value_size-1 out-of-bounds in order to leak kernel memory
via side-channel to user space.
Before this change, the computed ptr_limit for retrieve_ptr_limit() helper
represents largest valid distance when moving pointer to the right or left
which is then fed as aux->alu_limit to generate masking instructions against
the offset register. After the change, the derived aux->alu_limit represents
the largest potential value of the offset register which we mask against which
is just a narrower subset of the former limit.
For minimal complexity, we call sanitize_ptr_alu() from 2 observation points
in adjust_ptr_min_max_vals(), that is, before and after the simulated alu
operation. In the first step, we retieve the alu_state and alu_limit before
the operation as well as we branch-off a verifier path and push it to the
verification stack as we did before which checks the dst_reg under truncation,
in other words, when the speculative domain would attempt to move the pointer
out-of-bounds.
In the second step, we retrieve the new alu_limit and calculate the absolute
distance between both. Moreover, we commit the alu_state and final alu_limit
via update_alu_sanitation_state() to the env's instruction aux data, and bail
out from there if there is a mismatch due to coming from different verification
paths with different states.
Reported-by: Piotr Krysiuk <piotras@gmail.com>
Reported-by: Benedict Schlueter <benedict.schlueter@rub.de>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Tested-by: Benedict Schlueter <benedict.schlueter@rub.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 073815b756 ]
Move the bounds check in adjust_ptr_min_max_vals() into a small helper named
sanitize_check_bounds() in order to simplify the former a bit.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 01f810ace9 ]
Before this patch, variable offset access to the stack was dissalowed
for regular instructions, but was allowed for "indirect" accesses (i.e.
helpers). This patch removes the restriction, allowing reading and
writing to the stack through stack pointers with variable offsets. This
makes stack-allocated buffers more usable in programs, and brings stack
pointers closer to other types of pointers.
The motivation is being able to use stack-allocated buffers for data
manipulation. When the stack size limit is sufficient, allocating
buffers on the stack is simpler than per-cpu arrays, or other
alternatives.
In unpriviledged programs, variable-offset reads and writes are
disallowed (they were already disallowed for the indirect access case)
because the speculative execution checking code doesn't support them.
Additionally, when writing through a variable-offset stack pointer, if
any pointers are in the accessible range, there's possilibities of later
leaking pointers because the write cannot be tracked precisely.
Writes with variable offset mark the whole range as initialized, even
though we don't know which stack slots are actually written. This is in
order to not reject future reads to these slots. Note that this doesn't
affect writes done through helpers; like before, helpers need the whole
stack range to be initialized to begin with.
All the stack slots are in range are considered scalars after the write;
variable-offset register spills are not tracked.
For reads, all the stack slots in the variable range needs to be
initialized (but see above about what writes do), otherwise the read is
rejected. All register spilled in stack slots that might be read are
marked as having been read, however reads through such pointers don't do
register filling; the target register will always be either a scalar or
a constant zero.
Signed-off-by: Andrei Matei <andreimatei1@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20210207011027.676572-2-andreimatei1@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Add vh before and after __update_load_avg_se
in order to collect load change of tasks.
Bug: 185557444
Change-Id: I210973f7e388164b68ed766074d1420cdf9d4c32
Signed-off-by: JianMin Liu <jian-min.liu@mediatek.com>
add vendor hooks to compute new cpu freq for oem feature.
Bug: 183674818
Signed-off-by: lijianzhong <lijianzhong@xiaomi.com>
Change-Id: I232d2e1ae885d6736eca9e4709870f4272b4873d
The broadcast device is switched to oneshot mode when the system switches
to oneshot mode. If a broadcast clock event device is registered after the
system switched to oneshot mode, it will stay in periodic mode forever.
Ensure that a late registered device which is selected as broadcast device
is initialized in oneshot mode when the system already uses oneshot mode.
[ tglx: Massage changelog ]
Signed-off-by: Jindong Yue <jindong.yue@nxp.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20210331083318.21794-1-jindong.yue@nxp.com
(cherry picked from commit 9c336c9935
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core)
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: If570b8d396f84add2266150bc85d5c82c45bcb0f
Bug: 185092876
Exporting the symbol find_user()& free_uid(), in which ko module can get
user task information for tuning.
Bug: 183674818
Signed-off-by: lijianzhong <lijianzhong@xiaomi.com>
Change-Id: I12135c0af312904dd21b6f074beda086ad5ece98
add vendor hooks for cpu affinity to support oem's feature.
Bug: 183674818
Signed-off-by: lijianzhong <lijianzhong@xiaomi.com>
Change-Id: I3402abec4d9faa08f564409bfb8db8d7902f3aa2
Changes in 5.10.32
net/sctp: fix race condition in sctp_destroy_sock
mtd: rawnand: mtk: Fix WAITRDY break condition and timeout
Input: nspire-keypad - enable interrupts only when opened
gpio: sysfs: Obey valid_mask
dmaengine: idxd: Fix clobbering of SWERR overflow bit on writeback
dmaengine: idxd: fix delta_rec and crc size field for completion record
dmaengine: idxd: fix opcap sysfs attribute output
dmaengine: idxd: fix wq size store permission state
dmaengine: dw: Make it dependent to HAS_IOMEM
dmaengine: Fix a double free in dma_async_device_register
dmaengine: plx_dma: add a missing put_device() on error path
dmaengine: idxd: fix wq cleanup of WQCFG registers
ACPI: x86: Call acpi_boot_table_init() after acpi_table_upgrade()
ARM: dts: Drop duplicate sha2md5_fck to fix clk_disable race
ARM: dts: Fix moving mmc devices with aliases for omap4 & 5
lockdep: Add a missing initialization hint to the "INFO: Trying to register non-static key" message
arc: kernel: Return -EFAULT if copy_to_user() fails
iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_enqueue_hcmd()
xfrm: BEET mode doesn't support fragments for inner packets
ASoC: max98373: Changed amp shutdown register as volatile
ASoC: max98373: Added 30ms turn on/off time delay
gpu/xen: Fix a use after free in xen_drm_drv_init
neighbour: Disregard DEAD dst in neigh_update
ARM: keystone: fix integer overflow warning
ARM: omap1: fix building with clang IAS
drm/msm: Fix a5xx/a6xx timestamps
ASoC: fsl_esai: Fix TDM slot setup for I2S mode
scsi: scsi_transport_srp: Don't block target in SRP_PORT_LOST state
iwlwifi: add support for Qu with AX201 device
net: ieee802154: stop dump llsec keys for monitors
net: ieee802154: forbid monitor for add llsec key
net: ieee802154: forbid monitor for del llsec key
net: ieee802154: stop dump llsec devs for monitors
net: ieee802154: forbid monitor for add llsec dev
net: ieee802154: forbid monitor for del llsec dev
net: ieee802154: stop dump llsec devkeys for monitors
net: ieee802154: forbid monitor for add llsec devkey
net: ieee802154: forbid monitor for del llsec devkey
net: ieee802154: stop dump llsec seclevels for monitors
net: ieee802154: forbid monitor for add llsec seclevel
pcnet32: Use pci_resource_len to validate PCI resource
mac80211: clear sta->fast_rx when STA removed from 4-addr VLAN
virt_wifi: Return micros for BSS TSF values
lib: fix kconfig dependency on ARCH_WANT_FRAME_POINTERS
Input: s6sy761 - fix coordinate read bit shift
Input: i8042 - fix Pegatron C15B ID entry
HID: wacom: set EV_KEY and EV_ABS only for non-HID_GENERIC type of devices
dm verity fec: fix misaligned RS roots IO
readdir: make sure to verify directory entry for legacy interfaces too
arm64: fix inline asm in load_unaligned_zeropad()
arm64: alternatives: Move length validation in alternative_{insn, endif}
vfio/pci: Add missing range check in vfio_pci_mmap
riscv: Fix spelling mistake "SPARSEMEM" to "SPARSMEM"
scsi: libsas: Reset num_scatter if libata marks qc as NODATA
ixgbe: fix unbalanced device enable/disable in suspend/resume
netfilter: flowtable: fix NAT IPv6 offload mangling
netfilter: conntrack: do not print icmpv6 as unknown via /proc
ice: Fix potential infinite loop when using u8 loop counter
libnvdimm/region: Fix nvdimm_has_flush() to handle ND_REGION_ASYNC
netfilter: bridge: add pre_exit hooks for ebtable unregistration
netfilter: arp_tables: add pre_exit hook for table unregister
libbpf: Fix potential NULL pointer dereference
net: macb: fix the restore of cmp registers
net/mlx5e: fix ingress_ifindex check in mlx5e_flower_parse_meta
netfilter: nft_limit: avoid possible divide error in nft_limit_init
net/mlx5e: Fix setting of RS FEC mode
net: davicom: Fix regulator not turned off on failed probe
net: sit: Unregister catch-all devices
net: ip6_tunnel: Unregister catch-all devices
mm: ptdump: fix build failure
net: Make tcp_allowed_congestion_control readonly in non-init netns
i40e: fix the panic when running bpf in xdpdrv mode
ethtool: pause: make sure we init driver stats
ia64: remove duplicate entries in generic_defconfig
ia64: tools: remove inclusion of ia64-specific version of errno.h header
ibmvnic: avoid calling napi_disable() twice
ibmvnic: remove duplicate napi_schedule call in do_reset function
ibmvnic: remove duplicate napi_schedule call in open function
ch_ktls: Fix kernel panic
ch_ktls: fix device connection close
ch_ktls: tcb close causes tls connection failure
ch_ktls: do not send snd_una update to TCB in middle
gro: ensure frag0 meets IP header alignment
ARM: OMAP2+: Fix warning for omap_init_time_of()
ARM: 9069/1: NOMMU: Fix conversion for_each_membock() to for_each_mem_range()
ARM: footbridge: fix PCI interrupt mapping
ARM: OMAP2+: Fix uninitialized sr_inst
arm64: dts: allwinner: Fix SD card CD GPIO for SOPine systems
arm64: dts: allwinner: h6: beelink-gs1: Remove ext. 32 kHz osc reference
bpf: Use correct permission flag for mixed signed bounds arithmetic
KVM: VMX: Convert vcpu_vmx.exit_reason to a union
KVM: VMX: Don't use vcpu->run->internal.ndata as an array index
r8169: tweak max read request size for newer chips also in jumbo mtu mode
r8169: don't advertise pause in jumbo mode
bpf: Ensure off_reg has no mixed signed bounds for all types
bpf: Move off_reg into sanitize_ptr_alu
ARM: 9071/1: uprobes: Don't hook on thumb instructions
arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is set atomically
bpf: Rework ptr_limit into alu_limit and add common error path
bpf: Improve verifier error messages for users
bpf: Move sanitize_val_alu out of op switch
net: phy: marvell: fix detection of PHY on Topaz switches
Linux 5.10.32
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: If247bf8401509195e4f55f03dcc514f80d467966
Add hooks to capture various per-zone memory stats when
a trigger threshold is hit.
Bug: 178721511
Change-Id: Ibe39263ddb05ffc3fa63b5225497a90c6480c8d7
Signed-off-by: Georgi Djakov <quic_c_gdjako@quicinc.com>
commit f528819334 upstream.
Add a small sanitize_needed() helper function and move sanitize_val_alu()
out of the main opcode switch. In upcoming work, we'll move sanitize_ptr_alu()
as well out of its opcode switch so this helps to streamline both.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 6f55b2f2a1 ]
Small refactor to drag off_reg into sanitize_ptr_alu(), so we later on can
use off_reg for generalizing some of the checks for all pointer types.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 24c109bb15 ]
The mixed signed bounds check really belongs into retrieve_ptr_limit()
instead of outside of it in adjust_ptr_min_max_vals(). The reason is
that this check is not tied to PTR_TO_MAP_VALUE only, but to all pointer
types that we handle in retrieve_ptr_limit() and given errors from the latter
propagate back to adjust_ptr_min_max_vals() and lead to rejection of the
program, it's a better place to reside to avoid anything slipping through
for future types. The reason why we must reject such off_reg is that we
otherwise would not be able to derive a mask, see details in 9d7eceede7
("bpf: restrict unknown scalars of mixed signed bounds for unprivileged").
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 9601148392 ]
We forbid adding unknown scalars with mixed signed bounds due to the
spectre v1 masking mitigation. Hence this also needs bypass_spec_v1
flag instead of allow_ptr_leaks.
Fixes: 2c78ee898d ("bpf: Implement CAP_BPF")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
