* Re: configurable block error injection
From: Christoph Hellwig @ 2026-06-05 7:23 UTC (permalink / raw)
To: Daniel Gomez
Cc: Christoph Hellwig, Jens Axboe, Jonathan Corbet, linux-block,
linux-doc, bpf, linux-kselftest, Luis Chamberlain,
Masami Hiramatsu, Brendan Gregg, GOST, Shin'ichiro Kawasaki
In-Reply-To: <d9a5b911-7692-4df2-b67c-c33bc80b61aa@kernel.org>
On Thu, Jun 04, 2026 at 01:06:13PM +0200, Daniel Gomez wrote:
> IIU the series correctly, and oversimplifying: when
> injection is enabled and a bio matches, the block layer completes the
> bio inline with the chosen blk_status_t (the status= rule from debugfs)
> via bio_endio_status(). The submission path returns to the caller
> immediately, with the bio already in the error state. Nothing is ever
> sent to the device, but the completion path sees the injected error.
Yes.
> > I'd have to allow access to certain bio
>
> With struct_ops the bio is passed to the ebpf side as read-only, bio
> fields can be read to decide the policy but cannot write them. Is
> read-only access to bio fields itself a concern?
Yes, for the reason state below.
>
> > fields and would have create a stable UAPI for commands and status
> > using the fake BTF struct access which really would not be a good
> > idea here as we need to be able to change internals.
>
> That should not be a problem at all. With CO-RE (compile once, run
> everywhere) the program resolves the bio field offsets against the
> BTF of the kernel it loads on, so it adapts dynamically if the layout
> changes. The contract is just the struct_ops callback signature: a
> struct bio * argument and a blk_status_t return. And that doesn't imply
> any UAPI commitment AFAIK.
That assumes the fields even exists in this form. And we definitively
need to do things about the iter going ahead. In other words we have
to build up a huge abstraction here first.
> > Additionally
> > having fully BTF-enabled toolchains in test VMs is not great either.
>
> Are you referring to the old BCC toolchain requirements [1]? This is
> solved in CO-RE [2]. The toolchain (Clang/LLVM, pahole) stays on the
> build host; the test VM only needs the prebuilt BPF object, libbpf at
> runtime, and the kernel's own BTF (CONFIG_DEBUG_INFO_BTF). No compiler
> or BTF toolchain is required inside the VM. Clang/LLVM 10+ is enough to
> build CO-RE libbpf tools [3].
libbpf and BTF support is what I mean. And of course whatever code
you write to communicate with it as a simple shell script won't work
any more.
> Are you referring to the bio sector range comparison in
> __blk_error_inject()?
Yes.
> I don't think that needs to be delegated to a
> BPF map (Documentation/bpf/maps.rst). The ebpf side has direct access
> to the bio fields, so it can apply the same sector/op filtering
> __blk_error_inject() does today. That match is already a linear list
> walk, so the ebpf program just runs the same [start, end] condition
> check.
Which means I need to write eBPF code for every specific range I
want to inject, which makes the thing very hard to use.
> In summary: what do you think of evolving this series
> into eBPF, but BPF_PROG_TYPE_STRUCT_OPS instead of
> ALLOW_ERROR_INJECTION/bpf_override_return()?.
As said before, I prototyped it and it was a mess. Having about 300
lines of simple code that can be directly used from a shell script
seems much preferable.
^ permalink raw reply
* Re: (subset) [PATCH] leds: Fix sysfs ABI date
From: Lee Jones @ 2026-06-05 7:45 UTC (permalink / raw)
To: lee, pavel, Armin Wolf; +Cc: corbet, linux-leds, linux-doc
In-Reply-To: <20260527001422.51111-1-W_Armin@gmx.de>
On Wed, 27 May 2026 02:14:22 +0200, Armin Wolf wrote:
> The "multi_max_intensity" sysfs attribute was not included
> in kernel 7.1, so update the KernelVersion and Date tags
> accordingly.
Applied, thanks!
[1/1] leds: Fix sysfs ABI date
commit: fa252b55ea6126729b7e0c1de975268056673464
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v1] arm64: errata: Workaround NVIDIA Olympus device store/load ordering erratum
From: Catalin Marinas @ 2026-06-05 8:01 UTC (permalink / raw)
To: Shanker Donthineni
Cc: Will Deacon, linux-arm-kernel, Mark Rutland, linux-kernel,
linux-doc, Vikram Sethi, Jason Sequeira
In-Reply-To: <20260604231254.1904988-1-sdonthineni@nvidia.com>
On Thu, Jun 04, 2026 at 06:12:54PM -0500, Shanker Donthineni wrote:
> On systems with NVIDIA Olympus cores, a Device-nGnR* load can be
> observed by a peripheral before an older, non-overlapping Device-nGnR*
> store to the same peripheral. This breaks the program-order guarantee
> that software expects for Device-nGnR* accesses and can leave a
> peripheral in an incorrect state, as a load is observed before an
> earlier store takes effect.
>
> The erratum can occur only when all of the following apply:
>
> - A PE executes a Device-nGnR* store followed by a younger
> Device-nGnR* load.
> - The store is not a store-release.
> - The accesses target the same peripheral and do not overlap in bytes.
> - There is at most one intervening Device-nGnR* store in program
> order, and there are no intervening Device-nGnR* loads.
> - There is no DSB, and no DMB that orders loads, between the store and
> the load.
> - Specific micro-architectural and timing conditions occur.
>
> Two ways to restore ordering: insert a barrier (any DSB, or a DMB that
> orders loads) between the store and the load, or make the store a
> store-release. A load-acquire on the load side would not help, because
> acquire semantics do not prevent a load from being observed ahead of an
> older store; only the store side (release or a barrier) closes the
> window.
Ignoring Device-nGnR*, a store-release followed by a load (not
load-acquire) would not guarantee any ordering. I assume the
store-release behaviour is specific to this erratum - part of the
preconditions.
The patch looks fine to me.
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* Re: [PATCH mm-unstable v18 06/14] mm/khugepaged: generalize collapse_huge_page for mTHP collapse
From: Lorenzo Stoakes @ 2026-06-05 8:07 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Nico Pache, Lance Yang, linux-doc, linux-kernel, linux-mm,
linux-trace-kernel, aarcange, akpm, anshuman.khandual, apopple,
baohua, baolin.wang, byungchul, catalin.marinas, cl, corbet,
dave.hansen, dev.jain, gourry, hannes, hughd, jack, jackmanb,
jannh, jglisse, joshua.hahnjy, kas, liam, mathieu.desnoyers,
matthew.brost, mhiramat, mhocko, peterx, pfalcato, rakie.kim,
raquini, rdunlap, richard.weiyang, rientjes, rostedt, rppt,
ryan.roberts, shivankg, sunnanyong, surenb, thomas.hellstrom,
tiwai, usamaarif642, vbabka, vishal.moola, wangkefeng.wang, will,
willy, yang, ying.huang, ziy, zokeefe, usama.arif
In-Reply-To: <0ef96c28-9e6c-4d04-90ae-ac43c81d465d@kernel.org>
On Fri, Jun 05, 2026 at 09:18:27AM +0200, David Hildenbrand (Arm) wrote:
> On 6/4/26 19:04, Nico Pache wrote:
> > On Mon, Jun 1, 2026 at 9:00 AM Nico Pache <npache@redhat.com> wrote:
> >>
> >> On Mon, Jun 1, 2026 at 5:14 AM David Hildenbrand (Arm) <david@kernel.org> wrote:
> >>>
> >>>
> >>> Yeah. BTW, I think we'd need a spin_lock_nested(), so @Nico, treat my code as a
> >>> draft.
> >>
> >> Okay, I read the above and did some investigating.
> >>
> >> I will try to implement and verify the changes you suggested :)
> >
> > I've implemented something slightly different actually and I *think* its better!
> >
> > } else {
> > /* this is map_anon_folio_pte_nopf with no mmu update */
> > __map_anon_folio_pte_nopf(folio, pte, vma, start_addr,
> > /*uffd_wp=*/ false);
> > smp_wmb();
> > pmd_populate(mm, pmd, pmd_pgtable(_pmd));
> > /*
> > * Some architectures (e.g. MIPS) walk the live page table in
> > * their implementation. update_mmu_cache_range() must be called
> > * with a valid page table hierarchy and the PTE lock held.
> > * Acquire it nested inside pmd_ptl when they are distinct locks.
> > */
> > if (pte_ptl != pmd_ptl)
> > spin_lock_nested(pte_ptl, SINGLE_DEPTH_NESTING);
> > update_mmu_cache_range(NULL, vma, start_addr, pte, nr_pages);
> > if (pte_ptl != pmd_ptl)
> > spin_unlock(pte_ptl);
> > }
> > spin_unlock(pmd_ptl);
> >
> > The logic here is that when the PMD becomes visible, PTEs are already
> > populated (no possibility of spurious faults on local CPU)
> >
> > the SMP_WMB makes sure of the above
THe locks prevent those 'spurious' (really: incorrect) faults anyway so I don't
think this is necessary.
> >
> > And the pmd is installed with the pte and pmd lock both held through
> > the mmu_cache update.
> >
> > This follows the conventions used in pmd_install() and clears the
> > potential for local CPU faults hitting cleared PTE entries.
>
> After the pmdp_collapse_flush() we'd be getting CPU faults due to the cleared
> PMD already? So the case here is rather different.
Yeah conceptually the code above is problematic because you immediately make the
PTE available right at the point you populate, so taking a PTE lock after that
is rather shutting the stable door after the horse has bolted.
Doing it this way is not a good idea in any case because we're adding
complexity, an extra function and an open-coded cache maintenance call for
really no benefit.
I asked Nico to abstract the anon folio mapping stuff explicitly so we could
avoid this sort of duplication so let's not roll that back :)
So again, I think going with the original suggestion (with an updated comment)
is the right thing to do.
Anyway, an aside But in practice we can't have page faults here right? The VMA is:
- Ensured to span at least the PMD range (this isn't immediately obvious in the
code)
- VMA write locked (mmap write lock held)
And we hold the anon_vma lock so no rmap walkers can walk the page tables here
either.
So I actually wonder, given that, whether we need the PTE PTL at all.
But.
At this stage it'll almost certainly be an owned exclusive cache line so it's
very low cost to do it, and it means we honour the update_mmu_cache_range()
contract.
And it also makes it clear that we're gating changes on the PTE being
untouchable so any future stuff that maybe changes some of these rules doesn't
get caught out.
So probably worth keeping.
>
> --
> Cheers,
>
> David
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH v3 3/5] KVM: arm64: Add support for FEAT_HDBSS
From: Tian Zheng @ 2026-06-05 8:29 UTC (permalink / raw)
To: Inochi Amaoto, Marc Zyngier
Cc: oupton, catalin.marinas, corbet, pbonzini, will, yuzenghui,
wangzhou1, liuyonglong, Jonathan.Cameron, yezhenyu2, linuxarm,
joey.gouly, kvmarm, kvm, linux-arm-kernel, linux-doc,
linux-kernel, skhan, suzuki.poulose, leo.bras
In-Reply-To: <ah1KLrpYBXSMM91H@inochi.infowork>
On 6/1/2026 5:05 PM, Inochi Amaoto wrote:
> On Mon, Jun 01, 2026 at 09:58:49AM +0100, Marc Zyngier wrote:
>> On Mon, 01 Jun 2026 01:50:22 +0100,
>> Inochi Amaoto <inochiama@gmail.com> wrote:
>>> On Wed, Feb 25, 2026 at 12:04:19PM +0800, Tian Zheng wrote:
>>>> From: eillon <yezhenyu2@huawei.com>
>>>>
>>>> Armv9.5 introduces the Hardware Dirty Bit State Structure (HDBSS) feature,
>>>> indicated by ID_AA64MMFR1_EL1.HAFDBS == 0b0100. A CPU capability is added
>>>> to notify the user of the feature.
>>>>
>>>> Add KVM_CAP_ARM_HW_DIRTY_STATE_TRACK ioctl and basic framework for
>>>> ARM64 HDBSS support. Since the HDBSS buffer size is configurable and
>>>> cannot be determined at KVM initialization, an IOCTL interface is
>>>> required.
>>>>
>>>> Actually exposing the new capability to user space happens in a later
>>>> patch.
>>>>
>>>> Signed-off-by: eillon <yezhenyu2@huawei.com>
>>>> Signed-off-by: Tian Zheng <zhengtian10@huawei.com>
>>>> ---
>>>> arch/arm64/include/asm/cpufeature.h | 5 +++++
>>>> arch/arm64/kernel/cpufeature.c | 12 ++++++++++++
>>>> arch/arm64/tools/cpucaps | 1 +
>>>> include/uapi/linux/kvm.h | 1 +
>>>> tools/include/uapi/linux/kvm.h | 1 +
>>>> 5 files changed, 20 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
>>>> index 4de51f8d92cb..dcc2e2cad5ad 100644
>>>> --- a/arch/arm64/include/asm/cpufeature.h
>>>> +++ b/arch/arm64/include/asm/cpufeature.h
>>>> @@ -856,6 +856,11 @@ static inline bool system_supports_haft(void)
>>>> return cpus_have_final_cap(ARM64_HAFT);
>>>> }
>>>>
>>>> +static inline bool system_supports_hdbss(void)
>>>> +{
>>>> + return cpus_have_final_cap(ARM64_HAS_HDBSS);
>>>> +}
>>>> +
>>>> static __always_inline bool system_supports_mpam(void)
>>>> {
>>>> return alternative_has_cap_unlikely(ARM64_MPAM);
>>>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>>>> index c31f8e17732a..348b0afffc3e 100644
>>>> --- a/arch/arm64/kernel/cpufeature.c
>>>> +++ b/arch/arm64/kernel/cpufeature.c
>>>> @@ -2124,6 +2124,11 @@ static bool hvhe_possible(const struct arm64_cpu_capabilities *entry,
>>>> return arm64_test_sw_feature_override(ARM64_SW_FEATURE_OVERRIDE_HVHE);
>>>> }
>>>>
>>>> +static bool has_vhe_hdbss(const struct arm64_cpu_capabilities *entry, int cope)
>>>> +{
>>>> + return is_kernel_in_hyp_mode() && has_cpuid_feature(entry, cope);
>>>> +}
>>>> +
>>>> bool cpu_supports_bbml2_noabort(void)
>>>> {
>>>> /*
>>>> @@ -2759,6 +2764,13 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
>>>> ARM64_CPUID_FIELDS(ID_AA64MMFR1_EL1, HAFDBS, HAFT)
>>>> },
>>>> #endif
>>>> + {
>>>> + .desc = "Hardware Dirty state tracking structure (HDBSS)",
>>>> + .type = ARM64_CPUCAP_SYSTEM_FEATURE,
>>>> + .capability = ARM64_HAS_HDBSS,
>>>> + .matches = has_vhe_hdbss,
>>>> + ARM64_CPUID_FIELDS(ID_AA64MMFR1_EL1, HAFDBS, HDBSS)
>>>> + },
>>>> {
>>>> .desc = "CRC32 instructions",
>>>> .capability = ARM64_HAS_CRC32,
>>>> diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
>>>> index 7261553b644b..f6ece5b85532 100644
>>>> --- a/arch/arm64/tools/cpucaps
>>>> +++ b/arch/arm64/tools/cpucaps
>>>> @@ -68,6 +68,7 @@ HAS_VA52
>>>> HAS_VIRT_HOST_EXTN
>>>> HAS_WFXT
>>>> HAS_XNX
>>>> +HAS_HDBSS
>>>> HAFT
>>>> HW_DBM
>>>> KVM_HVHE
>>>
>>>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>>>> index 65500f5db379..15ee42cdbd51 100644
>>>> --- a/include/uapi/linux/kvm.h
>>>> +++ b/include/uapi/linux/kvm.h
>>>> @@ -985,6 +985,7 @@ struct kvm_enable_cap {
>>>> #define KVM_CAP_ARM_SEA_TO_USER 245
>>>> #define KVM_CAP_S390_USER_OPEREXEC 246
>>>> #define KVM_CAP_S390_KEYOP 247
>>>> +#define KVM_CAP_ARM_HW_DIRTY_STATE_TRACK 248
>>>>
>>>> struct kvm_irq_routing_irqchip {
>>>> __u32 irqchip;
>>>> diff --git a/tools/include/uapi/linux/kvm.h b/tools/include/uapi/linux/kvm.h
>>>> index dddb781b0507..93e0a1e14dc7 100644
>>>> --- a/tools/include/uapi/linux/kvm.h
>>>> +++ b/tools/include/uapi/linux/kvm.h
>>>> @@ -974,6 +974,7 @@ struct kvm_enable_cap {
>>>> #define KVM_CAP_GUEST_MEMFD_FLAGS 244
>>>> #define KVM_CAP_ARM_SEA_TO_USER 245
>>>> #define KVM_CAP_S390_USER_OPEREXEC 246
>>>> +#define KVM_CAP_ARM_HW_DIRTY_STATE_TRACK 248
>>>>
>>>> struct kvm_irq_routing_irqchip {
>>>> __u32 irqchip;
>>>> --
>>>> 2.33.0
>>>>
>>> Instead of having these architecture specific capability, I wonder if
>>> we can add a generic capability like "KVM_CAP_HW_DIRTY_STATE", so
>>> other architecture supports similar things can reuse this capability,
>> What of the existing stuff doing the same thing? x86's PML, to start
>> with?
>>
> In fact I think the HDBSS is the first one with non-fixed size.
> Although there is a in process RISC-V extension for it, there will
> be a long story to make it ratified.
>
>>> For this generic thing I suggest, the getter returns the max support
>>> entry count (or the buffer size) it supports like the dirty ring
>>> capability. And the setter just let the architecture set the parameters
>>> based on the user request.
>> This looks wrong on a number of levels.
>>
>> - If you want something generic, there is the existing dirty
>> log/bitmap. How this stuff is populated is none of the user's
>> business (trapping write accesses, dirty bit collection from the
>> PTs, or HW-generated log), and we don't need an extra feature for
>> it. Performance will obviously suck, but that's what you pay for
>> something abstracted and cross-architecture.
>>
>> - If you want something architecture specific, then it can't be
>> generic, by definition. You get the raw speed and compatibility with
>> other arch-specific extensions.
>>
> OK, I agree, it is better to keep this thing arch-specific. Doing a
> generic thing does not benefit too much, I have made a mistake on
> it. Thanks for your kindly explanation.
Awesome. Thanks for the review.
I agree with Marc—keeping this ARM-specific is the right approach.
Also, in v4 we're removing the ioctl interface entirely. HDBSS will be
auto-enabled during migration setup and auto-disabled when migration
completes, so the capability naming issue becomes moot.
I plan to post v4 with the updated approach soon.
>>> This should do no harm to this implement, as everything still depends
>>> on the architecture behavior, and leave room for other architecture
>>> to reuse this.
>> Again, the generic framework exists, you just have to implement the
>> backend you want.
>>
>> M.
>>
>> --
>> Without deviation from the norm, progress is not possible.
> Regards,
> Inochi
^ permalink raw reply
* [PATCH] Document: Fix missing reference pages
From: [Ko Han Chen] @ 2026-06-05 8:41 UTC (permalink / raw)
To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet
Cc: Simon Horman, Shuah Khan, netdev, linux-doc, linux-kernel,
[Ko Han Chen]
Today, my friend and I are discussing a wwan driver produced by
Mediatek. I am reading the related document and reference link,
then I found the page is missing. So after a short search I am
giving the better link and test the two pages with my bash
program for more dead links. It turns out only this one. I check
the page and the following documents. Details are covered in
this markdown [page](https://hackmd.io/@Urbaner/lk_patch_doc).
Signed-off-by: [Ko Han Chen] <urbaner3@gmail.com>
---
Documentation/networking/device_drivers/wwan/iosm.rst | 2 +-
Documentation/networking/device_drivers/wwan/t7xx.rst | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/device_drivers/wwan/iosm.rst b/Documentation/networking/device_drivers/wwan/iosm.rst
index 6f9e955af984..d28a922391ce 100644
--- a/Documentation/networking/device_drivers/wwan/iosm.rst
+++ b/Documentation/networking/device_drivers/wwan/iosm.rst
@@ -84,7 +84,7 @@ session 1.
References
==========
[1] "MBIM (Mobile Broadband Interface Model) Errata-1"
- - https://www.usb.org/document-library/
+ - http://usb.org/document-library/mobile-broadband-interface-model-v10-errata-1-and-adopters-agreement
[2] libmbim - "a glib-based library for talking to WWAN modems and
devices which speak the Mobile Interface Broadband Model (MBIM)
diff --git a/Documentation/networking/device_drivers/wwan/t7xx.rst b/Documentation/networking/device_drivers/wwan/t7xx.rst
index e07de7700dfc..fd532a7e225a 100644
--- a/Documentation/networking/device_drivers/wwan/t7xx.rst
+++ b/Documentation/networking/device_drivers/wwan/t7xx.rst
@@ -187,7 +187,7 @@ References
==========
[1] *MBIM (Mobile Broadband Interface Model) Errata-1*
-- https://www.usb.org/document-library/
+- http://usb.org/document-library/mobile-broadband-interface-model-v10-errata-1-and-adopters-agreement
[2] *libmbim "a glib-based library for talking to WWAN modems and devices which
speak the Mobile Interface Broadband Model (MBIM) protocol"*
--
2.48.1
^ permalink raw reply related
* [sailus-media-tree:partial-reg 9/9] htmldocs: Warning: Documentation/userspace-api/media/mediactl/media-ioc-dqevent.rst references a file that doesn't exist: Documentation/media/uapi/fdl-appendix.rst
From: kernel test robot @ 2026-06-05 8:48 UTC (permalink / raw)
To: Sakari Ailus; +Cc: oe-kbuild-all, linux-media, linux-doc
tree: git://linuxtv.org/sailus/media_tree.git partial-reg
head: b7d01dab7d47849d483b459ff2abf50497b52149
commit: b7d01dab7d47849d483b459ff2abf50497b52149 [9/9] Documentation: media: Add Media controller event documentation
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project f43d6834093b19baf79beda8c0337ab020ac5f17)
docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
reproduce: (https://download.01.org/0day-ci/archive/20260605/202606051009.SvtAY0cZ-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606051009.SvtAY0cZ-lkp@intel.com/
All warnings (new ones prefixed by >>):
Warning: Documentation/translations/zh_CN/filesystems/gfs2-uevents.rst references a file that doesn't exist: Documentation/filesystems/gfs2-uevents.rst
Warning: Documentation/translations/zh_CN/filesystems/gfs2.rst references a file that doesn't exist: Documentation/filesystems/gfs2.rst
Warning: Documentation/translations/zh_CN/how-to.rst references a file that doesn't exist: Documentation/xxx/xxx.rst
Warning: Documentation/translations/zh_CN/networking/xfrm_proc.rst references a file that doesn't exist: Documentation/networking/xfrm_proc.rst
Warning: Documentation/translations/zh_CN/scsi/scsi_mid_low_api.rst references a file that doesn't exist: Documentation/Configure.help
>> Warning: Documentation/userspace-api/media/mediactl/media-ioc-dqevent.rst references a file that doesn't exist: Documentation/media/uapi/fdl-appendix.rst
>> Warning: Documentation/userspace-api/media/mediactl/media-ioc-subscribe-event.rst references a file that doesn't exist: Documentation/media/uapi/fdl-appendix.rst
Warning: MAINTAINERS references a file that doesn't exist: Documentation/ABI/testing/sysfs-platform-ayaneo
Warning: MAINTAINERS references a file that doesn't exist: Documentation/devicetree/bindings/display/bridge/megachips-stdpxxxx-ge-b850v3-fw.txt
Warning: arch/powerpc/sysdev/mpic.c references a file that doesn't exist: Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
Warning: drivers/net/ethernet/smsc/Kconfig references a file that doesn't exist: file:Documentation/networking/device_drivers/ethernet/smsc/smc9.rst
Warning: rust/kernel/sync/atomic/ordering.rs references a file that doesn't exist: srctree/tools/memory-model/Documentation/explanation.txt
--
c:type:`MC.media_v2_entity` (from userspace-api/media/mediactl/media-ioc-g-topology)
c:enum:`media_entity_type` (from driver-api/media/mc-core)
c:struct:`media_entity_enum` (from driver-api/media/mc-core) [ref.missing]
include/uapi/linux/media.h:390: WARNING: Invalid xref: c:type:`MC.media_event_subscription`. Possible alternatives:
c:type:`media_event_subscription` (from userspace-api/media/mediactl/media-ioc-subscribe-event) [ref.missing]
>> Documentation/userspace-api/media/mediactl/media-ioc-subscribe-event.rst:76: WARNING: undefined label: 'media_subscribe_event' [ref.ref]
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v7 20/42] KVM: SEV: Make 'uaddr' parameter optional for KVM_SEV_SNP_LAUNCH_UPDATE
From: Suzuki K Poulose @ 2026-06-05 8:54 UTC (permalink / raw)
To: Ackerley Tng, aik, andrew.jones, binbin.wu, brauner, chao.p.peng,
david, ira.weiny, jmattson, jthoughton, michael.roth, oupton,
pankaj.gupta, qperret, rick.p.edgecombe, rientjes, shivankg,
steven.price, tabba, willy, wyihan, yan.y.zhao, forkloop,
pratyush, aneesh.kumar, liam, Paolo Bonzini, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Jonathan Corbet, Shuah Khan, Shuah Khan,
Vishal Annapurve, Andrew Morton, Chris Li, Kairui Song,
Kemeng Shi, Nhat Pham, Baoquan He, Barry Song, Axel Rasmussen,
Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng, Shakeel Butt,
Kiryl Shutsemau, Jason Gunthorpe, Vlastimil Babka
Cc: kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <CAEvNRgF43RBv77RgM67kXRRHDnQw4L5uwQTuvkJHzkHJWB1mag@mail.gmail.com>
On 04/06/2026 20:05, Ackerley Tng wrote:
> Suzuki K Poulose <suzuki.poulose@arm.com> writes:
>
>>
>> [...snip...]
>>
>>> +In the case where ``type`` is KVM_SEV_SNP_PAGE_TYPE_ZERO, ``uaddr`` will be
>>> +ignored completely. Otherwise, ``uaddr`` is required if
>>> +kvm.vm_memory_attributes=1 and optional if kvm.vm_memory_attributes=0, since
>>> +in the latter case guest memory can be initialized directly from userspace
>>> +prior to converting it to private and passing the GPA range on to this
>>> +interface.
>>
>> Just to confirm, so the sev_gmem_prepare doesn't destroy the contents in
>> the process of making it "private" ? i.e., the contents of a SNP shared
>> page are preserved while transitioning to "SNP Private" (via RMP
>> update).
>>
>> Suzuki
>>
>
> The following is the guest_memfd perspective, I didn't look at the SNP
> spec:
>
> Do you mean specifically for KVM_SEV_SNP_PAGE_TYPE_ZERO, or for any
> type?
>
> guest_memfd has no plans to do any special zeroing based on type.
>
> guest_memfd decoupled zeroing from preparation a while ago (Michael had
> some patches), so zeroing is supposed to be once during folio ownership
> by guest_memfd, tracked by the uptodate flag, and preparation is tracked
> outside of guest_memfd. So far only SNP does preparation.
I am talking about the SEV SNP conversions (specifically quoted in my
response), I will follow up on Michael's response.
Suzuki
^ permalink raw reply
* Re: [PATCH mm-unstable v18 06/14] mm/khugepaged: generalize collapse_huge_page for mTHP collapse
From: Lance Yang @ 2026-06-05 8:59 UTC (permalink / raw)
To: ljs, david, npache
Cc: lance.yang, linux-doc, linux-kernel, linux-mm, linux-trace-kernel,
aarcange, akpm, anshuman.khandual, apopple, baohua, baolin.wang,
byungchul, catalin.marinas, cl, corbet, dave.hansen, dev.jain,
gourry, hannes, hughd, jack, jackmanb, jannh, jglisse,
joshua.hahnjy, kas, liam, mathieu.desnoyers, matthew.brost,
mhiramat, mhocko, peterx, pfalcato, rakie.kim, raquini, rdunlap,
richard.weiyang, rientjes, rostedt, rppt, ryan.roberts, shivankg,
sunnanyong, surenb, thomas.hellstrom, tiwai, usamaarif642, vbabka,
vishal.moola, wangkefeng.wang, will, willy, yang, ying.huang, ziy,
zokeefe, usama.arif
In-Reply-To: <aiJ90SWqXvwN9dNT@lucifer>
On Fri, Jun 05, 2026 at 09:07:23AM +0100, Lorenzo Stoakes wrote:
>On Fri, Jun 05, 2026 at 09:18:27AM +0200, David Hildenbrand (Arm) wrote:
>> On 6/4/26 19:04, Nico Pache wrote:
>> > On Mon, Jun 1, 2026 at 9:00 AM Nico Pache <npache@redhat.com> wrote:
>> >>
>> >> On Mon, Jun 1, 2026 at 5:14 AM David Hildenbrand (Arm) <david@kernel.org> wrote:
>> >>>
>> >>>
>> >>> Yeah. BTW, I think we'd need a spin_lock_nested(), so @Nico, treat my code as a
>> >>> draft.
>> >>
>> >> Okay, I read the above and did some investigating.
>> >>
>> >> I will try to implement and verify the changes you suggested :)
>> >
>> > I've implemented something slightly different actually and I *think* its better!
>> >
>> > } else {
>> > /* this is map_anon_folio_pte_nopf with no mmu update */
>> > __map_anon_folio_pte_nopf(folio, pte, vma, start_addr,
>> > /*uffd_wp=*/ false);
>> > smp_wmb();
>> > pmd_populate(mm, pmd, pmd_pgtable(_pmd));
>> > /*
>> > * Some architectures (e.g. MIPS) walk the live page table in
>> > * their implementation. update_mmu_cache_range() must be called
>> > * with a valid page table hierarchy and the PTE lock held.
>> > * Acquire it nested inside pmd_ptl when they are distinct locks.
>> > */
>> > if (pte_ptl != pmd_ptl)
>> > spin_lock_nested(pte_ptl, SINGLE_DEPTH_NESTING);
>> > update_mmu_cache_range(NULL, vma, start_addr, pte, nr_pages);
>> > if (pte_ptl != pmd_ptl)
>> > spin_unlock(pte_ptl);
>> > }
>> > spin_unlock(pmd_ptl);
>> >
>> > The logic here is that when the PMD becomes visible, PTEs are already
>> > populated (no possibility of spurious faults on local CPU)
>> >
>> > the SMP_WMB makes sure of the above
>
>THe locks prevent those 'spurious' (really: incorrect) faults anyway so I don't
>think this is necessary.
>
>> >
>> > And the pmd is installed with the pte and pmd lock both held through
>> > the mmu_cache update.
>> >
>> > This follows the conventions used in pmd_install() and clears the
>> > potential for local CPU faults hitting cleared PTE entries.
>>
>> After the pmdp_collapse_flush() we'd be getting CPU faults due to the cleared
>> PMD already? So the case here is rather different.
The issue I was worried about: update_mmu_cache_range() can re-walk
vma->vm_mm while the PTE page table is still not reachable through the
PMD. And, yeah, that assumption is ugly, but it is what it is, and there
maybe be similar code elsewhere ...
So the ordering we need is "the PMD points to the PTE page table from
_pmd before update_mmu_cache_range()", not "new PTEs before PMD".
Those PTEs are cleared, but we hold the PTL, so nobody else can install
anything there :)
So David's original suggestion looks enough to me:
if (pte_ptl != pmd_ptl)
spin_lock_nested(pte_ptl, SINGLE_DEPTH_NESTING);
pmd_populate();
map_anon_folio_pte_nopf();
if (pte_ptl != pmd_ptl)
spin_unlock(pte_ptl);
>Yeah conceptually the code above is problematic because you immediately make the
>PTE available right at the point you populate, so taking a PTE lock after that
>is rather shutting the stable door after the horse has bolted.
>
>Doing it this way is not a good idea in any case because we're adding
>complexity, an extra function and an open-coded cache maintenance call for
>really no benefit.
>
>I asked Nico to abstract the anon folio mapping stuff explicitly so we could
>avoid this sort of duplication so let's not roll that back :)
>
>So again, I think going with the original suggestion (with an updated comment)
>is the right thing to do.
>
>
>Anyway, an aside But in practice we can't have page faults here right? The VMA is:
>
>- Ensured to span at least the PMD range (this isn't immediately obvious in the
> code)
>- VMA write locked (mmap write lock held)
>
>And we hold the anon_vma lock so no rmap walkers can walk the page tables here
>either.
>
>So I actually wonder, given that, whether we need the PTE PTL at all.
I'd keep it. Cheap, and lets us sleep better at night :P
>But.
>
>At this stage it'll almost certainly be an owned exclusive cache line so it's
>very low cost to do it, and it means we honour the update_mmu_cache_range()
>contract.
>
>And it also makes it clear that we're gating changes on the PTE being
>untouchable so any future stuff that maybe changes some of these rules doesn't
>get caught out.
>
>So probably worth keeping.
Yes!
Cheers, Lance
>>
>> --
>> Cheers,
>>
>> David
>
>Thanks, Lorenzo
>
^ permalink raw reply
* Re: [PATCH v7 20/42] KVM: SEV: Make 'uaddr' parameter optional for KVM_SEV_SNP_LAUNCH_UPDATE
From: Suzuki K Poulose @ 2026-06-05 9:06 UTC (permalink / raw)
To: Michael Roth
Cc: ackerleytng, aik, andrew.jones, binbin.wu, brauner, chao.p.peng,
david, ira.weiny, jmattson, jthoughton, oupton, pankaj.gupta,
qperret, rick.p.edgecombe, rientjes, shivankg, steven.price,
tabba, willy, wyihan, yan.y.zhao, forkloop, pratyush,
aneesh.kumar, liam, Paolo Bonzini, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Jonathan Corbet, Shuah Khan, Shuah Khan,
Vishal Annapurve, Andrew Morton, Chris Li, Kairui Song,
Kemeng Shi, Nhat Pham, Baoquan He, Barry Song, Axel Rasmussen,
Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng, Shakeel Butt,
Kiryl Shutsemau, Jason Gunthorpe, Vlastimil Babka, kvm,
linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <4muegrza5iyyhqx6wevdlssnb6wvlc4m4wmuz5hmd3xikkftc4@3e2lpuq6tjgr>
On 04/06/2026 21:11, Michael Roth wrote:
> On Thu, Jun 04, 2026 at 04:29:19PM +0100, Suzuki K Poulose wrote:
>> On 23/05/2026 01:18, Ackerley Tng via B4 Relay wrote:
>>> From: Michael Roth <michael.roth@amd.com>
>>>
>>> For vm_memory_attributes=1, in-place conversion/population is not
>>> supported, so the initial contents necessarily must need to come
>>> from a separate src address, which is enforced by the current
>>> implementation. However, for vm_memory_attributes=0, it is possible for
>>> guest memory to be initialized directly from userspace by mmap()'ing the
>>> guest_memfd and writing to it while the corresponding GPA ranges are in
>>> a 'shared' state before converting them to the 'private' state expected
>>> by KVM_SEV_SNP_LAUNCH_UPDATE.
>>>
>>> Update the handling/documentation for KVM_SEV_SNP_LAUNCH_UPDATE to allow
>>> for 'uaddr' to be set to NULL when vm_memory_attributes=0, which
>>> SNP_LAUNCH_UPDATE will then use to determine when it should/shouldn't
>>> copy in data from a separate memory location. Continue to enforce
>>> non-NULL for the original vm_memory_attributes=1 case.
>>>
>>> Signed-off-by: Michael Roth <michael.roth@amd.com>
>>> [Added src_page check in error handling path when the firmware command fails]
>>> [Dropped ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES]
>>> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
>>
>>
>>
>>
>>> ---
>>> Documentation/virt/kvm/x86/amd-memory-encryption.rst | 15 +++++++++++----
>>> arch/x86/kvm/svm/sev.c | 18 +++++++++++++-----
>>> virt/kvm/kvm_main.c | 1 +
>>> 3 files changed, 25 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/Documentation/virt/kvm/x86/amd-memory-encryption.rst b/Documentation/virt/kvm/x86/amd-memory-encryption.rst
>>> index b2395dd4769de..43085f65b2d85 100644
>>> --- a/Documentation/virt/kvm/x86/amd-memory-encryption.rst
>>> +++ b/Documentation/virt/kvm/x86/amd-memory-encryption.rst
>>> @@ -503,7 +503,8 @@ secrets.
>>> It is required that the GPA ranges initialized by this command have had the
>>> KVM_MEMORY_ATTRIBUTE_PRIVATE attribute set in advance. See the documentation
>>> -for KVM_SET_MEMORY_ATTRIBUTES for more details on this aspect.
>>> +for KVM_SET_MEMORY_ATTRIBUTES/KVM_SET_MEMORY_ATTRIBUTES2 for more details on
>>> +this aspect.
>>> Upon success, this command is not guaranteed to have processed the entire
>>> range requested. Instead, the ``gfn_start``, ``uaddr``, and ``len`` fields of
>>> @@ -511,9 +512,15 @@ range requested. Instead, the ``gfn_start``, ``uaddr``, and ``len`` fields of
>>> remaining range that has yet to be processed. The caller should continue
>>> calling this command until those fields indicate the entire range has been
>>> processed, e.g. ``len`` is 0, ``gfn_start`` is equal to the last GFN in the
>>> -range plus 1, and ``uaddr`` is the last byte of the userspace-provided source
>>> -buffer address plus 1. In the case where ``type`` is KVM_SEV_SNP_PAGE_TYPE_ZERO,
>>> -``uaddr`` will be ignored completely.
>>> +range plus 1, and ``uaddr`` (if specified) is the last byte of the
>>> +userspace-provided source buffer address plus 1.
>>> +
>>> +In the case where ``type`` is KVM_SEV_SNP_PAGE_TYPE_ZERO, ``uaddr`` will be
>>> +ignored completely. Otherwise, ``uaddr`` is required if
>>> +kvm.vm_memory_attributes=1 and optional if kvm.vm_memory_attributes=0, since
>>> +in the latter case guest memory can be initialized directly from userspace
>>> +prior to converting it to private and passing the GPA range on to this
>>> +interface.
>>
>> Just to confirm, so the sev_gmem_prepare doesn't destroy the contents in the
>> process of making it "private" ? i.e., the contents of a SNP shared
>> page are preserved while transitioning to "SNP Private" (via RMP
>> update).
>
> sev_gmem_prepare() does sort of destroy contents since it finalizes the
> shared->private conversion which puts the page in an unusable state
> until the guest 'accepts' it as private memory and re-initializes the
> contents.
>
> But that's run-time, when the guest is doing conversions. The
> documentation here is relating to initialization time when we are
> setting up the initial pre-encrypted/pre-measured guest memory image,
> via SNP_LAUNCH_UPDATE. That path calls into kvm_gmem_populate(), and it
> is then sev_gmem_post_populate() callback that actually finalizes the
> shared->private conversion. The sev_gmem_prepare() hook doesn't get used
> in this flow (kvm_gmem_populate() calls __kvm_gmem_get_pfn() which skips
> preparation).
Thanks, thats the bit I was missing. Skipping the prepare path, with
__kvm_gmem_get_pfn(). I was under the assumption that
kvm_arch_gmem_prepare() was called for all PFNs allocated from gmem
and how SNP was handling this populate case.
Thanks
Suzuki
>
> -Mike
>
>>
>> Suzuki
>>
>>
^ permalink raw reply
* [PATCH net-next v2 00/15] mptcp: pm: drop TCP TS with ADD_ADDRv6 + port
From: Matthieu Baerts (NGI0) @ 2026-06-05 9:21 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: netdev, mptcp, linux-kernel, Matthieu Baerts (NGI0),
Jonathan Corbet, Shuah Khan, linux-doc, linux-kselftest,
Neal Cardwell, Kuniyuki Iwashima, Shuah Khan
Up to this series, it was possible to add a "signal" MPTCP endpoint with
an IPv6 address and a port, or to directly request to send an ADD_ADDR
with a v6 address and a port, but the expected ADD_ADDR wasn't sent when
TCP timestamps was used for the connection.
In fact, such signalling option cannot be sent when TCP timestamps is
used due to a lack of option space: the limit is at 40 bytes, and, with
padding, TCP timestamps is taking 12 bytes, while an ADD_ADDR IPv6 +
port is taking 30 bytes. The selected solution here is to simply drop
the TCP timestamps option when such ADD_ADDR of 30 bytes needs to be
sent.
- Patches 1-3: small cleanups to avoid computing ADD/RM_ADDR twice.
- Patches 4-7: the new feature, controlled by a new sysctl knob.
- Patch 8: extra checks in the MPTCP Join selftests.
- Patches 9-15: A bunch of refactoring: renamed confusing helpers and
variables, and prevent future misused functions.
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Changes in v2:
- Rebased: some diff caused by commit a02a765bd5c2 ("mptcp: change
mptcp_established_options() to return opt_size") and commit
bd34fa025726 ("mptcp: add-addr: always drop other suboptions")
- Patch 4: Use READ_ONCE() to read sysctl data. (Eric)
- Patches 5-6: Avoid passing local variables' addresses to
mptcp_established_options not to force the compiler to use a stack
canary in this hot function, even for non-MPTCP flows. (Eric)
- Replaced previous patches 9-11 modifying selftests by a bunch of
pm related refactoring: patches 9-15.
- Link to v1: https://patch.msgid.link/20260601-net-next-mptcp-add-addr6-port-ts-v1-0-4fc25dfef62e@kernel.org
---
Matthieu Baerts (NGI0) (15):
mptcp: options: suboptions sizes can be negative
mptcp: pm: avoid computing rm_addr size twice
mptcp: pm: avoid computing add_addr size twice
mptcp: introduce add_addr_v6_port_drop_ts sysctl knob
tcp: allow mptcp to drop TS for some packets
mptcp: pm: drop TCP TS with ADD_ADDRv6 + port
selftests: mptcp: validate ADD_ADDRv6 + TS + port
selftests: mptcp: always check sent/dropped ADD_ADDRs
mptcp: pm: use for_each_subflow helper
mptcp: pm: rename add_entry structure to add_addr
mptcp: pm: uniform announced addresses helpers
mptcp: pm: remove add_ prefix from timer
mptcp: pm: make mptcp_pm_add_addr_send_ack static
mptcp: pm: avoid using del_timer directly
mptcp: options: rst: drop unused skb parameter
Documentation/networking/mptcp-sysctl.rst | 13 ++
include/net/mptcp.h | 13 +-
net/ipv4/tcp_output.c | 10 +-
net/mptcp/ctrl.c | 18 ++-
net/mptcp/options.c | 68 +++------
net/mptcp/pm.c | 191 ++++++++++++++----------
net/mptcp/pm_kernel.c | 22 +--
net/mptcp/pm_userspace.c | 6 +-
net/mptcp/protocol.h | 48 ++----
net/mptcp/subflow.c | 4 +-
tools/testing/selftests/net/mptcp/mptcp_join.sh | 83 +++++-----
11 files changed, 248 insertions(+), 228 deletions(-)
---
base-commit: bfa3d89cc15c09f7d1581c834a5ed725189ec19f
change-id: 20260601-net-next-mptcp-add-addr6-port-ts-40d8d74d8e20
Best regards,
--
Matthieu Baerts (NGI0) <matttbe@kernel.org>
^ permalink raw reply
* [PATCH net-next v2 04/15] mptcp: introduce add_addr_v6_port_drop_ts sysctl knob
From: Matthieu Baerts (NGI0) @ 2026-06-05 9:21 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: netdev, mptcp, linux-kernel, Matthieu Baerts (NGI0),
Jonathan Corbet, Shuah Khan, linux-doc, linux-kselftest
In-Reply-To: <20260605-net-next-mptcp-add-addr6-port-ts-v2-0-758e7ca73f4d@kernel.org>
This sysctl is going to be used in the next commits to drop TCP
timestamps option, to be able to send an ADD_ADDR with a v6 IP address
and a port number. It is enabled by default.
This knob is explicitly disabled in the MPTCP Join selftest, with the
"signal addr list progresses after tx drop" subtest, to continue
verifying the previous behaviour where the ADD_ADDR is not sent due to a
lack of space.
While at it, move syn_retrans_before_tcp_fallback down from struct
mptcp_pernet, to avoid creating another 3 bytes hole.
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
- v2: Use READ_ONCE() to read sysctl data. (Eric Dumazet)
To: Jonathan Corbet <corbet@lwn.net>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: linux-doc@vger.kernel.org
Cc: linux-kselftest@vger.kernel.org
---
Documentation/networking/mptcp-sysctl.rst | 13 +++++++++++++
net/mptcp/ctrl.c | 18 +++++++++++++++++-
net/mptcp/protocol.h | 1 +
tools/testing/selftests/net/mptcp/mptcp_join.sh | 1 +
4 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/Documentation/networking/mptcp-sysctl.rst b/Documentation/networking/mptcp-sysctl.rst
index 1eb6af26b4a7..b9b5f58e0625 100644
--- a/Documentation/networking/mptcp-sysctl.rst
+++ b/Documentation/networking/mptcp-sysctl.rst
@@ -21,6 +21,19 @@ add_addr_timeout - INTEGER (seconds)
Default: 120
+add_addr_v6_port_drop_ts - BOOLEAN
+ Control whether preparing an ADD_ADDR with an IPv6 address and a port
+ should drop the TCP timestamps option to have enough option space to
+ send the signal.
+
+ If there is not enough option space, and the TCP timestamps option
+ cannot be dropped, the signal cannot be sent. Note that dropping the TCP
+ timestamps option for one packet of the connection could disrupt some
+ middleboxes: even if it should be unlikely, they could drop the packet
+ or block the connection. This is a per-namespace sysctl.
+
+ Default: 1 (enabled)
+
allow_join_initial_addr_port - BOOLEAN
Allow peers to send join requests to the IP address and port number used
by the initial subflow if the value is 1. This controls a flag that is
diff --git a/net/mptcp/ctrl.c b/net/mptcp/ctrl.c
index d96130e49942..63c5747f0f63 100644
--- a/net/mptcp/ctrl.c
+++ b/net/mptcp/ctrl.c
@@ -32,12 +32,13 @@ struct mptcp_pernet {
unsigned int close_timeout;
unsigned int stale_loss_cnt;
atomic_t active_disable_times;
- u8 syn_retrans_before_tcp_fallback;
unsigned long active_disable_stamp;
+ u8 syn_retrans_before_tcp_fallback;
u8 mptcp_enabled;
u8 checksum_enabled;
u8 allow_join_initial_addr_port;
u8 pm_type;
+ u8 add_addr_v6_port_drop_ts;
char scheduler[MPTCP_SCHED_NAME_MAX];
char path_manager[MPTCP_PM_NAME_MAX];
};
@@ -94,6 +95,11 @@ const char *mptcp_get_scheduler(const struct net *net)
return mptcp_get_pernet(net)->scheduler;
}
+unsigned int mptcp_add_addr_v6_port_drop_ts(const struct net *net)
+{
+ return READ_ONCE(mptcp_get_pernet(net)->add_addr_v6_port_drop_ts);
+}
+
static void mptcp_pernet_set_defaults(struct mptcp_pernet *pernet)
{
pernet->mptcp_enabled = 1;
@@ -108,6 +114,7 @@ static void mptcp_pernet_set_defaults(struct mptcp_pernet *pernet)
pernet->pm_type = MPTCP_PM_TYPE_KERNEL;
strscpy(pernet->scheduler, "default", sizeof(pernet->scheduler));
strscpy(pernet->path_manager, "kernel", sizeof(pernet->path_manager));
+ pernet->add_addr_v6_port_drop_ts = 1;
}
#ifdef CONFIG_SYSCTL
@@ -362,6 +369,14 @@ static struct ctl_table mptcp_sysctl_table[] = {
.mode = 0444,
.proc_handler = proc_available_path_managers,
},
+ {
+ .procname = "add_addr_v6_port_drop_ts",
+ .maxlen = sizeof(u8),
+ .mode = 0644,
+ .proc_handler = proc_dou8vec_minmax,
+ .extra1 = SYSCTL_ZERO,
+ .extra2 = SYSCTL_ONE
+ },
};
static int mptcp_pernet_new_table(struct net *net, struct mptcp_pernet *pernet)
@@ -389,6 +404,7 @@ static int mptcp_pernet_new_table(struct net *net, struct mptcp_pernet *pernet)
table[10].data = &pernet->syn_retrans_before_tcp_fallback;
table[11].data = &pernet->path_manager;
/* table[12] is for available_path_managers which is read-only info */
+ table[13].data = &pernet->add_addr_v6_port_drop_ts;
hdr = register_net_sysctl_sz(net, MPTCP_SYSCTL_PATH, table,
ARRAY_SIZE(mptcp_sysctl_table));
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index 4dfea209ac16..b43dae72e7de 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -798,6 +798,7 @@ unsigned int mptcp_close_timeout(const struct sock *sk);
int mptcp_get_pm_type(const struct net *net);
const char *mptcp_get_path_manager(const struct net *net);
const char *mptcp_get_scheduler(const struct net *net);
+unsigned int mptcp_add_addr_v6_port_drop_ts(const struct net *net);
void mptcp_active_disable(struct sock *sk);
bool mptcp_active_should_disable(struct sock *ssk);
diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh
index ac8dc7051aae..70d5b26be4e0 100755
--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
+++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
@@ -3313,6 +3313,7 @@ add_addr_ports_tests()
if reset "signal addr list progresses after tx drop"; then
pm_nl_set_limits $ns1 0 2
pm_nl_set_limits $ns2 1 0
+ ip netns exec $ns1 sysctl -q net.mptcp.add_addr_v6_port_drop_ts=0 2>/dev/null || true
ip netns exec $ns1 sysctl -q net.ipv4.tcp_timestamps=1
ip netns exec $ns2 sysctl -q net.ipv4.tcp_timestamps=1
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v1] arm64: errata: Workaround NVIDIA Olympus device store/load ordering erratum
From: Vladimir Murzin @ 2026-06-05 9:26 UTC (permalink / raw)
To: Shanker Donthineni, Catalin Marinas, Will Deacon,
linux-arm-kernel
Cc: Mark Rutland, linux-kernel, linux-doc, Vikram Sethi,
Jason Sequeira
In-Reply-To: <20260604231254.1904988-1-sdonthineni@nvidia.com>
On 6/5/26 00:12, Shanker Donthineni wrote:
> On systems with NVIDIA Olympus cores, a Device-nGnR* load can be
> observed by a peripheral before an older, non-overlapping Device-nGnR*
> store to the same peripheral. This breaks the program-order guarantee
> that software expects for Device-nGnR* accesses and can leave a
> peripheral in an incorrect state, as a load is observed before an
> earlier store takes effect.
>
> The erratum can occur only when all of the following apply:
>
> - A PE executes a Device-nGnR* store followed by a younger
> Device-nGnR* load.
> - The store is not a store-release.
> - The accesses target the same peripheral and do not overlap in bytes.
> - There is at most one intervening Device-nGnR* store in program
> order, and there are no intervening Device-nGnR* loads.
> - There is no DSB, and no DMB that orders loads, between the store and
> the load.
> - Specific micro-architectural and timing conditions occur.
>
> Two ways to restore ordering: insert a barrier (any DSB, or a DMB that
> orders loads) between the store and the load, or make the store a
> store-release. A load-acquire on the load side would not help, because
> acquire semantics do not prevent a load from being observed ahead of an
> older store; only the store side (release or a barrier) closes the
> window.
>
> Promote the raw MMIO store helpers (__raw_writeb/w/l/q) from plain str*
> to stlr* (Store-Release), which removes the "store is not a
> store-release" condition for every device write the kernel issues.
> Because writel() and writel_relaxed() are both built on __raw_writel()
> in asm-generic/io.h, patching the raw variants covers both the
> non-relaxed and relaxed APIs without touching the higher layers. Note
> that writel()'s own barrier sits before the store, so it does not order
> the store against a subsequent readl(); the store-release promotion is
> what provides that ordering.
>
> Like ARM64_ERRATUM_832075 on the load side, the change is gated on a new
> ARM64_WORKAROUND_DEVICE_STORE_RELEASE capability and only activated on
> parts that match MIDR_NVIDIA_OLYMPUS, so unaffected CPUs continue to use
> the plain str* sequence.
>
> Co-developed-by: Vikram Sethi <vsethi@nvidia.com>
> Signed-off-by: Vikram Sethi <vsethi@nvidia.com>
> Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com>
> ---
> Documentation/arch/arm64/silicon-errata.rst | 2 ++
> arch/arm64/Kconfig | 23 ++++++++++++++++++++
> arch/arm64/include/asm/io.h | 24 ++++++++++++++-------
> arch/arm64/kernel/cpu_errata.c | 8 +++++++
> arch/arm64/tools/cpucaps | 1 +
> 5 files changed, 50 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
> index 211119ce7adc..899bed3908bb 100644
> --- a/Documentation/arch/arm64/silicon-errata.rst
> +++ b/Documentation/arch/arm64/silicon-errata.rst
> @@ -256,6 +256,8 @@ stable kernels.
> +----------------+-----------------+-----------------+-----------------------------+
> | NVIDIA | Carmel Core | N/A | NVIDIA_CARMEL_CNP_ERRATUM |
> +----------------+-----------------+-----------------+-----------------------------+
> +| NVIDIA | Olympus core | T410-OLY-1027 | NVIDIA_OLYMPUS_1027_ERRATUM |
> ++----------------+-----------------+-----------------+-----------------------------+
> | NVIDIA | T241 GICv3/4.x | T241-FABRIC-4 | N/A |
> +----------------+-----------------+-----------------+-----------------------------+
> | NVIDIA | T241 MPAM | T241-MPAM-1 | N/A |
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index fe60738e5943..a6bac84b05a1 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -564,6 +564,29 @@ config ARM64_ERRATUM_832075
>
> If unsure, say Y.
>
> +config NVIDIA_OLYMPUS_1027_ERRATUM
> + bool "NVIDIA Olympus: device store/load ordering erratum"
> + default y
> + help
> + This option adds an alternative code sequence to work around an
> + NVIDIA Olympus core erratum where a Device-nGnR* store can be
> + observed by a peripheral after a younger Device-nGnR* load to the
> + same peripheral. This breaks the program order that drivers rely
> + on for MMIO and can leave a device in an incorrect state.
> +
> + The workaround promotes the raw MMIO store helpers
> + (__raw_writeb/w/l/q) to Store-Release (STLR), which restores the
> + required ordering. Because writel() and writel_relaxed() are built
> + on __raw_writel(), both are covered without changes to the higher
> + layers.
> +
> + The fix is applied through the alternatives framework, so enabling
> + this option does not by itself activate the workaround: it is
> + patched in only when an affected CPU is detected, and is a no-op on
> + unaffected CPUs.
> +
> + If unsure, say Y.
> +
> config ARM64_ERRATUM_834220
> bool "Cortex-A57: 834220: Stage 2 translation fault might be incorrectly reported in presence of a Stage 1 fault (rare)"
> depends on KVM
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 8cbd1e96fd50..b6d7966e9c19 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -25,29 +25,37 @@
> #define __raw_writeb __raw_writeb
> static __always_inline void __raw_writeb(u8 val, volatile void __iomem *addr)
> {
> - volatile u8 __iomem *ptr = addr;
> - asm volatile("strb %w0, %1" : : "rZ" (val), "Qo" (*ptr));
> + asm volatile(ALTERNATIVE("strb %w0, [%1]",
> + "stlrb %w0, [%1]",
> + ARM64_WORKAROUND_DEVICE_STORE_RELEASE)
> + : : "rZ" (val), "r" (addr));
> }
>
Nitpick:
The change has the side effect of undoing d044d6ba6f02 ("arm64:
io: permit offset addressing"), since stlr* do not support
offset addressing. Unaffected CPUs would continue to use str*,
but would lose the benefit of offset addressing :(
Not sure if this needs to be mentioned in the commit message...
Cheers
Vladimir
> #define __raw_writew __raw_writew
> static __always_inline void __raw_writew(u16 val, volatile void __iomem *addr)
> {
> - volatile u16 __iomem *ptr = addr;
> - asm volatile("strh %w0, %1" : : "rZ" (val), "Qo" (*ptr));
> + asm volatile(ALTERNATIVE("strh %w0, [%1]",
> + "stlrh %w0, [%1]",
> + ARM64_WORKAROUND_DEVICE_STORE_RELEASE)
> + : : "rZ" (val), "r" (addr));
> }
>
> #define __raw_writel __raw_writel
> static __always_inline void __raw_writel(u32 val, volatile void __iomem *addr)
> {
> - volatile u32 __iomem *ptr = addr;
> - asm volatile("str %w0, %1" : : "rZ" (val), "Qo" (*ptr));
> + asm volatile(ALTERNATIVE("str %w0, [%1]",
> + "stlr %w0, [%1]",
> + ARM64_WORKAROUND_DEVICE_STORE_RELEASE)
> + : : "rZ" (val), "r" (addr));
> }
>
> #define __raw_writeq __raw_writeq
> static __always_inline void __raw_writeq(u64 val, volatile void __iomem *addr)
> {
> - volatile u64 __iomem *ptr = addr;
> - asm volatile("str %x0, %1" : : "rZ" (val), "Qo" (*ptr));
> + asm volatile(ALTERNATIVE("str %x0, [%1]",
> + "stlr %x0, [%1]",
> + ARM64_WORKAROUND_DEVICE_STORE_RELEASE)
> + : : "rZ" (val), "r" (addr));
> }
>
> #define __raw_readb __raw_readb
> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> index 5377e4c2eba2..958d7f16bfeb 100644
> --- a/arch/arm64/kernel/cpu_errata.c
> +++ b/arch/arm64/kernel/cpu_errata.c
> @@ -809,6 +809,14 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
> ERRATA_MIDR_ALL_VERSIONS(MIDR_NVIDIA_CARMEL),
> },
> #endif
> +#ifdef CONFIG_NVIDIA_OLYMPUS_1027_ERRATUM
> + {
> + /* NVIDIA Olympus core */
> + .desc = "NVIDIA Olympus device load/store ordering erratum",
> + .capability = ARM64_WORKAROUND_DEVICE_STORE_RELEASE,
> + ERRATA_MIDR_ALL_VERSIONS(MIDR_NVIDIA_OLYMPUS),
> + },
> +#endif
> #ifdef CONFIG_ARM64_WORKAROUND_TRBE_OVERWRITE_FILL_MODE
> {
> /*
> diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
> index 811c2479e82d..d367257bf770 100644
> --- a/arch/arm64/tools/cpucaps
> +++ b/arch/arm64/tools/cpucaps
> @@ -120,6 +120,7 @@ WORKAROUND_CAVIUM_TX2_219_PRFM
> WORKAROUND_CAVIUM_TX2_219_TVM
> WORKAROUND_CLEAN_CACHE
> WORKAROUND_DEVICE_LOAD_ACQUIRE
> +WORKAROUND_DEVICE_STORE_RELEASE
> WORKAROUND_NVIDIA_CARMEL_CNP
> WORKAROUND_PMUV3_IMPDEF_TRAPS
> WORKAROUND_QCOM_FALKOR_E1003
> -- 2.43.0
>
^ permalink raw reply
* Re: [PATCH v8 2/6] mm/memory-failure: surface unhandlable kernel pages as -ENOTRECOVERABLE
From: Breno Leitao @ 2026-06-05 9:35 UTC (permalink / raw)
To: Miaohe Lin
Cc: David Hildenbrand (Arm), linux-mm, linux-kernel, linux-doc,
linux-kselftest, linux-trace-kernel, kernel-team, Lance Yang,
Andrew Morton, Lorenzo Stoakes, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Shuah Khan, Naoya Horiguchi,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Jonathan Corbet, Shuah Khan, Liam R. Howlett
In-Reply-To: <4b27467e-935f-5587-2f48-5a794c30a592@huawei.com>
On Wed, Jun 03, 2026 at 10:33:04AM +0800, Miaohe Lin wrote:
> On 2026/6/2 17:41, David Hildenbrand (Arm) wrote:
> > On 6/2/26 05:08, Miaohe Lin wrote:
> >> On 2026/6/1 21:22, David Hildenbrand (Arm) wrote:
> >>> On 6/1/26 14:28, Miaohe Lin wrote:
> >>>>
> >>>> Thanks for your patch.
> >>>>
> >>>>
> >>>> Once shake_page finds a lightweight range-based way to shrink slab, slab pages could be freed
> >>>> into buddy and above PageSlab test should be removed then. Maybe add a TODO or XXX here?
> >>>>
> >>>>
> >>>> I'm not sure but is it safe or a common way to test PageReserved, PageSlab,
> >>>> PageTable and PageLargeKmalloc without extra page refcnt?
> >>>
> >>> Checking typed pages in a racy fashion is fine (PageSlab, PageTable,
> >>> PageLargeKmalloc).
> >>
> >> Got it. Thanks.
> >>
> >>> Checking PageReserved in a racy fashion is fine as well. TESTPAGEFLAG() will
> >>> allow checking it on compound pages.
> >>
> >> It seems PageReserved is not intended to be set on compound pages. I see there are PF_NO_COMPOUND
> >> in its definition: PAGEFLAG(Reserved, reserved, PF_NO_COMPOUND).
> >>
> >>>
> >>> For PageLargeKmalloc, we would want to check the head page, though. The page
> >>> type is only stored for the head page.
> >>
> >> Maybe we should check the head page for PageSlab and PageTable too? alloc_slab_page only
> >> set PageSlab on the head page and __pagetable_ctor uses __folio_set_pgtable to set PageTable
> >> on folio.
> >>
> >>>
> >>> So maybe we want to lookup the compound head (if any) and perform the type
> >>> checks against that?
> >>
> >> Maybe we should or we might miss some pages that could have been handled. And
> >> if compound head is required, should we hold an extra page refcnt to guard against
> >> possible folio split race?
> >
> > Races are fine. We might miss some pages, but that can happen on races either way.
> >
> >
> > I'd just do something like
> >
> > if (PageReserved(page))
> > return true;
> >
> > head = compound_head(page);
>
> If @head is split just after compound_head. And then @head is freed into buddy and re-allocated as slab
> page while @page is still in the buddy. We would panic on this scene as @head is PageSlab. But we were
> supposed to successfully handle @page. Or am I miss something?
You're right that it is racy, but I think it is an acceptable race here.
For it to happen, the poisoned @page has to be a tail of a live compound page
at the time of the fault, and then -- in the few instructions between
compound_head() and the PageSlab(head) test -- that compound page has to be
split, the old head freed to buddy, and that head re-allocated as a slab page,
all while @page lands back in the buddy. It cannot happen without concurrent
split/free/alloc activity in that exact window.
It is also worth noting the page in question genuinely took a unrecoverable ECC
error, and panic_on_unrecoverable_memory_failure is opt-in -- an operator who
enables it has explicitly chosen to crash rather than risk running on corrupted
memory. Mis-attributing one such rare, genuinely-poisoned page as
unrecoverable is within that contract.
Thanks for the review and discussions,
--breno
^ permalink raw reply
* Re: [PATCH v8 4/6] mm/memory-failure: add panic option for unrecoverable pages
From: Breno Leitao @ 2026-06-05 9:37 UTC (permalink / raw)
To: Miaohe Lin
Cc: linux-mm, linux-kernel, linux-doc, linux-kselftest,
linux-trace-kernel, kernel-team, Andrew Morton, David Hildenbrand,
Lorenzo Stoakes, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Shuah Khan, Naoya Horiguchi,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Jonathan Corbet, Shuah Khan, Liam R. Howlett
In-Reply-To: <4d7b720a-7975-8a4d-a00e-e888d63812a0@huawei.com>
On Tue, Jun 02, 2026 at 03:05:32PM +0800, Miaohe Lin wrote:
> On 2026/5/27 22:06, Breno Leitao wrote:
> > Add a sysctl panic_on_unrecoverable_memory_failure (disabled by
> > default) that triggers a kernel panic when memory_failure()
> > encounters pages that cannot be recovered. This provides a clean
> > crash with useful debug information rather than allowing silent
> > data corruption or a delayed crash at an unrelated code path.
> >
> > Panic eligibility is intentionally narrow: only MF_MSG_KERNEL with
> > result == MF_IGNORED panics. After the previous patch, MF_MSG_KERNEL
> > covers PG_reserved pages and the kernel-owned pages promoted from
> > get_hwpoison_page() via -ENOTRECOVERABLE (slab, page tables,
> > large-kmalloc).
> >
> > All other action types are excluded:
> >
> > - MF_MSG_GET_HWPOISON and MF_MSG_KERNEL_HIGH_ORDER can be reached by
> > transient refcount races with the page allocator (an in-flight buddy
> > allocation has refcount 0 and is no longer on the buddy free list,
> > briefly), and panicking on them would risk killing the box for what
> > is actually a recoverable userspace page.
> >
> > - MF_MSG_UNKNOWN means identify_page_state() could not classify the
> > page; that is precisely the wrong basis for a panic decision.
> >
> > Signed-off-by: Breno Leitao <leitao@debian.org>
> > ---
> > mm/memory-failure.c | 23 +++++++++++++++++++++++
> > 1 file changed, 23 insertions(+)
> >
> > diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> > index 14c0a958638c..dcd53dbc6aec 100644
> > --- a/mm/memory-failure.c
> > +++ b/mm/memory-failure.c
> > @@ -74,6 +74,8 @@ static int sysctl_memory_failure_recovery __read_mostly = 1;
> >
> > static int sysctl_enable_soft_offline __read_mostly = 1;
> >
> > +static int sysctl_panic_on_unrecoverable_mf __read_mostly;
> > +
> > atomic_long_t num_poisoned_pages __read_mostly = ATOMIC_LONG_INIT(0);
> >
> > static bool hw_memory_failure __read_mostly = false;
> > @@ -155,6 +157,15 @@ static const struct ctl_table memory_failure_table[] = {
> > .proc_handler = proc_dointvec_minmax,
> > .extra1 = SYSCTL_ZERO,
> > .extra2 = SYSCTL_ONE,
> > + },
> > + {
> > + .procname = "panic_on_unrecoverable_memory_failure",
> > + .data = &sysctl_panic_on_unrecoverable_mf,
> > + .maxlen = sizeof(sysctl_panic_on_unrecoverable_mf),
> > + .mode = 0644,
> > + .proc_handler = proc_dointvec_minmax,
> > + .extra1 = SYSCTL_ZERO,
> > + .extra2 = SYSCTL_ONE,
> > }
> > };
> >
> > @@ -1255,6 +1266,15 @@ static void update_per_node_mf_stats(unsigned long pfn,
> > ++mf_stats->total;
> > }
> >
> > +static bool panic_on_unrecoverable_mf(enum mf_action_page_type type,
> > + enum mf_result result)
> > +{
> > + if (!sysctl_panic_on_unrecoverable_mf || result != MF_IGNORED)
> > + return false;
> > +
> > + return type == MF_MSG_KERNEL;
>
> Would it be more straightforward to write as something like:
>
> if (!sysctl_panic_on_unrecoverable_mf)
> return false;
>
> return (type == MF_MSG_KERNEL && result == MF_IGNORED);
Sure, that reads better. I'll fold the MF_IGNORED check into the return for
the next revision.
static bool panic_on_unrecoverable_mf(enum mf_action_page_type type,
enum mf_result result)
{
if (!sysctl_panic_on_unrecoverable_mf)
return false;
return type == MF_MSG_KERNEL && result == MF_IGNORED;
}
^ permalink raw reply
* Re: [PATCH v8 2/6] mm/memory-failure: surface unhandlable kernel pages as -ENOTRECOVERABLE
From: David Hildenbrand (Arm) @ 2026-06-05 9:42 UTC (permalink / raw)
To: Breno Leitao, Miaohe Lin
Cc: linux-mm, linux-kernel, linux-doc, linux-kselftest,
linux-trace-kernel, kernel-team, Lance Yang, Andrew Morton,
Lorenzo Stoakes, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Shuah Khan, Naoya Horiguchi,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Jonathan Corbet, Shuah Khan, Liam R. Howlett
In-Reply-To: <aiKXrovzrNN-gExm@gmail.com>
On 6/5/26 11:35, Breno Leitao wrote:
> On Wed, Jun 03, 2026 at 10:33:04AM +0800, Miaohe Lin wrote:
>> On 2026/6/2 17:41, David Hildenbrand (Arm) wrote:
>>>
>>> Races are fine. We might miss some pages, but that can happen on races either way.
>>>
>>>
>>> I'd just do something like
>>>
>>> if (PageReserved(page))
>>> return true;
>>>
>>> head = compound_head(page);
>>
>> If @head is split just after compound_head. And then @head is freed into buddy and re-allocated as slab
>> page while @page is still in the buddy. We would panic on this scene as @head is PageSlab. But we were
>> supposed to successfully handle @page. Or am I miss something?
>
> You're right that it is racy, but I think it is an acceptable race here.
>
I mean, any such races can currently already happen one way or the other?
Really, the only way to not get races is to tryget the (compound)page,
revalidate that the page is still part of the compound page.
I'm not sure if that's really a good idea.
But my memory is a bit vague in which scenarios we already hold a page reference
here to prevent any concurrent freeing?
--
Cheers,
David
^ permalink raw reply
* [gourryinverse:scratch/gourry/managed_nodes/dax_base 4/9] htmldocs: Documentation/core-api/mm-api:131: ./mm/memory_hotplug.c:1657: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
From: kernel test robot @ 2026-06-05 10:20 UTC (permalink / raw)
To: Gregory Price; +Cc: oe-kbuild-all, linux-doc
Hi Gregory,
FYI, the error/warning was bisected to this commit, please ignore it if it's irrelevant.
tree: https://github.com/gourryinverse/linux scratch/gourry/managed_nodes/dax_base
head: 6d4daeccc0cecd3b478eb62b30d4e91f501447ed
commit: 8fc7484466b6a2fe5c68ced2feb37ab4bd22ed01 [4/9] mm/memory_hotplug: add __add_memory_driver_managed() with online_type arg
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project f43d6834093b19baf79beda8c0337ab020ac5f17)
docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
reproduce: (https://download.01.org/0day-ci/archive/20260605/202606051201.tRXGL6l7-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606051201.tRXGL6l7-lkp@intel.com/
All warnings (new ones prefixed by >>):
------------------------------------------------------------------------------------------------^
Documentation/core-api/kref:328: ./include/linux/kref.h:94: WARNING: Invalid C declaration: Expected end of definition. [error at 92]
int kref_put_lock (struct kref *kref, void (*release)(struct kref *kref), spinlock_t *lock) __cond_acquires(true# lock)
--------------------------------------------------------------------------------------------^
Documentation/core-api/mm-api:131: ./mm/memory_hotplug.c:1656: ERROR: Unexpected indentation. [docutils]
>> Documentation/core-api/mm-api:131: ./mm/memory_hotplug.c:1657: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
Documentation/driver-api/basics:42: ./kernel/time/time.c:370: WARNING: Duplicate C declaration, also defined at driver-api/basics:436.
Declaration is '.. c:function:: unsigned int jiffies_to_msecs (const unsigned long j)'. [duplicate_declaration.c]
Documentation/driver-api/basics:42: ./kernel/time/time.c:393: WARNING: Duplicate C declaration, also defined at driver-api/basics:453.
Declaration is '.. c:function:: unsigned int jiffies_to_usecs (const unsigned long j)'. [duplicate_declaration.c]
Documentation/driver-api/target:25: ./drivers/target/target_core_user.c:35: ERROR: Unexpected section title.
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH mm-unstable v18 11/14] mm/khugepaged: Introduce mTHP collapse support
From: Nico Pache @ 2026-06-05 11:07 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: linux-doc, linux-kernel, linux-mm, linux-trace-kernel, aarcange,
akpm, anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
catalin.marinas, cl, corbet, dave.hansen, david, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
lance.yang, liam, mathieu.desnoyers, matthew.brost, mhiramat,
mhocko, peterx, pfalcato, rakie.kim, raquini, rdunlap,
richard.weiyang, rientjes, rostedt, rppt, ryan.roberts, shivankg,
sunnanyong, surenb, thomas.hellstrom, tiwai, usamaarif642, vbabka,
vishal.moola, wangkefeng.wang, will, willy, yang, ying.huang, ziy,
zokeefe
In-Reply-To: <aiGOvIR9sfm91cvT@lucifer>
On Thu, Jun 4, 2026 at 8:45 AM Lorenzo Stoakes <ljs@kernel.org> wrote:
>
> On Fri, May 22, 2026 at 09:00:06AM -0600, Nico Pache wrote:
> > Enable khugepaged to collapse to mTHP orders. This patch implements the
> > main scanning logic using a bitmap to track occupied pages and a stack
> > structure that allows us to find optimal collapse sizes.
> >
> > Previous to this patch, PMD collapse had 3 main phases, a light weight
> > scanning phase (mmap_read_lock) that determines a potential PMD
> > collapse, an alloc phase (mmap unlocked), then finally heavier collapse
> > phase (mmap_write_lock).
> >
> > To enabled mTHP collapse we make the following changes:
> >
> > During PMD scan phase, track occupied pages in a bitmap. When mTHP
> > orders are enabled, we remove the restriction of max_ptes_none during the
> > scan phase to avoid missing potential mTHP collapse candidates. Once we
> > have scanned the full PMD range and updated the bitmap to track occupied
> > pages, we use the bitmap to find the optimal mTHP size.
> >
> > Implement collapse_scan_bitmap() to perform binary recursion on the bitmap
> > and determine the best eligible order for the collapse. A stack structure
> > is used instead of traditional recursion to manage the search. This also
> > prevents a traditional recursive approach when the kernel stack struct is
> > limited. The algorithm recursively splits the bitmap into smaller chunks to
> > find the highest order mTHPs that satisfy the collapse criteria. We start
> > by attempting the PMD order, then moved on the consecutively lower orders
> > (mTHP collapse). The stack maintains a pair of variables (offset, order),
> > indicating the number of PTEs from the start of the PMD, and the order of
> > the potential collapse candidate.
> >
> > The algorithm for consuming the bitmap works as such:
> > 1) push (0, HPAGE_PMD_ORDER) onto the stack
> > 2) pop the stack
> > 3) check if the number of set bits in that (offset,order) pair
> > statisfy the max_ptes_none threshold for that order
> > 4) if yes, attempt collapse
> > 5) if no (or collapse fails), push two new stack items representing
> > the left and right halves of the current bitmap range, at the
> > next lower order
> > 6) repeat at step (2) until stack is empty.
> >
> > Below is a diagram representing the algorithm and stack items:
> >
> > offset mid_offset
> > | |
> > | |
> > v v
> > ____________________________________
> > | PTE Page Table |
> > --------------------------------------
> > <-------><------->
> > order-1 order-1
> >
> > mTHP collapses reject regions containing swapped out or shared pages.
> > This is because adding new entries can lead to new none pages, and these
> > may lead to constant promotion into a higher order mTHP. A similar
> > issue can occur with "max_ptes_none > HPAGE_PMD_NR/2" due to a collapse
> > introducing at least 2x the number of pages, and on a future scan will
> > satisfy the promotion condition once again. This issue is prevented via
> > the collapse_max_ptes_none() function which imposes the max_ptes_none
> > restrictions above.
> >
> > We currently only support mTHP collapse for max_ptes_none values of 0
> > and HPAGE_PMD_NR - 1. resulting in the following behavior:
> >
> > - max_ptes_none=0: Never introduce new empty pages during collapse
> > - max_ptes_none=HPAGE_PMD_NR-1: Always try collapse to the highest
> > available mTHP order
> >
> > Any other max_ptes_none value will emit a warning and default mTHP
> > collapse to max_ptes_none=0. There should be no behavior change for PMD
> > collapse.
> >
> > Once we determine what mTHP sizes fits best in that PMD range a collapse
> > is attempted. A minimum collapse order of 2 is used as this is the lowest
> > order supported by anon memory as defined by THP_ORDERS_ALL_ANON.
> >
> > Currently madv_collapse is not supported and will only attempt PMD
> > collapse.
> >
> > We can also remove the check for is_khugepaged inside the PMD scan as
> > the collapse_max_ptes_none() function handles this logic now.
> >
> > Signed-off-by: Nico Pache <npache@redhat.com>
> > ---
> > mm/khugepaged.c | 181 +++++++++++++++++++++++++++++++++++++++++++++---
> > 1 file changed, 172 insertions(+), 9 deletions(-)
> >
> > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > index 64ceebc9d8a7..d3d7db8be26c 100644
> > --- a/mm/khugepaged.c
> > +++ b/mm/khugepaged.c
> > @@ -99,6 +99,30 @@ static DEFINE_READ_MOSTLY_HASHTABLE(mm_slots_hash, MM_SLOTS_HASH_BITS);
> >
> > static struct kmem_cache *mm_slot_cache __ro_after_init;
> >
> > +#define KHUGEPAGED_MIN_MTHP_ORDER 2
> > +/*
> > + * mthp_collapse() does an iterative DFS over a binary tree, from
> > + * HPAGE_PMD_ORDER down to KHUGEPAGED_MIN_MTHP_ORDER. The max stack
> > + * size needed for a DFS on a binary tree is height + 1, where
> > + * height = HPAGE_PMD_ORDER - KHUGEPAGED_MIN_MTHP_ORDER.
> > + *
> > + * ilog2 is used in place of HPAGE_PMD_ORDER because some architectures
> > + * (e.g. ppc64le) do not define HPAGE_PMD_ORDER until after build time.
> > + */
> > +#define MTHP_STACK_SIZE (ilog2(MAX_PTRS_PER_PTE) - KHUGEPAGED_MIN_MTHP_ORDER + 1)
> > +
> > +/*
> > + * Defines a range of PTE entries in a PTE page table which are being
> > + * considered for mTHP collapse.
> > + *
> > + * @offset: the offset of the first PTE entry in a PMD range.
> > + * @order: the order of the PTE entries being considered for collapse.
> > + */
> > +struct mthp_range {
> > + u16 offset;
> > + u8 order;
> > +};
> > +
> > struct collapse_control {
> > bool is_khugepaged;
> >
> > @@ -110,6 +134,12 @@ struct collapse_control {
> >
> > /* nodemask for allocation fallback */
> > nodemask_t alloc_nmask;
> > +
> > + /* Each bit represents a single occupied (!none/zero) page. */
> > + DECLARE_BITMAP(mthp_bitmap, MAX_PTRS_PER_PTE);
> > + /* A mask of the current range being considered for mTHP collapse. */
> > + DECLARE_BITMAP(mthp_bitmap_mask, MAX_PTRS_PER_PTE);
> > + struct mthp_range mthp_bitmap_stack[MTHP_STACK_SIZE];
> > };
> >
> > /**
> > @@ -1411,20 +1441,137 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long s
> > return result;
> > }
> >
> > +static void collapse_mthp_stack_push(struct collapse_control *cc, int *stack_size,
> > + u16 offset, u8 order)
> > +{
> > + const int size = *stack_size;
> > + struct mthp_range *stack = &cc->mthp_bitmap_stack[size];
> > +
> > + VM_WARN_ON_ONCE(size >= MTHP_STACK_SIZE);
> > + stack->order = order;
> > + stack->offset = offset;
> > + (*stack_size)++;
> > +}
> > +
> > +static struct mthp_range collapse_mthp_stack_pop(struct collapse_control *cc,
> > + int *stack_size)
> > +{
> > + const int size = *stack_size;
> > +
> > + VM_WARN_ON_ONCE(size <= 0);
> > + (*stack_size)--;
> > + return cc->mthp_bitmap_stack[size - 1];
> > +}
> > +
> > +static unsigned int collapse_mthp_count_present(struct collapse_control *cc,
> > + u16 offset, unsigned int nr_ptes)
> > +{
> > + bitmap_zero(cc->mthp_bitmap_mask, MAX_PTRS_PER_PTE);
> > + bitmap_set(cc->mthp_bitmap_mask, offset, nr_ptes);
> > + return bitmap_weight_and(cc->mthp_bitmap, cc->mthp_bitmap_mask, MAX_PTRS_PER_PTE);
> > +}
> > +
> > +/*
> > + * mthp_collapse() consumes the bitmap that is generated during
> > + * collapse_scan_pmd() to determine what regions and mTHP orders fit best.
> > + *
> > + * Each bit in cc->mthp_bitmap represents a single occupied (!none/zero) page.
> > + * A stack structure cc->mthp_bitmap_stack is used to check different regions
> > + * of the bitmap for collapse eligibility. The stack maintains a pair of
> > + * variables (offset, order), indicating the number of PTEs from the start of
> > + * the PMD, and the order of the potential collapse candidate respectively. We
> > + * start at the PMD order and check if it is eligible for collapse; if not, we
> > + * add two entries to the stack at a lower order to represent the left and right
> > + * halves of the PTE page table we are examining.
> > + *
> > + * offset mid_offset
> > + * | |
> > + * | |
> > + * v v
> > + * --------------------------------------
> > + * | cc->mthp_bitmap |
> > + * --------------------------------------
> > + * <-------><------->
> > + * order-1 order-1
> > + *
> > + * For each of these, we determine how many PTE entries are occupied in the
> > + * range of PTE entries we propose to collapse, then we compare this to a
> > + * threshold number of PTE entries which would need to be occupied for a
> > + * collapse to be permitted at that order (accounting for max_ptes_none).
> > + *
> > + * If a collapse is permitted, we attempt to collapse the PTE range into a
> > + * mTHP.
> > + */
> > +static int mthp_collapse(struct mm_struct *mm, struct vm_area_struct *vma,
> > + unsigned long address, int referenced, int unmapped,
> > + struct collapse_control *cc, unsigned long enabled_orders)
> > +{
> > + unsigned int nr_occupied_ptes, nr_ptes, max_ptes_none;
> > + int collapsed = 0, stack_size = 0;
> > + unsigned long collapse_address;
> > + struct mthp_range range;
> > + u16 offset;
> > + u8 order;
> > +
> > + collapse_mthp_stack_push(cc, &stack_size, 0, HPAGE_PMD_ORDER);
> > +
> > + while (stack_size) {
> > + range = collapse_mthp_stack_pop(cc, &stack_size);
> > + order = range.order;
> > + offset = range.offset;
> > + nr_ptes = 1UL << order;
> > +
> > + if (!test_bit(order, &enabled_orders))
> > + goto next_order;
> > +
> > + max_ptes_none = collapse_max_ptes_none(cc, vma, order);
> > +
> > + nr_occupied_ptes = collapse_mthp_count_present(cc, offset,
> > + nr_ptes);
> > +
> > + if (nr_occupied_ptes >= nr_ptes - max_ptes_none) {
> > + int ret;
> > +
> > + collapse_address = address + offset * PAGE_SIZE;
> > + ret = collapse_huge_page(mm, collapse_address, referenced,
> > + unmapped, cc, order);
> > + if (ret == SCAN_SUCCEED) {
> > + collapsed += nr_ptes;
> > + continue;
> > + }
> > + }
> > +
> > +next_order:
> > + if ((BIT(order) - 1) & enabled_orders) {
> > + const u8 next_order = order - 1;
> > + const u16 mid_offset = offset + (nr_ptes / 2);
> > +
> > + collapse_mthp_stack_push(cc, &stack_size, mid_offset,
> > + next_order);
> > + collapse_mthp_stack_push(cc, &stack_size, offset,
> > + next_order);
> > + }
> > + }
> > + return collapsed;
> > +}
> > +
> > static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> > struct vm_area_struct *vma, unsigned long start_addr,
> > bool *lock_dropped, struct collapse_control *cc)
> > {
> > - const unsigned int max_ptes_none = collapse_max_ptes_none(cc, vma, HPAGE_PMD_ORDER);
> > const unsigned int max_ptes_shared = collapse_max_ptes_shared(cc, HPAGE_PMD_ORDER);
> > const unsigned int max_ptes_swap = collapse_max_ptes_swap(cc, HPAGE_PMD_ORDER);
> > + unsigned int max_ptes_none = collapse_max_ptes_none(cc, vma, HPAGE_PMD_ORDER);
> > + enum tva_type tva_flags = cc->is_khugepaged ? TVA_KHUGEPAGED : TVA_FORCED_COLLAPSE;
> > pmd_t *pmd;
> > - pte_t *pte, *_pte;
> > - int none_or_zero = 0, shared = 0, referenced = 0;
> > + pte_t *pte, *_pte, pteval;
> > + int i;
> > + int none_or_zero = 0, shared = 0, nr_collapsed = 0, referenced = 0;
> > enum scan_result result = SCAN_FAIL;
> > struct page *page = NULL;
> > struct folio *folio = NULL;
> > unsigned long addr;
> > + unsigned long enabled_orders;
> > spinlock_t *ptl;
> > int node = NUMA_NO_NODE, unmapped = 0;
> >
> > @@ -1436,8 +1583,19 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> > goto out;
> > }
> >
> > + bitmap_zero(cc->mthp_bitmap, MAX_PTRS_PER_PTE);
> > memset(cc->node_load, 0, sizeof(cc->node_load));
> > nodes_clear(cc->alloc_nmask);
> > +
> > + enabled_orders = collapse_allowable_orders(vma, vma->vm_flags, tva_flags);
> > +
> > + /*
> > + * If PMD is the only enabled order, enforce max_ptes_none, otherwise
> > + * scan all pages to populate the bitmap for mTHP collapse.
> > + */
> > + if (enabled_orders != BIT(HPAGE_PMD_ORDER))
> > + max_ptes_none = KHUGEPAGED_MAX_PTES_LIMIT;
>
> Hmm, this is a bit odd, what if the user set max_ptes_none = 0?
We'd still want to scan the full PMD to populate the bitmap. That way
we can find the smaller orders that contain 0 none/zero PTEs.
>
> I assume we handle the 0/511 thing elsewhere?
Yes in the bitmap weight check and in collapse_huge_page_isolate()
>
> > +
> > pte = pte_offset_map_lock(mm, pmd, start_addr, &ptl);
> > if (!pte) {
> > cc->progress++;
> > @@ -1445,11 +1603,13 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> > goto out;
> > }
> >
> > - for (addr = start_addr, _pte = pte; _pte < pte + HPAGE_PMD_NR;
> > - _pte++, addr += PAGE_SIZE) {
> > + for (i = 0; i < HPAGE_PMD_NR; i++) {
> > + _pte = pte + i;
> > + addr = start_addr + i * PAGE_SIZE;
> > + pteval = ptep_get(_pte);
> > +
> > cc->progress++;
> >
> > - pte_t pteval = ptep_get(_pte);
> > if (pte_none_or_zero(pteval)) {
> > if (++none_or_zero > max_ptes_none) {
> > result = SCAN_EXCEED_NONE_PTE;
> > @@ -1529,6 +1689,8 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> > }
> > }
> >
> > + /* Set bit for occupied pages */
> > + __set_bit(i, cc->mthp_bitmap);
> > /*
> > * Record which node the original page is from and save this
> > * information to cc->node_load[].
> > @@ -1587,10 +1749,11 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> > if (result == SCAN_SUCCEED) {
> > /* collapse_huge_page expects the lock to be dropped before calling */
> > mmap_read_unlock(mm);
> > - result = collapse_huge_page(mm, start_addr, referenced,
> > - unmapped, cc, HPAGE_PMD_ORDER);
> > - /* collapse_huge_page will return with the mmap_lock released */
> > + nr_collapsed = mthp_collapse(mm, vma, start_addr, referenced,
> > + unmapped, cc, enabled_orders);
>
> I guess mthp_collapse() also does PMD collapse if only PMD is enabled?
>
> It feels like this name is a bit confusing then :)
>
> But I guess we can do a follow up to think of a better name possibly.
>
> > + /* mmap_lock was released above, set lock_dropped */
> > *lock_dropped = true;
> > + result = nr_collapsed ? SCAN_SUCCEED : SCAN_FAIL;
> > }
> > out:
> > trace_mm_khugepaged_scan_pmd(mm, folio, referenced,
> > --
> > 2.54.0
> >
>
> Thanks, Lorenzo
>
^ permalink raw reply
* Re: [PATCH mm-unstable v18 11/14] mm/khugepaged: Introduce mTHP collapse support
From: Nico Pache @ 2026-06-05 11:08 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: linux-doc, linux-kernel, linux-mm, linux-trace-kernel, aarcange,
akpm, anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
catalin.marinas, cl, corbet, dave.hansen, david, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
lance.yang, liam, mathieu.desnoyers, matthew.brost, mhiramat,
mhocko, peterx, pfalcato, rakie.kim, raquini, rdunlap,
richard.weiyang, rientjes, rostedt, rppt, ryan.roberts, shivankg,
sunnanyong, surenb, thomas.hellstrom, tiwai, usamaarif642, vbabka,
vishal.moola, wangkefeng.wang, will, willy, yang, ying.huang, ziy,
zokeefe
In-Reply-To: <CAA1CXcBeg5yFvG89xd49mD=LuSouDsXNCkfMF8Xmdgy7-h522g@mail.gmail.com>
On Fri, Jun 5, 2026 at 5:07 AM Nico Pache <npache@redhat.com> wrote:
>
> On Thu, Jun 4, 2026 at 8:45 AM Lorenzo Stoakes <ljs@kernel.org> wrote:
> >
> > On Fri, May 22, 2026 at 09:00:06AM -0600, Nico Pache wrote:
> > > Enable khugepaged to collapse to mTHP orders. This patch implements the
> > > main scanning logic using a bitmap to track occupied pages and a stack
> > > structure that allows us to find optimal collapse sizes.
> > >
> > > Previous to this patch, PMD collapse had 3 main phases, a light weight
> > > scanning phase (mmap_read_lock) that determines a potential PMD
> > > collapse, an alloc phase (mmap unlocked), then finally heavier collapse
> > > phase (mmap_write_lock).
> > >
> > > To enabled mTHP collapse we make the following changes:
> > >
> > > During PMD scan phase, track occupied pages in a bitmap. When mTHP
> > > orders are enabled, we remove the restriction of max_ptes_none during the
> > > scan phase to avoid missing potential mTHP collapse candidates. Once we
> > > have scanned the full PMD range and updated the bitmap to track occupied
> > > pages, we use the bitmap to find the optimal mTHP size.
> > >
> > > Implement collapse_scan_bitmap() to perform binary recursion on the bitmap
> > > and determine the best eligible order for the collapse. A stack structure
> > > is used instead of traditional recursion to manage the search. This also
> > > prevents a traditional recursive approach when the kernel stack struct is
> > > limited. The algorithm recursively splits the bitmap into smaller chunks to
> > > find the highest order mTHPs that satisfy the collapse criteria. We start
> > > by attempting the PMD order, then moved on the consecutively lower orders
> > > (mTHP collapse). The stack maintains a pair of variables (offset, order),
> > > indicating the number of PTEs from the start of the PMD, and the order of
> > > the potential collapse candidate.
> > >
> > > The algorithm for consuming the bitmap works as such:
> > > 1) push (0, HPAGE_PMD_ORDER) onto the stack
> > > 2) pop the stack
> > > 3) check if the number of set bits in that (offset,order) pair
> > > statisfy the max_ptes_none threshold for that order
> > > 4) if yes, attempt collapse
> > > 5) if no (or collapse fails), push two new stack items representing
> > > the left and right halves of the current bitmap range, at the
> > > next lower order
> > > 6) repeat at step (2) until stack is empty.
> > >
> > > Below is a diagram representing the algorithm and stack items:
> > >
> > > offset mid_offset
> > > | |
> > > | |
> > > v v
> > > ____________________________________
> > > | PTE Page Table |
> > > --------------------------------------
> > > <-------><------->
> > > order-1 order-1
> > >
> > > mTHP collapses reject regions containing swapped out or shared pages.
> > > This is because adding new entries can lead to new none pages, and these
> > > may lead to constant promotion into a higher order mTHP. A similar
> > > issue can occur with "max_ptes_none > HPAGE_PMD_NR/2" due to a collapse
> > > introducing at least 2x the number of pages, and on a future scan will
> > > satisfy the promotion condition once again. This issue is prevented via
> > > the collapse_max_ptes_none() function which imposes the max_ptes_none
> > > restrictions above.
> > >
> > > We currently only support mTHP collapse for max_ptes_none values of 0
> > > and HPAGE_PMD_NR - 1. resulting in the following behavior:
> > >
> > > - max_ptes_none=0: Never introduce new empty pages during collapse
> > > - max_ptes_none=HPAGE_PMD_NR-1: Always try collapse to the highest
> > > available mTHP order
> > >
> > > Any other max_ptes_none value will emit a warning and default mTHP
> > > collapse to max_ptes_none=0. There should be no behavior change for PMD
> > > collapse.
> > >
> > > Once we determine what mTHP sizes fits best in that PMD range a collapse
> > > is attempted. A minimum collapse order of 2 is used as this is the lowest
> > > order supported by anon memory as defined by THP_ORDERS_ALL_ANON.
> > >
> > > Currently madv_collapse is not supported and will only attempt PMD
> > > collapse.
> > >
> > > We can also remove the check for is_khugepaged inside the PMD scan as
> > > the collapse_max_ptes_none() function handles this logic now.
> > >
> > > Signed-off-by: Nico Pache <npache@redhat.com>
> > > ---
> > > mm/khugepaged.c | 181 +++++++++++++++++++++++++++++++++++++++++++++---
> > > 1 file changed, 172 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > > index 64ceebc9d8a7..d3d7db8be26c 100644
> > > --- a/mm/khugepaged.c
> > > +++ b/mm/khugepaged.c
> > > @@ -99,6 +99,30 @@ static DEFINE_READ_MOSTLY_HASHTABLE(mm_slots_hash, MM_SLOTS_HASH_BITS);
> > >
> > > static struct kmem_cache *mm_slot_cache __ro_after_init;
> > >
> > > +#define KHUGEPAGED_MIN_MTHP_ORDER 2
> > > +/*
> > > + * mthp_collapse() does an iterative DFS over a binary tree, from
> > > + * HPAGE_PMD_ORDER down to KHUGEPAGED_MIN_MTHP_ORDER. The max stack
> > > + * size needed for a DFS on a binary tree is height + 1, where
> > > + * height = HPAGE_PMD_ORDER - KHUGEPAGED_MIN_MTHP_ORDER.
> > > + *
> > > + * ilog2 is used in place of HPAGE_PMD_ORDER because some architectures
> > > + * (e.g. ppc64le) do not define HPAGE_PMD_ORDER until after build time.
> > > + */
> > > +#define MTHP_STACK_SIZE (ilog2(MAX_PTRS_PER_PTE) - KHUGEPAGED_MIN_MTHP_ORDER + 1)
> > > +
> > > +/*
> > > + * Defines a range of PTE entries in a PTE page table which are being
> > > + * considered for mTHP collapse.
> > > + *
> > > + * @offset: the offset of the first PTE entry in a PMD range.
> > > + * @order: the order of the PTE entries being considered for collapse.
> > > + */
> > > +struct mthp_range {
> > > + u16 offset;
> > > + u8 order;
> > > +};
> > > +
> > > struct collapse_control {
> > > bool is_khugepaged;
> > >
> > > @@ -110,6 +134,12 @@ struct collapse_control {
> > >
> > > /* nodemask for allocation fallback */
> > > nodemask_t alloc_nmask;
> > > +
> > > + /* Each bit represents a single occupied (!none/zero) page. */
> > > + DECLARE_BITMAP(mthp_bitmap, MAX_PTRS_PER_PTE);
> > > + /* A mask of the current range being considered for mTHP collapse. */
> > > + DECLARE_BITMAP(mthp_bitmap_mask, MAX_PTRS_PER_PTE);
> > > + struct mthp_range mthp_bitmap_stack[MTHP_STACK_SIZE];
> > > };
> > >
> > > /**
> > > @@ -1411,20 +1441,137 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long s
> > > return result;
> > > }
> > >
> > > +static void collapse_mthp_stack_push(struct collapse_control *cc, int *stack_size,
> > > + u16 offset, u8 order)
> > > +{
> > > + const int size = *stack_size;
> > > + struct mthp_range *stack = &cc->mthp_bitmap_stack[size];
> > > +
> > > + VM_WARN_ON_ONCE(size >= MTHP_STACK_SIZE);
> > > + stack->order = order;
> > > + stack->offset = offset;
> > > + (*stack_size)++;
> > > +}
> > > +
> > > +static struct mthp_range collapse_mthp_stack_pop(struct collapse_control *cc,
> > > + int *stack_size)
> > > +{
> > > + const int size = *stack_size;
> > > +
> > > + VM_WARN_ON_ONCE(size <= 0);
> > > + (*stack_size)--;
> > > + return cc->mthp_bitmap_stack[size - 1];
> > > +}
> > > +
> > > +static unsigned int collapse_mthp_count_present(struct collapse_control *cc,
> > > + u16 offset, unsigned int nr_ptes)
> > > +{
> > > + bitmap_zero(cc->mthp_bitmap_mask, MAX_PTRS_PER_PTE);
> > > + bitmap_set(cc->mthp_bitmap_mask, offset, nr_ptes);
> > > + return bitmap_weight_and(cc->mthp_bitmap, cc->mthp_bitmap_mask, MAX_PTRS_PER_PTE);
> > > +}
> > > +
> > > +/*
> > > + * mthp_collapse() consumes the bitmap that is generated during
> > > + * collapse_scan_pmd() to determine what regions and mTHP orders fit best.
> > > + *
> > > + * Each bit in cc->mthp_bitmap represents a single occupied (!none/zero) page.
> > > + * A stack structure cc->mthp_bitmap_stack is used to check different regions
> > > + * of the bitmap for collapse eligibility. The stack maintains a pair of
> > > + * variables (offset, order), indicating the number of PTEs from the start of
> > > + * the PMD, and the order of the potential collapse candidate respectively. We
> > > + * start at the PMD order and check if it is eligible for collapse; if not, we
> > > + * add two entries to the stack at a lower order to represent the left and right
> > > + * halves of the PTE page table we are examining.
> > > + *
> > > + * offset mid_offset
> > > + * | |
> > > + * | |
> > > + * v v
> > > + * --------------------------------------
> > > + * | cc->mthp_bitmap |
> > > + * --------------------------------------
> > > + * <-------><------->
> > > + * order-1 order-1
> > > + *
> > > + * For each of these, we determine how many PTE entries are occupied in the
> > > + * range of PTE entries we propose to collapse, then we compare this to a
> > > + * threshold number of PTE entries which would need to be occupied for a
> > > + * collapse to be permitted at that order (accounting for max_ptes_none).
> > > + *
> > > + * If a collapse is permitted, we attempt to collapse the PTE range into a
> > > + * mTHP.
> > > + */
> > > +static int mthp_collapse(struct mm_struct *mm, struct vm_area_struct *vma,
> > > + unsigned long address, int referenced, int unmapped,
> > > + struct collapse_control *cc, unsigned long enabled_orders)
> > > +{
> > > + unsigned int nr_occupied_ptes, nr_ptes, max_ptes_none;
> > > + int collapsed = 0, stack_size = 0;
> > > + unsigned long collapse_address;
> > > + struct mthp_range range;
> > > + u16 offset;
> > > + u8 order;
> > > +
> > > + collapse_mthp_stack_push(cc, &stack_size, 0, HPAGE_PMD_ORDER);
> > > +
> > > + while (stack_size) {
> > > + range = collapse_mthp_stack_pop(cc, &stack_size);
> > > + order = range.order;
> > > + offset = range.offset;
> > > + nr_ptes = 1UL << order;
> > > +
> > > + if (!test_bit(order, &enabled_orders))
> > > + goto next_order;
> > > +
> > > + max_ptes_none = collapse_max_ptes_none(cc, vma, order);
> > > +
> > > + nr_occupied_ptes = collapse_mthp_count_present(cc, offset,
> > > + nr_ptes);
> > > +
> > > + if (nr_occupied_ptes >= nr_ptes - max_ptes_none) {
> > > + int ret;
> > > +
> > > + collapse_address = address + offset * PAGE_SIZE;
> > > + ret = collapse_huge_page(mm, collapse_address, referenced,
> > > + unmapped, cc, order);
> > > + if (ret == SCAN_SUCCEED) {
> > > + collapsed += nr_ptes;
> > > + continue;
> > > + }
> > > + }
> > > +
> > > +next_order:
> > > + if ((BIT(order) - 1) & enabled_orders) {
> > > + const u8 next_order = order - 1;
> > > + const u16 mid_offset = offset + (nr_ptes / 2);
> > > +
> > > + collapse_mthp_stack_push(cc, &stack_size, mid_offset,
> > > + next_order);
> > > + collapse_mthp_stack_push(cc, &stack_size, offset,
> > > + next_order);
> > > + }
> > > + }
> > > + return collapsed;
> > > +}
> > > +
> > > static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> > > struct vm_area_struct *vma, unsigned long start_addr,
> > > bool *lock_dropped, struct collapse_control *cc)
> > > {
> > > - const unsigned int max_ptes_none = collapse_max_ptes_none(cc, vma, HPAGE_PMD_ORDER);
> > > const unsigned int max_ptes_shared = collapse_max_ptes_shared(cc, HPAGE_PMD_ORDER);
> > > const unsigned int max_ptes_swap = collapse_max_ptes_swap(cc, HPAGE_PMD_ORDER);
> > > + unsigned int max_ptes_none = collapse_max_ptes_none(cc, vma, HPAGE_PMD_ORDER);
> > > + enum tva_type tva_flags = cc->is_khugepaged ? TVA_KHUGEPAGED : TVA_FORCED_COLLAPSE;
> > > pmd_t *pmd;
> > > - pte_t *pte, *_pte;
> > > - int none_or_zero = 0, shared = 0, referenced = 0;
> > > + pte_t *pte, *_pte, pteval;
> > > + int i;
> > > + int none_or_zero = 0, shared = 0, nr_collapsed = 0, referenced = 0;
> > > enum scan_result result = SCAN_FAIL;
> > > struct page *page = NULL;
> > > struct folio *folio = NULL;
> > > unsigned long addr;
> > > + unsigned long enabled_orders;
> > > spinlock_t *ptl;
> > > int node = NUMA_NO_NODE, unmapped = 0;
> > >
> > > @@ -1436,8 +1583,19 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> > > goto out;
> > > }
> > >
> > > + bitmap_zero(cc->mthp_bitmap, MAX_PTRS_PER_PTE);
> > > memset(cc->node_load, 0, sizeof(cc->node_load));
> > > nodes_clear(cc->alloc_nmask);
> > > +
> > > + enabled_orders = collapse_allowable_orders(vma, vma->vm_flags, tva_flags);
> > > +
> > > + /*
> > > + * If PMD is the only enabled order, enforce max_ptes_none, otherwise
> > > + * scan all pages to populate the bitmap for mTHP collapse.
> > > + */
> > > + if (enabled_orders != BIT(HPAGE_PMD_ORDER))
> > > + max_ptes_none = KHUGEPAGED_MAX_PTES_LIMIT;
> >
> > Hmm, this is a bit odd, what if the user set max_ptes_none = 0?
>
> We'd still want to scan the full PMD to populate the bitmap. That way
> we can find the smaller orders that contain 0 none/zero PTEs.
>
> >
> > I assume we handle the 0/511 thing elsewhere?
>
> Yes in the bitmap weight check and in collapse_huge_page_isolate()
>
> >
> > > +
> > > pte = pte_offset_map_lock(mm, pmd, start_addr, &ptl);
> > > if (!pte) {
> > > cc->progress++;
> > > @@ -1445,11 +1603,13 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> > > goto out;
> > > }
> > >
> > > - for (addr = start_addr, _pte = pte; _pte < pte + HPAGE_PMD_NR;
> > > - _pte++, addr += PAGE_SIZE) {
> > > + for (i = 0; i < HPAGE_PMD_NR; i++) {
> > > + _pte = pte + i;
> > > + addr = start_addr + i * PAGE_SIZE;
> > > + pteval = ptep_get(_pte);
> > > +
> > > cc->progress++;
> > >
> > > - pte_t pteval = ptep_get(_pte);
> > > if (pte_none_or_zero(pteval)) {
> > > if (++none_or_zero > max_ptes_none) {
> > > result = SCAN_EXCEED_NONE_PTE;
> > > @@ -1529,6 +1689,8 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> > > }
> > > }
> > >
> > > + /* Set bit for occupied pages */
> > > + __set_bit(i, cc->mthp_bitmap);
> > > /*
> > > * Record which node the original page is from and save this
> > > * information to cc->node_load[].
> > > @@ -1587,10 +1749,11 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> > > if (result == SCAN_SUCCEED) {
> > > /* collapse_huge_page expects the lock to be dropped before calling */
> > > mmap_read_unlock(mm);
> > > - result = collapse_huge_page(mm, start_addr, referenced,
> > > - unmapped, cc, HPAGE_PMD_ORDER);
> > > - /* collapse_huge_page will return with the mmap_lock released */
> > > + nr_collapsed = mthp_collapse(mm, vma, start_addr, referenced,
> > > + unmapped, cc, enabled_orders);
> >
> > I guess mthp_collapse() also does PMD collapse if only PMD is enabled?
> >
> > It feels like this name is a bit confusing then :)
> >
> > But I guess we can do a follow up to think of a better name possibly.
Yeah, ideally we can clean that up later!
Thank you so much for reviewing and verifying the new algorithm. The
diff i sent was just a draft-- I have already added comments and
cleaned up the code more.
Cheers :)
-- Nico
> >
> > > + /* mmap_lock was released above, set lock_dropped */
> > > *lock_dropped = true;
> > > + result = nr_collapsed ? SCAN_SUCCEED : SCAN_FAIL;
> > > }
> > > out:
> > > trace_mm_khugepaged_scan_pmd(mm, folio, referenced,
> > > --
> > > 2.54.0
> > >
> >
> > Thanks, Lorenzo
> >
^ permalink raw reply
* Re: [PATCH v3] cgroup/dmem: introduce a peak file
From: Maarten Lankhorst @ 2026-06-05 11:13 UTC (permalink / raw)
To: Michal Koutný
Cc: Thadeu Lima de Souza Cascardo, Tejun Heo, Johannes Weiner,
Michal Hocko, Roman Gushchin, Shakeel Butt, Muchun Song,
Andrew Morton, Jonathan Corbet, Shuah Khan, Maxime Ripard,
Natalie Vock, Tvrtko Ursulin, cgroups, linux-kernel, linux-mm,
linux-doc, dri-devel, kernel-dev
In-Reply-To: <ahmOBo02TA8u8RW2@localhost.localdomain>
Hey,
On 5/29/26 15:01, Michal Koutný wrote:
> On Fri, May 29, 2026 at 09:34:28AM +0200, Maarten Lankhorst <dev@lankhorst.se> wrote:
>>> Reviewed-by: Michal Koutný <mkoutny@suse.com>
>> Reviewed-by: Maarten Lankhorst <dev@lankhorst.se>
>>
>> With your r-b it's ok to push it to the dmemcg tree?
>
> Please go for it.
>
> Michal
Thanks, pushed and queued for v7.3!
^ permalink raw reply
* Re: [PATCH v2 2/2] cgroup/dmem: add dmem.memcg control file for double-charging to memcg
From: Maarten Lankhorst @ 2026-06-05 11:27 UTC (permalink / raw)
To: Eric Chanudet, Michal Koutný
Cc: Johannes Weiner, Michal Hocko, Roman Gushchin, Shakeel Butt,
Muchun Song, Andrew Morton, Maxime Ripard, Natalie Vock,
Tejun Heo, Jonathan Corbet, Shuah Khan, cgroups, linux-mm,
linux-kernel, dri-devel, T.J. Mercier, Christian König,
Maxime Ripard, Albert Esteve, Dave Airlie, linux-doc
In-Reply-To: <ahXKFYBdCMDBvc_N@x1nano>
Hey,
On 5/26/26 18:59, Eric Chanudet wrote:
> On Fri, May 22, 2026 at 05:26:16PM +0200, Michal Koutný wrote:
>> Hello Eric.
>>
>> On Tue, May 19, 2026 at 11:59:02AM -0400, Eric Chanudet <echanude@redhat.com> wrote:
>>> Add a root-only cgroupfs file "dmem.memcg" that lets an administrator
>>> configure whether allocations in a dmem region should also be charged to
>>> the memory controller.
>>
>> This kinda makes sense as it is not unlike io.cost.* device
>> configurators.
>>
>> Just for my better understanding -- will there be a space for userspace
>> to switch this? (No charged dmem allocations happen before responsible
>> userspace runs, so that the attribute remains unlocked.)
>>
>> (I'm rather indifferent about the actual double charging/non-charging
>> matter.)
>
> Yes, this is intended to be configured before the user space stack that
> would start allocating things is started. Once it has started (and tried
> to charge something), the configuration is locked
>
>>
>>>
>>> To handle inheritance, dmem adds a depends_on the memory controller,
>>> unless MEMCG isn't configured in.
>>>
>>> Double-charging is disabled by default. Once a charge is attempted, the
>>> setting is locked to prevent inconsistent accounting by a small 4-state
>>> machine (off, on, locked off, locked on).
>>>
>>> The memcg to charge is derived from the pool's cgroup, since the pool
>>> holds a reference to the dmem cgroup state that keeps the cgroup alive
>>> until it gets uncharged.
>>>
>>> Signed-off-by: Eric Chanudet <echanude@redhat.com>
>>> ---
>>> Documentation/admin-guide/cgroup-v2.rst | 23 +++++
>>> kernel/cgroup/dmem.c | 158 +++++++++++++++++++++++++++++++-
>>> 2 files changed, 178 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
>>> index 6efd0095ed995b1550317662bc1b56c7a7f3db23..1d2fa55ddf0faa17baa916a8914d3033e8e42359 100644
>>> --- a/Documentation/admin-guide/cgroup-v2.rst
>>> +++ b/Documentation/admin-guide/cgroup-v2.rst
>>> @@ -2828,6 +2828,29 @@ DMEM Interface Files
>>> drm/0000:03:00.0/vram0 12550144
>>> drm/0000:03:00.0/stolen 8650752
>>>
>>> + dmem.memcg
>>> + A readwrite nested-keyed file that exists only on the root
>>> + cgroup.
>>
>> Strictly speaking this is not nested-keyed but flat keyed [1],
>
> Indeed,
>
>> which leads me to realization that this is the first instance of a boolean.
>> All in call, such a composition comes to my mind (latter is RO):
>>
>> drm/0000:03:00.0/vram0 enable=0|1 locked=0|1
>>
>
> So per[1] 1 key, 2 sub-keys (enable RW, locked RO), that looks better
> and match the documentation, thanks!
>
>>
>>
>>> +static ssize_t dmem_cgroup_memcg_write(struct kernfs_open_file *of, char *buf,
>>> + size_t nbytes, loff_t off)
>>> +{
>>> + while (buf) {
>>> + struct dmem_cgroup_region *region;
>>> + char *options, *name;
>>> + bool flag;
>>> +
>>> + options = buf;
>>> + buf = strchr(buf, '\n');
>>> + if (buf)
>>> + *buf++ = '\0';
>>
>> I recall there was a discussion about accepting only a single device per
>> write(2) (at the same time I see this idiom is still present in other
>> dmem.* files, so this is nothing to change in _this_ patch).
>
> I would second that. When setting say dmem.max for 2 regions, with a
> typo on the second, the first one is set, but write still get EINVAL.
>
> Also, I just notice dmemcg_limit_write() returns EINVAL if the region is
> not found (this patch returns ENODEV).
>
>>
>> Thanks,
>> Michal
>>
>> [1] https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#format
>
>
>
Perhaps a bit late, but before we start adding this UAPI we should enforce a
single region per write?
Kind regards,
~Maarten Lankhorst
^ permalink raw reply
* Re: [PATCH v6 06/11] x86/virt/tdx: Optimize tdx_pamt_get/put()
From: Kiryl Shutsemau @ 2026-06-05 11:42 UTC (permalink / raw)
To: Chao Gao
Cc: Edgecombe, Rick P, kvm@vger.kernel.org,
linux-coco@lists.linux.dev, Huang, Kai, Hansen, Dave, Zhao, Yan Y,
seanjc@google.com, mingo@redhat.com, linux-kernel@vger.kernel.org,
pbonzini@redhat.com, nik.borisov@suse.com,
linux-doc@vger.kernel.org, hpa@zytor.com, tglx@kernel.org,
Annapurve, Vishal, bp@alien8.de, kirill.shutemov@linux.intel.com,
x86@kernel.org
In-Reply-To: <aiJhScChLZkH44eB@intel.com>
On Fri, Jun 05, 2026 at 01:40:25PM +0800, Chao Gao wrote:
> On Thu, Jun 04, 2026 at 05:59:02PM +0100, Kiryl Shutsemau wrote:
> >On Tue, May 26, 2026 at 04:42:24PM +0000, Edgecombe, Rick P wrote:
> >> On Tue, 2026-05-26 at 16:57 +0800, Chao Gao wrote:
> >> > > - scoped_guard(spinlock, &pamt_lock) {
> >> >
> >> > This converts the scoped_guard() added by the previous patch to
> >> > explicit lock/unlock and goto. It would reduce code churn if the
> >> > previous patch used that form directly.
> >>
> >> Yea, it's a good point. I actually debated doing it, but decided not to because
> >> the scoped version is cleaner for the non-optimized version. But for
> >> reviewability, never doing the scoped version is probably better.
> >
> >I don't see a reason why we can't keep the scoped_guard() on get side.
>
> One additional reason to drop scoped_guard() is that it mixes cleanup helpers
> with goto, which is discouraged. See [*]
>
> :Lastly, given that the benefit of cleanup helpers is removal of “goto”, and
> :that the “goto” statement can jump between scopes, the expectation is that
> :usage of “goto” and cleanup helpers is never mixed in the same function.
Fair enough.
But it can also be address if we free the PAMT page array with the guard
too :P
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH v4 0/3] ALSA: usb-audio: Add QUIRK_FLAG_MIXER_GET_CUR_BROKEN
From: Thorsten Leemhuis @ 2026-06-05 12:00 UTC (permalink / raw)
To: Takashi Iwai, Rong Zhang
Cc: Jaroslav Kysela, Takashi Iwai, Jonathan Corbet, Shuah Khan,
Steve Smith, linux-sound, linux-doc, linux-kernel,
Linux kernel regressions list
In-Reply-To: <87se77o9xr.wl-tiwai@suse.de>
On 5/31/26 17:50, Takashi Iwai wrote:
> On Sun, 31 May 2026 17:45:19 +0200,
> Rong Zhang wrote:
>>
>> Since commit 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky
>> mixers"), the UAC mixer core utilizes volume SET_CUR and GET_CUR to
>> identify devices with sticky mixers. Unfortunately, even though most
>> devices with sticky GET_CUR also have corresponding sticky SET_CUR,
>> which I actually met more since the commit had been merged, there is
>> also a rare case that some devices may have volume mixers that responds
>> to SET_CUR properly but with its GET_CUR stubbed. This cause the sticky
>> check to consider the mixer to be sticky and unnecessarily disable it.
> [...]
>
> Now took all three patches onto for-next branch. Thanks.
I noticed that patch 1 is somewhat on the larger side, nevertheless
allow me to ask: wouldn't it be better to mainline this for -rc7, as
this fixes a regression from the 7.1 cycle? Or did I misjudge this? Then
don't hesitate to tell me!
Ciao, Thorsten
^ permalink raw reply
* Re: [PATCH v4 0/3] ALSA: usb-audio: Add QUIRK_FLAG_MIXER_GET_CUR_BROKEN
From: Takashi Iwai @ 2026-06-05 12:05 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Takashi Iwai, Rong Zhang, Jaroslav Kysela, Takashi Iwai,
Jonathan Corbet, Shuah Khan, Steve Smith, linux-sound, linux-doc,
linux-kernel, Linux kernel regressions list
In-Reply-To: <37b3d366-7a22-4117-8be8-821098246885@leemhuis.info>
On Fri, 05 Jun 2026 14:00:02 +0200,
Thorsten Leemhuis wrote:
>
> On 5/31/26 17:50, Takashi Iwai wrote:
> > On Sun, 31 May 2026 17:45:19 +0200,
> > Rong Zhang wrote:
> >>
> >> Since commit 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky
> >> mixers"), the UAC mixer core utilizes volume SET_CUR and GET_CUR to
> >> identify devices with sticky mixers. Unfortunately, even though most
> >> devices with sticky GET_CUR also have corresponding sticky SET_CUR,
> >> which I actually met more since the commit had been merged, there is
> >> also a rare case that some devices may have volume mixers that responds
> >> to SET_CUR properly but with its GET_CUR stubbed. This cause the sticky
> >> check to consider the mixer to be sticky and unnecessarily disable it.
> > [...]
> >
> > Now took all three patches onto for-next branch. Thanks.
>
> I noticed that patch 1 is somewhat on the larger side, nevertheless
> allow me to ask: wouldn't it be better to mainline this for -rc7, as
> this fixes a regression from the 7.1 cycle? Or did I misjudge this? Then
> don't hesitate to tell me!
A regression fix will be included in the upcoming PR by another commit
aa2f4addab44407c7aa742321de5dc1914ab5762.
Takashi
^ permalink raw reply
* Re: htmldocs: Warning: MAINTAINERS references a file that doesn't exist: Documentation/devicetree/bindings/net/toshiba,tc956x-dwmac.yaml
From: Alex Elder @ 2026-06-05 12:16 UTC (permalink / raw)
To: kernel test robot, Daniel Thompson; +Cc: oe-kbuild-all, linux-doc
In-Reply-To: <202606050946.JGkrxO1C-lkp@intel.com>
On 6/5/26 2:15 AM, kernel test robot wrote:
> tree: https://github.com/intel-lab-lkp/linux/commits/Alex-Elder/dt-bindings-net-qca-qca808x-Add-regulator-properties/20260605-091912
> head: a2cf643cd5401eea03d3f1a49d81e7d066ae6047
> commit: b6d9c722ce11c43b1e14ca3a15d993e470299502 dt-bindings: net: toshiba,tc9654-dwmac: add TC9564 Ethernet bridge
> date: 6 hours ago
> compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project f43d6834093b19baf79beda8c0337ab020ac5f17)
> docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
> reproduce: (https://download.01.org/0day-ci/archive/20260605/202606050946.JGkrxO1C-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202606050946.JGkrxO1C-lkp@intel.com/
This issue was caught once I upgraded the "dtschema" package.
It will be fixed in the next version of the series.
-Alex
>
> All warnings (new ones prefixed by >>):
>
> Warning: Documentation/translations/zh_CN/how-to.rst references a file that doesn't exist: Documentation/xxx/xxx.rst
> Warning: Documentation/translations/zh_CN/networking/xfrm_proc.rst references a file that doesn't exist: Documentation/networking/xfrm_proc.rst
> Warning: Documentation/translations/zh_CN/scsi/scsi_mid_low_api.rst references a file that doesn't exist: Documentation/Configure.help
> Warning: MAINTAINERS references a file that doesn't exist: Documentation/ABI/testing/sysfs-platform-ayaneo
> Warning: MAINTAINERS references a file that doesn't exist: Documentation/devicetree/bindings/display/bridge/megachips-stdpxxxx-ge-b850v3-fw.txt
>>> Warning: MAINTAINERS references a file that doesn't exist: Documentation/devicetree/bindings/net/toshiba,tc956x-dwmac.yaml
> Warning: arch/powerpc/sysdev/mpic.c references a file that doesn't exist: Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
> Warning: drivers/net/ethernet/smsc/Kconfig references a file that doesn't exist: file:Documentation/networking/device_drivers/ethernet/smsc/smc9.rst
> Warning: rust/kernel/sync/atomic/ordering.rs references a file that doesn't exist: srctree/tools/memory-model/Documentation/explanation.txt
> Warning: tools/docs/documentation-file-ref-check references a file that doesn't exist: Documentation/virtual/lguest/lguest.c
> Warning: tools/docs/documentation-file-ref-check references a file that doesn't exist: m,\b(\S*)(Documentation/[A-Za-z0-9
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox