|
Revision tags: v7.1-rc2 |
|
| #
0fc8f620 |
| 27-Apr-2026 |
Thomas Zimmermann <tzimmermann@suse.de> |
Merge drm/drm-fixes into drm-misc-fixes
Getting fixes and updates from v7.1-rc1.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
|
|
Revision tags: v7.1-rc1 |
|
| #
f4b369c6 |
| 20-Apr-2026 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
Merge branch 'next' into for-linus
Prepare input updates for 7.1 merge window.
|
|
Revision tags: v7.0, v7.0-rc7, v7.0-rc6, v7.0-rc5, v7.0-rc4 |
|
| #
0421ccdf |
| 12-Mar-2026 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
Merge tag 'v7.0-rc3' into next
Sync up with the mainline to brig up the latest changes, specifically changes to ALPS driver.
|
| #
eb5249b1 |
| 18-Apr-2026 |
Linus Torvalds <torvalds@linux-foundation.org> |
Merge tag 'parisc-for-7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux
Pull parisc architecture updates from Helge Deller:
- A fix to make modules on 32-bit parisc arc
Merge tag 'parisc-for-7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux
Pull parisc architecture updates from Helge Deller:
- A fix to make modules on 32-bit parisc architecture work again
- Drop ip_fast_csum() inline assembly to avoid unaligned memory accesses
- Allow to build kernel without 32-bit VDSO
- Reference leak fix in error path in LED driver
* tag 'parisc-for-7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: led: fix reference leak on failed device registration module.lds.S: Fix modules on 32-bit parisc architecture parisc: Allow to build without VDSO32 parisc: Include 32-bit VDSO only when building for 32-bit or compat mode parisc: Allow to disable COMPAT mode on 64-bit kernel parisc: Fix default stack size when COMPAT=n parisc: Fix signal code to depend on CONFIG_COMPAT instead of CONFIG_64BIT parisc: is_compat_task() shall return false for COMPAT=n parisc: Avoid compat syscalls when COMPAT=n parisc: _llseek syscall is only available for 32-bit userspace parisc: Drop ip_fast_csum() inline assembly implementation parisc: update outdated comments for renamed ccio_alloc_consistent()
show more ...
|
| #
9cdca336 |
| 18-Apr-2026 |
Linus Torvalds <torvalds@linux-foundation.org> |
Merge tag 'integrity-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity
Pull integrity updates from Mimi Zohar: "There are two main changes, one feature removal, some code
Merge tag 'integrity-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity
Pull integrity updates from Mimi Zohar: "There are two main changes, one feature removal, some code cleanup, and a number of bug fixes.
Main changes: - Detecting secure boot mode was limited to IMA. Make detecting secure boot mode accessible to EVM and other LSMs - IMA sigv3 support was limited to fsverity. Add IMA sigv3 support for IMA regular file hashes and EVM portable signatures
Remove: - Remove IMA support for asychronous hash calculation originally added for hardware acceleration
Cleanup: - Remove unnecessary Kconfig CONFIG_MODULE_SIG and CONFIG_KEXEC_SIG tests - Add descriptions of the IMA atomic flags
Bug fixes: - Like IMA, properly limit EVM "fix" mode - Define and call evm_fix_hmac() to update security.evm - Fallback to using i_version to detect file change for filesystems that do not support STATX_CHANGE_COOKIE - Address missing kernel support for configured (new) TPM hash algorithms - Add missing crypto_shash_final() return value"
* tag 'integrity-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity: evm: Enforce signatures version 3 with new EVM policy 'bit 3' integrity: Allow sigv3 verification on EVM_XATTR_PORTABLE_DIGSIG ima: add support to require IMA sigv3 signatures ima: add regular file data hash signature version 3 support ima: Define asymmetric_verify_v3() to verify IMA sigv3 signatures ima: remove buggy support for asynchronous hashes integrity: Eliminate weak definition of arch_get_secureboot() ima: Add code comments to explain IMA iint cache atomic_flags ima_fs: Correctly create securityfs files for unsupported hash algos ima: check return value of crypto_shash_final() in boot aggregate ima: Define and use a digest_size field in the ima_algo_desc structure powerpc/ima: Drop unnecessary check for CONFIG_MODULE_SIG ima: efi: Drop unnecessary check for CONFIG_MODULE_SIG/CONFIG_KEXEC_SIG ima: fallback to using i_version to detect file change evm: fix security.evm for a file with IMA signature s390: Drop unnecessary CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT evm: Don't enable fix mode when secure boot is enabled integrity: Make arch_ima_get_secureboot integrity-wide
show more ...
|
| #
1221365f |
| 07-Apr-2026 |
Helge Deller <deller@gmx.de> |
module.lds.S: Fix modules on 32-bit parisc architecture
On the 32-bit parisc architecture, we always used the -ffunction-sections compiler option to tell the compiler to put the functions into seper
module.lds.S: Fix modules on 32-bit parisc architecture
On the 32-bit parisc architecture, we always used the -ffunction-sections compiler option to tell the compiler to put the functions into seperate text sections. This is necessary, otherwise "big" kernel modules like ext4 or ipv6 fail to load because some branches won't be able to reach their stubs.
Commit 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros") broke this for parisc because all text sections will get unconditionally merged now.
Introduce the ARCH_WANTS_MODULES_TEXT_SECTIONS config option which avoids the text section merge for modules, and fix this issue by enabling this option by default for 32-bit parisc.
Fixes: 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros") Cc: Josh Poimboeuf <jpoimboe@kernel.org> Cc: stable@vger.kernel.org # v6.19+ Suggested-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Petr Pavlu <petr.pavlu@suse.com> Signed-off-by: Helge Deller <deller@gmx.de>
show more ...
|
| #
d568788b |
| 14-Apr-2026 |
Linus Torvalds <torvalds@linux-foundation.org> |
Merge tag 'hardening-v7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
Pull hardening updates from Kees Cook:
- randomize_kstack: Improve implementation across arches (Ryan Rob
Merge tag 'hardening-v7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
Pull hardening updates from Kees Cook:
- randomize_kstack: Improve implementation across arches (Ryan Roberts)
- lkdtm/fortify: Drop unneeded FORTIFY_STR_OBJECT test
- refcount: Remove unused __signed_wrap function annotations
* tag 'hardening-v7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: lkdtm/fortify: Drop unneeded FORTIFY_STR_OBJECT test refcount: Remove unused __signed_wrap function annotations randomize_kstack: Unify random source across arches randomize_kstack: Maintain kstack_offset per task
show more ...
|
| #
26ff9699 |
| 13-Apr-2026 |
Linus Torvalds <torvalds@linux-foundation.org> |
Merge tag 'rust-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux
Pull Rust updates from Miguel Ojeda: "Toolchain and infrastructure:
- Bump the minimum Rust version to 1.85.0 (
Merge tag 'rust-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux
Pull Rust updates from Miguel Ojeda: "Toolchain and infrastructure:
- Bump the minimum Rust version to 1.85.0 (and 'bindgen' to 0.71.1).
As proposed in LPC 2025 and the Maintainers Summit [1], we are going to follow Debian Stable's Rust versions as our minimum versions.
Debian Trixie was released on 2025-08-09 with a Rust 1.85.0 and 'bindgen' 0.71.1 toolchain, which is a fair amount of time for e.g. kernel developers to upgrade.
Other major distributions support a Rust version that is high enough as well, including:
+ Arch Linux. + Fedora Linux. + Gentoo Linux. + Nix. + openSUSE Slowroll and openSUSE Tumbleweed. + Ubuntu 25.10 and 26.04 LTS. In addition, 24.04 LTS using their versioned packages.
The merged patch series comes with the associated cleanups and simplifications treewide that can be performed thanks to both bumps, as well as documentation updates.
In addition, start using 'bindgen''s '--with-attribute-custom-enum' feature to set the 'cfi_encoding' attribute for the 'lru_status' enum used in Binder.
Link: https://lwn.net/Articles/1050174/ [1]
- Add experimental Kconfig option ('CONFIG_RUST_INLINE_HELPERS') that inlines C helpers into Rust.
Essentially, it performs a step similar to LTO, but just for the helpers, i.e. very local and fast.
It relies on 'llvm-link' and its '--internalize' flag, and requires a compatible LLVM between Clang and 'rustc' (i.e. same major version, 'CONFIG_RUSTC_CLANG_LLVM_COMPATIBLE'). It is only enabled for two architectures for now.
The result is a measurable speedup in different workloads that different users have tested. For instance, for the null block driver, it amounts to a 2%.
- Support global per-version flags.
While we already have per-version flags in many places, we didn't have a place to set global ones that depend on the compiler version, i.e. in 'rust_common_flags', which sometimes is needed to e.g. tweak the lints set per version.
Use that to allow the 'clippy::precedence' lint for Rust < 1.86.0, since it had a change in behavior.
- Support overriding the crate name and apply it to Rust Binder, which wanted the module to be called 'rust_binder'.
- Add the remaining '__rust_helper' annotations (started in the previous cycle).
'kernel' crate:
- Introduce the 'const_assert!' macro: a more powerful version of 'static_assert!' that can refer to generics inside functions or implementation bodies, e.g.:
fn f<const N: usize>() { const_assert!(N > 1); }
fn g<T>() { const_assert!(size_of::<T>() > 0, "T cannot be ZST"); }
In addition, reorganize our set of build-time assertion macros ('{build,const,static_assert}!') to live in the 'build_assert' module.
Finally, improve the docs as well to clarify how these are different from one another and how to pick the right one to use, and their equivalence (if any) to the existing C ones for extra clarity.
- 'sizes' module: add 'SizeConstants' trait.
This gives us typed 'SZ_*' constants (avoiding casts) for use in device address spaces where the address width depends on the hardware (e.g. 32-bit MMIO windows, 64-bit GPU framebuffers, etc.), e.g.:
let gpu_heap = 14 * u64::SZ_1M; let mmio_window = u32::SZ_16M;
- 'clk' module: implement 'Send' and 'Sync' for 'Clk' and thus simplify the users in Tyr and PWM.
- 'ptr' module: add 'const_align_up'.
- 'str' module: improve the documentation of the 'c_str!' macro to explain that one should only use it for non-literal cases (for the other case we instead use C string literals, e.g. 'c"abc"').
- Disallow the use of 'CStr::{as_ptr,from_ptr}' and clean one such use in the 'task' module.
- 'sync' module: finish the move of 'ARef' and 'AlwaysRefCounted' outside of the 'types' module, i.e. update the last remaining instances and finally remove the re-exports.
- 'error' module: clarify that 'from_err_ptr' can return 'Ok(NULL)', including runtime-tested examples.
The intention is to hopefully prevent UB that assumes the result of the function is not 'NULL' if successful. This originated from a case of UB I noticed in 'regulator' that created a 'NonNull' on it.
Timekeeping:
- Expand the example section in the 'HrTimer' documentation.
- Mark the 'ClockSource' trait as unsafe to ensure valid values for 'ktime_get()'.
- Add 'Delta::from_nanos()'.
'pin-init' crate:
- Replace the 'Zeroable' impls for 'Option<NonZero*>' with impls of 'ZeroableOption' for 'NonZero*'.
- Improve feature gate handling for unstable features.
- Declutter the documentation of implementations of 'Zeroable' for tuples.
- Replace uses of 'addr_of[_mut]!' with '&raw [mut]'.
rust-analyzer:
- Add type annotations to 'generate_rust_analyzer.py'.
- Add support for scripts written in Rust ('generate_rust_target.rs', 'rustdoc_test_builder.rs', 'rustdoc_test_gen.rs').
- Refactor 'generate_rust_analyzer.py' to explicitly identify host and target crates, improve readability, and reduce duplication.
And some other fixes, cleanups and improvements"
* tag 'rust-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: (79 commits) rust: sizes: add SizeConstants trait for device address space constants rust: kernel: update `file_with_nul` comment rust: kbuild: allow `clippy::precedence` for Rust < 1.86.0 rust: kbuild: support global per-version flags rust: declare cfi_encoding for lru_status docs: rust: general-information: use real example docs: rust: general-information: simplify Kconfig example docs: rust: quick-start: remove GDB/Binutils mention docs: rust: quick-start: remove Nix "unstable channel" note docs: rust: quick-start: remove Gentoo "testing" note docs: rust: quick-start: add Ubuntu 26.04 LTS and remove subsection title docs: rust: quick-start: update minimum Ubuntu version docs: rust: quick-start: update Ubuntu versioned packages docs: rust: quick-start: openSUSE provides `rust-src` package nowadays rust: kbuild: remove "dummy parameter" workaround for `bindgen` < 0.71.1 rust: kbuild: update `bindgen --rust-target` version and replace comment rust: rust_is_available: remove warning for `bindgen` < 0.69.5 && libclang >= 19.1 rust: rust_is_available: remove warning for `bindgen` 0.66.[01] rust: bump `bindgen` minimum supported version to 0.71.1 (Debian Trixie) rust: block: update `const_refs_to_static` MSRV TODO comment ...
show more ...
|
| #
7ab26eb5 |
| 07-Apr-2026 |
Miguel Ojeda <ojeda@kernel.org> |
Merge patch series "rust: bump minimum Rust and `bindgen` versions"
As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1], we are going to follow Debian Stable's Rust versions as o
Merge patch series "rust: bump minimum Rust and `bindgen` versions"
As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1], we are going to follow Debian Stable's Rust versions as our minimum supported version.
Debian Trixie was released with a Rust 1.85.0 toolchain [2], which it still uses to this day [3] (i.e. no update to Rust 1.85.1).
Debian Trixie was released with `bindgen` 0.71.1, which it also still uses to this day [4].
Debian Trixie's release happened on 2025-08-09 [5], which means that a fair amount of time has passed since its release for kernel developers to upgrade.
Thus bump the minimum to the new versions, i.e.
- Rust: 1.78.0 -> 1.85.0 - bindgen: 0.65.1 -> 0.71.1
There are a few main parts to the series, in this order:
- A few cleanups that can be performed before the bumps. - The Rust bump (and its cleanups). - The `bindgen` bump (and its cleanups). - Documentation updates. - The `cfi_encoding` patch, added here, which needs the bump. - The per-version flags support and a Clippy cleanup on top.
Link: https://lwn.net/Articles/1050174/ [1] Link: https://www.debian.org/releases/trixie/release-notes/whats-new.en.html#desktops-and-well-known-packages [2] Link: https://packages.debian.org/trixie/rustc [3] Link: https://packages.debian.org/trixie/bindgen [4] Link: https://www.debian.org/releases/trixie/ [5] Link: https://patch.msgid.link/20260405235309.418950-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
| #
b28711ac |
| 06-Apr-2026 |
Miguel Ojeda <ojeda@kernel.org> |
rust: simplify `RUSTC_VERSION` Kconfig conditions
With the Rust version bump in place, several Kconfig conditions based on `RUSTC_VERSION` are always true.
Thus simplify them.
The minimum supporte
rust: simplify `RUSTC_VERSION` Kconfig conditions
With the Rust version bump in place, several Kconfig conditions based on `RUSTC_VERSION` are always true.
Thus simplify them.
The minimum supported major LLVM version by our new Rust minimum version is now LLVM 18, instead of LLVM 16. However, there are no possible cleanups for `RUSTC_LLVM_VERSION`.
Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-9-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
|
Revision tags: v7.0-rc3 |
|
| #
a96ef584 |
| 03-Mar-2026 |
Ryan Roberts <ryan.roberts@arm.com> |
randomize_kstack: Unify random source across arches
Previously different architectures were using random sources of differing strength and cost to decide the random kstack offset. A number of archit
randomize_kstack: Unify random source across arches
Previously different architectures were using random sources of differing strength and cost to decide the random kstack offset. A number of architectures (loongarch, powerpc, s390, x86) were using their timestamp counter, at whatever the frequency happened to be. Other arches (arm64, riscv) were using entropy from the crng via get_random_u16().
There have been concerns that in some cases the timestamp counters may be too weak, because they can be easily guessed or influenced by user space. And get_random_u16() has been shown to be too costly for the level of protection kstack offset randomization provides.
So let's use a common, architecture-agnostic source of entropy; a per-cpu prng, seeded at boot-time from the crng. This has a few benefits:
- We can remove choose_random_kstack_offset(); That was only there to try to make the timestamp counter value a bit harder to influence from user space [*].
- The architecture code is simplified. All it has to do now is call add_random_kstack_offset() in the syscall path.
- The strength of the randomness can be reasoned about independently of the architecture.
- Arches previously using get_random_u16() now have much faster syscall paths, see below results.
[*] Additionally, this gets rid of some redundant work on s390 and x86. Before this patch, those architectures called choose_random_kstack_offset() under arch_exit_to_user_mode_prepare(), which is also called for exception returns to userspace which were *not* syscalls (e.g. regular interrupts). Getting rid of choose_random_kstack_offset() avoids a small amount of redundant work for the non-syscall cases.
In some configurations, add_random_kstack_offset() will now call instrumentable code, so for a couple of arches, I have moved the call a bit later to the first point where instrumentation is allowed. This doesn't impact the efficacy of the mechanism.
There have been some claims that a prng may be less strong than the timestamp counter if not regularly reseeded. But the prng has a period of about 2^113. So as long as the prng state remains secret, it should not be possible to guess. If the prng state can be accessed, we have bigger problems.
Additionally, we are only consuming 6 bits to randomize the stack, so there are only 64 possible random offsets. I assert that it would be trivial for an attacker to brute force by repeating their attack and waiting for the random stack offset to be the desired one. The prng approach seems entirely proportional to this level of protection.
Performance data are provided below. The baseline is v6.18 with rndstack on for each respective arch. (I)/(R) indicate statistically significant improvement/regression. arm64 platform is AWS Graviton3 (m7g.metal). x86_64 platform is AWS Sapphire Rapids (m7i.24xlarge):
+-----------------+--------------+---------------+---------------+ | Benchmark | Result Class | per-cpu-prng | per-cpu-prng | | | | arm64 (metal) | x86_64 (VM) | +=================+==============+===============+===============+ | syscall/getpid | mean (ns) | (I) -9.50% | (I) -17.65% | | | p99 (ns) | (I) -59.24% | (I) -24.41% | | | p99.9 (ns) | (I) -59.52% | (I) -28.52% | +-----------------+--------------+---------------+---------------+ | syscall/getppid | mean (ns) | (I) -9.52% | (I) -19.24% | | | p99 (ns) | (I) -59.25% | (I) -25.03% | | | p99.9 (ns) | (I) -59.50% | (I) -28.17% | +-----------------+--------------+---------------+---------------+ | syscall/invalid | mean (ns) | (I) -10.31% | (I) -18.56% | | | p99 (ns) | (I) -60.79% | (I) -20.06% | | | p99.9 (ns) | (I) -61.04% | (I) -25.04% | +-----------------+--------------+---------------+---------------+
I tested an earlier version of this change on x86 bare metal and it showed a smaller but still significant improvement. The bare metal system wasn't available this time around so testing was done in a VM instance. I'm guessing the cost of rdtsc is higher for VMs.
Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com> Link: https://patch.msgid.link/20260303150840.3789438-3-ryan.roberts@arm.com Signed-off-by: Kees Cook <kees@kernel.org>
show more ...
|
| #
7caedbb5 |
| 09-Mar-2026 |
Nathan Chancellor <nathan@kernel.org> |
integrity: Eliminate weak definition of arch_get_secureboot()
security/integrity/secure_boot.c contains a single __weak function, which breaks recordmcount when building with clang:
$ make -skj"$
integrity: Eliminate weak definition of arch_get_secureboot()
security/integrity/secure_boot.c contains a single __weak function, which breaks recordmcount when building with clang:
$ make -skj"$(nproc)" ARCH=powerpc LLVM=1 ppc64_defconfig security/integrity/secure_boot.o Cannot find symbol for section 2: .text. security/integrity/secure_boot.o: failed
Introduce a Kconfig symbol, CONFIG_HAVE_ARCH_GET_SECUREBOOT, to indicate that an architecture provides a definition of arch_get_secureboot(). Provide a static inline stub when this symbol is not defined to achieve the same effect as the __weak function, allowing secure_boot.c to be removed altogether. Move the s390 definition of arch_get_secureboot() out of the CONFIG_KEXEC_FILE block to ensure it is always available, as it does not actually depend on KEXEC_FILE.
Reported-by: Arnd Bergmann <arnd@arndb.de> Fixes: 31a6a07eefeb ("integrity: Make arch_ima_get_secureboot integrity-wide") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
show more ...
|
| #
42d3b66d |
| 12-Mar-2026 |
Matthew Brost <matthew.brost@intel.com> |
Merge drm/drm-next into drm-xe-next
Backmerging to bring in 7.00-rc3. Important ahead GPU SVM merging THP support.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
|
|
Revision tags: v7.0-rc2 |
|
| #
f09812b8 |
| 25-Feb-2026 |
Jani Nikula <jani.nikula@intel.com> |
Merge drm/drm-next into drm-intel-next
Sync with v7.0-rc1 which contains a few treewide changes affecting i915.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
| #
8b85987d |
| 23-Feb-2026 |
Maxime Ripard <mripard@kernel.org> |
Merge drm/drm-next into drm-misc-next
Let's merge 7.0-rc1 to start the new drm-misc-next window
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
| #
c17ee635 |
| 23-Feb-2026 |
Maxime Ripard <mripard@kernel.org> |
Merge drm/drm-fixes into drm-misc-fixes
7.0-rc1 was just released, let's merge it to kick the new release cycle.
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
Revision tags: v7.0-rc1 |
|
| #
57cb8450 |
| 11-Feb-2026 |
Linus Torvalds <torvalds@linux-foundation.org> |
Merge tag 'x86_paravirt_for_v7.0_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 paravirt updates from Borislav Petkov:
- A nice cleanup to the paravirt code containing a un
Merge tag 'x86_paravirt_for_v7.0_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 paravirt updates from Borislav Petkov:
- A nice cleanup to the paravirt code containing a unification of the paravirt clock interface, taming the include hell by splitting the pv_ops structure and removing of a bunch of obsolete code (Juergen Gross)
* tag 'x86_paravirt_for_v7.0_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (23 commits) x86/paravirt: Use XOR r32,r32 to clear register in pv_vcpu_is_preempted() x86/paravirt: Remove trailing semicolons from alternative asm templates x86/pvlocks: Move paravirt spinlock functions into own header x86/paravirt: Specify pv_ops array in paravirt macros x86/paravirt: Allow pv-calls outside paravirt.h objtool: Allow multiple pv_ops arrays x86/xen: Drop xen_mmu_ops x86/xen: Drop xen_cpu_ops x86/xen: Drop xen_irq_ops x86/paravirt: Move pv_native_*() prototypes to paravirt.c x86/paravirt: Introduce new paravirt-base.h header x86/paravirt: Move paravirt_sched_clock() related code into tsc.c x86/paravirt: Use common code for paravirt_steal_clock() riscv/paravirt: Use common code for paravirt_steal_clock() loongarch/paravirt: Use common code for paravirt_steal_clock() arm64/paravirt: Use common code for paravirt_steal_clock() arm/paravirt: Use common code for paravirt_steal_clock() sched: Move clock related paravirt code to kernel/sched paravirt: Remove asm/paravirt_api_clock.h x86/paravirt: Move thunk macros to paravirt_types.h ...
show more ...
|
| #
ec496f77 |
| 09-Feb-2026 |
Jiri Kosina <jkosina@suse.com> |
Merge branch 'for-6.20/sony' into for-linus
- Support for Rock band 4 PS4 and PS5 guitars (Rosalie Wanders)
|
|
Revision tags: v6.19, v6.19-rc8, v6.19-rc7 |
|
| #
cc4adab1 |
| 20-Jan-2026 |
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> |
Merge tag 'v6.19-rc1' into msm-next
Merge Linux 6.19-rc1 in order to catch up with other changes (e.g. UBWC config database defining UBWC_6).
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.q
Merge tag 'v6.19-rc1' into msm-next
Merge Linux 6.19-rc1 in order to catch up with other changes (e.g. UBWC config database defining UBWC_6).
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
show more ...
|
|
Revision tags: v6.19-rc6, v6.19-rc5 |
|
| #
e6b2aa6d |
| 05-Jan-2026 |
Juergen Gross <jgross@suse.com> |
sched: Move clock related paravirt code to kernel/sched
Paravirt clock related functions are available in multiple archs.
In order to share the common parts, move the common static keys to kernel/s
sched: Move clock related paravirt code to kernel/sched
Paravirt clock related functions are available in multiple archs.
In order to share the common parts, move the common static keys to kernel/sched/ and remove them from the arch specific files.
Make a common paravirt_steal_clock() implementation available in kernel/sched/cputime.c, guarding it with a new config option CONFIG_HAVE_PV_STEAL_CLOCK_GEN, which can be selected by an arch in case it wants to use that common variant.
Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260105110520.21356-7-jgross@suse.com
show more ...
|
|
Revision tags: v6.19-rc4, v6.19-rc3, v6.19-rc2 |
|
| #
5add3c3c |
| 19-Dec-2025 |
Thomas Hellström <thomas.hellstrom@linux.intel.com> |
Merge drm/drm-next into drm-xe-next
Backmerging to bring in 6.19-rc1. An important upstream bugfix and to help unblock PTL CI.
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
|
| #
ec439c38 |
| 17-Dec-2025 |
Alexei Starovoitov <ast@kernel.org> |
Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf after 6.19-rc1
Cross-merge BPF and other fixes after downstream PR.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
| #
b8304863 |
| 15-Dec-2025 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
Merge drm/drm-next into drm-intel-next
Sync-up some display code needed for Async flips refactor.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
| #
7f790dd2 |
| 15-Dec-2025 |
Maxime Ripard <mripard@kernel.org> |
Merge drm/drm-next into drm-misc-next
Let's kickstart the v6.20 (7.0?) release cycle.
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
Revision tags: v6.19-rc1 |
|
| #
a4a508df |
| 13-Dec-2025 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
Merge tag 'v6.18' into next
Sync up with the mainline to bring in the latest APIs.
|