* Re: [RFC PATCH 0/5] mm, swap: Virtual Swap Space (Swap Table Edition)
From: Nhat Pham @ 2026-06-02 15:28 UTC (permalink / raw)
To: Kairui Song
Cc: Liam.Howlett, akpm, apopple, axelrasmussen, baohua, baolin.wang,
bhe, byungchul, cgroups, chengming.zhou, chrisl, corbet, david,
dev.jain, gourry, hannes, hughd, jannh, joshua.hahnjy, lance.yang,
lenb, linux-doc, linux-kernel, linux-mm, linux-pm,
lorenzo.stoakes, matthew.brost, mhocko, muchun.song, npache,
pavel, peterx, peterz, pfalcato, rafael, rakie.kim,
roman.gushchin, rppt, ryan.roberts, shakeel.butt, shikemeng,
surenb, tglx, vbabka, weixugc, ying.huang, yosry.ahmed, yuanchu,
zhengqi.arch, ziy, kernel-team, riel, haowenchao22
In-Reply-To: <CAMgjq7D4XsAD4NGDL7FC2kaYAQAP8PDJdn4bpzGZwXYtjEpJ6w@mail.gmail.com>
On Mon, Jun 1, 2026 at 8:25 PM Kairui Song <ryncsn@gmail.com> wrote:
>
> On Tue, Jun 2, 2026 at 2:06 AM Nhat Pham <nphamcs@gmail.com> wrote:
> >
> > On Mon, Jun 1, 2026 at 10:45 AM Kairui Song <ryncsn@gmail.com> wrote:
> > >
> > > On Mon, Jun 1, 2026 at 11:57 PM Nhat Pham <nphamcs@gmail.com> wrote:
> > > >
> > > > Are you suggesting we merge the virtual table with main swap table?
> > > >
> > > > Man, I'd love to do this. There is a problem though - we have a case
> > > > where we occupy both backing physical swap AND swap cache. Do you
> > > > think we can fit both the physical swap slot handle and the swap cache
> > > > PFN into the same slot in virtual table? Maybe with some expanding...?
> > >
> > > I don't really get why we would need to do that? If you put the PFN
> > > info in the virtual / upper layer, then the count info, locking, and
> > > all swap IO synchronization (via folio lock), dup (current protected
> > > by ci lock / folio lock), and allocation (folio_alloc_swap), are all
> > > handled in this layer.
> > >
> > > The physical / lower layer will just hold a reverse entry on
> > > folio_realloc_swap, or no entry at all (no physical layer used, zswap,
> > > or after swap allocation but before IO) right?
> > >
> > > Looking up the actual folio from the physical layer will be a bit
> > > slower since it needs to resolve the reverse entry, but the only place
> > > we need to do that is things like migrate, compaction (none of them
> > > exist yet) which seems totally fine?
> >
> > All of this is correct, but consider swaping in a vswap entry backed
> > by pswap. There are cases where you still want to maintain the pswap
> > slots around backing vswap entry, while having the swap cache folio as
> > well.
> >
> > For e.g, at swap in time, we add the folio into the swap cache. First
> > of all, we need to hold on to the physical swap slot for IO step. But
> > even after IO succeeds, there are cases where you would still like to
> > keep physical swap slots around (for e.g, to avoid swapping out again
> > if the folio is only speculatively fetched).
>
> A reverse entry is enough to hold the physical swap, just like how the
> current hibernation works with a fake shadow, you don't need a PFN
> just for holding that.
>
> >
> > So you have to make sure we have space for both the physical swap
> > slot, and the swap cache folio's PFN at the same time for each vswap
> > entry. So we still need the vtable extension (well maybe the other
> > approach I mentioned could work, but I'm not 100% sure).
>
> Right, vtable extension is fine, there is no redundant data. I just
> mean you don't need to set the PFN twice (for vswap & pswap). So
> simply reusing the PFN format in the vswap layer and solving
> everything there should be enough.
Ah yeah, then I might have misunderstood you here. I thought you were
proposing a way to remove vtable :)
"don't need to set the PFN twice" completely agree. I'm pretty sure I
did not here, but do let me know if I accidentally set it twice. I'm
be sure to check this myself for the next version.
>
> > > Thanks. Not too complicated, actually our internal kernel
> > > implementation still using si->percpu cluster, and use a counter for
> > > the rotation and each order have a counter :P, it's a bit ugly but
> > > works fine. It still serves pretty well just like the global percpu
> > > cluster, YoungJun's previous per ci percpu cluster also still provides
> > > the fast path, many ways to do that.
> >
> > Sounds like something that should be upstreamed? ;)
>
> I'd love to :), there is a lot of work going on as you can see and
> people seem to have many different proposals about this so I didn't
> prioritize it. I'll try as things settle down.
Yeah understandable. It's a very volatile codebase, with a lot of
folks trying to improve different aspects.
Hopefully we're close to a unified design :)
I'll keep my dedicated vswap per-cpu alloc caching for now, but I'll
get rid of it whenever the per-CPU per-si cache is ready.
>
> > > > >
> > > > > For patch 2, a few routines like vswap_can_swapin_thp seems not
> > > > > needed or should be moved to __swap_cache_alloc? VSWAP_FOLIO is
> > > > > same as swap cache folio check, which is already covered. Same for
> > > > > zero checking, and VSWAP_NONE which is same as swap count check
> > > > > I think. That way we not only save a lot of code, we also no
> > > > > longer need to treat vswap specially.
> > > >
> > > > Unfortunately, I think a lot of this complexity is still needed. Vswap
> > > > adds a new layer, which means new complications :)
> > > >
> > > > For instance, I think you still need vswap_can_swapin_thp. It
> > > > basically enforces that the backend must be something
> > > > swap_read_folio() can handle. That means:
> > > >
> > > > 1. No zswap.
> > > >
> > > > 2. No mixed backend.
> > >
> > > If mixed backend means phys vs zero vs zswap, then we already have
> > > part of that covered with the current swap cache except for the phys
> > > part (zswap part seems very doable with fujunjie's work).
> > > swap_cache_alloc_folio will ensure there is no mixed zerobit, it can
> > > be easily extended to ensure there is no mixed zswap as well
> > > (according to what I've learned from fujunjie's code). Similar logic
> > > for phys detection I think.
> >
> > Yeah it's basically generalizing that check, and handle the case where
> > we can have indirection.
> >
> > I mean I can open-code it, but it has to be there :) And I figure it
> > might be useful to check this opportunistically (at swap_pte_batch,
> > even if it's not guaranteed to be correct down the line) before we
> > even attempt to allocate a large folio etc. to avoid large folio
> > allocation.
>
> Right, but swap_cache_alloc_folio with orders=<large order> won't
> attempt a large allocation if the batch check fails, so that's fine.
>
> > > > Basically:
> > > >
> > > > 1. For vswap entry, not backed by phys swap: record swap memcg, hold
> > > > reference to pin the memcg, but not charging towards swap.current.
> > >
> > > Maybe you don't need to record memcg here since folio->memcg already
> > > have that info?
> > >
> > > I previously had a patch:
> > > https://lore.kernel.org/linux-mm/20260220-swap-table-p4-v1-7-104795d19815@tencent.com/
> > >
> > > The defers the recording of memcg, the behavior is almost identical to
> > > before, but charging & recording should be cleaner and you don't need
> > > to record memcg at allocation time hence maybe reduce the possibility
> > > of pinning a memcg. I didn't include that in P4 just to reduce LOC,
> > > maybe can be resent or included.
> >
> > That works-ish when the folio is sitll in swap cache, but say if it's
> > vswap backed by zswap (and the swap cache folio has been reclaimed),
> > you need a place to store the memcg, no?
>
> "Backed by zswap" means the actual swapout already happened, which is
> the case where we always have to record the memcg info because the
> folio is gone, seems still fit in the model.
Hmmm I might have misunderstood you in my last response here.
So what you are doing in that patch:
1. Charge towards folio->memcg when we allocate swap slots, but do not
record or take reference yet.
2. Once we reclaimed the folio after swap out, then we record and
acquire reference to pin.
You know what - this would simplify my usecase. For vswap entries not
backing by pswap, it *basically* just means I skip step 1 for vswap
backend. Step 2 is shared for all cases. Donezo.
You're right. This is simpler :) Let me brew on it a bit longer in
case there might be something we're missing. but it does seem like
this will reduce complexity (and with the added benefits of me not
having to come up with names for helpers).
>
> > Just seems cleaner to centralize this info at vswap layer when it is
> > presented, for now anyway, rather than juggling this on a per-backend
> > basis.
>
> Zswap charge could be merged with vswap I think but pswap we just
> discussed that we might want to charge it differently? And actually
> vswap charge is still quite different from zswap charge if you want to
> make vswap infinitely large? I think we can figure out this part as we
> progress; it's not a major problem at this point.
That was because I misunderstood your suggestions. My bad :)
Anyway, please keep the suggestions and recommendations coming :) I'm
playing with some of your suggestions right now, and waiting for other
folks' inputs as well. Will send out the next version at some point.
If there is no fundamental design flaws, I will un-RFC once I've
addressed all the main issues.
^ permalink raw reply
* Re: [PATCH mm-unstable v18 06/14] mm/khugepaged: generalize collapse_huge_page for mTHP collapse
From: Nico Pache @ 2026-06-02 15:30 UTC (permalink / raw)
To: Lance Yang
Cc: David Hildenbrand (Arm), 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, ljs, 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: <baa0a462-46e0-44ab-b583-c722ad253afe@linux.dev>
On Mon, Jun 1, 2026 at 4:48 AM Lance Yang <lance.yang@linux.dev> wrote:
>
>
>
> On 2026/6/1 18:23, David Hildenbrand (Arm) wrote:
> > On 6/1/26 11:08, Lance Yang wrote:
> >>
> >>
> >> On 2026/6/1 14:54, David Hildenbrand (Arm) wrote:
> >>> On 6/1/26 05:28, Lance Yang wrote:
> >>>>
> >>>>
> >>>> Ah, fair point.
> >>>>
> >>>> I was mostly worried about arch hooks that walk vma->vm_mm again, rather
> >>>> than only using the pte pointer passed in. For example, mips does:
> >>>
> >>> Right, a re-walk would be the real problem.
> >>>
> >>>>
> >>>> update_mmu_cache_range()
> >>>> -> __update_tlb()
> >>>> -> pgd_offset(vma->vm_mm, address)
> >>>> -> pte_offset_map(...)
> >>>>
> >>>> and __update_tlb() has this assumption:
> >>>>
> >>>> /*
> >>>> * update_mmu_cache() is called between pte_offset_map_lock()
> >>>> * and pte_unmap_unlock(), so we can assume that ptep is not
> >>>> * NULL here: and what should be done below if it were NULL?
> >>>> */
> >>>>
> >>>> So if khugepaged happens to run with current->active_mm == vma->vm_mm
> >>>> here, could __update_tlb() hit the none PMD, get NULL from
> >>>> pte_offset_map(), and then dereference it?
> >>>
> >>> Likely yes -- that MIPS code is horrible. And the comment in MIPS code
> >>> even spells that out. :(
> >>>
> >>> Do you know about other code like that, or is MIPS the only one doing a
> >>> re-walk and crossing fingers?
> >>>
> >>>>
> >>>> Just wanted to raise it since some arch code may still have assumptions
> >>>> like this, and the always-enable-mTHP work is getting closer ...
> >>>
> >>> Right. I assume set_pte_at() couldn't trigger something similar (re-walk) in
> >>> arch code,
> >>> because we simply provide the ptep. update_mmu_cache_range() only consumes the
> >>> pte.
> >>>
> >>>>
> >>>> Probably very very very hard to hit, though :)
> >>>
> >>> Delaying update_mmu_cache_range() is nasty, as we'd have to make sure that
> >>> nobody can interfere in the meantime ... and the PMD lock will not be sufficient.
> >>>
> >>> Maybe we could reinstall the page table with the cleared (none) entries while
> >>> still holding the PTL?
> >>>
> >>> Thinking out loud:
> >>>
> >>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> >>> index 5ba298d420b7..e39b750b1e6f 100644
> >>> --- a/mm/khugepaged.c
> >>> +++ b/mm/khugepaged.c
> >>> @@ -1413,13 +1413,17 @@ static enum scan_result collapse_huge_page(struct
> >>> mm_struct *mm, unsigned long s
> >>> map_anon_folio_pmd_nopf(folio, pmd, vma, pmd_addr);
> >>> } else {
> >>> /*
> >>> - * set_ptes is called in map_anon_folio_pte_nopf with the
> >>> - * pmd_ptl lock still held; this is safe as the PMD is expected
> >>> - * to be none. The pmd entry is then repopulated below.
> >>> + * Re-insert the page table with the cleared entries, but
> >>> + * hold the PTL, such that no one can mess with the re-installed
> >>> + * page table until we updated the temporarily-cleared entries
> >>> + * through map_anon_folio_pte_nopf().
> >>> */
> >>> - map_anon_folio_pte_nopf(folio, pte, vma, start_addr, /
> >>> *uffd_wp=*/ false);
> >>> - smp_wmb(); /* make PTEs visible before PMD. See pmd_install() */
> >>
> >> One small thing, I think we should probably keep the smp_wmb(), and just
> >> move it before the earlier pmd_populate().
> >>
> >> IIUC, the ordering we want is still:
> >>
> >> clear old PTEs
> >> smp_wmb()
> >> pmd_populate()
> >>
> >> so another CPU cannot walk through the re-installed PMD and still observe
> >> the old PTEs, right?
> >
> > There is a smp_wmb() in __folio_mark_uptodate(), that should be sufficient?
>
> Ah, cool! __folio_mark_uptodate() already does the job :P
>
> So yeah, no extra smp_wmb() needed here!
are we sure? that folio_mark_uptodate is done before the PTEs are
reinstalled. Then we reinstall the PMD right after. Currently
separated by the smp_wmb().
I was copying this from other THP code that performs similar PTE/PMD juggling.
I can remove it, but I'd rather air on the side of caution with this.
>
> Cheers, Lance
>
^ permalink raw reply
* Re: [PATCH mm-unstable v18 11/14] mm/khugepaged: Introduce mTHP collapse support
From: Lance Yang @ 2026-06-02 15:44 UTC (permalink / raw)
To: Nico Pache
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,
liam, ljs, 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: <CAA1CXcA+oZmp=cxiC2_EBDxqGX94gAd335d9eFPNv=j_0=og7Q@mail.gmail.com>
On 2026/6/2 18:58, Nico Pache wrote:
> On Sun, May 31, 2026 at 1:19 AM Lance Yang <lance.yang@linux.dev> wrote:
>>
>>
>> On Fri, May 22, 2026 at 09:00:06AM -0600, Nico Pache wrote:
>> [...]
>>> @@ -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);
>>> + /* mmap_lock was released above, set lock_dropped */
>>> *lock_dropped = true;
>>> + result = nr_collapsed ? SCAN_SUCCEED : SCAN_FAIL;
>>
>> Hmm ... don't we lose the allocation-failure result here?
>>
>> Previously collapse_scan_pmd() propagated SCAN_ALLOC_HUGE_PAGE_FAIL from
>> collapse_huge_page(), so khugepaged would call khugepaged_alloc_sleep()
>> in khugepaged_do_scan().
>>
>> Now if allocation fails and nr_collapsed stays 0, we just return
>> SCAN_FAIL. So we won't back off via khugepaged_alloc_sleep() anymore?
>
> Ok I did the error propagation! I think I handled both of these cases
> you brought up pretty easily.
Thanks.
> However I don't know what to do in the following case: We successfully
> collapsed some portion of the PMD, but during that process, we also
> hit an allocation failure. Is it best to back off entirely? or can we
> treat some forward progress as a sign we can continue trying collapses
> without sleeping.
>
> Basically, do we prioritize SCAN_ALLOC_HUGE_PAGE_FAIL or the
> successful collapses as the returned value?
Thinking out loud, forward progress should win here, the allocation
failure only matter if we made no progress at all?
> This is what I currently have:
> done:
> if (collapsed)
> return SCAN_SUCCEED;
> if (alloc_failed)
> return SCAN_ALLOC_HUGE_PAGE_FAIL;
I'd go with this ordering :)
Cheers, Lance
^ permalink raw reply
* Re: [PATCH v3 2/2] arm64: kernel: Disable CNP on HiSilicon HIP09
From: Will Deacon @ 2026-06-02 15:53 UTC (permalink / raw)
To: Zeng Heng
Cc: vladimir.murzin, xuwei5, wangyushan12, yangyicong, maz,
yeoreum.yun, miko.lenczewski, james.clark, corbet, skhan,
kuninori.morimoto.gx, lucaswei, catalin.marinas, broonie,
lpieralisi, thuth, kevin.brodsky, tongtiangen, oupton,
ryan.roberts, mark.rutland, Sascha.Bischoff, linux-arm-kernel,
wangkefeng.wang, linux-doc, linux-kernel
In-Reply-To: <20260601112000.1145391-3-zengheng@huaweicloud.com>
On Mon, Jun 01, 2026 at 07:20:00PM +0800, Zeng Heng wrote:
> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> index b0db946568b7..02e0ee5c948c 100644
> --- a/arch/arm64/kernel/cpu_errata.c
> +++ b/arch/arm64/kernel/cpu_errata.c
> @@ -608,6 +608,14 @@ static const struct midr_range erratum_ac04_cpu_23_list[] = {
> };
> #endif
>
> +#ifdef CONFIG_ARM64_WORKAROUND_DISABLE_CNP
> +static const struct midr_range cnp_erratum_cpus[] = {
> + MIDR_ALL_VERSIONS(MIDR_NVIDIA_CARMEL),
> + MIDR_ALL_VERSIONS(MIDR_HISI_HIP09),
> + {},
> +};
> +#endif
Sashiko [1] points out that this means that
CONFIG_HISILICON_ERRATUM_162100125 now affects NVIDIA parts and
vice-versa for CONFIG_NVIDIA_CARMEL_CNP_ERRATUM.
The easiest fix is probably to guard the entries in the array above with
their respective config options? Otherwise, this all looks good to me.
Will
[1] https://sashiko.dev/#/patchset/20260601112000.1145391-1-zengheng@huaweicloud.com
^ permalink raw reply
* Re: [RFC PATCH 0/5] mm, swap: Virtual Swap Space (Swap Table Edition)
From: Nhat Pham @ 2026-06-02 15:54 UTC (permalink / raw)
To: Kairui Song
Cc: Liam.Howlett, akpm, apopple, axelrasmussen, baohua, baolin.wang,
bhe, byungchul, cgroups, chengming.zhou, chrisl, corbet, david,
dev.jain, gourry, hannes, hughd, jannh, joshua.hahnjy, lance.yang,
lenb, linux-doc, linux-kernel, linux-mm, linux-pm,
lorenzo.stoakes, matthew.brost, mhocko, muchun.song, npache,
pavel, peterx, peterz, pfalcato, rafael, rakie.kim,
roman.gushchin, rppt, ryan.roberts, shakeel.butt, shikemeng,
surenb, tglx, vbabka, weixugc, ying.huang, yosry.ahmed, yuanchu,
zhengqi.arch, ziy, kernel-team, riel, haowenchao22
In-Reply-To: <CAMgjq7CT0ccCnzmpRGjTGPnNEn4eK==5A-OFbr3+p465dQMH4A@mail.gmail.com>
On Mon, Jun 1, 2026 at 10:49 AM Kairui Song <ryncsn@gmail.com> wrote:
>
> On Tue, Jun 2, 2026 at 12:22 AM Nhat Pham <nphamcs@gmail.com> wrote:
> >
> > On Mon, Jun 1, 2026 at 8:56 AM Nhat Pham <nphamcs@gmail.com> wrote:
> > >
> > > On Mon, Jun 1, 2026 at 12:34 AM Kairui Song <ryncsn@gmail.com> wrote:
> > > >
> > > > On Thu, May 28, 2026 at 02:29:24PM +0800, Nhat Pham wrote:
> > > > > III. Follow-ups:
> > > > >
> > > > > In no particular order (and most of which can be done as follow-up
> > > > > patch series rather than shoving everything in the initial landing):
> > > > >
> > > > > - More thorough stress testing is very much needed.
> > > > >
> > > > > - Performance benchmarks to make sure I don't accidentally regress
> > > > > the vswap-less case, and that the vswap's case performance is
> > > > > good. I suspect I will have to port a lot of the
> > > > > optimizations I implemented in v6 over here - some of the
> > > > > inefficiencies are inherent in any swap virtualization, and
> > > > > would require the same fix (for e.g the MRU cluster caching
> > > > > for faster cluster lookup - see [8] and [9]).
> > > >
> > > > This could be imporved by per-si percpu cluster. Both YoungJun's
> > > > tiering and Baoquan's previous swap ops mentioned this is needed,
> > > > and now vswap also need that. If the vswap is also a si, then it will
> > > > make use of this too.
> >
> > Oh and the MRU cluster caching I mentioned here is not the allocation
> > caching. It's the lookup caching, basically to avoid doing the
> > xa_load() to look up clusters for consecutive swap operations on the
> > same vswap cluster (which is the common case with vswap). For v6, it
> > massively reduces this indirection lookup overhead. Performance-wise
> > it's an absolute winner, just more complexity (because I need to
> > handle reference counting carefully).
>
> Ah alright, that's interesting. And I think we can keep things simple
> to start, since sensitive users is stil able tol use plain device this
> way.
Of course. I'm hoping vswap-on-zswap will not be too terrible at a
start. We can then optimize for the swapfile backend case later.
>
> BTW maintaining MRU is also an overhead, I'm not sure if the lookup
> pattern always follows that?
Yeah I had to be a bit careful in v6 to make sure the cache (and cache
invalidation) happens at the right time. I've had this idea for awhile
- there's a reason why I waited until v6 to implement it :)
For instance, when physical swap allocator runs out of slot for a
cluster, we try to reclaim the swap-cache-only slots. That involves
taking the rmap back to vswap layer, to check swap cache and swap
count. This is a very random pattern, so it does not benefit from this
lookup cache, and in fact invalidates the cache :) So I had to add
some hint to avoid going back to the vswap layer to check for
swap-cache-only state.
>
> > I also just realized we'll induce the indirection overhead on
> > allocation here too, even if the cached cluster still have slots for
> > allocation, because we look up the cluster (which is basically free
> > for static swap device, but not free for vswap devices). Might need to
> > take care of that to maintain vswap performance (but it will then
> > diverge from your existing code...).
>
> That part should be indeed coverable by the si->percpu cluster though, I think.
Yeah agree - we just need to be a bit craftier with it. The
fundamental problem is in the current model, we're only storing offset
and si, then look up cluster based on that. But for dynamic vswap,
that look up takes the xa_load().
Once we move to per-si per-cpu cluster, then I think it becomes ok to
store the cluster pointer directly, correct?
The reference counting needs to be carefully handled though. I think
in my old vss design I did something fairly silly - just hold a
reference to it while it's in cache, then add CPU offlining handler to
clean up. Not the end of the world I suppose, but maybe there's a
smarter scheme.
^ permalink raw reply
* [PATCH v4] drm/xe/hwmon: document DG2 fan speed reporting quirk
From: Zhan Wei @ 2026-06-02 16:17 UTC (permalink / raw)
To: matthew.brost, thomas.hellstrom, rodrigo.vivi
Cc: raag.jadav, corbet, skhan, intel-xe, dri-devel, linux-doc,
linux-kernel, Zhan Wei
In-Reply-To: <ahqN8Esjz9SmGofH@black.igk.intel.com>
On DG2 the driver always shows two fan channels, because the
FSC_READ_NUM_FANS command does not work on some cards. OEMs decide how
the fans map to tach channels, so two fans can share one tach line.
When that happens, the second channel reads 0 RPM even though the fan
is spinning.
Note this on the fan2_input ABI entry so the steady 0 RPM is not
mistaken for a driver bug.
Fixes: 28f79ac609de ("drm/xe/hwmon: expose fan speed")
Signed-off-by: Zhan Wei <zhanwei919@gmail.com>
Reviewed-by: Raag Jadav <raag.jadav@intel.com>
---
v4:
- Add Fixes: tag and collect Reviewed-by from Raag.
v3: https://lore.kernel.org/intel-xe/20260529172449.41504-1-zhanwei919@gmail.com/
- Drop the dedicated Documentation/gpu/xe/xe_hwmon.rst doc and the
index.rst hunk; add a short note under the fan2_input entry in the
existing ABI doc instead, per Raag's feedback.
v2: https://lore.kernel.org/intel-xe/20260529135028.20763-1-zhanwei919@gmail.com/
- Drop the code change that reported a single fan on DG2; document the
shared-tach behaviour instead, per review feedback on v1.
v1: https://lore.kernel.org/intel-xe/20260527115311.13398-1-zhanwei919@gmail.com/
Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon b/Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon
index 55ab45f669ac..0da739d9a816 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon
@@ -251,6 +251,13 @@ Description: RO. Fan 2 speed in RPM.
Only supported for particular Intel Xe graphics platforms.
+ On DG2 the driver always shows two fan channels, because the
+ FSC_READ_NUM_FANS command does not work on some cards. OEMs
+ decide how the fans map to tach channels, so two fans can share
+ one tach line. When that happens, the second channel
+ reads 0 RPM even though the fan is spinning. This is normal, not
+ a bug.
+
What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/fan3_input
Date: March 2025
KernelVersion: 6.16
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v23 06/28] riscv/mm : ensure PROT_WRITE leads to VM_READ | VM_WRITE
From: Deepak Gupta @ 2026-06-02 16:19 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Andreas Schwab, Deepak Gupta via B4 Relay, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Andrew Morton, Liam R. Howlett, Vlastimil Babka, Lorenzo Stoakes,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Conor Dooley,
Rob Herring, Krzysztof Kozlowski, Arnd Bergmann,
Christian Brauner, Peter Zijlstra, Oleg Nesterov, Kees Cook,
Jonathan Corbet, Shuah Khan, Jann Horn, Conor Dooley,
Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
Björn Roy Baron, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Benno Lossin, linux-kernel, linux-fsdevel, linux-mm, linux-riscv,
devicetree, linux-arch, linux-doc, linux-kselftest,
alistair.francis, richard.henderson, jim.shu, andybnac,
kito.cheng, charlie, atishp, evan, cleger, alexghiti,
samitolvanen, broonie, rick.p.edgecombe, rust-for-linux, Zong Li
In-Reply-To: <87tsrli6lt.fsf@email.froward.int.ebiederm.org>
On Tue, Jun 2, 2026 at 3:23 AM Eric W. Biederman <ebiederm@xmission.com> wrote:
>
> Andreas Schwab <schwab@linux-m68k.org> writes:
>
> > On Jun 01 2026, Deepak Gupta wrote:
> >
> >> riscv uses `VM_SHADOW_STACK`. It's just very simple to use `protection_map`
> >> with just `VM_WRITE`. On RISC-V, `-W-` is a shadow stack mapping. It's not same
> >> on x86 or arm64. So `protection_map[VM_WRITE]` simply picks shadow stack
> >> encoding. We just ensure that PROT_WRITE is converted to
> >> "VM_READ | VM_WRITE" at vma level.
> >
> > That does not explain _why_ you need to make that user visible change,
> > when others can get away without it.
>
> Especially since as I recall the decision was made was that the user
> visible protection bits would match the mmap call. If there is some
> combination an architecture does not support that would simply not be
> reflected in hardware until some future version of the hardware gets
> around to supporting it.
>
> This is what happened with executable page permissions on x86 for
> example. It used to be that it was not possible to deny execute
> permission on a readable page. Later that proved sufficiently valuable
> that support for denying execute permission was added to the hardware.
>
> That all happened quite transparently to userspace, that wasn't trying
> to assuming PROT_READ implied PROT_EXEC.
>
> So I am at a complete loss why someone would choose to break userspace
> by confusing hardware limitations with what userspace asks for in mmap.
Initially my plan was to re-use (only) VM_WRITE as (alias to) VM_SHADOW_STACK
on risc-v to match hardware Write-only PTE encoding and I didn't see
any opposition
to that initially. Until later when it was suggested to use distinct
VM_SHADOW_STACK
encoding.
Although there wasn't any oppostion to this patch, seems like it made it in.
Now that I take a look at it, I think it can be made to work. Sorry about that.
Now that I have switched my affiliation to meta, I'll have to spend
some time to set
up risc-v dev environment.
I'll send a patch. Thanks.
>
> Eric
>
^ permalink raw reply
* Re: [PATCH mm-unstable v18 06/14] mm/khugepaged: generalize collapse_huge_page for mTHP collapse
From: Lance Yang @ 2026-06-02 16:34 UTC (permalink / raw)
To: npache
Cc: lance.yang, david, 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, ljs, 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: <CAA1CXcD7peS3WHueVgAWhhRrjBO_1b19+Xc0CfZBSO8OwJJKQw@mail.gmail.com>
On Tue, Jun 02, 2026 at 09:30:06AM -0600, Nico Pache wrote:
>On Mon, Jun 1, 2026 at 4:48 AM Lance Yang <lance.yang@linux.dev> wrote:
>>
>>
>>
>> On 2026/6/1 18:23, David Hildenbrand (Arm) wrote:
>> > On 6/1/26 11:08, Lance Yang wrote:
>> >>
>> >>
>> >> On 2026/6/1 14:54, David Hildenbrand (Arm) wrote:
>> >>> On 6/1/26 05:28, Lance Yang wrote:
>> >>>>
>> >>>>
>> >>>> Ah, fair point.
>> >>>>
>> >>>> I was mostly worried about arch hooks that walk vma->vm_mm again, rather
>> >>>> than only using the pte pointer passed in. For example, mips does:
>> >>>
>> >>> Right, a re-walk would be the real problem.
>> >>>
>> >>>>
>> >>>> update_mmu_cache_range()
>> >>>> -> __update_tlb()
>> >>>> -> pgd_offset(vma->vm_mm, address)
>> >>>> -> pte_offset_map(...)
>> >>>>
>> >>>> and __update_tlb() has this assumption:
>> >>>>
>> >>>> /*
>> >>>> * update_mmu_cache() is called between pte_offset_map_lock()
>> >>>> * and pte_unmap_unlock(), so we can assume that ptep is not
>> >>>> * NULL here: and what should be done below if it were NULL?
>> >>>> */
>> >>>>
>> >>>> So if khugepaged happens to run with current->active_mm == vma->vm_mm
>> >>>> here, could __update_tlb() hit the none PMD, get NULL from
>> >>>> pte_offset_map(), and then dereference it?
>> >>>
>> >>> Likely yes -- that MIPS code is horrible. And the comment in MIPS code
>> >>> even spells that out. :(
>> >>>
>> >>> Do you know about other code like that, or is MIPS the only one doing a
>> >>> re-walk and crossing fingers?
>> >>>
>> >>>>
>> >>>> Just wanted to raise it since some arch code may still have assumptions
>> >>>> like this, and the always-enable-mTHP work is getting closer ...
>> >>>
>> >>> Right. I assume set_pte_at() couldn't trigger something similar (re-walk) in
>> >>> arch code,
>> >>> because we simply provide the ptep. update_mmu_cache_range() only consumes the
>> >>> pte.
>> >>>
>> >>>>
>> >>>> Probably very very very hard to hit, though :)
>> >>>
>> >>> Delaying update_mmu_cache_range() is nasty, as we'd have to make sure that
>> >>> nobody can interfere in the meantime ... and the PMD lock will not be sufficient.
>> >>>
>> >>> Maybe we could reinstall the page table with the cleared (none) entries while
>> >>> still holding the PTL?
>> >>>
>> >>> Thinking out loud:
>> >>>
>> >>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>> >>> index 5ba298d420b7..e39b750b1e6f 100644
>> >>> --- a/mm/khugepaged.c
>> >>> +++ b/mm/khugepaged.c
>> >>> @@ -1413,13 +1413,17 @@ static enum scan_result collapse_huge_page(struct
>> >>> mm_struct *mm, unsigned long s
>> >>> map_anon_folio_pmd_nopf(folio, pmd, vma, pmd_addr);
>> >>> } else {
>> >>> /*
>> >>> - * set_ptes is called in map_anon_folio_pte_nopf with the
>> >>> - * pmd_ptl lock still held; this is safe as the PMD is expected
>> >>> - * to be none. The pmd entry is then repopulated below.
>> >>> + * Re-insert the page table with the cleared entries, but
>> >>> + * hold the PTL, such that no one can mess with the re-installed
>> >>> + * page table until we updated the temporarily-cleared entries
>> >>> + * through map_anon_folio_pte_nopf().
>> >>> */
>> >>> - map_anon_folio_pte_nopf(folio, pte, vma, start_addr, /
>> >>> *uffd_wp=*/ false);
>> >>> - smp_wmb(); /* make PTEs visible before PMD. See pmd_install() */
>> >>
>> >> One small thing, I think we should probably keep the smp_wmb(), and just
>> >> move it before the earlier pmd_populate().
>> >>
>> >> IIUC, the ordering we want is still:
>> >>
>> >> clear old PTEs
>> >> smp_wmb()
>> >> pmd_populate()
>> >>
>> >> so another CPU cannot walk through the re-installed PMD and still observe
>> >> the old PTEs, right?
>> >
>> > There is a smp_wmb() in __folio_mark_uptodate(), that should be sufficient?
>>
>> Ah, cool! __folio_mark_uptodate() already does the job :P
>>
>> So yeah, no extra smp_wmb() needed here!
>
>are we sure? that folio_mark_uptodate is done before the PTEs are
>reinstalled. Then we reinstall the PMD right after. Currently
>separated by the smp_wmb().
Reinstalling the PMD first makes the PTE table reachable again, right?
So before pmd_populate(), we only need to order the old PTE clears before
the PTE table is reachable again; __folio_mark_uptodate() already has the
smp_wmb() for that :)
The new PTEs are filled later under the PTL.
Hopefully I didn't miss soemthing :)
>I was copying this from other THP code that performs similar PTE/PMD juggling.
>
>I can remove it, but I'd rather air on the side of caution with this.
Cheers, Lance
^ permalink raw reply
* Re: [PATCH v4 2/2] hwmon: (pmbus/max20860a) Add driver for Analog Devices MAX20860A
From: Pradhan, Sanman @ 2026-06-02 16:34 UTC (permalink / raw)
To: sashiko-bot@kernel.org
Cc: linux-hwmon@vger.kernel.org, linux@roeck-us.net, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, corbet@lwn.net,
skhan@linuxfoundation.org, devicetree@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
noname.nuno@gmail.com, Syed, Arif, Sanman Pradhan,
sashiko-reviews@lists.linux.dev
In-Reply-To: <20260601190606.8BADC1F00893@smtp.kernel.org>
From: Sanman Pradhan <psanman@juniper.net>
On Mon, Jun 01, 2026 at 19:06:06 +0000, sashiko-bot@kernel.org wrote:
> [Severity: High]
> Will this prevent the regulator core from matching the device tree node?
>
> The PMBUS_REGULATOR_ONE("vout") macro sets of_match to "vout". During
> registration, the regulator core searches for a child node named "vout"
> or a parent node with that exact name to associate the of_node.
>
> If the device tree schema expects regulator properties directly on the
> parent node (which is typically named generically, like regulator@xx),
> will the regulator core fail to match the node?
>
> If the match fails, the regulator is registered with of_node = NULL,
> which silently ignores regulator constraints and prevents consumers
> from referencing it as a supply.
The Sashiko AI Review is right that with a generic node like regulator@xx
and no "vout" child, DT init data is NULL.
But that only means no DT constraints were provided; the regulator still
registers successfully and the PMBus regulator ops remain functional.
Saw a similar single-output PMBus regulator pattern [PMBUS_REGULATOR_ONE("vout")]
in drivers/hwmon/pmbus/ir38064.c, just followed that.
Thank you.
Regards,
Sanman Pradhan
^ permalink raw reply
* Re: [PATCH v19 00/14] crypto/dmaengine: qce: introduce BAM locking and use DMA for register I/O
From: Stephan Gerhold @ 2026-06-02 16:38 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Bjorn Andersson, Peter Ujfalusi,
Michal Simek, Frank Li, Andy Gross, Neil Armstrong, dmaengine,
linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski, Dmitry Baryshkov,
Konrad Dybcio
In-Reply-To: <20260526-qcom-qce-cmd-descr-v19-0-08472fdcbf4a@oss.qualcomm.com>
On Tue, May 26, 2026 at 03:10:48PM +0200, Bartosz Golaszewski wrote:
> I feel like I fell into the trap of trying to address pre-existing
> issues reported by sashiko and in the process provoking more reports so
> let this be the last iteration where I do this. Vinod can we get this
> queued for v7.2 now and iron out any previously existing problems in
> tree?
Thanks a lot for working on fixing all these issues!
I agree there is no point addressing all the "pre-existing issues"
pointed out by Sashiko, but have you looked through the other comments
for new issues pointed out for your patches?
Out of curiosity, I was looking a bit at the comments for [PATCH v19
06/14] dmaengine: qcom: bam_dma: add support for BAM locking [1]. There
are 8 open comments there (Critical: 1, High: 6 and Medium: 1). From a
quick look I would say most of these could be valid. The critical one
about the usage of dma_cookie_assign() sounds a bit concerning to me, if
it is true we would be basically breaking parts of the dmaengine API for
consumers by inserting the lock descriptor in front of everything else.
[1]: https://sashiko.dev/#/patchset/20260526-qcom-qce-cmd-descr-v19-0-08472fdcbf4a%40oss.qualcomm.com?part=6
Thanks,
Stephan
^ permalink raw reply
* Re: [PATCH v4 07/13] kho: add support for linked-block serialization
From: Pratyush Yadav @ 2026-06-02 16:43 UTC (permalink / raw)
To: Pasha Tatashin
Cc: Pratyush Yadav, linux-kselftest, rppt, shuah, akpm, linux-mm,
skhan, linux-doc, linux-kernel, corbet, dmatlack, kexec, skhawaja,
graf
In-Reply-To: <ah2OeTDFltPWwsik@google.com>
On Mon, Jun 01 2026, Pasha Tatashin wrote:
> On 06-01 15:38, Pratyush Yadav wrote:
>> On Sat, May 30 2026, Pasha Tatashin wrote:
>>
>> > Introduce a linked-block serialization mechanism for state handover.
>> >
>> > Previously, LUO used contiguous memory blocks for serializing sessions
>> > and files, which imposed limits on the total number of items that could
>> > be preserved across a live update.
>> >
>> > This commit adds the infrastructure for a more flexible, block-based
>> > approach where serialized data is stored in a chain of linked blocks.
>> > This is a generic KHO serialization block infrastructure that can be
>> > used by multiple subsystems.
>> >
>> > Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
[...]
>> > +/**
>> > + * DOC: KHO Serialization Blocks ABI
>> > + *
>> > + * Subsystems using the KHO Serialization Blocks framework rely on the stable
>> > + * Application Binary Interface defined below to pass serialized state from a
>> > + * pre-update kernel to a post-update kernel.
>> > + *
>> > + * This interface is a contract. Any modification to the structure fields,
>> > + * compatible strings, or the layout of the `__packed` serialization
>> > + * structures defined here constitutes a breaking change. Such changes require
>> > + * incrementing the version number in the `KHO_BLOCK_ABI_COMPATIBLE` string to
>> > + * prevent a new kernel from misinterpreting data from an old kernel.
>> > + *
>> > + * Changes are allowed provided the compatibility version is incremented;
>> > + * however, backward/forward compatibility is only guaranteed for kernels
>> > + * supporting the same ABI version.
>> > + */
>> > +
>> > +#ifndef _LINUX_KHO_ABI_BLOCK_H
>> > +#define _LINUX_KHO_ABI_BLOCK_H
>> > +
>> > +#include <asm/page.h>
>> > +#include <linux/types.h>
>> > +
>> > +#define KHO_BLOCK_ABI_COMPATIBLE "kho-block-v1"
>>
>> During KHO radix development, I argued for a separate compatible for the
>> radix tree, but at that time, we tied the radix tree to core KHO ABI.
>> The argument being that all core KHO data structures belong to the KHO
>> ABI set. I imagine this will be used by kho_vmalloc, so it will also be
>> end up being used by a core KHO API.
>>
>> So, do we want separate ABI? I don't much have a preference myself, but
>> I do think the compatible management will be a bit easier if this relied
>> on KHO compatible, especially once kho_vmalloc starts using it.
>
> I prefer to make them fine-grained, now that we are adding more and more
> features: kho vmalloc, kho radix, and kho block should all have their
> own compatibility strings. Furthermore, any components that depend on
> them should include these compatibility strings in their own
> compatibility strings, in the same manner I have done in this series.
Sure, sounds good.
>
>>
>> > +
>> > +/**
>> > + * KHO_BLOCK_SIZE - The size of each serialization block.
>> > + *
>> > + * This is defined as PAGE_SIZE. PAGE_SIZE is ABI compliant because live
>> > + * update between kernels with different page sizes is not supported by KHO.
>> > + */
>> > +#define KHO_BLOCK_SIZE PAGE_SIZE
>> > +
>> > +/**
>> > + * struct kho_block_header_ser - Header for the serialized data block.
>> > + * @next: Physical address of the next struct kho_block_header_ser.
>> > + * @count: The number of entries that immediately follow this header in the
>> > + * memory block.
>> > + *
>> > + * This structure is located at the beginning of a block of physical memory
>> > + * preserved across a kexec. It provides the necessary metadata to interpret
>> > + * the array of entries that follow.
>> > + */
>> > +struct kho_block_header_ser {
>> > + u64 next;
>> > + u64 count;
>> > +} __packed;
>> > +
>> > +#endif /* _LINUX_KHO_ABI_BLOCK_H */
>> > diff --git a/include/linux/kho_block.h b/include/linux/kho_block.h
>> > new file mode 100644
>> > index 000000000000..5e6b87b1befa
>> > --- /dev/null
>> > +++ b/include/linux/kho_block.h
>> > @@ -0,0 +1,79 @@
>> > +/* SPDX-License-Identifier: GPL-2.0 */
>> > +/*
>> > + * Copyright (c) 2026, Google LLC.
>> > + * Pasha Tatashin <pasha.tatashin@soleen.com>
>> > + */
>> > +
>> > +#ifndef _LINUX_KHO_BLOCK_H
>> > +#define _LINUX_KHO_BLOCK_H
>> > +
>> > +#include <linux/list.h>
>> > +#include <linux/types.h>
>> > +#include <linux/kho/abi/block.h>
>> > +
>> > +/**
>> > + * struct kho_block - Internal representation of a serialization block.
>> > + * @list: List head for linking blocks in memory.
>> > + * @ser: Pointer to the serialized header in preserved memory.
>> > + */
>> > +struct kho_block {
>> > + struct list_head list;
>> > + struct kho_block_header_ser *ser;
>> > +};
>> > +
>> > +/**
>> > + * struct kho_block_set - A set of blocks that belong to the same object.
>> > + * @blocks: The list of serialization blocks (struct kho_block).
>> > + * @nblocks: The number of allocated serialization blocks.
>> > + * @head_pa: Physical address of the first block header.
>> > + * @entry_size: The size of each entry in the blocks.
>> > + * @count_per_block: The maximum number of entries each block can hold.
>> > + * @incoming: True if this block set was restored from the previous kernel.
>> > + */
>> > +struct kho_block_set {
>> > + struct list_head blocks;
>> > + long nblocks;
>> > + u64 head_pa;
>> > + size_t entry_size;
>>
>> I think we should add the entry_size to kho_block_header_ser? I think it
>> is a part of the ABI of the block set. If this changes, we cannot parse
>> a block set with a different size. If a subsystem wants to change entry
>> size, they create a new block set with different entry size, and then
>> they bump their compatible version.
>
> I have considered that, and we can certainly do it; however, I do not
> see how it would affect the current implementation. If luo_file or
> luo_session change entry_size, they must change the LUO compatibility
> version, which would prevent LU from one kernel to the next. However,
> for flexibility and future extensibility, I believe it would be useful
> to add entry_size and block_size (which is PAGE_SIZE, but could be
> larger for some users) to the header. This is more of a feature request
> than an issue with the current series.
My suggestion was mainly for sanity checking. So if LUO or another user
inadvertently changes entry size, it gets caught. But thinking about it
more, there are a million other ways to break compatibility while
keeping the entry size same so perhaps it doesn't matter as much...
>
>>
>> > + u64 count_per_block;
>> > + bool incoming;
>> > +};
>> > +
>> > +/**
>> > + * struct kho_block_it - Iterator for serializing entries into blocks.
>> > + * @bs: The block set being iterated.
>> > + * @block: The current block.
>> > + * @i: The current entry index within @block.
>> > + */
>> > +struct kho_block_it {
>> > + struct kho_block_set *bs;
>> > + struct kho_block *block;
>> > + u64 i;
>> > +};
>> > +
>> > +/**
>> > + * KHO_BLOCK_SET_INIT - Initialize a static kho_block_set.
>> > + * @_name: Name of the kho_block_set variable.
>> > + * @_entry_size: The size of each entry in the block set.
>> > + */
>> > +#define KHO_BLOCK_SET_INIT(_name, _entry_size) { \
>> > + .blocks = LIST_HEAD_INIT((_name).blocks), \
>> > + .entry_size = _entry_size, \
>> > +}
>> > +
>> > +void kho_block_set_init(struct kho_block_set *bs, size_t entry_size);
>> > +
>> > +int kho_block_grow(struct kho_block_set *bs, u64 count);
>> > +void kho_block_shrink(struct kho_block_set *bs, u64 count);
>>
>> These block management functions seem like internal details of the block
>
> This is not so. The confusion here is that they must be allocated and
> preserved at runtime as resources are registered/unregistered, while
> these blocks are only used serialization phase,
>
> These calls are more like notifiers that more files/sessions are created
> removed, so we can adjust block count accordingly if necessary (allocate
> preserver memory), and have them available durign
> serialization/deserialization
Yeah, I got that when reading the later patches that use these.
Perhaps kho_block_prealloc() and kho_block_unalloc() is more clear,
although it does not sound as nice. If not, then I suppose at least add
a comment explaining the intended usage.
>
>> set API. Do we need to export them? I think users should not have to
>> worry about block management. They should read, set, or clear entries
>> using the iterators, and internally the block management should take of
>> allocation or freeing. So here for example, I th
>
> something is missing :-)
I don't remember what I meant to say anymore :-/
[...]
>> > +/**
>> > + * kho_block_set_init - Initialize a block set.
>> > + * @bs: The block set to initialize.
>> > + * @entry_size: The size of each entry in the blocks.
>> > + */
>> > +void kho_block_set_init(struct kho_block_set *bs, size_t entry_size)
>> > +{
>> > + *bs = (struct kho_block_set)KHO_BLOCK_SET_INIT(*bs, entry_size);
>> > +}
>> > +
>> > +static inline u64 kho_block_count_per_block(struct kho_block_set *bs)
>> > +{
>> > + if (unlikely(!bs->count_per_block)) {
>> > + bs->count_per_block = (KHO_BLOCK_SIZE -
>> > + sizeof(struct kho_block_header_ser)) /
>> > + bs->entry_size;
>> > + WARN_ON(!bs->count_per_block);
>> > + }
>> > + return bs->count_per_block;
>> > +}
>>
>> This looks odd. I don't see a reason to calculate this lazily. Why not
>> just do it when initializing the block set, in kho_block_set_init() or
>> kho_block_restore()? And then use bs->count_per_block directly.
>
> This allows for blocks to use static initilziation, I like static inits
> :-)
You can do this:
#define KHO_BLOCK_SET_INIT(_name, _entry_size) { \
.blocks = LIST_HEAD_INIT((_name).blocks), \
.entry_size = _entry_size, \
.count_per_block = (KHO_BLOCK_SIZE - sizeof(struct kho_block_header_ser)) / (_entry_size), \
}
Compiles for me.
[...]
>> > +void kho_block_destroy(struct kho_block_set *bs)
>> > +{
>> > + u64 head_pa = bs->head_pa;
>> > + struct kho_block *block;
>> > +
>> > + while (!list_empty(&bs->blocks)) {
>> > + block = list_first_entry(&bs->blocks, struct kho_block, list);
>> > + list_del(&block->list);
>> > + kfree(block);
>> > + }
>>
>> Nit:
>>
>> list_for_each_entry_safe(block, tmp, &bs->blocks, list) {
>> list_del(&block->list);
>> kfree(block);
>> }
>>
>> is a bit more idiomatic (and IMO easier to read).
>
> Sure
>
>>
>> > + bs->nblocks = 0;
>> > + bs->head_pa = 0;
>> > +
>> > + while (head_pa) {
>> > + struct kho_block_header_ser *ser = phys_to_virt(head_pa);
>> > +
>> > + head_pa = ser->next;
>> > + kho_block_free_ser(bs, ser);
>>
>> Nit: also, can't you put this also in the previous loop? Something like:
>>
>> list_for_each_entry_safe(block, tmp, &bs->blocks, list) {
>> list_del(&block->list);
>> kho_block_free_ser(block->ser);
>> kfree(block);
>> }
>
> We actually can't merge these into a single loop because of partial
> restoration failures handling in kho_block_restore().
>
> If kho_block_restore fails halfway through restoring a chain of blocks
> (for example, if kho_block_add fails on block 3 of 5), we jump to the
> err_destroy cleanup path which calls kho_block_destroy().
>
> At this point:
> - bs->blocks only contains the tracked blocks we successfully added
> (blocks 1 and 2).
> - bs->head_pa still points to the physical head of the entire 5-block
> incoming chain.
>
> But, this is a good place to add a comment.
IMO it would be cleaner for kho_block_destroy() to destroy the currently
initialized block set, and then the error handling path in restore path
can clean up the rest.
>
>> > + }
>> > +}
[...]
>> > +/**
>> > + * kho_block_it_prev - Return the previous entry slot in the block set.
>> > + * @it: The block iterator.
>> > + *
>> > + * If the current index is at the start of a block, it automatically moves to
>> > + * the end of the previous block.
>> > + *
>> > + * Return: A pointer to the previous entry slot, or NULL if at the very
>> > + * beginning of the block set.
>> > + */
>> > +void *kho_block_it_prev(struct kho_block_it *it)
>> > +{
>> > + if (!it->block)
>> > + return NULL;
>> > +
>> > + if (it->i == 0) {
>> > + if (list_is_first(&it->block->list, &it->bs->blocks))
>> > + return NULL;
>> > + it->block = list_prev_entry(it->block, list);
>> > + it->i = kho_block_count_per_block(it->bs);
>> > + }
>> > +
>> > + return (void *)(it->block->ser + 1) + (--it->i * it->bs->entry_size);
>> > +}
>> > +
>> > +/**
>> > + * kho_block_it_finalize - Finalize the current block by setting its entry count.
>> > + * @it: The block iterator.
>> > + */
>> > +void kho_block_it_finalize(struct kho_block_it *it)
>> > +{
>> > + if (it->block)
>> > + it->block->ser->count = it->i;
>> > +}
>>
>> Doesn't kho_block_it_next() already do this when you add an entry? So
>> this seems redundant.
>
> It is not redundant because of how the final partially-fille block is handled.
>
> kho_block_it_next() only writes the count into the block header when a block is completely full and it is advancing to the next one:
>
> if (it->i == kho_block_count_per_block(it->bs)) {
> it->block->ser->count = it->i;
> ...
>
> But for the very last block in the set, it is usually only partially
> filled (e.g., we write 10 entries into a block with a capacity of 64).
> Since it->i never reaches the maximum capacity, kho_block_it_next()
> never commits its count.
>
> Pasha
I think we can make kho_block_it_next() always write it. I think it
makes sense from an API point of view, since I see this API as "adding
an entry to the block set", so updating its internal counters makes
sense.
Requiring the finalize will be error prone, since it is easy to forget.
Then you silently lose some entries on the next boot.
--
Regards,
Pratyush Yadav
^ permalink raw reply
* Re: [RFC PATCH 0/5] mm, swap: Virtual Swap Space (Swap Table Edition)
From: Kairui Song @ 2026-06-02 16:43 UTC (permalink / raw)
To: Nhat Pham
Cc: Liam.Howlett, akpm, apopple, axelrasmussen, baohua, baolin.wang,
bhe, byungchul, cgroups, chengming.zhou, chrisl, corbet, david,
dev.jain, gourry, hannes, hughd, jannh, joshua.hahnjy, lance.yang,
lenb, linux-doc, linux-kernel, linux-mm, linux-pm,
lorenzo.stoakes, matthew.brost, mhocko, muchun.song, npache,
pavel, peterx, peterz, pfalcato, rafael, rakie.kim,
roman.gushchin, rppt, ryan.roberts, shakeel.butt, shikemeng,
surenb, tglx, vbabka, weixugc, ying.huang, yosry.ahmed, yuanchu,
zhengqi.arch, ziy, kernel-team, riel, haowenchao22
In-Reply-To: <CAKEwX=M3WAkSY=Zd35dEuQ6V3ZiNR02bKAN_DnCgVr69w9=0sQ@mail.gmail.com>
On Tue, Jun 2, 2026 at 11:54 PM Nhat Pham <nphamcs@gmail.com> wrote:
>
> On Mon, Jun 1, 2026 at 10:49 AM Kairui Song <ryncsn@gmail.com> wrote:
> >
> >
> > That part should be indeed coverable by the si->percpu cluster though, I think.
>
> Yeah agree - we just need to be a bit craftier with it. The
> fundamental problem is in the current model, we're only storing offset
> and si, then look up cluster based on that. But for dynamic vswap,
> that look up takes the xa_load().
>
> Once we move to per-si per-cpu cluster, then I think it becomes ok to
> store the cluster pointer directly, correct?
>
> The reference counting needs to be carefully handled though. I think
> in my old vss design I did something fairly silly - just hold a
> reference to it while it's in cache, then add CPU offlining handler to
> clean up. Not the end of the world I suppose, but maybe there's a
> smarter scheme.
Yeah... I'm not entirely sure about this at this point, maybe it can
be sorted out as we process. Maybe we can also avoid the xa_load with
other techniques too.
^ permalink raw reply
* Re: [PATCH v15 06/12] iio: core: add decimal value formatting into 64-bit value
From: Nuno Sá @ 2026-06-02 16:56 UTC (permalink / raw)
To: Rodrigo Alencar, rodrigo.alencar
Cc: linux-kernel, linux-iio, devicetree, linux-doc, Jonathan Cameron,
David Lechner, Andy Shevchenko, Lars-Peter Clausen,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Andrew Morton, Petr Mladek, Steven Rostedt,
Andy Shevchenko, Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan
In-Reply-To: <u7p5ndqqh3ngnmmzoir37yuc3hfm2llenaihuekwuwoji743mf@itbbdxfo4qan>
On Mon, 2026-06-01 at 16:12 +0100, Rodrigo Alencar wrote:
> On 26/06/01 10:43AM, Nuno Sá wrote:
> > On Sun, May 31, 2026 at 09:30:49AM +0100, Rodrigo Alencar via B4 Relay wrote:
> > > From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> > >
> > > Create new format types for iio values (IIO_VAL_DECIMAL64_*), which
> > > defines the representation of fixed decimal point values into a single
> > > 64-bit number. This new format increases the range of represented values,
> > > allowing for integer parts greater than 2^32, as bits are not "wasted"
> > > in the fractional part, which can be seen in IIO_VAL_INT_PLUS_MICRO and
> > > IIO_VAL_INT_PLUS_NANO. Helpers are created to compose and decompose 64-bit
> > > decimals into integer values used in IIO formatting interfaces, which
> > > creates consistency and avoid error-prone manual assignments when using
> > > wordpart macros. When doing the parsing, kstrtodec64() is used with the
> > > scale defined by the specific decimal format type.
> > >
> > > Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
> > > ---
> > > drivers/iio/industrialio-core.c | 47 +++++++++++++++++++++++++++++++++--------
> > > include/linux/iio/types.h | 30 ++++++++++++++++++++++++++
> > > 2 files changed, 68 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> > > index bd6f4f9f4533..a88088cac641 100644
> > > --- a/drivers/iio/industrialio-core.c
> > > +++ b/drivers/iio/industrialio-core.c
> > > @@ -19,6 +19,7 @@
> > > #include <linux/idr.h>
> > > #include <linux/kdev_t.h>
> > > #include <linux/kernel.h>
> > > +#include <linux/math64.h>
> > > #include <linux/module.h>
> > > #include <linux/mutex.h>
> > > #include <linux/poll.h>
> > > @@ -26,7 +27,6 @@
> > > #include <linux/sched.h>
> > > #include <linux/slab.h>
> > > #include <linux/wait.h>
> > > -#include <linux/wordpart.h>
> > >
> > > #include <linux/iio/buffer.h>
> > > #include <linux/iio/buffer_impl.h>
> > > @@ -655,6 +655,7 @@ static ssize_t __iio_format_value(char *buf, size_t offset,
> > > unsigned int type,
> > > int size, const int *vals)
> > > {
> > > int tmp0, tmp1;
> > > + int l = 0;
> > > s64 tmp2;
> > > bool scale_db = false;
> > >
> > > @@ -698,7 +699,6 @@ static ssize_t __iio_format_value(char *buf, size_t offset,
> > > unsigned int type,
> > > case IIO_VAL_INT_MULTIPLE:
> > > {
> > > int i;
> > > - int l = 0;
> > >
> > > for (i = 0; i < size; ++i)
> > > l += sysfs_emit_at(buf, offset + l, "%d ", vals[i]);
> > > @@ -707,8 +707,25 @@ static ssize_t __iio_format_value(char *buf, size_t
> > > offset, unsigned int type,
> > > case IIO_VAL_CHAR:
> > > return sysfs_emit_at(buf, offset, "%c", (char)vals[0]);
> > > case IIO_VAL_INT_64:
> > > - tmp2 = (s64)((((u64)vals[1]) << 32) | (u32)vals[0]);
> > > + tmp2 = iio_val_s64_from_s32s(vals);
> >
> > I might be missing something but can't we just call
> > iio_val_s64_compose()? Likely even inline in sysfs_emit_at()?
>
> There is a compose() already.
>
Yes and I was suggesting using that one instead iio_val_s64_from_s32s() :). To be
consistent to what you use in the other path (which is decompose() if I'm not
mistaken).
>
> > It would match your call to iio_val_s64_decompose() below.
>
> here are the helpers prototype:
>
> s64 iio_val_s64_compose(s32 val0, s32 val1);
> s64 iio_val_s64_from_s32s(const s32 *vals);
>
> void iio_val_s64_decompose(s64 dec64, s32 *val0, s32 *val1);
> void iio_val_s64_to_s32s(s64 dec64, s32 *vals);
>
Yes and it feels that iio_val_s64_compose() and iio_val_s64_decompose() are the only
ones we really need? (Maybe with other naming if you prefer iio_val_s64_from_s32s()
and iio_val_s64_to_s32s()).
> > And the above makes me wonder if the compose()/decompose() are not the
> > only helpers we need? At least in terms of parameters? I mean, just
> > assuming we only have two integers instead of allowing s32* and opening
> > the door for misbehave :)?
>
> I suppose we would really need some sort of:
>
> union iio_val {
> s32 val32[2];
> s64 val64;
> };
>
> or even add a:
>
> struct { void *ptr, size_t size }
I just meant using two where we just have (s32 val1, s32 vals2) given that is
what IIO has anyways. No need to overthinking it for now IMO.
- Nuno Sá
> > - Nuno Sá
> >
^ permalink raw reply
* Re: [PATCH] KVM: x86/xen: Add KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE
From: David Woodhouse @ 2026-06-02 17:01 UTC (permalink / raw)
To: xadimgnik
Cc: bp, corbet, dave.hansen, dwmw2, hpa, kvm, linux-doc, linux-kernel,
linux-kselftest, mingo, pbonzini, seanjc, skhan, tglx, x86
In-Reply-To: <d56d47ab-1306-4b33-9120-8849a7b33928@xen.org>
[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]
On Wed, 29 Apr 2026 12:36:52 +0200, Paul Durrant wrote:
> On 28/04/2026 21:12, David Woodhouse wrote:
> > From: David Woodhouse <dwmw@amazon.co.uk>
> >
> > Commit 3617c0ee7decb ("KVM: x86/xen: Only write Xen hypercall page for
> > guest writes to MSR") blocked host-initiated writes from triggering the
> > Xen hypercall page setup, to fix an SRCU usage violation when the
> > hypercall MSR index collides with a real MSR written during vCPU reset.
> >
> > However, some VMMs legitimately need to trigger hypercall page setup
> > from host context. For example, a VMM may intercept the guest's MSR
> > write to track an epoch (for kexec/crash recovery), and then replay the
> > write as a host-initiated KVM_SET_MSRS to populate the hypercall page.
> > The host_initiated check breaks this use case.
> >
> > Add KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE as a new vcpu attribute
> > that explicitly invokes kvm_xen_write_hypercall_page() under proper
> > locking. This gives userspace a safe interface to trigger hypercall page
> > setup without going through the MSR write path, preserving the
> > host_initiated defence in depth while restoring the lost functionality.
> >
> > Fixes: 3617c0ee7dec ("KVM: x86/xen: Only write Xen hypercall page for guest writes to MSR")
> > Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> > ---
> > Documentation/virt/kvm/api.rst | 11 +++
> > arch/x86/include/uapi/asm/kvm.h | 3 +
> > arch/x86/kvm/x86.c | 3 +-
> > arch/x86/kvm/xen.c | 7 ++
> > .../selftests/kvm/x86/xen_vmcall_test.c | 96 +++++++++++++++++++
> > 5 files changed, 119 insertions(+), 1 deletion(-)
>
> Reviewed-by: Paul Durrant <paul@xen.org>
Ping?
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH v5 04/13] liveupdate: register luo_ser as KHO subtree
From: Pratyush Yadav @ 2026-06-02 17:02 UTC (permalink / raw)
To: Pasha Tatashin
Cc: linux-kselftest, rppt, shuah, akpm, linux-mm, skhan, linux-doc,
linux-kernel, corbet, dmatlack, kexec, pratyush, skhawaja, graf
In-Reply-To: <20260602031717.197696-5-pasha.tatashin@soleen.com>
On Tue, Jun 02 2026, Pasha Tatashin wrote:
> Entirely remove the LUO FDT wrapper since the FDT only carries the
> compatible string and the pointer to the centralized struct luo_ser.
> Instead, register the struct luo_ser via the KHO raw subtree
> API, placing the compatibility string inside the structure itself.
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Reviewed-by: Pratyush Yadav (Google) <pratyush@kernel.org>
[...]
--
Regards,
Pratyush Yadav
^ permalink raw reply
* Re: [PATCH v5 08/13] liveupdate: defer session block allocation and PA setting
From: Pratyush Yadav @ 2026-06-02 17:06 UTC (permalink / raw)
To: Pasha Tatashin
Cc: linux-kselftest, rppt, shuah, akpm, linux-mm, skhan, linux-doc,
linux-kernel, corbet, dmatlack, kexec, pratyush, skhawaja, graf
In-Reply-To: <20260602031717.197696-9-pasha.tatashin@soleen.com>
On Tue, Jun 02 2026, Pasha Tatashin wrote:
> Currently, luo_session_setup_outgoing() allocates the session block and
> sets its physical address in the header immediately. With upcoming
> dynamic block-based session management, this makes the first block
> different from the rest. Move the allocation to where it is first needed.
>
> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Reviewed-by: Pratyush Yadav (Google) <pratyush@kernel.org>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> ---
> include/linux/kho_block.h | 22 +++++++++++
> kernel/liveupdate/luo_core.c | 4 +-
> kernel/liveupdate/luo_internal.h | 2 +-
> kernel/liveupdate/luo_session.c | 68 ++++++++++++++++++++------------
> 4 files changed, 67 insertions(+), 29 deletions(-)
>
> diff --git a/include/linux/kho_block.h b/include/linux/kho_block.h
> index 505bf78409f2..0a8cda2cbfb5 100644
> --- a/include/linux/kho_block.h
> +++ b/include/linux/kho_block.h
> @@ -70,6 +70,28 @@ int kho_block_set_restore(struct kho_block_set *bs, u64 head_pa);
> void kho_block_set_destroy(struct kho_block_set *bs);
> void kho_block_set_clear(struct kho_block_set *bs);
>
> +/**
> + * kho_block_set_head_pa - Get the physical address of the first block header.
> + * @bs: The block set.
> + *
> + * Return: The physical address of the first block header, or 0 if empty.
> + */
> +static inline u64 kho_block_set_head_pa(struct kho_block_set *bs)
> +{
> + return bs->head_pa;
> +}
> +
> +/**
> + * kho_block_set_is_empty - Check if the block set has no allocated blocks.
> + * @bs: The block set.
> + *
> + * Return: True if there are no blocks in the set, false otherwise.
> + */
> +static inline bool kho_block_set_is_empty(struct kho_block_set *bs)
> +{
> + return list_empty(&bs->blocks);
> +}
> +
Are these intended to be here or should they go in patch 7?
> void kho_block_it_init(struct kho_block_it *it, struct kho_block_set *bs);
> void *kho_block_it_reserve_entry(struct kho_block_it *it);
> void *kho_block_it_read_entry(struct kho_block_it *it);
[...]
--
Regards,
Pratyush Yadav
^ permalink raw reply
* Re: [PATCH v5 10/13] liveupdate: Remove limit on the number of files per session
From: Pratyush Yadav @ 2026-06-02 17:07 UTC (permalink / raw)
To: Pasha Tatashin
Cc: linux-kselftest, rppt, shuah, akpm, linux-mm, skhan, linux-doc,
linux-kernel, corbet, dmatlack, kexec, pratyush, skhawaja, graf
In-Reply-To: <20260602031717.197696-11-pasha.tatashin@soleen.com>
On Tue, Jun 02 2026, Pasha Tatashin wrote:
> To remove the fixed limit on the number of preserved files per session,
> transition the file metadata serialization from a single contiguous
> memory block to a chain of linked blocks.
>
> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Reviewed-by: Pratyush Yadav (Google) <pratyush@kernel.org>
[...]
--
Regards,
Pratyush Yadav
^ permalink raw reply
* Re: [PATCH mm-unstable v18 11/14] mm/khugepaged: Introduce mTHP collapse support
From: Nico Pache @ 2026-06-02 17:23 UTC (permalink / raw)
To: David Hildenbrand (Arm)
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, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
lance.yang, liam, ljs, 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, vbabka, vishal.moola,
wangkefeng.wang, will, willy, yang, ying.huang, ziy, zokeefe,
Usama Arif, usamaarif642
In-Reply-To: <d3c2b00c-6810-434a-b837-0707b0a11611@kernel.org>
On 6/1/26 7:15 AM, David Hildenbrand (Arm) wrote:
>>>
>>> Reading this, it is unclear why exactly do we need the stack.
>>
>> So I looked into your items below. It seems logical, and I think it
>> works the same way; however, your method seems slightly harder to
>> understand due to all the edge cases and more error-prone to future
>> changes (the stack holds implicit knowledge of the offset/order that
>> must now be tracked in the edge cases).
>>
>> Given the stack is 24 bytes, I'm not sure if the extra complexity is
>> worth saving that small amount of memory. Although we would also be
>> getting rid of (3?) functions, so both approaches have pros and cons.
>
> I consider a simple forward loop over the offset ... less complexity compared to
> a stack structure :)
>
>>
>> I will implement a patch comparing your solution against mine and send
>> it here, then we can decide which approach is better.
>
> Right, throw it over the fence and I'll see how to improve it further.
Ok heres what the diff looks like on top of my V19.
you can access the tree here https://gitlab.com/npache/linux/-/commits/mthp-v19?ref_type=heads for easier review.
So far I have no problem with this approach it appeared cleaner than i thought. Did some light testing. Gonna throw it more through the ringer tomorrow.
From 9496c5d17eba7f6d04820d78c7c6f1592a58888a Mon Sep 17 00:00:00 2001
From: Nico Pache <npache@redhat.com>
Date: Tue, 2 Jun 2026 10:26:18 -0600
Subject: [PATCH] convert from stack to forward loop
Signed-off-by: Nico Pache <npache@redhat.com>
---
mm/khugepaged.c | 96 ++++++++-----------------------------------------
1 file changed, 15 insertions(+), 81 deletions(-)
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 498eba009751..6de935e76ceb 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -100,28 +100,6 @@ 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;
@@ -137,7 +115,6 @@ struct collapse_control {
/* Each bit represents a single occupied (!none/zero) page. */
DECLARE_BITMAP(mthp_present_ptes, MAX_PTRS_PER_PTE);
- struct mthp_range mthp_bitmap_stack[MTHP_STACK_SIZE];
};
/**
@@ -1458,50 +1435,14 @@ 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];
-}
-
/*
* 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_present_ptes 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_present_ptes |
- * --------------------------------------
- * <-------><------->
- * order-1 order-1
+ * page. We start at the PMD order and check if it is eligible for collapse;
+ * if not, we check the left and right halves of the PTE page table we are
+ * examining at a lower order.
*
* 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
@@ -1517,26 +1458,20 @@ static enum scan_result mthp_collapse(struct mm_struct *mm,
{
unsigned int nr_occupied_ptes, nr_ptes, max_ptes_none;
enum scan_result last_result = SCAN_FAIL;
- int collapsed = 0, stack_size = 0;
+ int collapsed = 0;
bool alloc_failed = false;
unsigned long collapse_address;
- struct mthp_range range;
- u16 offset;
- u8 order;
+ unsigned int offset = 0;
+ unsigned int order = HPAGE_PMD_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;
+ while (offset < HPAGE_PMD_NR) {
nr_ptes = 1UL << order;
if (!test_bit(order, &enabled_orders))
goto next_order;
max_ptes_none = collapse_max_ptes_none(cc, NULL, order);
-
nr_occupied_ptes = bitmap_weight_from(cc->mthp_present_ptes, offset,
offset + nr_ptes);
@@ -1553,7 +1488,7 @@ static enum scan_result mthp_collapse(struct mm_struct *mm,
collapsed += nr_ptes;
fallthrough;
case SCAN_PTE_MAPPED_HUGEPAGE:
- continue;
+ goto next_offset;
/* Cases where lower orders might still succeed */
case SCAN_ALLOC_HUGE_PAGE_FAIL:
alloc_failed = true;
@@ -1581,15 +1516,14 @@ static enum scan_result mthp_collapse(struct mm_struct *mm,
}
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);
+ if (order > KHUGEPAGED_MIN_MTHP_ORDER &&
+ (BIT(order) - 1) & enabled_orders) {
+ order = order - 1;
+ continue;
}
+next_offset:
+ offset += nr_ptes;
+ order = min_t(int, __ffs(offset), HPAGE_PMD_ORDER);
}
done:
if (collapsed)
--
2.54.0
>
> [...]
>
>>>> + 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.
>>>> + */
>>>
>>> You should note here, that we re-verify in mthp_collapse().
>>>
>>> But the question is, whether we should relocate the check completely into
>>> mthp_collapse(), instead of conditionally duplicating it.
>>>
>>> What speaks against always populating the bitmap and making the decision in
>>> mthp_collapse()?
>>>
>>> Sure, we might scan a page table a bit longer, but the code gets clearer ... and
>>> I am not sure if scanning some more page table entries is really that critical here.
>>
>> Someone asked me to preserve the legacy behavior (PMD only). Although
>> rather trivial, if you set max_ptes_none=0 for example, we'd still
>> have to do 511 iterations for no reason if PMD collapse is the only
>> enabled order rather than bailing immediately.
>>
>> I'm ok with dropping it, but I think its the correct approach (despite
>> the extra complexity). @Usama Arif brought up this point here
>> https://lore.kernel.org/all/f8f7bb71-ca31-46ee-a62d-7ddfd83e0ead@gmail.com/
>
> We talk about regressions, but I am not sure if we care about scanning speed
> within a page table that much?
>
> After all, we locked it and already read some entries.
>
> Having the same check at two places to optimize for PMD order might right now
> feel like a good optimization, but likely an irrelevant one in a near future?
>
> Anyhow, won't push back, as long as we document why we are special casing things
> here.
>
^ permalink raw reply related
* Re: [PATCH mm-unstable v18 11/14] mm/khugepaged: Introduce mTHP collapse support
From: Nico Pache @ 2026-06-02 17:26 UTC (permalink / raw)
To: David Hildenbrand (Arm)
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, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
lance.yang, liam, ljs, 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, vbabka, vishal.moola,
wangkefeng.wang, will, willy, yang, ying.huang, ziy, zokeefe,
Usama Arif, usamaarif642
In-Reply-To: <19639b08-5bf1-4974-9635-c458d512fa38@redhat.com>
On Tue, Jun 2, 2026 at 11:22 AM Nico Pache <npache@redhat.com> wrote:
>
>
>
> On 6/1/26 7:15 AM, David Hildenbrand (Arm) wrote:
> >>>
> >>> Reading this, it is unclear why exactly do we need the stack.
> >>
> >> So I looked into your items below. It seems logical, and I think it
> >> works the same way; however, your method seems slightly harder to
> >> understand due to all the edge cases and more error-prone to future
> >> changes (the stack holds implicit knowledge of the offset/order that
> >> must now be tracked in the edge cases).
> >>
> >> Given the stack is 24 bytes, I'm not sure if the extra complexity is
> >> worth saving that small amount of memory. Although we would also be
> >> getting rid of (3?) functions, so both approaches have pros and cons.
> >
> > I consider a simple forward loop over the offset ... less complexity compared to
> > a stack structure :)
> >
> >>
> >> I will implement a patch comparing your solution against mine and send
> >> it here, then we can decide which approach is better.
> >
> > Right, throw it over the fence and I'll see how to improve it further.
>
> Ok heres what the diff looks like on top of my V19.
>
> you can access the tree here https://gitlab.com/npache/linux/-/commits/mthp-v19?ref_type=heads for easier review.
>
> So far I have no problem with this approach it appeared cleaner than i thought. Did some light testing. Gonna throw it more through the ringer tomorrow.
not sure why this didnt send with the proper encoding I guess my email
is still a little screwed up
>
>
> From 9496c5d17eba7f6d04820d78c7c6f1592a58888a Mon Sep 17 00:00:00 2001
> From: Nico Pache <npache@redhat.com>
> Date: Tue, 2 Jun 2026 10:26:18 -0600
> Subject: [PATCH] convert from stack to forward loop
>
> Signed-off-by: Nico Pache <npache@redhat.com>
> ---
> mm/khugepaged.c | 96 ++++++++-----------------------------------------
> 1 file changed, 15 insertions(+), 81 deletions(-)
>
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index 498eba009751..6de935e76ceb 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -100,28 +100,6 @@ 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;
> @@ -137,7 +115,6 @@ struct collapse_control {
>
> /* Each bit represents a single occupied (!none/zero) page. */
> DECLARE_BITMAP(mthp_present_ptes, MAX_PTRS_PER_PTE);
> - struct mthp_range mthp_bitmap_stack[MTHP_STACK_SIZE];
> };
>
> /**
> @@ -1458,50 +1435,14 @@ 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];
> -}
> -
> /*
> * 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_present_ptes 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_present_ptes |
> - * --------------------------------------
> - * <-------><------->
> - * order-1 order-1
> + * page. We start at the PMD order and check if it is eligible for collapse;
> + * if not, we check the left and right halves of the PTE page table we are
> + * examining at a lower order.
> *
> * 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
> @@ -1517,26 +1458,20 @@ static enum scan_result mthp_collapse(struct mm_struct *mm,
> {
> unsigned int nr_occupied_ptes, nr_ptes, max_ptes_none;
> enum scan_result last_result = SCAN_FAIL;
> - int collapsed = 0, stack_size = 0;
> + int collapsed = 0;
> bool alloc_failed = false;
> unsigned long collapse_address;
> - struct mthp_range range;
> - u16 offset;
> - u8 order;
> + unsigned int offset = 0;
> + unsigned int order = HPAGE_PMD_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;
> + while (offset < HPAGE_PMD_NR) {
> nr_ptes = 1UL << order;
>
> if (!test_bit(order, &enabled_orders))
> goto next_order;
>
> max_ptes_none = collapse_max_ptes_none(cc, NULL, order);
> -
> nr_occupied_ptes = bitmap_weight_from(cc->mthp_present_ptes, offset,
> offset + nr_ptes);
>
> @@ -1553,7 +1488,7 @@ static enum scan_result mthp_collapse(struct mm_struct *mm,
> collapsed += nr_ptes;
> fallthrough;
> case SCAN_PTE_MAPPED_HUGEPAGE:
> - continue;
> + goto next_offset;
> /* Cases where lower orders might still succeed */
> case SCAN_ALLOC_HUGE_PAGE_FAIL:
> alloc_failed = true;
> @@ -1581,15 +1516,14 @@ static enum scan_result mthp_collapse(struct mm_struct *mm,
> }
>
> 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);
> + if (order > KHUGEPAGED_MIN_MTHP_ORDER &&
> + (BIT(order) - 1) & enabled_orders) {
> + order = order - 1;
> + continue;
> }
> +next_offset:
> + offset += nr_ptes;
> + order = min_t(int, __ffs(offset), HPAGE_PMD_ORDER);
> }
> done:
> if (collapsed)
> --
> 2.54.0
>
>
>
> >
> > [...]
> >
> >>>> + 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.
> >>>> + */
> >>>
> >>> You should note here, that we re-verify in mthp_collapse().
> >>>
> >>> But the question is, whether we should relocate the check completely into
> >>> mthp_collapse(), instead of conditionally duplicating it.
> >>>
> >>> What speaks against always populating the bitmap and making the decision in
> >>> mthp_collapse()?
> >>>
> >>> Sure, we might scan a page table a bit longer, but the code gets clearer ... and
> >>> I am not sure if scanning some more page table entries is really that critical here.
> >>
> >> Someone asked me to preserve the legacy behavior (PMD only). Although
> >> rather trivial, if you set max_ptes_none=0 for example, we'd still
> >> have to do 511 iterations for no reason if PMD collapse is the only
> >> enabled order rather than bailing immediately.
> >>
> >> I'm ok with dropping it, but I think its the correct approach (despite
> >> the extra complexity). @Usama Arif brought up this point here
> >> https://lore.kernel.org/all/f8f7bb71-ca31-46ee-a62d-7ddfd83e0ead@gmail.com/
> >
> > We talk about regressions, but I am not sure if we care about scanning speed
> > within a page table that much?
> >
> > After all, we locked it and already read some entries.
> >
> > Having the same check at two places to optimize for PMD order might right now
> > feel like a good optimization, but likely an irrelevant one in a near future?
> >
> > Anyhow, won't push back, as long as we document why we are special casing things
> > here.
> >
>
^ permalink raw reply
* Re: [linux] Documentation/arch/sparc/oradax/dax-hv-api.txt and Documentation/driver-api/parport-lowlevel.rst : Form feed (^L) characters
From: Randy Dunlap @ 2026-06-02 17:31 UTC (permalink / raw)
To: Xose Vazquez Perez, Jonathan Corbet, DOC ML
In-Reply-To: <25667a7c-e426-413d-aa3d-a52ebbeb9de5@gmail.com>
On 6/2/26 2:39 AM, Xose Vazquez Perez wrote:
> Hi,
>
> I noticed that Documentation/arch/sparc/oradax/dax-hv-api.txt and
> Documentation/driver-api/parport-lowlevel.rst contains several
> legacy form feed (\f, ^L) characters used as page breaks.
>
> I am not sure if these are still required for any specific formatting
> reasons or if they should be removed.
These form feed ^L characters seem to be ignored in the produced html output.
If someone printed the text files, they would cause page feeds.
In the case of parport-lowlevel.rst the form feeds might make the output
look nicer at the expense of wasting paper.
IMO they can all be removed.
> They appear in the following lines:
>
> $ grep -n -P '\f' Documentation/arch/sparc/oradax/dax-hv-api.txt Documentation/driver-api/parport-lowlevel.rst
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:66:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:128:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:176:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:228:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:284:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:342:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:397:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:454:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:504:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:554:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:609:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:667:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:719:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:779:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:830:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:887:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:943:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:995:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:1048:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:1105:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:1156:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:1216:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:1272:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:1326:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:1381:
> Coprocessor services
> ./Documentation/arch/sparc/oradax/dax-hv-api.txt:1433:
>
> ./Documentation/driver-api/parport-lowlevel.rst:104:
>
> ./Documentation/driver-api/parport-lowlevel.rst:504:
>
> ./Documentation/driver-api/parport-lowlevel.rst:540:
>
> ./Documentation/driver-api/parport-lowlevel.rst:586:
>
> ./Documentation/driver-api/parport-lowlevel.rst:674:
>
> ./Documentation/driver-api/parport-lowlevel.rst:709:
>
> ./Documentation/driver-api/parport-lowlevel.rst:866:
>
> ./Documentation/driver-api/parport-lowlevel.rst:1102:
>
> ./Documentation/driver-api/parport-lowlevel.rst:1188:
>
> ./Documentation/driver-api/parport-lowlevel.rst:1217:
>
> ./Documentation/driver-api/parport-lowlevel.rst:1253:
>
> ./Documentation/driver-api/parport-lowlevel.rst:1282:
>
> ./Documentation/driver-api/parport-lowlevel.rst:1319:
>
> ./Documentation/driver-api/parport-lowlevel.rst:1355:
>
> ./Documentation/driver-api/parport-lowlevel.rst:1386:
>
> ./Documentation/driver-api/parport-lowlevel.rst:1413:
>
> ./Documentation/driver-api/parport-lowlevel.rst:1444:
>
> ./Documentation/driver-api/parport-lowlevel.rst:1511:
>
> ./Documentation/driver-api/parport-lowlevel.rst:1589:
>
> ./Documentation/driver-api/parport-lowlevel.rst:1629:
>
> ./Documentation/driver-api/parport-lowlevel.rst:1661:
>
> ./Documentation/driver-api/parport-lowlevel.rst:1771:
>
> ./Documentation/driver-api/parport-lowlevel.rst:1805:
>
--
~Randy
^ permalink raw reply
* Re: [PATCH 8/9] block: add configurable error injection
From: Randy Dunlap @ 2026-06-02 17:56 UTC (permalink / raw)
To: Christoph Hellwig, Jens Axboe
Cc: Jonathan Corbet, linux-block, linux-doc, bpf, linux-kselftest
In-Reply-To: <20260602054615.3788425-9-hch@lst.de>
On 6/1/26 10:45 PM, Christoph Hellwig wrote:
> diff --git a/Documentation/block/error-injection.rst b/Documentation/block/error-injection.rst
> new file mode 100644
> index 000000000000..be87091b5330
> --- /dev/null
> +++ b/Documentation/block/error-injection.rst
> @@ -0,0 +1,59 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +============================
> +Configurable Error Injection
> +============================
> +
> +Overview
> +--------
> +
> +Configurable error injection allows injecting specific block layer status codes
> +for ranges of a block device. Error can be injected unconditional, or with a
Errors can be injected unconditionally or with a
> +given probability.
> +
> +To use configurable error injection, CONFIG_FAIL_MAKE_REQUEST must be enabled.
> +
> +The only interface is the error_injection debugfs file, which is created for
> +each registered gendisk. Writes to this file are used to create or delete rules
> +and reads return a list of the current error injection sites.
[snip]
--
~Randy
^ permalink raw reply
* Re: [PATCH v15 06/12] iio: core: add decimal value formatting into 64-bit value
From: Rodrigo Alencar @ 2026-06-02 18:01 UTC (permalink / raw)
To: Nuno Sá, Rodrigo Alencar, rodrigo.alencar
Cc: linux-kernel, linux-iio, devicetree, linux-doc, Jonathan Cameron,
David Lechner, Andy Shevchenko, Lars-Peter Clausen,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Andrew Morton, Petr Mladek, Steven Rostedt,
Andy Shevchenko, Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan
In-Reply-To: <a607ff15c5a9c6edd6be1a40182b16b5dc48c151.camel@gmail.com>
On 26/06/02 05:56PM, Nuno Sá wrote:
> On Mon, 2026-06-01 at 16:12 +0100, Rodrigo Alencar wrote:
> > On 26/06/01 10:43AM, Nuno Sá wrote:
> > > On Sun, May 31, 2026 at 09:30:49AM +0100, Rodrigo Alencar via B4 Relay wrote:
> > > > From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> > > >
> > > > Create new format types for iio values (IIO_VAL_DECIMAL64_*), which
> > > > defines the representation of fixed decimal point values into a single
> > > > 64-bit number. This new format increases the range of represented values,
> > > > allowing for integer parts greater than 2^32, as bits are not "wasted"
> > > > in the fractional part, which can be seen in IIO_VAL_INT_PLUS_MICRO and
> > > > IIO_VAL_INT_PLUS_NANO. Helpers are created to compose and decompose 64-bit
> > > > decimals into integer values used in IIO formatting interfaces, which
> > > > creates consistency and avoid error-prone manual assignments when using
> > > > wordpart macros. When doing the parsing, kstrtodec64() is used with the
> > > > scale defined by the specific decimal format type.
...
> > > > @@ -707,8 +707,25 @@ static ssize_t __iio_format_value(char *buf, size_t
> > > > offset, unsigned int type,
> > > > case IIO_VAL_CHAR:
> > > > return sysfs_emit_at(buf, offset, "%c", (char)vals[0]);
> > > > case IIO_VAL_INT_64:
> > > > - tmp2 = (s64)((((u64)vals[1]) << 32) | (u32)vals[0]);
> > > > + tmp2 = iio_val_s64_from_s32s(vals);
> > >
> > > I might be missing something but can't we just call
> > > iio_val_s64_compose()? Likely even inline in sysfs_emit_at()?
> >
> > There is a compose() already.
> >
>
> Yes and I was suggesting using that one instead iio_val_s64_from_s32s() :). To be
> consistent to what you use in the other path (which is decompose() if I'm not
> mistaken).
>
> >
> > > It would match your call to iio_val_s64_decompose() below.
> >
> > here are the helpers prototype:
> >
> > s64 iio_val_s64_compose(s32 val0, s32 val1);
> > s64 iio_val_s64_from_s32s(const s32 *vals);
> >
> > void iio_val_s64_decompose(s64 dec64, s32 *val0, s32 *val1);
> > void iio_val_s64_to_s32s(s64 dec64, s32 *vals);
> >
>
> Yes and it feels that iio_val_s64_compose() and iio_val_s64_decompose() are the only
> ones we really need? (Maybe with other naming if you prefer iio_val_s64_from_s32s()
> and iio_val_s64_to_s32s()).
>
> > > And the above makes me wonder if the compose()/decompose() are not the
> > > only helpers we need? At least in terms of parameters? I mean, just
> > > assuming we only have two integers instead of allowing s32* and opening
> > > the door for misbehave :)?
> >
> > I suppose we would really need some sort of:
> >
> > union iio_val {
> > s32 val32[2];
> > s64 val64;
> > };
> >
> > or even add a:
> >
> > struct { void *ptr, size_t size }
>
> I just meant using two where we just have (s32 val1, s32 vals2) given that is
> what IIO has anyways. No need to overthinking it for now IMO.
Understood. will drop iio_val_s64_from_s32s() and iio_val_s64_to_s32s()!
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v15 02/12] lib: kstrtox: add local _parse_integer_limit_init() helper
From: Andy Shevchenko @ 2026-06-02 19:43 UTC (permalink / raw)
To: rodrigo.alencar
Cc: linux-kernel, linux-iio, devicetree, linux-doc, Jonathan Cameron,
David Lechner, Andy Shevchenko, Lars-Peter Clausen,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Andrew Morton, Petr Mladek, Steven Rostedt,
Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan
In-Reply-To: <20260531-adf41513-iio-driver-v15-2-da09adf1c0dd@analog.com>
On Sun, May 31, 2026 at 09:30:45AM +0100, Rodrigo Alencar via B4 Relay wrote:
> Add parsing helper that accepts an initial value for the accumulated
> result when parsing an 64-bit integer. It reuses current implementation
> for _parse_integer_limit(), which now consumes the new function with
> init = 0. The diff algorithm would have the documentation header and
> prototype of _parse_integer_limit() moved around so it is adjusted
> according to guidelines.
...
> +static unsigned int _parse_integer_limit_init(const char *s, unsigned int base,
> + unsigned long long init,
Why not name it res...
> + unsigned long long *p,
> + size_t max_chars)
> {
> unsigned long long res;
...and drop this one...
> unsigned int rv;
>
> - res = 0;
> + res = init;
...and this one?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v7 02/10] dt-bindings: extcon: document Samsung S2M series PMIC extcon device
From: Rob Herring @ 2026-06-02 19:46 UTC (permalink / raw)
To: Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Krzysztof Kozlowski, Conor Dooley,
MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran,
Łukasz Lebiedziński, Yassine Oudjana, linux-leds,
devicetree, linux-kernel, linux-pm, linux-samsung-soc, linux-rtc,
linux-doc, Conor Dooley, Krzysztof Kozlowski
In-Reply-To: <20260516-s2mu005-pmic-v7-2-73f9702fb461@disroot.org>
On Sat, May 16, 2026 at 03:08:34AM +0530, Kaustabh Chakraborty wrote:
> Certain Samsung S2M series PMICs have a MUIC device which reports
> various cable states by measuring the ID-GND resistance with an internal
> ADC. Document the devicetree schema for this device.
>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
> ---
> .../bindings/extcon/samsung,s2mu005-muic.yaml | 40 ++++++++++++++++++++++
> 1 file changed, 40 insertions(+)
As the rest of the series was applied without this, I've applied it to
fix errors in dt_binding_check.
Rob
^ permalink raw reply
* Re: [PATCH v7 07/42] KVM: guest_memfd: Only prepare folios for private pages
From: Ackerley Tng @ 2026-06-02 20:46 UTC (permalink / raw)
To: Suzuki K Poulose, 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: <d01cf1ec-b85d-4af6-9810-8107c0e2a4ec@arm.com>
Suzuki K Poulose <suzuki.poulose@arm.com> writes:
> On 23/05/2026 01:17, Ackerley Tng via B4 Relay wrote:
>> From: Ackerley Tng <ackerleytng@google.com>
>>
>> All-shared guest_memfd used to be only supported for non-CoCo VMs where
>> preparation doesn't apply. INIT_SHARED is about to be supported for
>> non-CoCo VMs in a later patch in this series.
>
> nit: s/non-CoCo/CoCo ?
>
Yes, thanks!
>>
>> In addition, KVM_SET_MEMORY_ATTRIBUTES2 is about to be supported in
>> guest_memfd in a later patch in this series.
>>
>> This means that the kvm fault handler may now call kvm_gmem_get_pfn() on a
>> shared folio for a CoCo VM where preparation applies.
>>
>> Add a check to make sure that preparation is only performed for private
>> folios.
>>
>> Preparation will be undone on freeing (see kvm_gmem_free_folio()) and on
>> conversion to shared.
>>
>> Signed-off-by: Michael Roth <michael.roth@amd.com>
>
> nit: Missing Co-Developed-by: ?
>
IIRC this should have been
Suggested-by: Michael Roth <michael.roth@amd.com>
IIRC Michael suggested this on one of the guest_memfd calls, Michael
please let me know if you remember otherwise!
>>
>> [...snip...]
>>
^ 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