| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Add new ACPI ID AMDI0105 used by upcoming AMD platform to the PMF
supported list of devices.
Signed-off-by: Shyam Sundar S K <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Hans de Goede <[email protected]>
|
|
The P2SB could get an invalid BAR from the BIOS, and that won't be fixed
up until pcibios_assign_resources(), which is an fs_initcall().
- Move p2sb_fs_init() to an fs_initcall_sync(). This is still early
enough to avoid a race with any dependent drivers.
- Add a check for IORESOURCE_UNSET in p2sb_valid_resource() to catch
unset BARs going forward.
- Return error values from p2sb_fs_init() so that the 'initcall_debug'
cmdline arg provides useful data.
Signed-off-by: Ben Fradella <[email protected]>
Acked-by: Andy Shevchenko <[email protected]>
Tested-by: Klara Modin <[email protected]>
Reviewed-by: Shin'ichiro Kawasaki <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
|
|
Emits messages upon errors during probing of SAM. Hopefully this could
provide useful context to user for the purpose of diagnosis when
something miserable happen.
Reviewed-by: Maximilian Luz <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Weifeng Liu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
|
|
As part of adding support for calling i2c_register_spd() on muxed SMBUS
segments the same message has been removed from i2c_register_spd().
However users may find it useful, therefore reintroduce it as part of
the DMI scan code.
[JD: Static variable dmi_memdev_populated_nr is only used in __init
functions, so it can be marked __initdata.]
Signed-off-by: Heiner Kallweit <[email protected]>
Signed-off-by: Jean Delvare <[email protected]>
|
|
BPF just-in-time compiler depended on CONFIG_MODULES because it used
module_alloc() to allocate memory for the generated code.
Since code allocations are now implemented with execmem, drop dependency of
CONFIG_BPF_JIT on CONFIG_MODULES and make it select CONFIG_EXECMEM.
Suggested-by: Björn Töpel <[email protected]>
Signed-off-by: Mike Rapoport (IBM) <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>
|
|
kprobes depended on CONFIG_MODULES because it has to allocate memory for
code.
Since code allocations are now implemented with execmem, kprobes can be
enabled in non-modular kernels.
Add #ifdef CONFIG_MODULE guards for the code dealing with kprobes inside
modules, make CONFIG_KPROBES select CONFIG_EXECMEM and drop the
dependency of CONFIG_KPROBES on CONFIG_MODULES.
Signed-off-by: Mike Rapoport (IBM) <[email protected]>
Acked-by: Masami Hiramatsu (Google) <[email protected]>
[mcgrof: rebase in light of NEED_TASKS_RCU ]
Signed-off-by: Luis Chamberlain <[email protected]>
|
|
There are places where CONFIG_MODULES guards the code that depends on
memory allocation being done with module_alloc().
Replace CONFIG_MODULES with CONFIG_EXECMEM in such places.
Signed-off-by: Mike Rapoport (IBM) <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>
|
|
Dynamic ftrace must allocate memory for code and this was impossible
without CONFIG_MODULES.
With execmem separated from the modules code, execmem_text_alloc() is
available regardless of CONFIG_MODULES.
Remove dependency of dynamic ftrace on CONFIG_MODULES and make
CONFIG_DYNAMIC_FTRACE select CONFIG_EXECMEM in Kconfig.
Signed-off-by: Mike Rapoport (IBM) <[email protected]>
Reviewed-by: Steven Rostedt (Google) <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>
|
|
execmem does not depend on modules, on the contrary modules use
execmem.
To make execmem available when CONFIG_MODULES=n, for instance for
kprobes, split execmem_params initialization out from
arch/*/kernel/module.c and compile it when CONFIG_EXECMEM=y
Signed-off-by: Mike Rapoport (IBM) <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>
|
|
powerpc overrides kprobes::alloc_insn_page() to remove writable
permissions when STRICT_MODULE_RWX is on.
Add definition of EXECMEM_KRPOBES to execmem_params to allow using the
generic kprobes::alloc_insn_page() with the desired permissions.
As powerpc uses breakpoint instructions to inject kprobes, it does not
need to constrain kprobe allocations to the modules area and can use the
entire vmalloc address space.
Signed-off-by: Mike Rapoport (IBM) <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>
|
|
The memory allocations for kprobes and BPF on arm64 can be placed
anywhere in vmalloc address space and currently this is implemented with
overrides of alloc_insn_page() and bpf_jit_alloc_exec() in arm64.
Define EXECMEM_KPROBES and EXECMEM_BPF ranges in arm64::execmem_info and
drop overrides of alloc_insn_page() and bpf_jit_alloc_exec().
Signed-off-by: Mike Rapoport (IBM) <[email protected]>
Acked-by: Will Deacon <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>
|
|
The memory allocations for kprobes and BPF on RISC-V are not placed in
the modules area and these custom allocations are implemented with
overrides of alloc_insn_page() and bpf_jit_alloc_exec().
Define MODULES_VADDR and MODULES_END as VMALLOC_START and VMALLOC_END for
32 bit and slightly reorder execmem_params initialization to support both
32 and 64 bit variants, define EXECMEM_KPROBES and EXECMEM_BPF ranges in
riscv::execmem_params and drop overrides of alloc_insn_page() and
bpf_jit_alloc_exec().
Signed-off-by: Mike Rapoport (IBM) <[email protected]>
Reviewed-by: Alexandre Ghiti <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>
|
|
Extend execmem parameters to accommodate more complex overrides of
module_alloc() by architectures.
This includes specification of a fallback range required by arm, arm64
and powerpc, EXECMEM_MODULE_DATA type required by powerpc, support for
allocation of KASAN shadow required by s390 and x86 and support for
late initialization of execmem required by arm64.
The core implementation of execmem_alloc() takes care of suppressing
warnings when the initial allocation fails but there is a fallback range
defined.
Signed-off-by: Mike Rapoport (IBM) <[email protected]>
Acked-by: Will Deacon <[email protected]>
Acked-by: Song Liu <[email protected]>
Tested-by: Liviu Dudau <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>
|
|
Several architectures override module_alloc() only to define address
range for code allocations different than VMALLOC address space.
Provide a generic implementation in execmem that uses the parameters for
address space ranges, required alignment and page protections provided
by architectures.
The architectures must fill execmem_info structure and implement
execmem_arch_setup() that returns a pointer to that structure. This way the
execmem initialization won't be called from every architecture, but rather
from a central place, namely a core_initcall() in execmem.
The execmem provides execmem_alloc() API that wraps __vmalloc_node_range()
with the parameters defined by the architectures. If an architecture does
not implement execmem_arch_setup(), execmem_alloc() will fall back to
module_alloc().
Signed-off-by: Mike Rapoport (IBM) <[email protected]>
Acked-by: Song Liu <[email protected]>
Reviewed-by: Masami Hiramatsu (Google) <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>
|
|
module_alloc() is used everywhere as a mean to allocate memory for code.
Beside being semantically wrong, this unnecessarily ties all subsystems
that need to allocate code, such as ftrace, kprobes and BPF to modules and
puts the burden of code allocation to the modules code.
Several architectures override module_alloc() because of various
constraints where the executable memory can be located and this causes
additional obstacles for improvements of code allocation.
Start splitting code allocation from modules by introducing execmem_alloc()
and execmem_free() APIs.
Initially, execmem_alloc() is a wrapper for module_alloc() and
execmem_free() is a replacement of module_memfree() to allow updating all
call sites to use the new APIs.
Since architectures define different restrictions on placement,
permissions, alignment and other parameters for memory that can be used by
different subsystems that allocate executable memory, execmem_alloc() takes
a type argument, that will be used to identify the calling subsystem and to
allow architectures define parameters for ranges suitable for that
subsystem.
No functional changes.
Signed-off-by: Mike Rapoport (IBM) <[email protected]>
Acked-by: Masami Hiramatsu (Google) <[email protected]>
Acked-by: Song Liu <[email protected]>
Acked-by: Steven Rostedt (Google) <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>
|
|
Move the logic related to the memory allocation and freeing into
module_memory_alloc() and module_memory_free().
Signed-off-by: Mike Rapoport (IBM) <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Masami Hiramatsu (Google) <[email protected]>
Acked-by: Song Liu <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>
|
|
Define MODULES_VADDR and MODULES_END as VMALLOC_START and VMALLOC_END
for 32-bit and reduce module_alloc() to
__vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END, ...)
as with the new defines the allocations becomes identical for both 32
and 64 bits.
While on it, drop unused include of <linux/jump_label.h>
Suggested-by: Sam Ravnborg <[email protected]>
Signed-off-by: Mike Rapoport (IBM) <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>
|
|
nios2 uses kmalloc() to implement module_alloc() because CALL26/PCREL26
cannot reach all of vmalloc address space.
Define module space as 32MiB below the kernel base and switch nios2 to
use vmalloc for module allocations.
Suggested-by: Thomas Gleixner <[email protected]>
Acked-by: Dinh Nguyen <[email protected]>
Acked-by: Song Liu <[email protected]>
Signed-off-by: Mike Rapoport (IBM) <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>
|
|
and MODULE_END to MODULES_END to match other architectures that define
custom address space for modules.
Signed-off-by: Mike Rapoport (IBM) <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>
|
|
Since commit f6f37d9320a1 ("arm64: select KASAN_VMALLOC for SW/HW_TAGS
modes") KASAN_VMALLOC is always enabled when KASAN is on. This means
that allocations in module_alloc() will be tracked by KASAN protection
for vmalloc() and that kasan_alloc_module_shadow() will be always an
empty inline and there is no point in calling it.
Drop meaningless call to kasan_alloc_module_shadow() from
module_alloc().
Signed-off-by: Mike Rapoport (IBM) <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>
|
|
strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces. The goal is to remove its use completely [2].
namebuf is eventually cleaned of any trailing llvm suffixes using
strstr(). This hints that namebuf should be NUL-terminated.
static void cleanup_symbol_name(char *s)
{
char *res;
...
res = strstr(s, ".llvm.");
...
}
Due to this, use strscpy() over strncpy() as it guarantees
NUL-termination on the destination buffer. Drop the -1 from the length
calculation as it is no longer needed to ensure NUL-termination.
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html
Link: https://github.com/KSPP/linux/issues/90 [2]
Cc: [email protected]
Signed-off-by: Justin Stitt <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>
|
|
If UNUSED_KSYMS_WHITELIST is a file generated
before Kbuild runs, and the source tree is in
a read-only filesystem, the developer must put
the file somewhere and specify an absolute
path to UNUSED_KSYMS_WHITELIST. This worked,
but if IKCONFIG=y, an absolute path is embedded
into .config and eventually into vmlinux, causing
the build to be less reproducible when building
on a different machine.
This patch makes the handling of
UNUSED_KSYMS_WHITELIST to be similar to
MODULE_SIG_KEY.
First, check if UNUSED_KSYMS_WHITELIST is an
absolute path, just as before this patch. If so,
use the path as is.
If it is a relative path, use wildcard to check
the existence of the file below objtree first.
If it does not exist, fall back to the original
behavior of adding $(srctree)/ before the value.
After this patch, the developer can put the generated
file in objtree, then use a relative path against
objtree in .config, eradicating any absolute paths
that may be evaluated differently on different machines.
Signed-off-by: Yifan Hong <[email protected]>
Reviewed-by: Elliot Berman <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>
|
|
Commit 99a741aa7a2d ("i2c: mux: gpio: remove support for class-based
device instantiation") removed the last call to i2c_mux_add_adapter()
with a non-null class argument. Therefore the class argument can be
removed.
Note: Class-based device instantiation is a legacy mechanism which
shouldn't be used in new code, so we can rule out that this argument
may be needed again in the future.
This driver was forgotten by the patch in the Fixes tag.
Fixes: fec1982d7072 ("i2c: mux: Remove class argument from i2c_mux_add_adapter()")
Signed-off-by: Wolfram Sang <[email protected]>
Acked-by: Sebastian Reichel <[email protected]>
|
|
Commit 8788ca164eb4b ("ftrace: Remove the legacy _ftrace_direct API")
stopped setting the 'ftrace_direct_func_count' variable, but left
it around. Clean it up.
Link: https://lore.kernel.org/linux-trace-kernel/[email protected]
Signed-off-by: Dr. David Alan Gilbert <[email protected]>
Signed-off-by: Steven Rostedt (Google) <[email protected]>
|
|
The bcm2835-unicam driver calls the clk_set_min_rate() function, which
is declared but not implemented on platforms that don't provide
COMMON_CLK. This causes linkage failures with some configurations.
Fix it by depending on COMMON_CLK. This only slightly restricts
compilation testing, but not usage of the driver as all platforms on
which the hardware can be found provide COMMON_CLK.
Fixes: 392cd78d495f ("media: bcm2835-unicam: Add support for CCP2/CSI2 camera interface")
Reported-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Dave Stevenson <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
|
|
Commit 8788ca164eb4b ("ftrace: Remove the legacy _ftrace_direct API")
stopped using 'ftrace_direct_funcs' (and the associated
struct ftrace_direct_func). Remove them.
Build tested only (on x86-64 with FTRACE and DYNAMIC_FTRACE
enabled)
Link: https://lore.kernel.org/linux-trace-kernel/[email protected]
Signed-off-by: Dr. David Alan Gilbert <[email protected]>
Signed-off-by: Steven Rostedt (Google) <[email protected]>
|
|
Commit ddb5cdbafaaa ("kbuild: generate KSYMTAB entries by modpost")
forget drop the .export_symbol section from the final modules.
Fixes: ddb5cdbafaaa ("kbuild: generate KSYMTAB entries by modpost")
Signed-off-by: Wang Yao <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
Pull DSA and IAA accelerator mis-alignment fix from Arjan van de Ven:
"The DSA (memory copy/zero/etc) and IAA (compression) accelerators in
the Sapphire Rapids and Emerald Rapids SOCs turn out to have a bug
that has security implications.
Both of these accelerators work by the application submitting a 64
byte command to the device; this command contains an opcode as well as
the virtual address of the return value that the device will update on
completion... and a set of opcode specific values.
In a typical scenario a ring 3 application mmaps the device file and
uses the ENQCMD or MOVDIR64 instructions (which are variations of a 64
byte atomic write) on this mmap'd memory region to directly submit
commands to a device hardware.
The return value as specified in the command, is supposed to be 32 (or
64) bytes aligned in memory, and generally the hardware checks and
enforces this alignment.
However in testing it has been found that there are conditions
(controlled by the submitter) where this enforcement does not
happen... which makes it possible for the return value to span a page
boundary. And this is where it goes wrong - the accelerators will
perform the virtual to physical address lookup on the first of the two
pages, but end up continue writing to the next consecutive physical
(host) page rather than the consecutive virtual page. In addition, the
device will end up in a hung state on such unaligned write of the
return value.
This patch series has the proposed software side solution consisting
of three parts:
- Don't allow these two PCI devices to be assigned to VM guests (we
cannot trust a VM guest to behave correctly and not cause this
condition)
- Don't allow ring 3 applications to set up the mmap unless they have
CAP_SYS_RAWIO permissions. This makes it no longer possible for
non-root applications to directly submit commands to the
accelerator
- Add a write() method to the device so that an application can
submit its commands to the kernel driver, which performs the needed
sanity checks before submitting it to the hardware.
This switch from mmap to write is an incompatible interface change to
non-root userspace, but we have not found a way to avoid this. All
software we know of uses a small set of accessor libraries for these
accelerators, for which libqpl and libdml (on github) are the most
common. As part of the security release, updated versions of these
libraries will be released that transparently fall back to write().
Intel has assigned CVE-2024-21823 to this hardware issue"
* tag 'idxd-for-linus-may2024' of git bundle from Arjan:
dmaengine: idxd: add a write() method for applications to submit work
dmaengine: idxd: add a new security check to deal with a hardware erratum
VFIO: Add the SPR_DSA and SPR_IAX devices to the denylist
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 shadow stacks from Ingo Molnar:
"Enable shadow stacks for x32.
While we normally don't do such feature-enabling for 32-bit anymore,
this change is small, straightforward & tested on upstream glibc"
* tag 'x86-shstk-2024-05-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/shstk: Enable shadow stacks for x32
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 platform updates from Ingo Molnar:
- Improve the DeviceTree (OF) NUMA enumeration code to address
kernel warnings & mis-mappings on DeviceTree platforms
- Migrate x86 platform drivers to the .remove_new callback API
- Misc cleanups & fixes
* tag 'x86-platform-2024-05-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/platform/olpc-xo1-sci: Convert to platform remove callback returning void
x86/platform/olpc-x01-pm: Convert to platform remove callback returning void
x86/platform/iris: Convert to platform remove callback returning void
x86/of: Change x86_dtb_parse_smp_config() to static
x86/of: Map NUMA node to CPUs as per DeviceTree
x86/of: Set the parse_smp_cfg for all the DeviceTree platforms by default
x86/hyperv/vtl: Correct x86_init.mpparse.parse_smp_cfg assignment
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 percpu updates from Ingo Molnar:
- Expand the named address spaces optimizations down to
GCC 9.1+.
- Re-enable named address spaces with sanitizers for GCC 13.3+
- Generate better this_percpu_xchg_op() code
- Introduce raw_cpu_read_long() to reduce ifdeffery
- Simplify the x86_this_cpu_test_bit() et al macros
- Address Sparse warnings
- Misc cleanups & fixes
* tag 'x86-percpu-2024-05-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/percpu: Introduce raw_cpu_read_long() to reduce ifdeffery
x86/percpu: Rewrite x86_this_cpu_test_bit() and friends as macros
x86/percpu: Fix x86_this_cpu_variable_test_bit() asm template
x86/percpu: Re-enable named address spaces with sanitizers for GCC 13.3+
x86/percpu: Use __force to cast from __percpu address space
x86/percpu: Do not use this_cpu_read_stable_8() for 32-bit targets
x86/percpu: Unify arch_raw_cpu_ptr() defines
x86/percpu: Enable named address spaces for GCC 9.1+
x86/percpu: Re-enable named address spaces with KASAN for GCC 13.3+
x86/percpu: Move raw_percpu_xchg_op() to a better place
x86/percpu: Convert this_percpu_xchg_op() from asm() to C code, to generate better code
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 mm updates from Ingo Molnar:
- Fix W^X violation check false-positives in the CPA code
when running as a Xen PV guest
- Fix W^X violation warning false-positives in show_fault_oops()
* tag 'x86-mm-2024-05-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/pat: Fix W^X violation false-positives when running as Xen PV guest
x86/pat: Restructure _lookup_address_cpa()
x86/mm: Use lookup_address_in_pgd_attr() in show_fault_oops()
x86/pat: Introduce lookup_address_in_pgd_attr()
|
|
Commit c27b2d2012e1 ("crypto: testmgr - allow ecdsa-nist-p256 and -p384
in FIPS mode") enabled support for ECDSA in crypto/testmgr.c. The
PKCS#7 signature verification API builds upon the KCAPI primitives to
perform its high-level operations. Therefore, this change in testmgr.c
also allows ECDSA to be used by the PKCS#7 signature verification API
(in FIPS mode).
However, from a FIPS perspective, the PKCS#7 signature verification API
is a distinct "service" from the KCAPI primitives. This is because the
PKCS#7 API performs a "full" signature verification, which consists of
both hashing the data to be verified, and the public key operation.
On the other hand, the KCAPI primitive does not perform this hashing
step - it accepts pre-hashed data from the caller and only performs the
public key operation.
For this reason, the ECDSA self-tests in crypto/testmgr.c are not
sufficient to cover ECDSA signature verification offered by the PKCS#7
API. This is reflected by the self-test already present in this file
for RSA PKCS#1 v1.5 signature verification.
The solution is simply to add a second self-test here for ECDSA. P-256
with SHA-256 hashing was chosen as those parameters should remain
FIPS-approved for the foreseeable future, while keeping the performance
impact to a minimum. The ECDSA certificate and PKCS#7 signed data was
generated using OpenSSL. The input data is identical to the input data
for the existing RSA self-test.
Signed-off-by: Joachim Vandersmissen <[email protected]>
Reviewed-by: Jarkko Sakkinen <[email protected]>
Acked-by: Herbert Xu <[email protected]>
Signed-off-by: Jarkko Sakkinen <[email protected]>
|
|
In preparation of adding new ECDSA self-tests, the existing data for
the RSA self-tests is moved to a separate file. This file is only
compiled if the new CONFIG_FIPS_SIGNATURE_SELFTEST_RSA configuration
option is set, which ensures that the required dependencies (RSA,
SHA-256) are present. Otherwise, the kernel would panic when trying to
execute the self-test.
The introduction of this new option, rather than adding the
dependencies to the existing CONFIG_FIPS_SIGNATURE_SELFTEST option,
allows for additional self-tests to be added for different algorithms.
The kernel can then be configured to only execute the self-tests for
those algorithms that are included.
Signed-off-by: Joachim Vandersmissen <[email protected]>
Reviewed-by: Jarkko Sakkinen <[email protected]>
Acked-by: Herbert Xu <[email protected]>
Signed-off-by: Jarkko Sakkinen <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fpu updates from Ingo Molnar:
- Fix asm() constraints & modifiers in restore_fpregs_from_fpstate()
- Update comments
- Robustify the free_vm86() definition
* tag 'x86-fpu-2024-05-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/fpu: Update fpu_swap_kvm_fpu() uses in comments as well
x86/vm86: Make sure the free_vm86(task) definition uses its parameter even in the !CONFIG_VM86 case
x86/fpu: Fix AMD X86_BUG_FXSAVE_LEAK fixup
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 entry cleanup from Ingo Molnar:
- Merge thunk_64.S and thunk_32.S into thunk.S
* tag 'x86-entry-2024-05-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/entry: Merge thunk_64.S and thunk_32.S into thunk.S
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 cpu updates from Ingo Molnar:
- Rework the x86 CPU vendor/family/model code: introduce the 'VFM'
value that is an 8+8+8 bit concatenation of the vendor/family/model
value, and add macros that work on VFM values. This simplifies the
addition of new Intel models & families, and simplifies existing
enumeration & quirk code.
- Add support for the AMD 0x80000026 leaf, to better parse topology
information
- Optimize the NUMA allocation layout of more per-CPU data structures
- Improve the workaround for AMD erratum 1386
- Clear TME from /proc/cpuinfo as well, when disabled by the firmware
- Improve x86 self-tests
- Extend the mce_record tracepoint with the ::ppin and ::microcode fields
- Implement recovery for MCE errors in TDX/SEAM non-root mode
- Misc cleanups and fixes
* tag 'x86-cpu-2024-05-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (34 commits)
x86/mm: Switch to new Intel CPU model defines
x86/tsc_msr: Switch to new Intel CPU model defines
x86/tsc: Switch to new Intel CPU model defines
x86/cpu: Switch to new Intel CPU model defines
x86/resctrl: Switch to new Intel CPU model defines
x86/microcode/intel: Switch to new Intel CPU model defines
x86/mce: Switch to new Intel CPU model defines
x86/cpu: Switch to new Intel CPU model defines
x86/cpu/intel_epb: Switch to new Intel CPU model defines
x86/aperfmperf: Switch to new Intel CPU model defines
x86/apic: Switch to new Intel CPU model defines
perf/x86/msr: Switch to new Intel CPU model defines
perf/x86/intel/uncore: Switch to new Intel CPU model defines
perf/x86/intel/pt: Switch to new Intel CPU model defines
perf/x86/lbr: Switch to new Intel CPU model defines
perf/x86/intel/cstate: Switch to new Intel CPU model defines
x86/bugs: Switch to new Intel CPU model defines
x86/bugs: Switch to new Intel CPU model defines
x86/cpu/vfm: Update arch/x86/include/asm/intel-family.h
x86/cpu/vfm: Add new macros to work with (vendor/family/model) values
...
|
|
The series is causing issues with PHY drivers built as modules.
Since it was only partially applied and the merge window has
opened let's revert and try again for v6.11.
Revert 6916e461e793 ("net: phy: Introduce ethernet link topology representation")
Revert 0ec5ed6c130e ("net: sfp: pass the phy_device when disconnecting an sfp module's PHY")
Revert e75e4e074c44 ("net: phy: add helpers to handle sfp phy connect/disconnect")
Revert fdd353965b52 ("net: sfp: Add helper to return the SFP bus name")
Revert 841942bc6212 ("net: ethtool: Allow passing a phy index for some commands")
Link: https://lore.kernel.org/all/171242462917.4000.9759453824684907063.git-patchwork-notify@kernel.org/
Link: https://lore.kernel.org/all/[email protected]/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Xiaolei Wang says:
====================
Move EST lock and EST structure to struct stmmac_priv
1. Pulling the mutex protecting the EST structure out to avoid
clearing it during reinit/memset of the EST structure,and
reacquire the mutex lock when doing this initialization.
2. Moving the EST structure to a more logical location
====================
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Move the EST structure to struct stmmac_priv, because the
EST configs don't look like platform config, but EST is
enabled in runtime with the settings retrieved for the TC
TAPRIO feature also in runtime. So it's better to have the
EST-data preserved in the driver private data instead of
the platform data storage.
Signed-off-by: Xiaolei Wang <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Reviewed-by: Serge Semin <[email protected]>
Reviewed-by: Andrew Halaney <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Reinitialize the whole EST structure would also reset the mutex
lock which is embedded in the EST structure, and then trigger
the following warning. To address this, move the lock to struct
stmmac_priv. We also need to reacquire the mutex lock when doing
this initialization.
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068
Modules linked in:
CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29
Hardware name: NXP i.MX8MPlus EVK board (DT)
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __mutex_lock+0xd84/0x1068
lr : __mutex_lock+0xd84/0x1068
sp : ffffffc0864e3570
x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003
x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac
x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000
x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff
x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000
x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8
x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698
x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001
x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027
x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000
Call trace:
__mutex_lock+0xd84/0x1068
mutex_lock_nested+0x28/0x34
tc_setup_taprio+0x118/0x68c
stmmac_setup_tc+0x50/0xf0
taprio_change+0x868/0xc9c
Fixes: b2aae654a479 ("net: stmmac: add mutex lock to protect est parameters")
Signed-off-by: Xiaolei Wang <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Reviewed-by: Serge Semin <[email protected]>
Reviewed-by: Andrew Halaney <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Mat Martineau says:
====================
mptcp: small improvements, fix and clean-ups
This series contain mostly unrelated patches:
- The two first patches can be seen as "fixes". They are part of this
series for -next because it looks like the last batch of fixes for
v6.9 has already been sent. These fixes are not urgent, so they can
wait if an unlikely v6.9-rc8 is published. About the two patches:
- Patch 1 fixes getsockopt(SO_KEEPALIVE) support on MPTCP sockets
- Patch 2 makes sure the full TCP keep-alive feature is supported,
not just SO_KEEPALIVE.
- Patch 3 is a small optimisation when getsockopt(MPTCP_INFO) is used
without buffer, just to check if MPTCP is still being used: no
fallback to TCP.
- Patch 4 adds net.mptcp.available_schedulers sysctl knob to list packet
schedulers, similar to net.ipv4.tcp_available_congestion_control.
- Patch 5 and 6 fix CheckPatch warnings: "prefer strscpy over strcpy"
and "else is not generally useful after a break or return".
- Patch 7 and 8 remove and add header includes to avoid unused ones, and
add missing ones to be self-contained.
====================
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
So this file is now self-contained: it can be compiled alone with
analytic tools.
Reviewed-by: Geliang Tang <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: Mat Martineau <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Nothing from protocol.h depends on mptcp_pm_gen.h, only code from
pm_netlink.c and pm_userspace.c depends on it.
So this include can be moved where it is needed to avoid a "unused
includes" warning.
Reviewed-by: Geliang Tang <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: Mat Martineau <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
The 'else' statements are not needed here, because their previous 'if'
block ends with a 'return'.
This fixes CheckPatch warnings:
WARNING: else is not generally useful after a break or return
Reviewed-by: Geliang Tang <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: Mat Martineau <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
strcpy() performs no bounds checking on the destination buffer. This
could result in linear overflows beyond the end of the buffer, leading
to all kinds of misbehaviors. The safe replacement is strscpy() [1].
This is in preparation of a possible future step where all strcpy() uses
will be removed in favour of strscpy() [2].
This fixes CheckPatch warnings:
WARNING: Prefer strscpy over strcpy
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strcpy [1]
Link: https://github.com/KSPP/linux/issues/88 [2]
Reviewed-by: Geliang Tang <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: Mat Martineau <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
The sysctl lists the available schedulers that can be set using
net.mptcp.scheduler similarly to net.ipv4.tcp_available_congestion_control.
Signed-off-by: Gregory Detal <[email protected]>
Reviewed-by: Mat Martineau <[email protected]>
Tested-by: Geliang Tang <[email protected]>
Reviewed-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: Mat Martineau <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Up to recently, it has been recommended to use getsockopt(MPTCP_INFO) to
check if a fallback to TCP happened, or if the client requested to use
MPTCP.
In this case, the userspace app is only interested by the returned value
of the getsocktop() call, and can then give 0 for the option length, and
NULL for the buffer address. An easy optimisation is then to stop early,
and avoid filling a local buffer -- which now requires two different
locks -- if it is not needed.
Reviewed-by: Mat Martineau <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: Mat Martineau <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
SO_KEEPALIVE support has been added a while ago, as part of a series
"adding SOL_SOCKET" support. To have a full control of this keep-alive
feature, it is important to also support TCP_KEEP* socket options at the
SOL_TCP level.
Supporting them on the setsockopt() part is easy, it is just a matter of
remembering each value in the MPTCP sock structure, and calling
tcp_sock_set_keep*() helpers on each subflow. If the value is not
modified (0), calling these helpers will not do anything. For the
getsockopt() part, the corresponding value from the MPTCP sock structure
or the default one is simply returned. All of this is very similar to
other TCP_* socket options supported by MPTCP.
It looks important for kernels supporting SO_KEEPALIVE, to also support
TCP_KEEP* options as well: some apps seem to (wrongly) consider that if
the former is supported, the latter ones will be supported as well. But
also, not having this simple and isolated change is preventing MPTCP
support in some apps, and libraries like GoLang [1]. This is why this
patch is seen as a fix.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/383
Fixes: 1b3e7ede1365 ("mptcp: setsockopt: handle SO_KEEPALIVE and SO_PRIORITY")
Link: https://github.com/golang/go/issues/56539 [1]
Acked-by: Paolo Abeni <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: Mat Martineau <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
SO_KEEPALIVE support has to be set on each subflow: on each TCP socket,
where sk_prot->keepalive is defined. Technically, nothing has to be done
on the MPTCP socket. That's why mptcp_sol_socket_sync_intval() was
called instead of mptcp_sol_socket_intval().
Except that when nothing is done on the MPTCP socket, the
getsockopt(SO_KEEPALIVE), handled in net/core/sock.c:sk_getsockopt(),
will not know if SO_KEEPALIVE has been set on the different subflows or
not.
The fix is simple: simply call mptcp_sol_socket_intval() which will end
up calling net/core/sock.c:sk_setsockopt() where the SOCK_KEEPOPEN flag
will be set, the one used in sk_getsockopt().
So now, getsockopt(SO_KEEPALIVE) on an MPTCP socket will return the same
value as the one previously set with setsockopt(SO_KEEPALIVE).
Fixes: 1b3e7ede1365 ("mptcp: setsockopt: handle SO_KEEPALIVE and SO_PRIORITY")
Acked-by: Paolo Abeni <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: Mat Martineau <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|