| Age | Commit message (Collapse) | Author |
|---|
|
Multiple vendors seem to prefer taking discussions off list, and
ask contributors to work with them privately rather than just send
patches to the list. I'd imagine this is because it's hard to fit in
time for random developers popping up with features to review into
packed schedule. From what I've seen "work in private" usually means
someone on the company side will be assigned to handle the interaction,
possibly months later. In worst case, the person scheduled to help
the contributor takes over and writes the code themselves.
This is not how the community is supposed to work.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20240713235020.820910-1-kuba@kernel.org
Link: https://lore.kernel.org/r/20240712144903.392284-1-kuba@kernel.org
|
|
Similar to kvm_x86_call(), kvm_pmu_call() is added to streamline the usage
of static calls of kvm_pmu_ops, which improves code readability.
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Wei Wang <wei.w.wang@intel.com>
Link: https://lore.kernel.org/r/20240507133103.15052-4-wei.w.wang@intel.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Introduces kvm_x86_call(), to streamline the usage of static calls of
kvm_x86_ops. The current implementation of these calls is verbose and
could lead to alignment challenges. This makes the code susceptible to
exceeding the "80 columns per single line of code" limit as defined in
the coding-style document. Another issue with the existing implementation
is that the addition of kvm_x86_ prefix to hooks at the static_call sites
hinders code readability and navigation. kvm_x86_call() is added to
improve code readability and maintainability, while adhering to the coding
style guidelines.
Signed-off-by: Wei Wang <wei.w.wang@intel.com>
Link: https://lore.kernel.org/r/20240507133103.15052-3-wei.w.wang@intel.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
The use of static_call_cond() is essentially the same as static_call() on
x86 (e.g. static_call() now handles a NULL pointer as a NOP), so replace
it with static_call() to simplify the code.
Link: https://lore.kernel.org/all/3916caa1dcd114301a49beafa5030eca396745c1.1679456900.git.jpoimboe@kernel.org/
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Wei Wang <wei.w.wang@intel.com>
Link: https://lore.kernel.org/r/20240507133103.15052-2-wei.w.wang@intel.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Fixes the following warning when building allmodconfig with W=1 C=1:
WARNING: modpost: missing MODULE_DESCRIPTION() in arch/sh/drivers/push-switch.o
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Link: https://lore.kernel.org/r/20240702-md-sh-arch-sh-drivers-v1-1-2c5d439a5479@quicinc.com
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
|
|
The GHCB 2.0 specification defines 2 GHCB request types to allow SNP guests
to send encrypted messages/requests to firmware: SNP Guest Requests and SNP
Extended Guest Requests. These encrypted messages are used for things like
servicing attestation requests issued by the guest. Implementing support for
these is required to be fully GHCB-compliant.
For the most part, KVM only needs to handle forwarding these requests to
firmware (to be issued via the SNP_GUEST_REQUEST firmware command defined
in the SEV-SNP Firmware ABI), and then forwarding the encrypted response to
the guest.
However, in the case of SNP Extended Guest Requests, the host is also
able to provide the certificate data corresponding to the endorsement key
used by firmware to sign attestation report requests. This certificate data
is provided by userspace because:
1) It allows for different keys/key types to be used for each particular
guest with requiring any sort of KVM API to configure the certificate
table in advance on a per-guest basis.
2) It provides additional flexibility with how attestation requests might
be handled during live migration where the certificate data for
source/dest might be different.
3) It allows all synchronization between certificates and firmware/signing
key updates to be handled purely by userspace rather than requiring
some in-kernel mechanism to facilitate it. [1]
To support fetching certificate data from userspace, a new KVM exit type will
be needed to handle fetching the certificate from userspace. An attempt to
define a new KVM_EXIT_COCO/KVM_EXIT_COCO_REQ_CERTS exit type to handle this
was introduced in v1 of this patchset, but is still being discussed by
community, so for now this patchset only implements a stub version of SNP
Extended Guest Requests that does not provide certificate data, but is still
enough to provide compliance with the GHCB 2.0 spec.
|
|
Version 2 of GHCB specification added support for the SNP Extended Guest
Request Message NAE event. This event serves a nearly identical purpose
to the previously-added SNP_GUEST_REQUEST event, but for certain message
types it allows the guest to supply a buffer to be used for additional
information in some cases.
Currently the GHCB spec only defines extended handling of this sort in
the case of attestation requests, where the additional buffer is used to
supply a table of certificate data corresponding to the attestion
report's signing key. Support for this extended handling will require
additional KVM APIs to handle coordinating with userspace.
Whether or not the hypervisor opts to provide this certificate data is
optional. However, support for processing SNP_EXTENDED_GUEST_REQUEST
GHCB requests is required by the GHCB 2.0 specification for SNP guests,
so for now implement a stub implementation that provides an empty
certificate table to the guest if it supplies an additional buffer, but
otherwise behaves identically to SNP_GUEST_REQUEST.
Reviewed-by: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
Message-ID: <20240701223148.3798365-4-michael.roth@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
sev_guest.h currently contains various definitions relating to the
format of SNP_GUEST_REQUEST commands to SNP firmware. Currently only the
sev-guest driver makes use of them, but when the KVM side of this is
implemented there's a need to parse the SNP_GUEST_REQUEST header to
determine whether additional information needs to be provided to the
guest. Prepare for this by moving those definitions to a common header
that's shared by host/guest code so that KVM can also make use of them.
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
Message-ID: <20240701223148.3798365-3-michael.roth@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Version 2 of GHCB specification added support for the SNP Guest Request
Message NAE event. The event allows for an SEV-SNP guest to make
requests to the SEV-SNP firmware through the hypervisor using the
SNP_GUEST_REQUEST API defined in the SEV-SNP firmware specification.
This is used by guests primarily to request attestation reports from
firmware. There are other request types are available as well, but the
specifics of what guest requests are being made generally does not
affect how they are handled by the hypervisor, which only serves as a
proxy for the guest requests and firmware responses.
Implement handling for these events.
When an SNP Guest Request is issued, the guest will provide its own
request/response pages, which could in theory be passed along directly
to firmware. However, these pages would need special care:
- Both pages are from shared guest memory, so they need to be
protected from migration/etc. occurring while firmware reads/writes
to them. At a minimum, this requires elevating the ref counts and
potentially needing an explicit pinning of the memory. This places
additional restrictions on what type of memory backends userspace
can use for shared guest memory since there would be some reliance
on using refcounted pages.
- The response page needs to be switched to Firmware-owned state
before the firmware can write to it, which can lead to potential
host RMP #PFs if the guest is misbehaved and hands the host a
guest page that KVM is writing to for other reasons (e.g. virtio
buffers).
Both of these issues can be avoided completely by using
separately-allocated bounce pages for both the request/response pages
and passing those to firmware instead. So that's the approach taken
here.
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Co-developed-by: Alexey Kardashevskiy <aik@amd.com>
Signed-off-by: Alexey Kardashevskiy <aik@amd.com>
Co-developed-by: Ashish Kalra <ashish.kalra@amd.com>
Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
[mdr: ensure FW command failures are indicated to guest, drop extended
request handling to be re-written as separate patch, massage commit]
Signed-off-by: Michael Roth <michael.roth@amd.com>
Message-ID: <20240701223148.3798365-2-michael.roth@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
There is a spelling mistake in a netdev_warn message. Fix it.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://patch.msgid.link/20240716093851.1003131-1-colin.i.king@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Replace the deprecated[1] uses of strncpy() in tcp_ca_get_name_by_key()
and tcp_get_default_congestion_control(). The callers use the results as
standard C strings (via nla_put_string() and proc handlers respectively),
so trailing padding is not needed.
Since passing the destination buffer arguments decays it to a pointer,
the size can't be trivially determined by the compiler. ca->name is
the same length in both cases, so strscpy() won't fail (when ca->name
is NUL-terminated). Include the length explicitly instead of using the
2-argument strscpy().
Link: https://github.com/KSPP/linux/issues/90 [1]
Signed-off-by: Kees Cook <kees@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20240714041111.it.918-kees@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
gcc 11.4.1-3 warns about memcpy() with overlapping pointers:
drivers/net/wireless/ath/ath12k/wow.c: In function ‘ath12k_wow_convert_8023_to_80211.constprop’:
./include/linux/fortify-string.h:114:33: error: ‘__builtin_memcpy’ accessing 18446744073709551611 or more bytes at offsets 0 and 0 overlaps 9223372036854775799 bytes at offset -9223372036854775804 [-Werror=restrict]
114 | #define __underlying_memcpy __builtin_memcpy
| ^
./include/linux/fortify-string.h:637:9: note: in expansion of macro ‘__underlying_memcpy’
637 | __underlying_##op(p, q, __fortify_size); \
| ^~~~~~~~~~~~~
./include/linux/fortify-string.h:682:26: note: in expansion of macro ‘__fortify_memcpy_chk’
682 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \
| ^~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/ath/ath12k/wow.c:190:25: note: in expansion of macro ‘memcpy’
190 | memcpy(pat, eth_pat, eth_pat_len);
| ^~~~~~
./include/linux/fortify-string.h:114:33: error: ‘__builtin_memcpy’ accessing 18446744073709551605 or more bytes at offsets 0 and 0 overlaps 9223372036854775787 bytes at offset -9223372036854775798 [-Werror=restrict]
114 | #define __underlying_memcpy __builtin_memcpy
| ^
./include/linux/fortify-string.h:637:9: note: in expansion of macro ‘__underlying_memcpy’
637 | __underlying_##op(p, q, __fortify_size); \
| ^~~~~~~~~~~~~
./include/linux/fortify-string.h:682:26: note: in expansion of macro ‘__fortify_memcpy_chk’
682 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \
| ^~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/ath/ath12k/wow.c:232:25: note: in expansion of macro ‘memcpy’
232 | memcpy(pat, eth_pat, eth_pat_len);
| ^~~~~~
The sum of size_t operands can overflow SIZE_MAX, triggering the
warning.
Address the issue using the suitable helper.
Fixes: 4a3c212eee0e ("wifi: ath12k: add basic WoW functionalities")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Kees Cook <kees@kernel.org>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Link: https://patch.msgid.link/3175f87d7227e395b330fd88fb840c1645084ea7.1721127979.git.pabeni@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The explanation for @handled_access_fs and @handled_access_net has
significant overlap and is better explained together.
* Explain the commonalities in structure-level documentation.
* Clarify some wording and break up longer sentences.
* Put emphasis on the word "handled" to make it clearer that "handled"
is a term with special meaning in the context of Landlock.
I'd like to transfer this wording into the man pages as well.
Signed-off-by: Günther Noack <gnoack@google.com>
Cc: Alejandro Colomar <alx@kernel.org>
Cc: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
Cc: linux-security-module@vger.kernel.org
Link: https://lore.kernel.org/r/20240711165456.2148590-2-gnoack@google.com
[mic: Format commit message]
Signed-off-by: Mickaël Salaün <mic@digikod.net>
|
|
Explicitly suppress userspace emulated MMIO exits that are triggered when
emulating a task switch as KVM doesn't support userspace MMIO during
complex (multi-step) emulation. Silently ignoring the exit request can
result in the WARN_ON_ONCE(vcpu->mmio_needed) firing if KVM exits to
userspace for some other reason prior to purging mmio_needed.
See commit 0dc902267cb3 ("KVM: x86: Suppress pending MMIO write exits if
emulator detects exception") for more details on KVM's limitations with
respect to emulated MMIO during complex emulator flows.
Reported-by: syzbot+2fb9f8ed752c01bc9a3f@syzkaller.appspotmail.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20240712144841.1230591-1-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Tweak the definition of make_huge_page_split_spte() to eliminate an
unnecessarily long line, and opportunistically initialize child_spte to
make it more obvious that the child is directly derived from the huge
parent.
No functional change intended.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20240712151335.1242633-3-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Bug the VM instead of simply warning if KVM tries to split a SPTE that is
non-present or not-huge. KVM is guaranteed to end up in a broken state as
the callers fully expect a valid SPTE, e.g. the shadow MMU will add an
rmap entry, and all MMUs will account the expected small page. Returning
'0' is also technically wrong now that SHADOW_NONPRESENT_VALUE exists,
i.e. would cause KVM to create a potential #VE SPTE.
While it would be possible to have the callers gracefully handle failure,
doing so would provide no practical value as the scenario really should be
impossible, while the error handling would add a non-trivial amount of
noise.
Fixes: a3fe5dbda0a4 ("KVM: x86/mmu: Split huge pages mapped by the TDP MMU when dirty logging is enabled")
Cc: David Matlack <dmatlack@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20240712151335.1242633-2-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
KVM VMX changes for 6.11
- Remove an unnecessary EPT TLB flush when enabling hardware.
- Fix a series of bugs that cause KVM to fail to detect nested pending posted
interrupts as valid wake eents for a vCPU executing HLT in L2 (with
HLT-exiting disable by L1).
- Misc cleanups
|
|
KVM SVM changes for 6.11
- Make per-CPU save_area allocations NUMA-aware.
- Force sev_es_host_save_area() to be inlined to avoid calling into an
instrumentable function from noinstr code.
|
|
KVM selftests for 6.11
- Remove dead code in the memslot modification stress test.
- Treat "branch instructions retired" as supported on all AMD Family 17h+ CPUs.
- Print the guest pseudo-RNG seed only when it changes, to avoid spamming the
log for tests that create lots of VMs.
- Make the PMU counters test less flaky when counting LLC cache misses by
doing CLFLUSH{OPT} in every loop iteration.
|
|
KVM x86/pmu changes for 6.11
- Don't advertise IA32_PERF_GLOBAL_OVF_CTRL as an MSR-to-be-saved, as it reads
'0' and writes from userspace are ignored.
- Update to the newfangled Intel CPU FMS infrastructure.
- Use macros instead of open-coded literals to clean up KVM's manipulation of
FIXED_CTR_CTRL MSRs.
|
|
KVM x86 MTRR virtualization removal
Remove support for virtualizing MTRRs on Intel CPUs, along with a nasty CR0.CD
hack, and instead always honor guest PAT on CPUs that support self-snoop.
|
|
KVM x86 MMU changes for 6.11
- Don't allocate kvm_mmu_page.shadowed_translation for shadow pages that can't
hold leafs SPTEs.
- Unconditionally drop mmu_lock when allocating TDP MMU page tables for eager
page splitting to avoid stalling vCPUs when splitting huge pages.
- Misc cleanups
|
|
KVM x86 misc changes for 6.11
- Add a global struct to consolidate tracking of host values, e.g. EFER, and
move "shadow_phys_bits" into the structure as "maxphyaddr".
- Add KVM_CAP_X86_APIC_BUS_CYCLES_NS to allow configuring the effective APIC
bus frequency, because TDX.
- Print the name of the APICv/AVIC inhibits in the relevant tracepoint.
- Clean up KVM's handling of vendor specific emulation to consistently act on
"compatible with Intel/AMD", versus checking for a specific vendor.
- Misc cleanups
|
|
KVM generic changes for 6.11
- Enable halt poll shrinking by default, as Intel found it to be a clear win.
- Setup empty IRQ routing when creating a VM to avoid having to synchronize
SRCU when creating a split IRQCHIP on x86.
- Rework the sched_in/out() paths to replace kvm_arch_sched_in() with a flag
that arch code can use for hooking both sched_in() and sched_out().
- Take the vCPU @id as an "unsigned long" instead of "u32" to avoid
truncating a bogus value from userspace, e.g. to help userspace detect bugs.
- Mark a vCPU as preempted if and only if it's scheduled out while in the
KVM_RUN loop, e.g. to avoid marking it preempted and thus writing guest
memory when retrieving guest state during live migration blackout.
- A few minor cleanups
|
|
KVM Xen:
Fix a bug where KVM fails to check the validity of an incoming userspace
virtual address and tries to activate a gfn_to_pfn_cache with a kernel address.
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD
KVM/arm64 changes for 6.11
- Initial infrastructure for shadow stage-2 MMUs, as part of nested
virtualization enablement
- Support for userspace changes to the guest CTR_EL0 value, enabling
(in part) migration of VMs between heterogenous hardware
- Fixes + improvements to pKVM's FF-A proxy, adding support for v1.1 of
the protocol
- FPSIMD/SVE support for nested, including merged trap configuration
and exception routing
- New command-line parameter to control the WFx trap behavior under KVM
- Introduce kCFI hardening in the EL2 hypervisor
- Fixes + cleanups for handling presence/absence of FEAT_TCRX
- Miscellaneous fixes + documentation updates
|
|
Dereference auth after NULL check in tpm_buf_check_hmac_response().
Otherwise, unless tpm2_sessions_init() was called, a call can cause NULL
dereference, when TCG_TPM2_HMAC is enabled.
[jarkko: adjusted the commit message.]
Cc: stable@vger.kernel.org # v6.10+
Fixes: 7ca110f2679b ("tpm: Address !chip->auth in tpm_buf_append_hmac_session*()")
Signed-off-by: Hao Ge <gehao@kylinos.cn>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
- Rewrite of HID-BPF internal implementation to use bpf struct_ops
instead of tracing (Benjamin Tissoires)
- Add new HID-BPF hooks to be able to intercept userspace calls
targetting a HID device and filtering them (Benjamin Tissoires)
- Add support for various new devices through HID-BPF filters (Benjamin
Tissoires)
|
|
Couple of hid-uclogic fixes by José Expósito:
- Support HUION devices with up to 20 buttons
- Use Rx and Ry for touch strips
|
|
Cleanup unused functions in hid-nintendo by Jiapeng Chong
|
|
Couple of minor fixes on intel-ish-hid by Jeff Johnson:
- add missing MODULE_DESCRIPTION
- add missing doctext entry
|
|
Add support for the magic keyboard backlight (Orlando Chamberlain)
|
|
Couple of trivial fixes:
- extra semicolon (Chen Ni)
- typo (Thorsten Blum)
|
|
- add a bunch of missing MODULE_DESCRIPTION (Jeff Johnson)
|
|
Couple of fixes for HID-core:
- use of kvzalloc in case memory gets too fragmented (Hailong Liu)
- retrieve the device firmware node in the child HID device (Danny
Kaehn)
|
|
Add uprobes entry to MAINTAINERS to clarify the maintainers.
Link: https://lore.kernel.org/all/172074397710.247544.17045299807723238107.stgit@devnote2/
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Oleg Nesterov <oleg@redhat.com>
|
|
syzkaller reported KMSAN splat in tcp_create_openreq_child(). [0]
The uninit variable is tcp_rsk(req)->ao_keyid.
tcp_rsk(req)->ao_keyid is initialised only when tcp_conn_request() finds
a valid TCP AO option in SYN. Then, tcp_rsk(req)->used_tcp_ao is set
accordingly.
Let's not read tcp_rsk(req)->ao_keyid when tcp_rsk(req)->used_tcp_ao is
false.
[0]:
BUG: KMSAN: uninit-value in tcp_create_openreq_child+0x198b/0x1ff0 net/ipv4/tcp_minisocks.c:610
tcp_create_openreq_child+0x198b/0x1ff0 net/ipv4/tcp_minisocks.c:610
tcp_v4_syn_recv_sock+0x18e/0x2170 net/ipv4/tcp_ipv4.c:1754
tcp_check_req+0x1a3e/0x20c0 net/ipv4/tcp_minisocks.c:852
tcp_v4_rcv+0x26a4/0x53a0 net/ipv4/tcp_ipv4.c:2265
ip_protocol_deliver_rcu+0x884/0x1270 net/ipv4/ip_input.c:205
ip_local_deliver_finish+0x30f/0x530 net/ipv4/ip_input.c:233
NF_HOOK include/linux/netfilter.h:314 [inline]
ip_local_deliver+0x230/0x4c0 net/ipv4/ip_input.c:254
dst_input include/net/dst.h:460 [inline]
ip_sublist_rcv_finish net/ipv4/ip_input.c:580 [inline]
ip_list_rcv_finish net/ipv4/ip_input.c:631 [inline]
ip_sublist_rcv+0x10f7/0x13e0 net/ipv4/ip_input.c:639
ip_list_rcv+0x952/0x9c0 net/ipv4/ip_input.c:674
__netif_receive_skb_list_ptype net/core/dev.c:5703 [inline]
__netif_receive_skb_list_core+0xd92/0x11d0 net/core/dev.c:5751
__netif_receive_skb_list net/core/dev.c:5803 [inline]
netif_receive_skb_list_internal+0xd8f/0x1350 net/core/dev.c:5895
gro_normal_list include/net/gro.h:515 [inline]
napi_complete_done+0x3f2/0x990 net/core/dev.c:6246
e1000_clean+0x1fa4/0x5e50 drivers/net/ethernet/intel/e1000/e1000_main.c:3808
__napi_poll+0xd9/0x990 net/core/dev.c:6771
napi_poll net/core/dev.c:6840 [inline]
net_rx_action+0x90f/0x17e0 net/core/dev.c:6962
handle_softirqs+0x152/0x6b0 kernel/softirq.c:554
__do_softirq kernel/softirq.c:588 [inline]
invoke_softirq kernel/softirq.c:428 [inline]
__irq_exit_rcu kernel/softirq.c:637 [inline]
irq_exit_rcu+0x5d/0x120 kernel/softirq.c:649
common_interrupt+0x83/0x90 arch/x86/kernel/irq.c:278
asm_common_interrupt+0x26/0x40 arch/x86/include/asm/idtentry.h:693
__msan_instrument_asm_store+0xd6/0xe0
arch_atomic_inc arch/x86/include/asm/atomic.h:53 [inline]
raw_atomic_inc include/linux/atomic/atomic-arch-fallback.h:992 [inline]
atomic_inc include/linux/atomic/atomic-instrumented.h:436 [inline]
page_ref_inc include/linux/page_ref.h:153 [inline]
folio_ref_inc include/linux/page_ref.h:160 [inline]
filemap_map_order0_folio mm/filemap.c:3596 [inline]
filemap_map_pages+0x11c7/0x2270 mm/filemap.c:3644
do_fault_around mm/memory.c:4879 [inline]
do_read_fault mm/memory.c:4912 [inline]
do_fault mm/memory.c:5051 [inline]
do_pte_missing mm/memory.c:3897 [inline]
handle_pte_fault mm/memory.c:5381 [inline]
__handle_mm_fault mm/memory.c:5524 [inline]
handle_mm_fault+0x3677/0x6f00 mm/memory.c:5689
do_user_addr_fault+0x1373/0x2b20 arch/x86/mm/fault.c:1338
handle_page_fault arch/x86/mm/fault.c:1481 [inline]
exc_page_fault+0x54/0xc0 arch/x86/mm/fault.c:1539
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623
Uninit was stored to memory at:
tcp_create_openreq_child+0x1984/0x1ff0 net/ipv4/tcp_minisocks.c:611
tcp_v4_syn_recv_sock+0x18e/0x2170 net/ipv4/tcp_ipv4.c:1754
tcp_check_req+0x1a3e/0x20c0 net/ipv4/tcp_minisocks.c:852
tcp_v4_rcv+0x26a4/0x53a0 net/ipv4/tcp_ipv4.c:2265
ip_protocol_deliver_rcu+0x884/0x1270 net/ipv4/ip_input.c:205
ip_local_deliver_finish+0x30f/0x530 net/ipv4/ip_input.c:233
NF_HOOK include/linux/netfilter.h:314 [inline]
ip_local_deliver+0x230/0x4c0 net/ipv4/ip_input.c:254
dst_input include/net/dst.h:460 [inline]
ip_sublist_rcv_finish net/ipv4/ip_input.c:580 [inline]
ip_list_rcv_finish net/ipv4/ip_input.c:631 [inline]
ip_sublist_rcv+0x10f7/0x13e0 net/ipv4/ip_input.c:639
ip_list_rcv+0x952/0x9c0 net/ipv4/ip_input.c:674
__netif_receive_skb_list_ptype net/core/dev.c:5703 [inline]
__netif_receive_skb_list_core+0xd92/0x11d0 net/core/dev.c:5751
__netif_receive_skb_list net/core/dev.c:5803 [inline]
netif_receive_skb_list_internal+0xd8f/0x1350 net/core/dev.c:5895
gro_normal_list include/net/gro.h:515 [inline]
napi_complete_done+0x3f2/0x990 net/core/dev.c:6246
e1000_clean+0x1fa4/0x5e50 drivers/net/ethernet/intel/e1000/e1000_main.c:3808
__napi_poll+0xd9/0x990 net/core/dev.c:6771
napi_poll net/core/dev.c:6840 [inline]
net_rx_action+0x90f/0x17e0 net/core/dev.c:6962
handle_softirqs+0x152/0x6b0 kernel/softirq.c:554
__do_softirq kernel/softirq.c:588 [inline]
invoke_softirq kernel/softirq.c:428 [inline]
__irq_exit_rcu kernel/softirq.c:637 [inline]
irq_exit_rcu+0x5d/0x120 kernel/softirq.c:649
common_interrupt+0x83/0x90 arch/x86/kernel/irq.c:278
asm_common_interrupt+0x26/0x40 arch/x86/include/asm/idtentry.h:693
Uninit was created at:
__alloc_pages_noprof+0x82d/0xcb0 mm/page_alloc.c:4706
__alloc_pages_node_noprof include/linux/gfp.h:269 [inline]
alloc_pages_node_noprof include/linux/gfp.h:296 [inline]
alloc_slab_page mm/slub.c:2265 [inline]
allocate_slab mm/slub.c:2428 [inline]
new_slab+0x2af/0x14e0 mm/slub.c:2481
___slab_alloc+0xf73/0x3150 mm/slub.c:3667
__slab_alloc mm/slub.c:3757 [inline]
__slab_alloc_node mm/slub.c:3810 [inline]
slab_alloc_node mm/slub.c:3990 [inline]
kmem_cache_alloc_noprof+0x53a/0x9f0 mm/slub.c:4009
reqsk_alloc_noprof net/ipv4/inet_connection_sock.c:920 [inline]
inet_reqsk_alloc+0x63/0x700 net/ipv4/inet_connection_sock.c:951
tcp_conn_request+0x339/0x4860 net/ipv4/tcp_input.c:7177
tcp_v4_conn_request+0x13b/0x190 net/ipv4/tcp_ipv4.c:1719
tcp_rcv_state_process+0x2dd/0x4a10 net/ipv4/tcp_input.c:6711
tcp_v4_do_rcv+0xbee/0x10d0 net/ipv4/tcp_ipv4.c:1932
tcp_v4_rcv+0x3fad/0x53a0 net/ipv4/tcp_ipv4.c:2334
ip_protocol_deliver_rcu+0x884/0x1270 net/ipv4/ip_input.c:205
ip_local_deliver_finish+0x30f/0x530 net/ipv4/ip_input.c:233
NF_HOOK include/linux/netfilter.h:314 [inline]
ip_local_deliver+0x230/0x4c0 net/ipv4/ip_input.c:254
dst_input include/net/dst.h:460 [inline]
ip_sublist_rcv_finish net/ipv4/ip_input.c:580 [inline]
ip_list_rcv_finish net/ipv4/ip_input.c:631 [inline]
ip_sublist_rcv+0x10f7/0x13e0 net/ipv4/ip_input.c:639
ip_list_rcv+0x952/0x9c0 net/ipv4/ip_input.c:674
__netif_receive_skb_list_ptype net/core/dev.c:5703 [inline]
__netif_receive_skb_list_core+0xd92/0x11d0 net/core/dev.c:5751
__netif_receive_skb_list net/core/dev.c:5803 [inline]
netif_receive_skb_list_internal+0xd8f/0x1350 net/core/dev.c:5895
gro_normal_list include/net/gro.h:515 [inline]
napi_complete_done+0x3f2/0x990 net/core/dev.c:6246
e1000_clean+0x1fa4/0x5e50 drivers/net/ethernet/intel/e1000/e1000_main.c:3808
__napi_poll+0xd9/0x990 net/core/dev.c:6771
napi_poll net/core/dev.c:6840 [inline]
net_rx_action+0x90f/0x17e0 net/core/dev.c:6962
handle_softirqs+0x152/0x6b0 kernel/softirq.c:554
__do_softirq kernel/softirq.c:588 [inline]
invoke_softirq kernel/softirq.c:428 [inline]
__irq_exit_rcu kernel/softirq.c:637 [inline]
irq_exit_rcu+0x5d/0x120 kernel/softirq.c:649
common_interrupt+0x83/0x90 arch/x86/kernel/irq.c:278
asm_common_interrupt+0x26/0x40 arch/x86/include/asm/idtentry.h:693
CPU: 0 PID: 239 Comm: modprobe Tainted: G B 6.10.0-rc7-01816-g852e42cc2dd4 #3 1107521f0c7b55c9309062382d0bda9f604dbb6d
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
Fixes: 06b22ef29591 ("net/tcp: Wire TCP-AO to request sockets")
Reported-by: syzkaller <syzkaller@googlegroups.com>
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Acked-by: Dmitry Safonov <0x7f454c46@gmail.com>
Link: https://patch.msgid.link/20240714161719.6528-1-kuniyu@amazon.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
In kbd_rgb_mode_store the dev_get_drvdata() call was assuming the device
data was asus_wmi when it was actually led_classdev.
This patch corrects this by making the correct chain of calls to get the
asus_wmi driver data.
Fixes: ae834a549ec1 ("platform/x86: asus-wmi: add support variant of TUF RGB")
Tested-by: Denis Benato <benato.denis96@gmail.com>
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240716011130.17464-2-luke@ljones.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Smatch complains that 'str' can be used without being initialized:
drivers/platform/x86/intel/intel_plr_tpmi.c:178 plr_print_bits()
error: uninitialized symbol 'str'.
In this loop, we iterate over all the set bits and print the name of the
bit. The intention is that if there is a bit which is between 0-31 we
look for the name in the first array plr_coarse_reasons[] which has 10
elements. If the bit is in the 32-63 range we look for it in the
plr_fine_reasons[] array which has 30 elements. If the bit is in the
invalid ranges, 10-31 or 62-63, then we should print "UNKNOWN(%d)".
The problem is that 'str' needs to be initialized at the start of each
iteration, otherwise if we can't find the string then instead of printing
"UNKNOWN(%d)", we will re-print whatever the previous bit was.
Fixes: 9e9397a41b7b ("platform/x86/intel/tpmi/plr: Add support for the plr mailbox")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/b0084e70-4144-445a-9b89-fb19f6b8336a@stanley.mountain
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
pmf.rst was removed by the commit 2fd66f7d3b0d ("platform/x86/amd/pmf:
Remove update system state document") but the reference in the
admin-guide index remained in place which triggers this warning:
Documentation/admin-guide/index.rst:75: WARNING: toctree contains
reference to nonexisting document 'admin-guide/pmf'
Remove pmf also from the index to avoid the warning.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20240715104102.4615-1-ilpo.jarvinen@linux.intel.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
This flag is unneeded because a choice member can be detected by
other means.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Clarify that the given structures are not modified.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Kconfig simplifies expressions, but redundant '&&' and '||' operators
involving constant symbols 'y' and 'n' are sometimes trimmed and
sometimes not.
[Test Code]
config DEP
def_bool y
config A
bool "A"
depends on DEP && y
config B
bool "B"
depends on DEP && y && y
[Result]
$ make helpnewconfig
[ snip ]
-----
There is no help available for this option.
Symbol: A [=n]
Type : bool
Defined at Kconfig:4
Prompt: A
Depends on: DEP [=y] && y [=y]
Location:
-> A (A [=n])
-----
-----
There is no help available for this option.
Symbol: B [=n]
Type : bool
Defined at Kconfig:8
Prompt: B
Depends on: DEP [=y]
Location:
-> B (B [=n])
-----
The dependency for A, 'DEP && y', remains as-is, while that for B,
'DEP && y && y', has been reduced to 'DEP'.
Currently, expr_eliminate_dups() calls expr_eliminate_yn() only when
trans_count != 0, in other words, only when expr_eliminate_dups1() has
trimmed at least one leaf. It fails to trim a single '&& y', etc.
To fix this inconsistent behavior, expr_eliminate_yn() should be called
at least once even if no leaf has been trimmed.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
${DEBFULLNAME-${user}} falls back to ${user} when DEBFULLNAME is unset.
It is more reasonable to do so when DEBFULLNAME is unset or null.
Otherwise, the command:
$ DEBFULLNAME= make deb-pkg
will leave the name field blank.
The same applies to KBUILD_BUILD_USER and KBUILD_BUILD_HOST.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
|
|
/usr/include/elf.h, which originates from the glibc/musl, defines
R_ARM_THM_PC22 instead of R_ARM_THM_CALL.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
|
|
Commit f5983dab0ead ("modpost: define more R_ARM_* for old
distributions") added self-definitions for the R_ARM_* macros to fix
build errors on CentOS 7.
RHEL/CentOS 7 were retired at the end of June.
Remove all the R_ARM_* definitions (except for R_ARM_THM_CALL), which
should be available in recent distributions.
glibc and musl added most of R_ARM_* macros in 2013. [1] [2]
[1]: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=08cbd996d33114ca50644d060fbe3a08260430fb
[2]: https://git.musl-libc.org/cgit/musl/commit/?id=268375c1c017c0bdefeed1a330811e433c4dfaef
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
|
|
RHEL/CentOS 7, popular distributions that install GNU Make 3.82, reached
EOM/EOL on June 30, 2024. While you may get extended support, it is a
good time to raise the minimum GNU Make version.
The new requirement, GNU Make 4.0, was released in October, 2013.
I did not touch the Makefiles under tools/ because I do not know the
requirements for building tools. I do not find any GNU Make version
checks under tools/.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
|
|
As commit afa974b77128 ("kbuild: add real-prereqs shorthand for
$(filter-out FORCE,$^)") explained, $(real-prereqs) is not just a list
of objects when linking a multi-object module. If a single-object module
is turned into a multi-object module, $^ (and therefore $(real-prereqs)
as well) contains header files recorded in the *.cmd file. Such headers
must be filtered out.
Now that a DTB can be built either from a single source or multiple
source files, the same issue can occur.
Consider the following scenario:
First, foo.dtb is implemented as a single-blob device tree.
The code looks something like this:
[Sample Code 1]
Makefile:
dtb-y += foo.dtb
foo.dts:
#include <dt-bindings/gpio/gpio.h>
/dts-v1/;
/ { };
When it is compiled, .foo.dtb.cmd records that foo.dtb depends on
scripts/dtc/include-prefixes/dt-bindings/gpio/gpio.h.
Later, foo.dtb is split into a base and an overlay. The code looks
something like this:
[Sample Code 2]
Makefile:
dtb-y += foo.dtb
foo-dtbs := foo-base.dtb foo-addon.dtbo
foo-base.dts:
#include <dt-bindings/gpio/gpio.h>
/dts-v1/;
/ { };
foo-addon.dtso:
/dts-v1/;
/plugin/;
/ { };
If you rebuild foo.dtb without 'make clean', you will get this error:
Overlay 'scripts/dtc/include-prefixes/dt-bindings/gpio/gpio.h' is incomplete
$(real-prereqs) contains not only foo-base.dtb and foo-addon.dtbo but
also scripts/dtc/include-prefixes/dt-bindings/gpio/gpio.h, which is
passed to scripts/dtc/fdtoverlay.
Fixes: 15d16d6dadf6 ("kbuild: Add generic rule to apply fdtoverlay")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Set -e to make these scripts fail on the first error.
Set -u because these scripts are invoked by Makefile, and do not work
properly without necessary variables defined.
I tweaked mkdebian to cope with optional environment variables.
Remove the explicit "test -n ..." from install-extmod-build.
Both options are described in POSIX. [1]
[1]: https://pubs.opengroup.org/onlinepubs/009604499/utilities/set.html
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 cpu model updates from Borislav Petkov:
- Flip the logic to add feature names to /proc/cpuinfo to having to
explicitly specify the flag if there's a valid reason to show it in
/proc/cpuinfo
- Switch a bunch of Intel x86 model checking code to the new CPU model
defines
- Fixes and cleanups
* tag 'x86_cpu_for_v6.11_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/cpu/intel: Drop stray FAM6 check with new Intel CPU model defines
x86/cpufeatures: Flip the /proc/cpuinfo appearance logic
x86/CPU/AMD: Always inline amd_clear_divider()
x86/mce/inject: Add missing MODULE_DESCRIPTION() line
perf/x86/rapl: Switch to new Intel CPU model defines
x86/boot: Switch to new Intel CPU model defines
x86/cpu: Switch to new Intel CPU model defines
perf/x86/intel: Switch to new Intel CPU model defines
x86/virt/tdx: Switch to new Intel CPU model defines
x86/PCI: Switch to new Intel CPU model defines
x86/cpu/intel: Switch to new Intel CPU model defines
x86/platform/intel-mid: Switch to new Intel CPU model defines
x86/pconfig: Remove unused MKTME pconfig code
x86/cpu: Remove useless work in detect_tme_early()
|
