mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2026-11-13 07:31:07 +00:00
1,188,286 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Rong Tao
|
b3c09fdca1 |
selftests/bpf: cgroup_helpers.c: Fix strncpy() fortify warning
Copy libbpf_strlcpy() from libbpf_internal.h to bpf_util.h, and rename it
to bpf_strlcpy(), then replace selftests strncpy()/libbpf_strlcpy() with
bpf_strlcpy(), fix compile warning.
The libbpf_internal.h header cannot be used directly here, because
references to cgroup_helpers.c in samples/bpf will generate compilation
errors. We also can't add libbpf_strlcpy() directly to bpf_util.h,
because the definition of libbpf_strlcpy() in libbpf_internal.h is
duplicated. In order not to modify the libbpf code, add a new function
bpf_strlcpy() to selftests bpf_util.h.
How to reproduce this compilation warning:
$ make -C samples/bpf
cgroup_helpers.c: In function ‘__enable_controllers’:
cgroup_helpers.c:80:17: warning: ‘strncpy’ specified bound 4097 equals destination size [-Wstringop-truncation]
80 | strncpy(enable, controllers, sizeof(enable));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Rong Tao <rongtao@cestc.cn>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/tencent_469D8AF32BD56816A29981BED06E96D22506@qq.com
|
||
Kai Huang
|
16a7fe3728 |
KVM/VMX: Allow exposing EDECCSSA user leaf function to KVM guest
The new Asynchronous Exit (AEX) notification mechanism (AEX-notify) allows one enclave to receive a notification in the ERESUME after the enclave exit due to an AEX. EDECCSSA is a new SGX user leaf function (ENCLU[EDECCSSA]) to facilitate the AEX notification handling. The new EDECCSSA is enumerated via CPUID(EAX=0x12,ECX=0x0):EAX[11]. Besides Allowing reporting the new AEX-notify attribute to KVM guests, also allow reporting the new EDECCSSA user leaf function to KVM guests so the guest can fully utilize the AEX-notify mechanism. Similar to existing X86_FEATURE_SGX1 and X86_FEATURE_SGX2, introduce a new scattered X86_FEATURE_SGX_EDECCSSA bit for the new EDECCSSA, and report it in KVM's supported CPUIDs. Note, no additional KVM enabling is required to allow the guest to use EDECCSSA. It's impossible to trap ENCLU (without completely preventing the guest from using SGX). Advertise EDECCSSA as supported purely so that userspace doesn't need to special case EDECCSSA, i.e. doesn't need to manually check host CPUID. The inability to trap ENCLU also means that KVM can't prevent the guest from using EDECCSSA, but that virtualization hole is benign as far as KVM is concerned. EDECCSSA is simply a fancy way to modify internal enclave state. More background about how do AEX-notify and EDECCSSA work: SGX maintains a Current State Save Area Frame (CSSA) for each enclave thread. When AEX happens, the enclave thread context is saved to the CSSA and the CSSA is increased by 1. For a normal ERESUME which doesn't deliver AEX notification, it restores the saved thread context from the previously saved SSA and decreases the CSSA. If AEX-notify is enabled for one enclave, the ERESUME acts differently. Instead of restoring the saved thread context and decreasing the CSSA, it acts like EENTER which doesn't decrease the CSSA but establishes a clean slate thread context using the CSSA for the enclave to handle the notification. After some handling, the enclave must discard the "new-established" SSA and switch back to the previously saved SSA (upon AEX). Otherwise, the enclave will run out of SSA space upon further AEXs and eventually fail to run. To solve this problem, the new EDECCSSA essentially decreases the CSSA. It can be used by the enclave notification handler to switch back to the previous saved SSA when needed, i.e. after it handles the notification. Signed-off-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Sean Christopherson <seanjc@google.com> Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Link: https://lore.kernel.org/all/20221101022422.858944-1-kai.huang%40intel.com |
||
Dave Hansen
|
370839c241 |
x86/sgx: Allow enclaves to use Asynchrounous Exit Notification
Short Version: Allow enclaves to use the new Asynchronous EXit (AEX) notification mechanism. This mechanism lets enclaves run a handler after an AEX event. These handlers can run mitigations for things like SGX-Step[1]. AEX Notify will be made available both on upcoming processors and on some older processors through microcode updates. Long Version: == SGX Attribute Background == The SGX architecture includes a list of SGX "attributes". These attributes ensure consistency and transparency around specific enclave features. As a simple example, the "DEBUG" attribute allows an enclave to be debugged, but also destroys virtually all of SGX security. Using attributes, enclaves can know that they are being debugged. Attributes also affect enclave attestation so an enclave can, for instance, be denied access to secrets while it is being debugged. The kernel keeps a list of known attributes and will only initialize enclaves that use a known set of attributes. This kernel policy eliminates the chance that a new SGX attribute could cause undesired effects. For example, imagine a new attribute was added called "PROVISIONKEY2" that provided similar functionality to "PROVISIIONKEY". A kernel policy that allowed indiscriminate use of unknown attributes and thus PROVISIONKEY2 would undermine the existing kernel policy which limits use of PROVISIONKEY enclaves. == AEX Notify Background == "Intel Architecture Instruction Set Extensions and Future Features - Version 45" is out[2]. There is a new chapter: Asynchronous Enclave Exit Notify and the EDECCSSA User Leaf Function. Enclaves exit can be either synchronous and consensual (EEXIT for instance) or asynchronous (on an interrupt or fault). The asynchronous ones can evidently be exploited to single step enclaves[1], on top of which other naughty things can be built. AEX Notify will be made available both on upcoming processors and on some older processors through microcode updates. == The Problem == These attacks are currently entirely opaque to the enclave since the hardware does the save/restore under the covers. The Asynchronous Enclave Exit Notify (AEX Notify) mechanism provides enclaves an ability to detect and mitigate potential exposure to these kinds of attacks. == The Solution == Define the new attribute value for AEX Notification. Ensure the attribute is cleared from the list reserved attributes. Instead of adding to the open-coded lists of individual attributes, add named lists of privileged (disallowed by default) and unprivileged (allowed by default) attributes. Add the AEX notify attribute as an unprivileged attribute, which will keep the kernel from rejecting enclaves with it set. 1. https://github.com/jovanbulck/sgx-step 2. https://cdrdv2.intel.com/v1/dl/getContent/671368?explicitVersion=true Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: Haitao Huang <haitao.huang@intel.com> Tested-by: Kai Huang <kai.huang@intel.com> Link: https://lore.kernel.org/all/20220720191347.1343986-1-dave.hansen%40linux.intel.com |
||
Peter Zijlstra
|
c86df29d11 |
bpf: Convert BPF_DISPATCHER to use static_call() (not ftrace)
The dispatcher function is currently abusing the ftrace __fentry__ call location for its own purposes -- this obviously gives trouble when the dispatcher and ftrace are both in use. A previous solution tried using __attribute__((patchable_function_entry())) which works, except it is GCC-8+ only, breaking the build on the earlier still supported compilers. Instead use static_call() -- which has its own annotations and does not conflict with ftrace -- to rewrite the dispatch function. By using: return static_call()(ctx, insni, bpf_func) you get a perfect forwarding tail call as function body (iow a single jmp instruction). By having the default static_call() target be bpf_dispatcher_nop_func() it retains the default behaviour (an indirect call to the argument function). Only once a dispatcher program is attached is the target rewritten to directly call the JIT'ed image. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Tested-by: Björn Töpel <bjorn@kernel.org> Tested-by: Jiri Olsa <jolsa@kernel.org> Acked-by: Björn Töpel <bjorn@kernel.org> Acked-by: Jiri Olsa <jolsa@kernel.org> Link: https://lkml.kernel.org/r/Y1/oBlK0yFk5c/Im@hirez.programming.kicks-ass.net Link: https://lore.kernel.org/bpf/20221103120647.796772565@infradead.org |
||
|
Peter Zijlstra
|
18acb7fac2 |
bpf: Revert ("Fix dispatcher patchable function entry to 5 bytes nop")
Because __attribute__((patchable_function_entry)) is only available since GCC-8 this solution fails to build on the minimum required GCC version. Undo these changes so we might try again -- without cluttering up the patches with too many changes. This is an almost complete revert of: |
||
Linus Torvalds
|
64c3dd0b98 |
Bug fixes for 6.1-rc4:
- Fix a UAF bug during log recovery.
- Fix memory leaks when mount fails.
- Detect corrupt bestfree information in a directory block.
- Fix incorrect return value type for the dax page fault handlers.
- Fix fortify complaints about memcpy of xfs log item objects.
- Strengthen inadequate validation of recovered log items.
- Fix incorrectly declared flex array in EFI log item structs.
- Log corrupt log items for debugging purposes.
- Fix infinite loop problems in the refcount code if the refcount btree
node block keys are corrupt.
- Fix infinite loop problems in the refcount code if the refcount btree
records suffer MSB bitflips.
- Add more sanity checking to continued defer ops to prevent overflows
from one AG to the next or off EOFS.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmNhT68ACgkQ+H93GTRK
tOs5Bw/+NSyPZ7jYVa3mXYKRsqMU/nqAGnNK4D4uS8gRlJTBolpC8Vs4fpBTQzV8
3JN8F/AUIQJOCxt5a81tlsPSYgEsxuIqion1olh3Z6ln4wN0su3rj0E3h+CTtgV8
xf3axdre4uC2xYhmKiDTD4ezLqylnRmsK1nNLbFzRnnJrYN+FiiJB7BefuJkbEzI
HRTAJPo3oxsCDinkkyQhZ8CjD7ZenYuhgc4jFmVSLqNjULkF2kDyHgLCfojq+p3E
G6WsuJ9fonMXlt2WV7k3tKektHIll8+ile6+zuPSjOH+WHo4/jWIjvUsg0X+M3DS
jemPFNgpS6jSJy3qbPJoDej8XlV0FV4VzsCh2a/YaGa1Outl8V9ZhMyt9tc8LWzF
3Z1KkywsBqzK9m9yDlokmGPq71kCEQ+OMQSSlELEf6q7HHUf6yr3MyA5tXKqzJod
DYFYoX70EoPAKk47gFI5EIYrzuTFx7PRugUUSU09e0wmjSswH7RjNur+Ya1eHhYc
VUe6gUluuAkTFHhEjk+8mTg1iUlg92YdzL7pKSoeAlQczz1ZwQhE9W0ul1/z07d4
F4DXi6CtmM38e7XsX0CKmZ0ins9QmSDJheCKmE3kdLYY9PpzQpgtlq4kqjUP5eJw
XZwB6cUS4pXw2zf4tW1qQ5pe13umfN6/VqymagG4fKWfAwj8s9o=
=1IfG
-----END PGP SIGNATURE-----
Merge tag 'xfs-6.1-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
Pull xfs fixes from Darrick Wong:
"Dave and I had thought that this would be a very quiet cycle, but we
thought wrong.
At first there were the usual trickle of minor bugfixes, but then
Zorro pulled -rc1 and noticed complaints about the stronger memcpy
checks w.r.t. flex arrays.
Analyzing how to fix that revealed a bunch of validation gaps in
validating ondisk log items during recovery, and then a customer hit
an infinite loop in the refcounting code on a corrupt filesystem.
So. This largeish batch of fixes addresses all those problems, I hope.
Summary:
- Fix a UAF bug during log recovery
- Fix memory leaks when mount fails
- Detect corrupt bestfree information in a directory block
- Fix incorrect return value type for the dax page fault handlers
- Fix fortify complaints about memcpy of xfs log item objects
- Strengthen inadequate validation of recovered log items
- Fix incorrectly declared flex array in EFI log item structs
- Log corrupt log items for debugging purposes
- Fix infinite loop problems in the refcount code if the refcount
btree node block keys are corrupt
- Fix infinite loop problems in the refcount code if the refcount
btree records suffer MSB bitflips
- Add more sanity checking to continued defer ops to prevent
overflows from one AG to the next or off EOFS"
* tag 'xfs-6.1-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: (28 commits)
xfs: rename XFS_REFC_COW_START to _COWFLAG
xfs: fix uninitialized list head in struct xfs_refcount_recovery
xfs: fix agblocks check in the cow leftover recovery function
xfs: check record domain when accessing refcount records
xfs: remove XFS_FIND_RCEXT_SHARED and _COW
xfs: refactor domain and refcount checking
xfs: report refcount domain in tracepoints
xfs: track cow/shared record domains explicitly in xfs_refcount_irec
xfs: refactor refcount record usage in xchk_refcountbt_rec
xfs: dump corrupt recovered log intent items to dmesg consistently
xfs: move _irec structs to xfs_types.h
xfs: actually abort log recovery on corrupt intent-done log items
xfs: check deferred refcount op continuation parameters
xfs: refactor all the EFI/EFD log item sizeof logic
xfs: create a predicate to verify per-AG extents
xfs: fix memcpy fortify errors in EFI log format copying
xfs: make sure aglen never goes negative in xfs_refcount_adjust_extents
xfs: fix memcpy fortify errors in RUI log format copying
xfs: fix memcpy fortify errors in CUI log format copying
xfs: fix memcpy fortify errors in BUI log format copying
...
|
||
|
Rong Tao
|
1baa7e3800 |
samples/bpf: Fix tracex2 error: No such file or directory
since commit c504e5c2f964("net: skb: introduce kfree_skb_reason()")
kfree_skb() is replaced by kfree_skb_reason() and kfree_skb() is set to
the inline function. So, we replace kprobe/kfree_skb with
kprobe/kfree_skb_reason to solve the tracex2 error.
$ cd samples/bpf
$ sudo ./tracex2
libbpf: prog 'bpf_prog2': failed to create kprobe 'kfree_skb+0x0' perf event: No such file or directory
ERROR: bpf_program__attach failed
Signed-off-by: Rong Tao <rongtao@cestc.cn>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/tencent_0F0DAE84C0B3C42E0B550E5E9F47A9114D09@qq.com
|
||
|
Linus Torvalds
|
5d8401be15 |
Landlock fix for v6.1-rc4
-----BEGIN PGP SIGNATURE----- iIYEABYIAC4WIQSVyBthFV4iTW/VU1/l49DojIL20gUCY2VLRRAcbWljQGRpZ2lr b2QubmV0AAoJEOXj0OiMgvbSejwBAMOIza4vHY0nL5a+C6jQGBjEdueSic8m4K8P cOOHEn3AAP44Bf1skIMIrgOL7VE+aGCJoIYWiN+rs/tBKYyPnO0gBQ== =gW7y -----END PGP SIGNATURE----- Merge tag 'landlock-6.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux Pull landlock fix from Mickaël Salaün: "Fix the test build for some distros" * tag 'landlock-6.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux: selftests/landlock: Build without static libraries |
||
|
Linus Torvalds
|
bd74502743 |
kernel hardening fix for v6.1-rc4
- Correctly report struct member size on memcpy overflow (Kees Cook) -----BEGIN PGP SIGNATURE----- iQJKBAABCgA0FiEEpcP2jyKd1g9yPm4TiXL039xtwCYFAmNlPO4WHGtlZXNjb29r QGNocm9taXVtLm9yZwAKCRCJcvTf3G3AJnALEACUBauDwHbFKdEDnaqB7z0i/LxO VbvjE6a6qNXXMuaeQr9u/ZxnrP/KuHPe3fh8JOI/VXEmw0O/eChetbokKos1kEDk cUCHH+ePTMjI4qaDzSy73hHb5tuyikT1wYdq4aipMUiP6NYyPKtlCvT7c6tCfhpO GDHnUejVPtI8kW40QQ3/A5XGtqvf52J7u6SXRPDTIZfbPN0Ei9o7r/V4i9TASrMZ YbCnOPrhTRh3e4luMom1w1TlERRIl5HV8JulQDoKVlAcCszcJxGDbZQMCmtQboQr ViC3wmXDVwWALLd1wetkrSlczyfA4HBeboOS31Fl46GK1Ykf4z5Czco5YNUyqtUR 9VOI6GaOp2sylalLvy0NfxHoKBFSYe8KEXD+5fMoYIsoIDVeiLUiYfhcP8rFt/f2 Su32M+mMEHQC+vtpTh7a6WNRUMLw66qEGwVEleWiVXcur4sh8Kvvuso168yZdqEP W4Lf9jvUEhXoJXCtZvoAobXFQ8SJHaBu3b5CAoO+4WVDYGzxstbrO+PZaHURijh2 AXP7ocgAB3Jw8Z1Rk9InMnAB4ls6fECfaHOTlHbsbaRQ+dVppazmgkkrsAQZII4z tySpprggVIjZoil8q1sJkiXsfhJgjTckzsmx9Htb/8Ok5yHmP+DgsRD3Nf7Wh3wi FeCYdfPXJVMV+TJNSw== =b39J -----END PGP SIGNATURE----- Merge tag 'hardening-v6.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull hardening fix from Kees Cook: - Correctly report struct member size on memcpy overflow (Kees Cook) * tag 'hardening-v6.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: fortify: Capture __bos() results in const temp vars |
||
|
Linus Torvalds
|
1caa2f182a |
Second batch of EFI fixes for v6.1
- A pair of tweaks to the EFI random seed code so that externally provided version of this config table are handled more robustly - Another fix for the v6.0 EFI variable refactor that turned out to break Apple machines which don't provide QueryVariableInfo() - Add some guard rails to the EFI runtime service call wrapper so we can recover from synchronous exceptions caused by firmware -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEE+9lifEBpyUIVN1cpw08iOZLZjyQFAmNj+NQACgkQw08iOZLZ jyTk1AwAmTAWL8o5U0Z+QTFPUAw1xM7qX7GgPtsrZ8Sn1d9MWYDKVKvDmaZwKWZh rK623STwTwM5PQoiFJgKhuEvDLyAj5ZJ48zd1ZiuzYzCQ2w7Aq4rtCONlfjeeY2C JAH/CqSF9VuSHM+ato5UfpeDfq+fnZWc17cM7xSGtFEJeeqi1la1XN5F9Nr1+Jfw XBckPxTWPh6qZ2Kim4TcYUaVgMwEmbHrzsz4mTNS6MGryPVj9rtDiP/IRs3f4QZl KaVCfY+mRmEy0Jzt0jy9wRKknb0lK+wipiPE4CSAuX4jkuwWIhEt0ZfzuEHCfl4R 6hmL2byMjmGnk9RTUllcMzWvBrRkz7cY3ssAhY+sXPXPmZLLaYpiUYLwnhRUKBGh U0kQYHYaB0kRsq/xLsGtnZVOon89rWOIW6okbpfcrhWNTaQ+DI54G7ci+he6F8lU Nfgo99RMse22ES87l3jsEwYSjLOSYhFAO5HTYblWcrCvVrPRhyelif6bnOF9iF3I 9yRtZV/A =fjxs -----END PGP SIGNATURE----- Merge tag 'efi-fixes-for-v6.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI fixes from Ard Biesheuvel: - A pair of tweaks to the EFI random seed code so that externally provided version of this config table are handled more robustly - Another fix for the v6.0 EFI variable refactor that turned out to break Apple machines which don't provide QueryVariableInfo() - Add some guard rails to the EFI runtime service call wrapper so we can recover from synchronous exceptions caused by firmware * tag 'efi-fixes-for-v6.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: arm64: efi: Recover from synchronous exceptions occurring in firmware efi: efivars: Fix variable writes with unsupported query_variable_store() efi: random: Use 'ACPI reclaim' memory for random seed efi: random: reduce seed size to 32 bytes efi/tpm: Pass correct address to memblock_reserve |
||
|
Linus Torvalds
|
10d916c86e |
ARM: SoC fixes for 6.1, part 2
There are not a lot of important fixes for the soc tree yet this
time, but it's time to upstream what I got so far:
- DT Fixes for Arm Juno and ST-Ericsson Ux500 to add missing critical
temperature points
- A number of fixes for the Arm SCMI firmware, addressing correctness
issues in the code, in particular error handling and resource leaks.
- One error handling fix for the new i.MX93 power domain driver
- Several devicetree fixes for NXP i.MX6/8/9 and Layerscape chips,
fixing incorrect or missing DT properties for MDIO controller nodes,
CPLD, USB and regulators for various boards, as well as some
fixes for DT schema checks.
- MAINTAINERS file updates for HiSilicon LPC Bus and Broadcom git URLs
-----BEGIN PGP SIGNATURE-----
iQIyBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmNk+VsACgkQmmx57+YA
GNkGYw/4yAY5HoPidRbG6Ka9XKfwqxT9n/pp9gndg0ciESOV+1agRExeA7VJFprK
VHoFaQ13GqDMEFr/D+FRx/2e9VNiXZKELIc6qFpFC8Vr+mCtH2/Hqalfus7hpvO1
o7T3xXKvqDUEOkG0VjcKcbLejIbPqw6Hiuq6f/MHf8BNi6nXRa+6EJJr0knMAmpF
AzXMvFsVxnaYAqfT6puKrLvoYHArIQ6yguV+LDKpi2UstxjfKWmO84Io/drbedK1
ELzyssClUeiLLsqNwzMSeedHmizuiyiFZ5aKkqCgHkXei6VdSAy6u6XoOLc9CKeM
H/fpIksaMnJVFx+fcQR+kg2WoYVW/0p6I4wEGzPNiGw2vZ/IkspzYb4yhJVu+VSZ
rfoHgCpNklumVXVf5JvqAGPfgdTQQW4s3myWS/SxX1R2xd5ZA/3BcMktcNCQYAvZ
iTA8tCAqd73gSxv+DBvX6BlweiJKIY+j+TcZqietSMFMj+PVRZz4kVp3gAe3abrx
tRnvZchdjoCZv0Xap5J/qu+wbW/QOeDS/oy11jXSwlFEcau8ldfMUG899jx7k39w
EkTH6Jo35tyP7rF3vETtnIYen6wUpKEAySWPZ/AO/VAP2zu1/9jgTOY8AY+t1q/d
QZOR4C4GVlByFxtXJVgU1ZOPInaJhSIwB3/0gqPP9sd24T7Nng==
=Apap
-----END PGP SIGNATURE-----
Merge tag 'soc-fixes-6.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM SoC fixes from Arnd Bergmann:
"There are not a lot of important fixes for the soc tree yet this time,
but it's time to upstream what I got so far:
- DT Fixes for Arm Juno and ST-Ericsson Ux500 to add missing critical
temperature points
- A number of fixes for the Arm SCMI firmware, addressing correctness
issues in the code, in particular error handling and resource
leaks.
- One error handling fix for the new i.MX93 power domain driver
- Several devicetree fixes for NXP i.MX6/8/9 and Layerscape chips,
fixing incorrect or missing DT properties for MDIO controller
nodes, CPLD, USB and regulators for various boards, as well as some
fixes for DT schema checks.
- MAINTAINERS file updates for HiSilicon LPC Bus and Broadcom git
URLs"
* tag 'soc-fixes-6.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (26 commits)
arm64: dts: juno: Add thermal critical trip points
firmware: arm_scmi: Fix deferred_tx_wq release on error paths
firmware: arm_scmi: Fix devres allocation device in virtio transport
firmware: arm_scmi: Make Rx chan_setup fail on memory errors
firmware: arm_scmi: Make tx_prepare time out eventually
firmware: arm_scmi: Suppress the driver's bind attributes
firmware: arm_scmi: Cleanup the core driver removal callback
MAINTAINERS: Update HiSilicon LPC BUS Driver maintainer
ARM: dts: ux500: Add trips to battery thermal zones
arm64: dts: ls208xa: specify clock frequencies for the MDIO controllers
arm64: dts: ls1088a: specify clock frequencies for the MDIO controllers
arm64: dts: lx2160a: specify clock frequencies for the MDIO controllers
soc: imx: imx93-pd: Fix the error handling path of imx93_pd_probe()
arm64: dts: imx93: correct gpio-ranges
arm64: dts: imx93: correct s4mu interrupt names
dt-bindings: power: gpcv2: add power-domains property
arm64: dts: imx8: correct clock order
ARM: dts: imx6dl-yapp4: Do not allow PM to switch PU regulator off on Q/QP
ARM: dts: imx6qdl-gw59{10,13}: fix user pushbutton GPIO offset
arm64: dts: imx8mn: Correct the usb power domain
...
|
||
John Harrison
|
178b8a3668 |
drm/i915/guc: Don't deadlock busyness stats vs reset
The engine busyness stats has a worker function to do things like 64bit extend the 32bit hardware counters. The GuC's reset prepare function flushes out this worker function to ensure no corruption happens during the reset. Unforunately, the worker function has an infinite wait for active resets to finish before doing its work. Thus a deadlock would occur if the worker function had actually started just as the reset starts. The function being used to lock the reset-in-progress mutex is called intel_gt_reset_trylock(). However, as noted it does not follow standard 'trylock' conventions and exit if already locked. So rename the current _trylock function to intel_gt_reset_lock_interruptible(), which is the behaviour it actually provides. In addition, add a new implementation of _trylock and call that from the busyness stats worker instead. v2: Rename existing trylock to interruptible rather than trying to preserve the existing (confusing) naming scheme (review comments from Tvrtko). Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221102192109.2492625-3-John.C.Harrison@Intel.com |
||
|
John Harrison
|
de51de9672 |
drm/i915/guc: Properly initialise kernel contexts
If a context has already been registered prior to first submission then context init code was not being called. The noticeable effect of that was the scheduling priority was left at zero (meaning super high priority) instead of being set to normal. This would occur with kernel contexts at start of day as they are manually pinned up front rather than on first submission. So add a call to initialise those when they are pinned. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221102192109.2492625-2-John.C.Harrison@Intel.com |
||
Tony Luck
|
7beade0dd4 |
x86/cpu: Add several Intel server CPU model numbers
These servers are all on the public versions of the roadmap. The model numbers for Grand Ridge, Granite Rapids, and Sierra Forest were included in the September 2022 edition of the Instruction Set Extensions document. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://lore.kernel.org/r/20221103203310.5058-1-tony.luck@intel.com |
||
Eduard Zingerman
|
2e20f50ff8 |
selftests/bpf: Tests for enum fwd resolved as full enum64
A set of test cases to verify enum fwd resolution logic: - verify that enum fwd can be resolved as full enum64; - verify that enum64 fwd can be resolved as full enum; - verify that enum size is considered when enums are compared for equivalence. Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20221101235413.1824260-2-eddyz87@gmail.com |
||
|
Eduard Zingerman
|
de048b6ee8 |
libbpf: Resolve enum fwd as full enum64 and vice versa
Changes de-duplication logic for enums in the following way:
- update btf_hash_enum to ignore size and kind fields to get
ENUM and ENUM64 types in a same hash bucket;
- update btf_compat_enum to consider enum fwd to be compatible with
full enum64 (and vice versa);
This allows BTF de-duplication in the following case:
// CU #1
enum foo;
struct s {
enum foo *a;
} *x;
// CU #2
enum foo {
x = 0xfffffffff // big enough to force enum64
};
struct s {
enum foo *a;
} *y;
De-duplicated BTF prior to this commit:
[1] ENUM64 'foo' encoding=UNSIGNED size=8 vlen=1
'x' val=68719476735ULL
[2] INT 'long unsigned int' size=8 bits_offset=0 nr_bits=64
encoding=(none)
[3] STRUCT 's' size=8 vlen=1
'a' type_id=4 bits_offset=0
[4] PTR '(anon)' type_id=1
[5] PTR '(anon)' type_id=3
[6] STRUCT 's' size=8 vlen=1
'a' type_id=8 bits_offset=0
[7] ENUM 'foo' encoding=UNSIGNED size=4 vlen=0
[8] PTR '(anon)' type_id=7
[9] PTR '(anon)' type_id=6
De-duplicated BTF after this commit:
[1] ENUM64 'foo' encoding=UNSIGNED size=8 vlen=1
'x' val=68719476735ULL
[2] INT 'long unsigned int' size=8 bits_offset=0 nr_bits=64
encoding=(none)
[3] STRUCT 's' size=8 vlen=1
'a' type_id=4 bits_offset=0
[4] PTR '(anon)' type_id=1
[5] PTR '(anon)' type_id=3
Enum forward declarations in C do not provide information about
enumeration values range. Thus the `btf_type->size` field is
meaningless for forward enum declarations. In fact, GCC does not
encode size in DWARF for forward enum declarations
(but dwarves sets enumeration size to a default value of `sizeof(int) * 8`
when size is not specified see dwarf_loader.c:die__create_new_enumeration).
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20221101235413.1824260-1-eddyz87@gmail.com
|
||
Xiaogang Chen
|
fcf00f8d29 |
drm/amdkfd: Remove skiping userptr buffer mapping when mmu notifier marks it as invalid
mmu notifier does not always hold mm->sem during call back. That causes a race condition between kfd userprt buffer mapping and mmu notifier which leds to gpu shadder or SDMA access userptr buffer before it has been mapped to gpu VM. Always map userptr buffer to avoid that though it may make some userprt buffers mapped two times. Suggested-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Xiaogang Chen <xiaogang.chen@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> |
||
Ao Zhong
|
79b72db633 |
drm/amd/display: add DCN support for ARM64
After moving all FPU code to the DML folder, we can enable DCN support for the ARM64 platform. Remove the -mgeneral-regs-only CFLAG from the code in the DML folder that needs to use hardware FPU, and add a control mechanism for ARM Neon. Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Ao Zhong <hacc1225@gmail.com> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> |
||
Victor Zhao
|
ec4927d463 |
drm/amdgpu: fix for suspend/resume sequence under sriov
- clear kiq ring after suspend/resume under sriov to aviod kiq ring test failure - update irq after resume to fix kiq interrput loss Signed-off-by: Victor Zhao <Victor.Zhao@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> |
||
Kenneth Feng
|
5cefe31b2a |
drm/amd/amdgpu: temporary workaround to skip ras error for gc_v11_0_3
temporary workaround to skip ras error for gc_v11_0_3 until IFWI release later Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> |
||
Ma Jun
|
c0cc999f3c |
drm/amdkfd: Fix the warning of array-index-out-of-bounds
For some GPUs with more CUs, the original sibling_map[32] in struct crat_subtype_cache is not enough to save the cache information when create the VCRAT table, so skip filling the struct crat_subtype_cache info instead fill struct kfd_cache_properties directly to fix this problem. Signed-off-by: Ma Jun <Jun.Ma2@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> |
||
Hawking Zhang
|
cfa61b8f9e |
drm/amdgpu: switch to select_se_sh wrapper for gfx v9_0
To allow invoking ip specific callbacks Acked-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Le Ma <le.ma@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> |
||
Nathan Chancellor
|
e4d0ef7520 |
drm/amdgpu: Fix type of second parameter in odn_edit_dpm_table() callback
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/amdgpu_smu.c:3008:29: error: incompatible function pointer types initializing 'int (*)(void *, uint32_t, long *, uint32_t)' (aka 'int (*)(void *, unsigned int, long *, unsigned int)') with an expression of type 'int (void *, enum PP_OD_DPM_TABLE_COMMAND, long *, uint32_t)' (aka 'int (void *, enum PP_OD_DPM_TABLE_COMMAND, long *, unsigned int)') [-Werror,-Wincompatible-function-pointer-types-strict]
.odn_edit_dpm_table = smu_od_edit_dpm_table,
^~~~~~~~~~~~~~~~~~~~~
1 error generated.
There are only two implementations of ->odn_edit_dpm_table() in 'struct
amd_pm_funcs': smu_od_edit_dpm_table() and pp_odn_edit_dpm_table(). One
has a second parameter type of 'enum PP_OD_DPM_TABLE_COMMAND' and the
other uses 'u32'. Ultimately, smu_od_edit_dpm_table() calls
->od_edit_dpm_table() from 'struct pptable_funcs' and
pp_odn_edit_dpm_table() calls ->odn_edit_dpm_table() from 'struct
pp_hwmgr_func', which both have a second parameter type of 'enum
PP_OD_DPM_TABLE_COMMAND'.
Update the type parameter in both the prototype in 'struct amd_pm_funcs'
and pp_odn_edit_dpm_table() to 'enum PP_OD_DPM_TABLE_COMMAND', which
cleans up the warning.
Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Reported-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
||
|
Nathan Chancellor
|
f0d0f10873 |
drm/amdgpu: Fix type of second parameter in trans_msg() callback
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:
drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c:412:15: error: incompatible function pointer types initializing 'void (*)(struct amdgpu_device *, u32, u32, u32, u32)' (aka 'void (*)(struct amdgpu_device *, unsigned int, unsigned int, unsigned int, unsigned int)') with an expression of type 'void (struct amdgpu_device *, enum idh_request, u32, u32, u32)' (aka 'void (struct amdgpu_device *, enum idh_request, unsigned int, unsigned int, unsigned int)') [-Werror,-Wincompatible-function-pointer-types-strict]
.trans_msg = xgpu_ai_mailbox_trans_msg,
^~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c:435:15: error: incompatible function pointer types initializing 'void (*)(struct amdgpu_device *, u32, u32, u32, u32)' (aka 'void (*)(struct amdgpu_device *, unsigned int, unsigned int, unsigned int, unsigned int)') with an expression of type 'void (struct amdgpu_device *, enum idh_request, u32, u32, u32)' (aka 'void (struct amdgpu_device *, enum idh_request, unsigned int, unsigned int, unsigned int)') [-Werror,-Wincompatible-function-pointer-types-strict]
.trans_msg = xgpu_nv_mailbox_trans_msg,
^~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
The type of the second parameter in the prototype should be 'enum
idh_request' instead of 'u32'. Update it to clear up the warnings.
Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Reported-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
||
Paulo Miguel Almeida
|
320e2590e2 |
drm/amdgpu: Replace one-element array with flexible-array member
One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element array with flexible-array member in struct _ATOM_FAKE_EDID_PATCH_RECORD and refactor the rest of the code accordingly. Important to mention is that doing a build before/after this patch results in no binary output differences. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/238 Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1] Signed-off-by: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> |
||
|
Paulo Miguel Almeida
|
c81c5bd5cf |
drm/radeon: Replace one-element array with flexible-array member
One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element array with flexible-array member in struct _ATOM_FAKE_EDID_PATCH_RECORD and refactor the rest of the code accordingly. It's worth mentioning that doing a build before/after this patch results in no binary output differences. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/239 Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1] Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> |
||
Alex Deucher
|
e053d71f8c |
drm/amdgpu/gfx11: set gfx.funcs in early init
So the callbacks are set early in case we need them. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> |
||
|
Alex Deucher
|
105195af02 |
drm/amdgpu/gfx10: set gfx.funcs in early init
So the callbacks are set early in case we need them. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> |
||
|
Alex Deucher
|
33034c5c2e |
drm/amdgpu/gfx9: set gfx.funcs in early init
So the callbacks are set before we use them. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> |
||
Peng Ju Zhou
|
f8638ad7fc |
drm/amdgpu: Remove unnecessary register program in SRIOV
Remove unnecessary register program in SRIOV Signed-off-by: Peng Ju Zhou <PengJu.Zhou@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> |
||
Yiqing Yao
|
8a1fbb4a5e |
drm/amdgpu: Disable MCBP from soc21 for SRIOV
[why] Start from soc21, CP does not support MCBP, so disable it. [how] Used amgpu_mcbp flag alone instead of checking if is in SRIOV to enable/disable MCBP. Only set flag to enable on asic_type prior to soc21 in SRIOV. Signed-off-by: Yiqing Yao <yiqing.yao@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> |
||
|
Yiqing Yao
|
0cfce2401e |
drm/amdgpu: Clean up soc21 early init for SRIOV
Use virt_init_setting instead of per ip version setting. Signed-off-by: Yiqing Yao <yiqing.yao@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> |
||
Graham Sider
|
9a1662f549 |
drm/amdgpu: extend halt_if_hws_hang to MES
Hang on MES timeout if halt_if_hws_hang is set to 1. Signed-off-by: Graham Sider <Graham.Sider@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> |
||
Jay Cornwall
|
403cea4019 |
drm/amdkfd: update GFX11 CWSR trap handler
With corresponding FW change fixes issue where triggering CWSR on a workgroup with waves in s_barrier wouldn't lead to a back-off and therefore cause a hang. Signed-off-by: Jay Cornwall <jay.cornwall@amd.com> Tested-by: Graham Sider <Graham.Sider@amd.com> Acked-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Acked-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Graham Sider <Graham.Sider@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> |
||
|
John Harrison
|
cc2e0cf0ad |
drm/i915/guc: Remove excessive line feeds in state dumps
Some of the GuC state dump messages were adding extra line feeds. When printing via a DRM printer to dmesg, for example, that messes up the log formatting as it loses any prefixing from the printer. Given that the extra line feeds are just in the middle of random bits of GuC state, there isn't any real need for them. So just remove them completely. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221031220007.4176835-1-John.C.Harrison@Intel.com |
||
Peng Wu
|
6e59419fd0 |
phy: sunplus: Fix an IS_ERR() vs NULL bug in sp_usb_phy_probe
The devm_ioremap() function returns NULL on error, it doesn't return
error pointers.
Fixes:
|
||
Stephen Boyd
|
4cc47e8add |
clk: qcom: gdsc: Remove direct runtime PM calls
We shouldn't be calling runtime PM APIs from within the genpd
enable/disable path for a couple reasons.
First, this causes an AA lockdep splat[1] because genpd can call into
genpd code again while holding the genpd lock.
WARNING: possible recursive locking detected
5.19.0-rc2-lockdep+ #7 Not tainted
--------------------------------------------
kworker/2:1/49 is trying to acquire lock:
ffffffeea0370788 (&genpd->mlock){+.+.}-{3:3}, at: genpd_lock_mtx+0x24/0x30
but task is already holding lock:
ffffffeea03710a8 (&genpd->mlock){+.+.}-{3:3}, at: genpd_lock_mtx+0x24/0x30
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&genpd->mlock);
lock(&genpd->mlock);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by kworker/2:1/49:
#0: 74ffff80811a5748 ((wq_completion)pm){+.+.}-{0:0}, at: process_one_work+0x320/0x5fc
#1: ffffffc008537cf8 ((work_completion)(&genpd->power_off_work)){+.+.}-{0:0}, at: process_one_work+0x354/0x5fc
#2: ffffffeea03710a8 (&genpd->mlock){+.+.}-{3:3}, at: genpd_lock_mtx+0x24/0x30
stack backtrace:
CPU: 2 PID: 49 Comm: kworker/2:1 Not tainted 5.19.0-rc2-lockdep+ #7
Hardware name: Google Lazor (rev3 - 8) with KB Backlight (DT)
Workqueue: pm genpd_power_off_work_fn
Call trace:
dump_backtrace+0x1a0/0x200
show_stack+0x24/0x30
dump_stack_lvl+0x7c/0xa0
dump_stack+0x18/0x44
__lock_acquire+0xb38/0x3634
lock_acquire+0x180/0x2d4
__mutex_lock_common+0x118/0xe30
mutex_lock_nested+0x70/0x7c
genpd_lock_mtx+0x24/0x30
genpd_runtime_suspend+0x2f0/0x414
__rpm_callback+0xdc/0x1b8
rpm_callback+0x4c/0xcc
rpm_suspend+0x21c/0x5f0
rpm_idle+0x17c/0x1e0
__pm_runtime_idle+0x78/0xcc
gdsc_disable+0x24c/0x26c
_genpd_power_off+0xd4/0x1c4
genpd_power_off+0x2d8/0x41c
genpd_power_off_work_fn+0x60/0x94
process_one_work+0x398/0x5fc
worker_thread+0x42c/0x6c4
kthread+0x194/0x1b4
ret_from_fork+0x10/0x20
Second, this confuses runtime PM on CoachZ for the camera devices by
causing the camera clock controller's runtime PM usage_count to go
negative after resuming from suspend. This is because runtime PM is
being used on the clock controller while runtime PM is disabled for the
device.
The reason for the negative count is because a GDSC is represented as a
genpd and each genpd that is attached to a device is resumed during the
noirq phase of system wide suspend/resume (see the noirq suspend ops
assignment in pm_genpd_init() for more details). The camera GDSCs are
attached to camera devices with the 'power-domains' property in DT.
Every device has runtime PM disabled in the late system suspend phase
via __device_suspend_late(). Runtime PM is not usable until runtime PM
is enabled in device_resume_early(). The noirq phases run after the
'late' and before the 'early' phase of suspend/resume. When the genpds
are resumed in genpd_resume_noirq(), we call down into gdsc_enable()
that calls pm_runtime_resume_and_get() and that returns -EACCES to
indicate failure to resume because runtime PM is disabled for all
devices.
Upon closer inspection, calling runtime PM APIs like this in the GDSC
driver doesn't make sense. It was intended to make sure the GDSC for the
clock controller providing other GDSCs was enabled, specifically the
MMCX GDSC for the display clk controller on SM8250 (sm8250-dispcc), so
that GDSC register accesses succeeded. That will already happen because
we make the 'dev->pm_domain' a parent domain of each GDSC we register in
gdsc_register() via pm_genpd_add_subdomain(). When any of these GDSCs
are accessed, we'll enable the parent domain (in this specific case
MMCX).
We also remove any getting of runtime PM during registration, because
when a genpd is registered it increments the count on the parent if the
genpd itself is already enabled.
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Johan Hovold <johan+linaro@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Taniya Das <quic_tdas@quicinc.com>
Cc: Satya Priya <quic_c_skakit@quicinc.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Cc: Matthias Kaehlcke <mka@chromium.org>
Reported-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/CAE-0n52xbZeJ66RaKwggeRB57fUAwjvxGxfFMKOKJMKVyFTe+w@mail.gmail.com [1]
Fixes:
|
||
Alexei Starovoitov
|
07d90c72ef |
Merge branch 'BPF verifier precision tracking improvements'
Andrii Nakryiko says: ==================== This patch set fixes and improves BPF verifier's precision tracking logic for SCALAR registers. Patches #1 and #2 are bug fixes discovered while working on these changes. Patch #3 enables precision tracking for BPF programs that contain subprograms. This was disabled before and prevent any modern BPF programs that use subprograms from enjoying the benefits of SCALAR (im)precise logic. Patch #4 is few lines of code changes and many lines of explaining why those changes are correct. We establish why ignoring precise markings in current state is OK. Patch #5 build on explanation in patch #4 and pushes it to the limit by forcefully forgetting inherited precise markins. Patch #4 by itself doesn't prevent current state from having precise=true SCALARs, so patch #5 is necessary to prevent such stray precise=true registers from creeping in. Patch #6 adjusts test_align selftests to work around BPF verifier log's limitations when it comes to interactions between state output and precision backtracking output. Overall, the goal of this patch set is to make BPF verifier's state tracking a bit more efficient by trying to preserve as much generality in checkpointed states as possible. v1->v2: - adjusted patch #1 commit message to make it clear we are fixing forward step, not precision backtracking (Alexei); - moved last_idx/first_idx verbose logging up to make it clear when global func reaches the first empty state (Alexei). ==================== Signed-off-by: Alexei Starovoitov <ast@kernel.org> |
||
Andrii Nakryiko
|
4f999b7677 |
selftests/bpf: make test_align selftest more robust
test_align selftest relies on BPF verifier log emitting register states for specific instructions in expected format. Unfortunately, BPF verifier precision backtracking log interferes with such expectations. And instruction on which precision propagation happens sometimes don't output full expected register states. This does indeed look like something to be improved in BPF verifier, but is beyond the scope of this patch set. So to make test_align a bit more robust, inject few dummy R4 = R5 instructions which capture desired state of R5 and won't have precision tracking logs on them. This fixes tests until we can improve BPF verifier output in the presence of precision tracking. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20221104163649.121784-7-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org> |
||
|
Andrii Nakryiko
|
7a830b53c1 |
bpf: aggressively forget precise markings during state checkpointing
Exploit the property of about-to-be-checkpointed state to be able to forget all precise markings up to that point even more aggressively. We now clear all potentially inherited precise markings right before checkpointing and branching off into child state. If any of children states require precise knowledge of any SCALAR register, those will be propagated backwards later on before this state is finalized, preserving correctness. There is a single selftests BPF program change, but tremendous one: 25x reduction in number of verified instructions and states in trace_virtqueue_add_sgs. Cilium results are more modest, but happen across wider range of programs. SELFTESTS RESULTS ================= $ ./veristat -C -e file,prog,insns,states ~/imprecise-early-results.csv ~/imprecise-aggressive-results.csv | grep -v '+0' File Program Total insns (A) Total insns (B) Total insns (DIFF) Total states (A) Total states (B) Total states (DIFF) ------------------- ----------------------- --------------- --------------- ------------------ ---------------- ---------------- ------------------- loop6.bpf.linked1.o trace_virtqueue_add_sgs 398057 15114 -382943 (-96.20%) 8717 336 -8381 (-96.15%) ------------------- ----------------------- --------------- --------------- ------------------ ---------------- ---------------- ------------------- CILIUM RESULTS ============== $ ./veristat -C -e file,prog,insns,states ~/imprecise-early-results-cilium.csv ~/imprecise-aggressive-results-cilium.csv | grep -v '+0' File Program Total insns (A) Total insns (B) Total insns (DIFF) Total states (A) Total states (B) Total states (DIFF) ------------- -------------------------------- --------------- --------------- ------------------ ---------------- ---------------- ------------------- bpf_host.o tail_handle_nat_fwd_ipv4 23426 23221 -205 (-0.88%) 1537 1515 -22 (-1.43%) bpf_host.o tail_handle_nat_fwd_ipv6 13009 12904 -105 (-0.81%) 719 708 -11 (-1.53%) bpf_host.o tail_nodeport_nat_ingress_ipv6 5261 5196 -65 (-1.24%) 247 243 -4 (-1.62%) bpf_host.o tail_nodeport_nat_ipv6_egress 3446 3406 -40 (-1.16%) 203 198 -5 (-2.46%) bpf_lxc.o tail_handle_nat_fwd_ipv4 23426 23221 -205 (-0.88%) 1537 1515 -22 (-1.43%) bpf_lxc.o tail_handle_nat_fwd_ipv6 13009 12904 -105 (-0.81%) 719 708 -11 (-1.53%) bpf_lxc.o tail_ipv4_ct_egress 5074 4897 -177 (-3.49%) 255 248 -7 (-2.75%) bpf_lxc.o tail_ipv4_ct_ingress 5100 4923 -177 (-3.47%) 255 248 -7 (-2.75%) bpf_lxc.o tail_ipv4_ct_ingress_policy_only 5100 4923 -177 (-3.47%) 255 248 -7 (-2.75%) bpf_lxc.o tail_ipv6_ct_egress 4558 4536 -22 (-0.48%) 188 187 -1 (-0.53%) bpf_lxc.o tail_ipv6_ct_ingress 4578 4556 -22 (-0.48%) 188 187 -1 (-0.53%) bpf_lxc.o tail_ipv6_ct_ingress_policy_only 4578 4556 -22 (-0.48%) 188 187 -1 (-0.53%) bpf_lxc.o tail_nodeport_nat_ingress_ipv6 5261 5196 -65 (-1.24%) 247 243 -4 (-1.62%) bpf_overlay.o tail_nodeport_nat_ingress_ipv6 5261 5196 -65 (-1.24%) 247 243 -4 (-1.62%) bpf_overlay.o tail_nodeport_nat_ipv6_egress 3482 3442 -40 (-1.15%) 204 201 -3 (-1.47%) bpf_xdp.o tail_nodeport_nat_egress_ipv4 17200 15619 -1581 (-9.19%) 1111 1010 -101 (-9.09%) ------------- -------------------------------- --------------- --------------- ------------------ ---------------- ---------------- ------------------- Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20221104163649.121784-6-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org> |
||
|
Andrii Nakryiko
|
f63181b6ae |
bpf: stop setting precise in current state
Setting reg->precise to true in current state is not necessary from correctness standpoint, but it does pessimise the whole precision (or rather "imprecision", because that's what we want to keep as much as possible) tracking. Why is somewhat subtle and my best attempt to explain this is recorded in an extensive comment for __mark_chain_precise() function. Some more careful thinking and code reading is probably required still to grok this completely, unfortunately. Whiteboarding and a bunch of extra handwaiving in person would be even more helpful, but is deemed impractical in Git commit. Next patch pushes this imprecision property even further, building on top of the insights described in this patch. End results are pretty nice, we get reduction in number of total instructions and states verified due to a better states reuse, as some of the states are now more generic and permissive due to less unnecessary precise=true requirements. SELFTESTS RESULTS ================= $ ./veristat -C -e file,prog,insns,states ~/subprog-precise-results.csv ~/imprecise-early-results.csv | grep -v '+0' File Program Total insns (A) Total insns (B) Total insns (DIFF) Total states (A) Total states (B) Total states (DIFF) --------------------------------------- ---------------------- --------------- --------------- ------------------ ---------------- ---------------- ------------------- bpf_iter_ksym.bpf.linked1.o dump_ksym 347 285 -62 (-17.87%) 20 19 -1 (-5.00%) pyperf600_bpf_loop.bpf.linked1.o on_event 3678 3736 +58 (+1.58%) 276 285 +9 (+3.26%) setget_sockopt.bpf.linked1.o skops_sockopt 4038 3947 -91 (-2.25%) 347 343 -4 (-1.15%) test_l4lb.bpf.linked1.o balancer_ingress 4559 2611 -1948 (-42.73%) 118 105 -13 (-11.02%) test_l4lb_noinline.bpf.linked1.o balancer_ingress 6279 6268 -11 (-0.18%) 237 236 -1 (-0.42%) test_misc_tcp_hdr_options.bpf.linked1.o misc_estab 1307 1303 -4 (-0.31%) 100 99 -1 (-1.00%) test_sk_lookup.bpf.linked1.o ctx_narrow_access 456 447 -9 (-1.97%) 39 38 -1 (-2.56%) test_sysctl_loop1.bpf.linked1.o sysctl_tcp_mem 1389 1384 -5 (-0.36%) 26 25 -1 (-3.85%) test_tc_dtime.bpf.linked1.o egress_fwdns_prio101 518 485 -33 (-6.37%) 51 46 -5 (-9.80%) test_tc_dtime.bpf.linked1.o egress_host 519 468 -51 (-9.83%) 50 44 -6 (-12.00%) test_tc_dtime.bpf.linked1.o ingress_fwdns_prio101 842 1000 +158 (+18.76%) 73 88 +15 (+20.55%) xdp_synproxy_kern.bpf.linked1.o syncookie_tc 405757 373173 -32584 (-8.03%) 25735 22882 -2853 (-11.09%) xdp_synproxy_kern.bpf.linked1.o syncookie_xdp 479055 371590 -107465 (-22.43%) 29145 22207 -6938 (-23.81%) --------------------------------------- ---------------------- --------------- --------------- ------------------ ---------------- ---------------- ------------------- Slight regression in test_tc_dtime.bpf.linked1.o/ingress_fwdns_prio101 is left for a follow up, there might be some more precision-related bugs in existing BPF verifier logic. CILIUM RESULTS ============== $ ./veristat -C -e file,prog,insns,states ~/subprog-precise-results-cilium.csv ~/imprecise-early-results-cilium.csv | grep -v '+0' File Program Total insns (A) Total insns (B) Total insns (DIFF) Total states (A) Total states (B) Total states (DIFF) ------------- ------------------------------ --------------- --------------- ------------------ ---------------- ---------------- ------------------- bpf_host.o cil_from_host 762 556 -206 (-27.03%) 43 37 -6 (-13.95%) bpf_host.o tail_handle_nat_fwd_ipv4 23541 23426 -115 (-0.49%) 1538 1537 -1 (-0.07%) bpf_host.o tail_nodeport_nat_egress_ipv4 33592 33566 -26 (-0.08%) 2163 2161 -2 (-0.09%) bpf_lxc.o tail_handle_nat_fwd_ipv4 23541 23426 -115 (-0.49%) 1538 1537 -1 (-0.07%) bpf_overlay.o tail_nodeport_nat_egress_ipv4 33581 33543 -38 (-0.11%) 2160 2157 -3 (-0.14%) bpf_xdp.o tail_handle_nat_fwd_ipv4 21659 20920 -739 (-3.41%) 1440 1376 -64 (-4.44%) bpf_xdp.o tail_handle_nat_fwd_ipv6 17084 17039 -45 (-0.26%) 907 905 -2 (-0.22%) bpf_xdp.o tail_lb_ipv4 73442 73430 -12 (-0.02%) 4370 4369 -1 (-0.02%) bpf_xdp.o tail_lb_ipv6 152114 151895 -219 (-0.14%) 6493 6479 -14 (-0.22%) bpf_xdp.o tail_nodeport_nat_egress_ipv4 17377 17200 -177 (-1.02%) 1125 1111 -14 (-1.24%) bpf_xdp.o tail_nodeport_nat_ingress_ipv6 6405 6397 -8 (-0.12%) 309 308 -1 (-0.32%) bpf_xdp.o tail_rev_nodeport_lb4 7126 6934 -192 (-2.69%) 414 402 -12 (-2.90%) bpf_xdp.o tail_rev_nodeport_lb6 18059 17905 -154 (-0.85%) 1105 1096 -9 (-0.81%) ------------- ------------------------------ --------------- --------------- ------------------ ---------------- ---------------- ------------------- Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20221104163649.121784-5-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org> |
||
|
Andrii Nakryiko
|
be2ef81615 |
bpf: allow precision tracking for programs with subprogs
Stop forcing precise=true for SCALAR registers when BPF program has any subprograms. Current restriction means that any BPF program, as soon as it uses subprograms, will end up not getting any of the precision tracking benefits in reduction of number of verified states. This patch keeps the fallback mark_all_scalars_precise() behavior if precise marking has to cross function frames. E.g., if subprogram requires R1 (first input arg) to be marked precise, ideally we'd need to backtrack to the parent function and keep marking R1 and its dependencies as precise. But right now we give up and force all the SCALARs in any of the current and parent states to be forced to precise=true. We can lift that restriction in the future. But this patch fixes two issues identified when trying to enable precision tracking for subprogs. First, prevent "escaping" from top-most state in a global subprog. While with entry-level BPF program we never end up requesting precision for R1-R5 registers, because R2-R5 are not initialized (and so not readable in correct BPF program), and R1 is PTR_TO_CTX, not SCALAR, and so is implicitly precise. With global subprogs, though, it's different, as global subprog a) can have up to 5 SCALAR input arguments, which might get marked as precise=true and b) it is validated in isolation from its main entry BPF program. b) means that we can end up exhausting parent state chain and still not mark all registers in reg_mask as precise, which would lead to verifier bug warning. To handle that, we need to consider two cases. First, if the very first state is not immediately "checkpointed" (i.e., stored in state lookup hashtable), it will get correct first_insn_idx and last_insn_idx instruction set during state checkpointing. As such, this case is already handled and __mark_chain_precision() already handles that by just doing nothing when we reach to the very first parent state. st->parent will be NULL and we'll just stop. Perhaps some extra check for reg_mask and stack_mask is due here, but this patch doesn't address that issue. More problematic second case is when global function's initial state is immediately checkpointed before we manage to process the very first instruction. This is happening because when there is a call to global subprog from the main program the very first subprog's instruction is marked as pruning point, so before we manage to process first instruction we have to check and checkpoint state. This patch adds a special handling for such "empty" state, which is identified by having st->last_insn_idx set to -1. In such case, we check that we are indeed validating global subprog, and with some sanity checking we mark input args as precise if requested. Note that we also initialize state->first_insn_idx with correct start insn_idx offset. For main program zero is correct value, but for any subprog it's quite confusing to not have first_insn_idx set. This doesn't have any functional impact, but helps with debugging and state printing. We also explicitly initialize state->last_insns_idx instead of relying on is_state_visited() to do this with env->prev_insns_idx, which will be -1 on the very first instruction. This concludes necessary changes to handle specifically global subprog's precision tracking. Second identified problem was missed handling of BPF helper functions that call into subprogs (e.g., bpf_loop and few others). From precision tracking and backtracking logic's standpoint those are effectively calls into subprogs and should be called as BPF_PSEUDO_CALL calls. This patch takes the least intrusive way and just checks against a short list of current BPF helpers that do call subprogs, encapsulated in is_callback_calling_function() function. But to prevent accidentally forgetting to add new BPF helpers to this "list", we also do a sanity check in __check_func_call, which has to be called for each such special BPF helper, to validate that BPF helper is indeed recognized as callback-calling one. This should catch any missed checks in the future. Adding some special flags to be added in function proto definitions seemed like an overkill in this case. With the above changes, it's possible to remove forceful setting of reg->precise to true in __mark_reg_unknown, which turns on precision tracking both inside subprogs and entry progs that have subprogs. No warnings or errors were detected across all the selftests, but also when validating with veristat against internal Meta BPF objects and Cilium objects. Further, in some BPF programs there are noticeable reduction in number of states and instructions validated due to more effective precision tracking, especially benefiting syncookie test. $ ./veristat -C -e file,prog,insns,states ~/baseline-results.csv ~/subprog-precise-results.csv | grep -v '+0' File Program Total insns (A) Total insns (B) Total insns (DIFF) Total states (A) Total states (B) Total states (DIFF) ---------------------------------------- -------------------------- --------------- --------------- ------------------ ---------------- ---------------- ------------------- pyperf600_bpf_loop.bpf.linked1.o on_event 3966 3678 -288 (-7.26%) 306 276 -30 (-9.80%) pyperf_global.bpf.linked1.o on_event 7563 7530 -33 (-0.44%) 520 517 -3 (-0.58%) pyperf_subprogs.bpf.linked1.o on_event 36358 36934 +576 (+1.58%) 2499 2531 +32 (+1.28%) setget_sockopt.bpf.linked1.o skops_sockopt 3965 4038 +73 (+1.84%) 343 347 +4 (+1.17%) test_cls_redirect_subprogs.bpf.linked1.o cls_redirect 64965 64901 -64 (-0.10%) 4619 4612 -7 (-0.15%) test_misc_tcp_hdr_options.bpf.linked1.o misc_estab 1491 1307 -184 (-12.34%) 110 100 -10 (-9.09%) test_pkt_access.bpf.linked1.o test_pkt_access 354 349 -5 (-1.41%) 25 24 -1 (-4.00%) test_sock_fields.bpf.linked1.o egress_read_sock_fields 435 375 -60 (-13.79%) 22 20 -2 (-9.09%) test_sysctl_loop2.bpf.linked1.o sysctl_tcp_mem 1508 1501 -7 (-0.46%) 29 28 -1 (-3.45%) test_tc_dtime.bpf.linked1.o egress_fwdns_prio100 468 435 -33 (-7.05%) 45 41 -4 (-8.89%) test_tc_dtime.bpf.linked1.o ingress_fwdns_prio100 398 408 +10 (+2.51%) 42 39 -3 (-7.14%) test_tc_dtime.bpf.linked1.o ingress_fwdns_prio101 1096 842 -254 (-23.18%) 97 73 -24 (-24.74%) test_tcp_hdr_options.bpf.linked1.o estab 2758 2408 -350 (-12.69%) 208 181 -27 (-12.98%) test_urandom_usdt.bpf.linked1.o urand_read_with_sema 466 448 -18 (-3.86%) 31 28 -3 (-9.68%) test_urandom_usdt.bpf.linked1.o urand_read_without_sema 466 448 -18 (-3.86%) 31 28 -3 (-9.68%) test_urandom_usdt.bpf.linked1.o urandlib_read_with_sema 466 448 -18 (-3.86%) 31 28 -3 (-9.68%) test_urandom_usdt.bpf.linked1.o urandlib_read_without_sema 466 448 -18 (-3.86%) 31 28 -3 (-9.68%) test_xdp_noinline.bpf.linked1.o balancer_ingress_v6 4302 4294 -8 (-0.19%) 257 256 -1 (-0.39%) xdp_synproxy_kern.bpf.linked1.o syncookie_tc 583722 405757 -177965 (-30.49%) 35846 25735 -10111 (-28.21%) xdp_synproxy_kern.bpf.linked1.o syncookie_xdp 609123 479055 -130068 (-21.35%) 35452 29145 -6307 (-17.79%) ---------------------------------------- -------------------------- --------------- --------------- ------------------ ---------------- ---------------- ------------------- Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20221104163649.121784-4-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org> |
||
|
Andrii Nakryiko
|
529409ea92 |
bpf: propagate precision across all frames, not just the last one
When equivalent completed state is found and it has additional precision
restrictions, BPF verifier propagates precision to
currently-being-verified state chain (i.e., including parent states) so
that if some of the states in the chain are not yet completed, necessary
precision restrictions are enforced.
Unfortunately, right now this happens only for the last frame (deepest
active subprogram's frame), not all the frames. This can lead to
incorrect matching of states due to missing precision marker. Currently
this doesn't seem possible as BPF verifier forces everything to precise
when validated BPF program has any subprograms. But with the next patch
lifting this restriction, this becomes problematic.
In fact, without this fix, we'll start getting failure in one of the
existing test_verifier test cases:
#906/p precise: cross frame pruning FAIL
Unexpected success to load!
verification time 48 usec
stack depth 0+0
processed 26 insns (limit 1000000) max_states_per_insn 3 total_states 17 peak_states 17 mark_read 8
This patch adds precision propagation across all frames.
Fixes:
|
||
|
Andrii Nakryiko
|
a3b666bfa9 |
bpf: propagate precision in ALU/ALU64 operations
When processing ALU/ALU64 operations (apart from BPF_MOV, which is
handled correctly already; and BPF_NEG and BPF_END are special and don't
have source register), if destination register is already marked
precise, this causes problem with potentially missing precision tracking
for the source register. E.g., when we have r1 >>= r5 and r1 is marked
precise, but r5 isn't, this will lead to r5 staying as imprecise. This
is due to the precision backtracking logic stopping early when it sees
r1 is already marked precise. If r1 wasn't precise, we'd keep
backtracking and would add r5 to the set of registers that need to be
marked precise. So there is a discrepancy here which can lead to invalid
and incompatible states matched due to lack of precision marking on r5.
If r1 wasn't precise, precision backtracking would correctly mark both
r1 and r5 as precise.
This is simple to fix, though. During the forward instruction simulation
pass, for arithmetic operations of `scalar <op>= scalar` form (where
<op> is ALU or ALU64 operations), if destination register is already
precise, mark source register as precise. This applies only when both
involved registers are SCALARs. `ptr += scalar` and `scalar += ptr`
cases are already handled correctly.
This does have (negative) effect on some selftest programs and few
Cilium programs. ~/baseline-tmp-results.csv are veristat results with
this patch, while ~/baseline-results.csv is without it. See post
scriptum for instructions on how to make Cilium programs testable with
veristat. Correctness has a price.
$ ./veristat -C -e file,prog,insns,states ~/baseline-results.csv ~/baseline-tmp-results.csv | grep -v '+0'
File Program Total insns (A) Total insns (B) Total insns (DIFF) Total states (A) Total states (B) Total states (DIFF)
----------------------- -------------------- --------------- --------------- ------------------ ---------------- ---------------- -------------------
bpf_cubic.bpf.linked1.o bpf_cubic_cong_avoid 997 1700 +703 (+70.51%) 62 90 +28 (+45.16%)
test_l4lb.bpf.linked1.o balancer_ingress 4559 5469 +910 (+19.96%) 118 126 +8 (+6.78%)
----------------------- -------------------- --------------- --------------- ------------------ ---------------- ---------------- -------------------
$ ./veristat -C -e file,prog,verdict,insns,states ~/baseline-results-cilium.csv ~/baseline-tmp-results-cilium.csv | grep -v '+0'
File Program Total insns (A) Total insns (B) Total insns (DIFF) Total states (A) Total states (B) Total states (DIFF)
------------- ------------------------------ --------------- --------------- ------------------ ---------------- ---------------- -------------------
bpf_host.o tail_nodeport_nat_ingress_ipv6 4448 5261 +813 (+18.28%) 234 247 +13 (+5.56%)
bpf_host.o tail_nodeport_nat_ipv6_egress 3396 3446 +50 (+1.47%) 201 203 +2 (+1.00%)
bpf_lxc.o tail_nodeport_nat_ingress_ipv6 4448 5261 +813 (+18.28%) 234 247 +13 (+5.56%)
bpf_overlay.o tail_nodeport_nat_ingress_ipv6 4448 5261 +813 (+18.28%) 234 247 +13 (+5.56%)
bpf_xdp.o tail_lb_ipv4 71736 73442 +1706 (+2.38%) 4295 4370 +75 (+1.75%)
------------- ------------------------------ --------------- --------------- ------------------ ---------------- ---------------- -------------------
P.S. To make Cilium ([0]) programs libbpf-compatible and thus
veristat-loadable, apply changes from topmost commit in [1], which does
minimal changes to Cilium source code, mostly around SEC() annotations
and BPF map definitions.
[0] https://github.com/cilium/cilium/
[1] https://github.com/anakryiko/cilium/commits/libbpf-friendliness
Fixes:
|
||
Stephen Boyd
|
57d894e772 |
clk: renesas: Updates for v6.2
- Round SD clock rate to improve parent clock selection,
- Add Ethernet Switch and internal SASYNCPER clocks on R-Car S4-8,
- Add DMA (SYS-DMAC), SPI (MSIOF), external interrupt (INTC-EX),
serial (SCIF), PWM (PWM and TPU), SDHI, and HyperFLASH/QSPI (RPC-IF)
clocks on R-Car V4H,
- Add Multi-Function Timer Pulse Unit (MTU3a) clock and reset on
RZ/G2L,
- Fix endless loop on RZ/N1,
- Miscellaneous fixes and improvements.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQ9qaHoIs/1I4cXmEiKwlD9ZEnxcAUCY2TtHwAKCRCKwlD9ZEnx
cG5oAP9EdwhyhiCabH5GPIrsTpgztDjie/frEHXEFDKJ+VI5rgEAnc6zerkGdlcJ
2TEFwsJ7kebmKxwEae1PerouV2s/jws=
=18oJ
-----END PGP SIGNATURE-----
Merge tag 'renesas-clk-for-v6.2-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into clk-renesas
Pull Renesas clk driver updates from Geert Uytterhoeven:
- Round SD clock rate to improve parent clock selection
- Add Ethernet Switch and internal SASYNCPER clocks on R-Car S4-8
- Add DMA (SYS-DMAC), SPI (MSIOF), external interrupt (INTC-EX)
serial (SCIF), PWM (PWM and TPU), SDHI, and HyperFLASH/QSPI (RPC-IF)
clocks on R-Car V4H
- Add Multi-Function Timer Pulse Unit (MTU3a) clock and reset on
RZ/G2L
- Fix endless loop on RZ/N1
- Miscellaneous fixes and improvements
* tag 'renesas-clk-for-v6.2-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers: (22 commits)
clk: renesas: r9a06g032: Repair grave increment error
clk: renesas: rzg2l: Don't assume all CPG_MOD clocks support PM
clk: renesas: rzg2l: Fix typo in struct rzg2l_cpg_priv kerneldoc
clk: renesas: r8a779a0: Fix SD0H clock name
clk: renesas: r8a779g0: Add RPC-IF clock
clk: renesas: r8a779g0: Add SDHI clocks
clk: renesas: r8a779f0: Add SASYNCPER internal clock
clk: renesas: r8a779f0: Fix SD0H clock name
clk: renesas: r9a07g043: Drop WDT2 clock and reset entry
clk: renesas: r9a07g044: Drop WDT2 clock and reset entry
clk: renesas: r8a779g0: Add TPU clock
clk: renesas: r8a779g0: Add PWM clock
clk: renesas: r8a779g0: Add SCIF clocks
clk: renesas: r8a779g0: Fix HSCIF parent clocks
clk: renesas: r8a779g0: Add SASYNCPER clocks
clk: renesas: r9a07g044: Add MTU3a clock and reset entry
clk: renesas: r8a779g0: Add INTC-EX clock
clk: renesas: r8a779g0: Add MSIOF clocks
clk: renesas: r8a779g0: Add SYS-DMAC clocks
clk: renesas: r8a779f0: Add Ethernet Switch clocks
...
|
||
|
Linus Torvalds
|
fde25beb38 |
drm fixes for 6.1-rc4
amdgpu: - DCN 3.1.4 fixes - DCN 3.2.x fixes - GC 11.x fixes - Virtual display fix - Fail suspend if resources can't be evicted - SR-IOV fix - Display PSR fix amdkfd: - Fix possible NULL pointer deref - GC 11.x trap handler fix i915: - Add locking around DKL PHY register accesses - Stop abusing swiotlb_max_segment - Filter out invalid outputs more sensibly - Setup DDC fully before output init - Simplify intel_panel_add_edid_alt_fixed_modes() - Grab mode_config.mutex during LVDS init to avoid WARNs rockchip: - fix probing issues - fix framebuffer without iommu - fix vop selection - fix NULL ptr access imx: - Fix Kconfig. - fix mode_valid function -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAmNkg60ACgkQDHTzWXnE hr6utQ/7Bmb0TtSTjgv2dTkHgSFfw2mmzBxkm6Xv2Lc03T+Iqqlr1XhbPVCUtfQs lWQUO79ELwr16hjKbGUR3WEyESez6M1RUN7MeevrZ4DCldliKh1MkFVEh3GdBCqk d5IQdJmSms+P7NpZxaLQ+ycwFtFZydRB1P//Kdq0BewzSWz4Fwh9QvlF6BSBmB0b TdDt1aVXxdzWaas65oAGrGY9Z+ESqe1D3g/VifbYeDSaSJaEJ/WO1ljZ3T8fNT79 ny3HYosNZN1ERjxlAvWzKNMoXXqcsMqGEvrFCYwRYirIS8rwtRsEXSt+s9fxzKPf 8J4kFrKUrAAbHUYKHYYn3lEngUa4N9TwQnmjb5T3Bcdiook29QGeJtR/lI3bQ77P CbotD5G31DCs6dHQgoYb3uN2KVS08PhC6L4+tGyo4UG/sh6ZnbqHDS4WKl9HtOQM cY1nIgdwYhMOBP2fATzI695T59fak6NrTHu8fcS+zLoaU+/yO+ugmfluklVNUsgJ oqZEmMZfB/YwpJNbSELNAiddrFfvjZ83ElXLYn48EP31O+D/rmmPf03KZolfVpNu WYHGNNDt7kUg7XCSiF+uzCtdigl89F831JnVW4bzW/1hokUuRgDYWXObPCbVJoor Z5I0q2SzdTt+c7ssPaQpJCtH2vb0TJj1OesR/b6hNoP4VLYrzL8= =adND -----END PGP SIGNATURE----- Merge tag 'drm-fixes-2022-11-04-1' of git://anongit.freedesktop.org/drm/drm Pull drm fixes from Dave Airlie: "This is the weekly fixes for rc4. Misc fixes across rockchip, imx, amdgpu and i915. The biggest change is for amdkfd where the trap handler needs an updated fw from a header which makes it a bit larger. I hadn't noticed this particular file before so I'm going to figure out what the magic is for, but the fix should be fine for now. amdgpu: - DCN 3.1.4 fixes - DCN 3.2.x fixes - GC 11.x fixes - Virtual display fix - Fail suspend if resources can't be evicted - SR-IOV fix - Display PSR fix amdkfd: - Fix possible NULL pointer deref - GC 11.x trap handler fix i915: - Add locking around DKL PHY register accesses - Stop abusing swiotlb_max_segment - Filter out invalid outputs more sensibly - Setup DDC fully before output init - Simplify intel_panel_add_edid_alt_fixed_modes() - Grab mode_config.mutex during LVDS init to avoid WARNs rockchip: - fix probing issues - fix framebuffer without iommu - fix vop selection - fix NULL ptr access imx: - Fix Kconfig - fix mode_valid function" * tag 'drm-fixes-2022-11-04-1' of git://anongit.freedesktop.org/drm/drm: (35 commits) drm/amdkfd: update GFX11 CWSR trap handler drm/amd/display: Investigate tool reported FCLK P-state deviations drm/amd/display: Add DSC delay factor workaround drm/amd/display: Round up DST_after_scaler to nearest int drm/amd/display: Use forced DSC bpp in DML drm/amd/display: Fix DCN32 DSC delay calculation drm/amdgpu: Disable GPU reset on SRIOV before remove pci. drm/amdgpu: disable GFXOFF during compute for GFX11 drm/amd: Fail the suspend if resources can't be evicted drm/amdkfd: Fix NULL pointer dereference in svm_migrate_to_ram() drm/amdgpu: correct MES debugfs versions drm/amdgpu: set fb_modifiers_not_supported in vkms drm/amd/display: cursor update command incomplete drm/amd/display: Enable timing sync on DCN32 drm/amd/display: Set memclk levels to be at least 1 for dcn32 drm/amd/display: Update latencies on DCN321 drm/amd/display: Limit dcn32 to 1950Mhz display clock drm/amd/display: Ignore Cable ID Feature drm/amd/display: Update DSC capabilitie for DCN314 drm/imx: imx-tve: Fix return type of imx_tve_connector_mode_valid ... |
||
|
Linus Torvalds
|
db385e0be4 |
Fixes in clk drivers and some clk rate range fixes in the core as well.
- Make sure the struct clk_rate_request is more sane.
- Remove a WARN_ON that was triggering for clks with no parents
that can change frequency.
- Fix bad i2c bus transactions on Renesas rs9.
- Actually return an error in clk_mt8195_topck_probe() on an error
path.
- Keep the GPU memories powered while the clk isn't enabled on
Qualcomm's sc7280 SoC.
- Fix the parent clk for HSCIF modules on Renesas' R-Car V4H SoC.
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEE9L57QeeUxqYDyoaDrQKIl8bklSUFAmNkc/IRHHNib3lkQGtl
cm5lbC5vcmcACgkQrQKIl8bklSXAww//V6V93fcenMvFywLn871iSLu2G2OSUKt/
WnPQBJuTGoJRMJsaFRMycCPSGmfMx0cnCaAkErpk5lKDZgFNRcjDTEtMMILn90Vm
NhRiWlX/60M7cUOUYbtXhJNc/K/Ia9X05fgRpN4a68ZhHBE57l2jOdH3p4ZIeJcx
RSYrddZPZO4Hyh1vr3f8sMwFhuA8XlIZFpKw9A4UsbkJVQGiJhom/ZdBM3B92ZKx
1w1enRakiwOPEV9qyo0JoEfjQff8cC3r0hRVGQMuwyFGOTj8xdTwk6IypLx60MlC
yPZoW3wPr5X4XCcxLLhWIPoyzuNIS8ForfFha9Q47wHu68AapjenG8jMI8wDpP8q
i7P3KpCB8fnGobaoHMRQEYZjURWakOov9MSaJAAVd0iCrc9vzk1rr1txAsQwEmPF
D7HFtaxaeFLcHojSXIBcZXj2uYA5NtbIa4Qi8g7RnD2d10i9d1bNuoerugNVHWbg
fbHKE5fO3I9T3xS8S2nUIa89UuMwEaFPnglLtRx704Rn4lRiAgq0jdpv+5PNDA4d
ZXn9UIGiysoaLQ8f4lhX2aUrGMhpaRcUJV3iGt2KCZeY+jpXjnOOZkmUanGCKKWG
Xeo2rZ98PlW3XtR0s0HcNCyfOaQstzIZ2RXeYAUYAYi6PEGl3xXqs4ndGRjC8QM6
TuMw1B9zocM=
=Awyk
-----END PGP SIGNATURE-----
Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
Pull clk fixes from Stephen Boyd:
"Fixes in clk drivers and some clk rate range fixes in the core as
well:
- Make sure the struct clk_rate_request is more sane
- Remove a WARN_ON that was triggering for clks with no parents that
can change frequency
- Fix bad i2c bus transactions on Renesas rs9
- Actually return an error in clk_mt8195_topck_probe() on an error
path
- Keep the GPU memories powered while the clk isn't enabled on
Qualcomm's sc7280 SoC
- Fix the parent clk for HSCIF modules on Renesas' R-Car V4H SoC"
* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
clk: qcom: Update the force mem core bit for GPU clocks
clk: Initialize max_rate in struct clk_rate_request
clk: Initialize the clk_rate_request even if clk_core is NULL
clk: Remove WARN_ON NULL parent in clk_core_init_rate_req()
clk: renesas: r8a779g0: Fix HSCIF parent clocks
clk: renesas: r8a779g0: Add SASYNCPER clocks
clk: mediatek: clk-mt8195-topckgen: Fix error return code in clk_mt8195_topck_probe()
clk: sifive: select by default if SOC_SIFIVE
clk: rs9: Fix I2C accessors
|
||
Kees Cook
|
e9d696cb44 |
igb: Proactively round up to kmalloc bucket size
In preparation for removing the "silently change allocation size" users of ksize(), explicitly round up all q_vector allocations so that allocations can be correctly compared to ksize(). Cc: Jesse Brandeburg <jesse.brandeburg@intel.com> Cc: Tony Nguyen <anthony.l.nguyen@intel.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: intel-wired-lan@lists.osuosl.org Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> |
||
|
Kees Cook
|
0668716506 |
igb: Do not free q_vector unless new one was allocated
Avoid potential use-after-free condition under memory pressure. If the kzalloc() fails, q_vector will be freed but left in the original adapter->q_vector[v_idx] array position. Cc: Jesse Brandeburg <jesse.brandeburg@intel.com> Cc: Tony Nguyen <anthony.l.nguyen@intel.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: intel-wired-lan@lists.osuosl.org Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> |
||
Jan Sokolowski
|
eac0b6804b |
ixgbevf: Add error messages on vlan error
ixgbevf did not provide an error in dmesg if VLAN addition failed. Add two descriptive failure messages in the kernel log. Signed-off-by: Jan Sokolowski <jan.sokolowski@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> |