* Re: [PATCH mm-unstable v18 11/14] mm/khugepaged: Introduce mTHP collapse support
From: Nico Pache @ 2026-06-02 10:58 UTC (permalink / raw)
To: Lance Yang
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: <20260531071845.10875-1-lance.yang@linux.dev>
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.
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?
This is what I currently have:
done:
if (collapsed)
return SCAN_SUCCEED;
if (alloc_failed)
return SCAN_ALLOC_HUGE_PAGE_FAIL;
Thanks,
-- Nico
>
> Cheers, Lance
>
^ permalink raw reply
* [PATCH 2/2] PCI: Add pci=nodpc kernel boot option
From: Yury Murashka @ 2026-06-02 10:55 UTC (permalink / raw)
To: bhelgaas; +Cc: corbet, skhan, linux-pci, linux-doc, linux-kernel, Yury Murashka
In-Reply-To: <20260602105558.1799563-1-yurypm@arista.com>
PCI DPC (Downstream Port Containment) support can be advertised by PCIe
devices, but it might not be fully supported in the firmware. On large
modular systems with a complex PCIe tree, enabling DPC could cause
unexpected behavior and side effects. Sometimes it would be nice to have
the option to keep the system in an unmodified state and be able to
handle PCIe errors from userspace.
Add pci=nodpc kernel boot option to disable PCI DPC. When this option
is set, DPC initialization, state save/restore, and recovery are all
skipped.
Signed-off-by: Yury Murashka <yurypm@arista.com>
---
Documentation/admin-guide/kernel-parameters.txt | 3 +++
drivers/pci/pci.c | 2 ++
drivers/pci/pci.h | 2 ++
drivers/pci/pcie/dpc.c | 16 +++++++++++++---
4 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index cfec12d37677..46a993c26dc0 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5065,6 +5065,9 @@ Kernel parameters
through ports 0xC000-0xCFFF).
See http://wiki.osdev.org/PCI for more info
on the configuration access mechanisms.
+ nodpc [PCIE] If the PCIE_DPC kernel config parameter is
+ enabled, this kernel boot option can be used to
+ disable the use of PCIE DPC.
noaer [PCIE] If the PCIEAER kernel config parameter is
enabled, this kernel boot option can be used to
disable the use of PCIE advanced error reporting.
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 1f71f9c773c4..2882c7bbb358 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -6723,6 +6723,8 @@ static int __init pci_setup(char *str)
} else if (!strncmp(str, "noats", 5)) {
pr_info("PCIe: ATS is disabled\n");
pcie_ats_disabled = true;
+ } else if (!strcmp(str, "nodpc")) {
+ pci_no_dpc();
} else if (!strcmp(str, "noaer")) {
pci_no_aer();
} else if (!strcmp(str, "noaer_recovery")) {
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 7a79df0ae712..1b6f17dddf21 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -887,6 +887,7 @@ struct rcec_ea {
#endif
#ifdef CONFIG_PCIE_DPC
+void pci_no_dpc(void);
void pci_save_dpc_state(struct pci_dev *dev);
void pci_restore_dpc_state(struct pci_dev *dev);
void pci_dpc_init(struct pci_dev *pdev);
@@ -895,6 +896,7 @@ pci_ers_result_t dpc_reset_link(struct pci_dev *pdev);
bool pci_dpc_recovered(struct pci_dev *pdev);
unsigned int dpc_tlp_log_len(struct pci_dev *dev);
#else
+static inline void pci_no_dpc(void) { }
static inline void pci_save_dpc_state(struct pci_dev *dev) { }
static inline void pci_restore_dpc_state(struct pci_dev *dev) { }
static inline void pci_dpc_init(struct pci_dev *pdev) { }
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
index 2b779bd1d861..10d1a0e026d7 100644
--- a/drivers/pci/pcie/dpc.c
+++ b/drivers/pci/pcie/dpc.c
@@ -43,12 +43,19 @@ static const char * const rp_pio_error_string[] = {
"Memory Request Completion Timeout", /* Bit Position 18 */
};
+static int pcie_dpc_disable;
+
+void pci_no_dpc(void)
+{
+ pcie_dpc_disable = 1;
+}
+
void pci_save_dpc_state(struct pci_dev *dev)
{
struct pci_cap_saved_state *save_state;
u16 *cap;
- if (!pci_is_pcie(dev))
+ if (pcie_dpc_disable || !pci_is_pcie(dev))
return;
save_state = pci_find_saved_ext_cap(dev, PCI_EXT_CAP_ID_DPC);
@@ -64,7 +71,7 @@ void pci_restore_dpc_state(struct pci_dev *dev)
struct pci_cap_saved_state *save_state;
u16 *cap;
- if (!pci_is_pcie(dev))
+ if (pcie_dpc_disable || !pci_is_pcie(dev))
return;
save_state = pci_find_saved_ext_cap(dev, PCI_EXT_CAP_ID_DPC);
@@ -104,7 +111,7 @@ bool pci_dpc_recovered(struct pci_dev *pdev)
{
struct pci_host_bridge *host;
- if (!pdev->dpc_cap)
+ if (pcie_dpc_disable || !pdev->dpc_cap)
return false;
/*
@@ -404,6 +411,9 @@ void pci_dpc_init(struct pci_dev *pdev)
{
u16 cap;
+ if (pcie_dpc_disable)
+ return;
+
pdev->dpc_cap = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_DPC);
if (!pdev->dpc_cap)
return;
--
2.51.0
^ permalink raw reply related
* [PATCH 1/2] PCI: Add pci=noaer_recovery kernel boot option
From: Yury Murashka @ 2026-06-02 10:55 UTC (permalink / raw)
To: bhelgaas; +Cc: corbet, skhan, linux-pci, linux-doc, linux-kernel, Yury Murashka
In-Reply-To: <20260602105558.1799563-1-yurypm@arista.com>
AER error recovery is part of the AER error handling subsystem in the
Linux kernel. On large modular systems with a complex PCIe tree, AER
recovery could cause unexpected behavior and side effects. Sometimes it
would be nice to have the option to keep the system in an unmodified
state and be able to handle PCIe errors from userspace.
Add pci=noaer_recovery kernel boot option to disable AER error recovery
when an uncorrectable error is reported. When this option is set, the
error status bits are still cleared, but no recovery actions are taken.
Signed-off-by: Yury Murashka <yurypm@arista.com>
---
Documentation/admin-guide/kernel-parameters.txt | 4 ++++
drivers/pci/pci.c | 2 ++
drivers/pci/pci.h | 2 ++
drivers/pci/pcie/err.c | 15 +++++++++++++++
4 files changed, 23 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 97007f4f69d4..cfec12d37677 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5068,6 +5068,10 @@ Kernel parameters
noaer [PCIE] If the PCIEAER kernel config parameter is
enabled, this kernel boot option can be used to
disable the use of PCIE advanced error reporting.
+ noaer_recovery [PCIE] If the PCIEAER kernel config parameter is
+ enabled, this kernel boot option can be used to
+ disable AER error recovery when an uncorrectable
+ error is reported.
nodomains [PCI] Disable support for multiple PCI
root domains (aka PCI segments, in ACPI-speak).
nommconf [X86] Disable use of MMCONFIG for PCI
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index d34266651ad0..1f71f9c773c4 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -6725,6 +6725,8 @@ static int __init pci_setup(char *str)
pcie_ats_disabled = true;
} else if (!strcmp(str, "noaer")) {
pci_no_aer();
+ } else if (!strcmp(str, "noaer_recovery")) {
+ pci_no_aer_recovery();
} else if (!strcmp(str, "earlydump")) {
pci_early_dump = true;
} else if (!strncmp(str, "realloc=", 8)) {
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 4a14f88e543a..7a79df0ae712 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -1283,6 +1283,7 @@ static inline void of_pci_remove_host_bridge_node(struct pci_host_bridge *bridge
#ifdef CONFIG_PCIEAER
void pci_no_aer(void);
+void pci_no_aer_recovery(void);
void pci_aer_init(struct pci_dev *dev);
void pci_aer_exit(struct pci_dev *dev);
extern const struct attribute_group aer_stats_attr_group;
@@ -1294,6 +1295,7 @@ void pci_save_aer_state(struct pci_dev *dev);
void pci_restore_aer_state(struct pci_dev *dev);
#else
static inline void pci_no_aer(void) { }
+static inline void pci_no_aer_recovery(void) { }
static inline void pci_aer_init(struct pci_dev *d) { }
static inline void pci_aer_exit(struct pci_dev *d) { }
static inline void pci_aer_clear_fatal_status(struct pci_dev *dev) { }
diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index bebe4bc111d7..c022cfd85b93 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -21,6 +21,13 @@
#include "portdrv.h"
#include "../pci.h"
+static int pcie_aer_recovery_disable;
+
+void pci_no_aer_recovery(void)
+{
+ pcie_aer_recovery_disable = 1;
+}
+
static pci_ers_result_t merge_result(enum pci_ers_result orig,
enum pci_ers_result new)
{
@@ -216,6 +223,14 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
pci_ers_result_t status = PCI_ERS_RESULT_CAN_RECOVER;
struct pci_host_bridge *host = pci_find_host_bridge(dev->bus);
+ if (pcie_aer_recovery_disable) {
+ if (host->native_aer || pcie_ports_native) {
+ pcie_clear_device_status(dev);
+ pci_aer_clear_nonfatal_status(dev);
+ }
+ return status;
+ }
+
/*
* If the error was detected by a Root Port, Downstream Port, RCEC,
* or RCiEP, recovery runs on the device itself. For Ports, that
--
2.51.0
^ permalink raw reply related
* [PATCH 0/2] PCI: Add boot options to disable DPC and AER recovery
From: Yury Murashka @ 2026-06-02 10:55 UTC (permalink / raw)
To: bhelgaas; +Cc: corbet, skhan, linux-pci, linux-doc, linux-kernel, Yury Murashka
On large modular systems with a complex PCIe tree, the default kernel
AER recovery and DPC behavior could cause unexpected side effects.
Sometimes it would be nice to have the option to keep the system in an
unmodified state and be able to handle PCIe errors from userspace.
This series adds two new PCI kernel boot options:
pci=noaer_recovery - Disable AER error recovery while still clearing
error status bits
pci=nodpc - Disable PCI Downstream Port Containment entirely
Yury Murashka (2):
PCI: Add pci=noaer_recovery kernel boot option
PCI: Add pci=nodpc kernel boot option
Documentation/admin-guide/kernel-parameters.txt | 7 +++++++
drivers/pci/pci.c | 4 ++++
drivers/pci/pci.h | 4 ++++
drivers/pci/pcie/dpc.c | 16 +++++++++++++---
drivers/pci/pcie/err.c | 15 +++++++++++++++
5 files changed, 43 insertions(+), 3 deletions(-)
base-commit: 6f3ed7fec72fc8979b2a8c7219c0a9fcfc8d07b5
--
2.51.0
^ permalink raw reply
* Re: [PATCH] PM: sleep: Allow disabling DPM watchdog by default
From: Tzung-Bi Shih @ 2026-06-02 10:48 UTC (permalink / raw)
To: Tomasz Figa
Cc: Rafael J. Wysocki, Jonathan Corbet, Greg Kroah-Hartman,
Danilo Krummrich, Shuah Khan, Pavel Machek, Len Brown, linux-doc,
linux-kernel, linux-pm, driver-core
In-Reply-To: <CAAFQd5Drvq0iPAb2Ly=K7WLOmbRAcLY4TzZxHmhzarK4cvx1xA@mail.gmail.com>
On Tue, Jun 02, 2026 at 05:37:13PM +0900, Tomasz Figa wrote:
> On Tue, Jun 2, 2026 at 11:09 AM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
> >
> > On Mon, Jun 01, 2026 at 08:39:42PM +0200, Rafael J. Wysocki wrote:
> > > On Thu, May 28, 2026 at 12:32 PM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
> > > > diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> > > > index e1b550664bab..4f92905f3edf 100644
> > > > --- a/drivers/base/power/main.c
> > > > +++ b/drivers/base/power/main.c
> > > > @@ -527,6 +527,20 @@ module_param(dpm_watchdog_all_cpu_backtrace, bool, 0644);
> > > > MODULE_PARM_DESC(dpm_watchdog_all_cpu_backtrace,
> > > > "Backtrace all CPUs on DPM watchdog timeout");
> > > >
> > > > +#ifdef CONFIG_DPM_WATCHDOG_DEFAULT_ENABLED
> > > > +static unsigned int __read_mostly dpm_watchdog_enabled = 1;
> > > > +#else
> > > > +static unsigned int __read_mostly dpm_watchdog_enabled;
> > > > +#endif
> > > > +
> > > > +static int __init dpm_watchdog_setup(char *str)
> > > > +{
> > > > + if (kstrtouint(str, 0, &dpm_watchdog_enabled) == 0)
> > > > + return 1;
> > > > + return 0;
> > > > +}
> > > > +__setup("dpm_watchdog_enabled=", dpm_watchdog_setup);
> > >
> > > You might as well use a module parameter to allow this to be set or
> > > clear at run time. Is there a particular reason why you only want it
> > > to be enabled or disabled via the kernel command line?
> >
> > Thanks for the suggestion. Mainly because in our use cases, we only need
> > to set it once at boot time.
> >
> > Also, I was wondering if we need to consider potential races if the flag
> > can be set at runtime. E.g.:
> > 1) The flag is set.
> > 2) dpm_watchdog_set() is called and the timer is started.
> > 3) The flag is then unset.
> > 4) The subsequent dpm_watchdog_clear() isn't stop the timer.
> >
> > Given this, would you still suggest providing the module parameter for
> > completeness?
>
> Would that lead to anything bad, though? If I'm remembering correctly,
> would that mean that any already ongoing PM operations would still be
> subject to the timer, but not any new ones.
I was overthinking the race. All userspace programs should be frozen when
the DPM watchdog is active. The race I was concerned about isn't possible.
Would you still suggest providing the module parameter for completeness?
>
> My suggestion would also be to actually make the timeout and warning
> timeout configurable at runtime.
I'm working on that and I think that should be in a separate patch.
^ permalink raw reply
* Re: [PATCH mm-unstable v18 05/14] mm/khugepaged: require collapse_huge_page to enter/exit with the lock dropped
From: Nico Pache @ 2026-06-02 10:26 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: linux-doc, linux-kernel, linux-mm, linux-trace-kernel, aarcange,
akpm, anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
catalin.marinas, cl, corbet, dave.hansen, david, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
lance.yang, liam, mathieu.desnoyers, matthew.brost, mhiramat,
mhocko, peterx, pfalcato, rakie.kim, raquini, rdunlap,
richard.weiyang, rientjes, rostedt, rppt, ryan.roberts, shivankg,
sunnanyong, surenb, thomas.hellstrom, tiwai, usamaarif642, vbabka,
vishal.moola, wangkefeng.wang, will, willy, yang, ying.huang, ziy,
zokeefe
In-Reply-To: <ah2Ro54tMDMsPevk@lucifer>
On Mon, Jun 1, 2026 at 8:13 AM Lorenzo Stoakes <ljs@kernel.org> wrote:
>
> On Fri, May 22, 2026 at 09:00:00AM -0600, Nico Pache wrote:
> > Currently the collapse_huge_page function requires the mmap_read_lock to
> > enter with it held, and exit with it dropped. This function moves the
> > unlock into its parent caller, and changes this semantic to requiring it
> > to enter/exit with it always unlocked.
> >
> > In future patches, we need this expectation, as for in mTHP collapse, we
> > may have already have dropped the lock, and do not want to conditionally
> > check for this by passing through the lock_dropped variable.
> >
> > No functional change is expected as one of the first things the
> > collapse_huge_page function does is drop this lock before allocating the
> > hugepage.
> >
> > Acked-by: David Hildenbrand (Arm) <david@kernel.org>
> > Signed-off-by: Nico Pache <npache@redhat.com>
>
> One small nit below, otherwise LGTM, so:
>
> Reviewed-by: Lorenzo Stoakes <ljs@kernel.org>
Thank you for reviewing!
>
> > ---
> > mm/khugepaged.c | 16 ++++++++--------
> > 1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > index e98ba5b15163..fab35d318641 100644
> > --- a/mm/khugepaged.c
> > +++ b/mm/khugepaged.c
> > @@ -1208,6 +1208,12 @@ static enum scan_result alloc_charge_folio(struct folio **foliop, struct mm_stru
> > return SCAN_SUCCEED;
> > }
> >
> > +/*
> > + * collapse_huge_page expects the mmap_lock to be unlocked before entering and
> > + * will always return with the lock unlocked, to avoid holding the mmap_lock
> > + * while allocating a THP, as that could trigger direct reclaim/compaction.
> > + * Note that the VMA must be rechecked after grabbing the mmap_lock again.
> > + */
> > static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long address,
> > int referenced, int unmapped, struct collapse_control *cc)
> > {
> > @@ -1223,14 +1229,6 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long a
> >
> > VM_BUG_ON(address & ~HPAGE_PMD_MASK);
> >
> > - /*
> > - * Before allocating the hugepage, release the mmap_lock read lock.
> > - * The allocation can take potentially a long time if it involves
> > - * sync compaction, and we do not need to hold the mmap_lock during
> > - * that. We will recheck the vma after taking it again in write mode.
> > - */
> > - mmap_read_unlock(mm);
> > -
>
> NIT: Maybe worth an mmap_assert_locked()?
But it will already be unlocked here. The contract is that we enter
unlocked and exit unlocked.
Cheers,
-- Nico
>
> > result = alloc_charge_folio(&folio, mm, cc, HPAGE_PMD_ORDER);
> > if (result != SCAN_SUCCEED)
> > goto out_nolock;
> > @@ -1535,6 +1533,8 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> > out_unmap:
> > pte_unmap_unlock(pte, ptl);
> > 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);
> > /* collapse_huge_page will return with the mmap_lock released */
> > --
> > 2.54.0
> >
>
> Cheers, Lorenzo
>
^ permalink raw reply
* Re: [PATCH v6 04/15] userfaultfd: test uffd VMA flags through the vma_flags_t API
From: Mike Rapoport @ 2026-06-02 10:07 UTC (permalink / raw)
To: Kiryl Shutsemau (Meta)
Cc: akpm, peterx, david, ljs, surenb, vbabka, Liam.Howlett, ziy,
corbet, skhan, seanjc, pbonzini, jthoughton, aarcange, sj,
usama.arif, linux-mm, linux-kernel, linux-doc, linux-kselftest,
kvm, kernel-team
In-Reply-To: <20260529172716.357179-5-kas@kernel.org>
On Fri, May 29, 2026 at 06:26:33PM +0100, Kiryl Shutsemau (Meta) wrote:
> The uffd VMA-flag helpers read vma->vm_flags directly. Now that
> config-gated per-mode masks exist, switch them to the vma_flags_t
> accessor vma_test_any_mask(), which is the going-forward API and keeps a
> single place (the VMA_UFFD_* masks) that knows which modes are available
> on the current build.
>
> No functional change: vma_flags_t is in union with vm_flags, so the same
> bits are read, and the masks fold to the same code the open-coded
> vm_flags tests produced -- verified identical on gcc and clang, 32- and
> 64-bit.
>
> Suggested-by: Lorenzo Stoakes <ljs@kernel.org>
> Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
> Assisted-by: Claude:claude-opus-4-8
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
> include/linux/userfaultfd_k.h | 14 ++++++++------
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/userfaultfd_k.h b/include/linux/userfaultfd_k.h
> index 658740df2978..c4f2cc6dfcf0 100644
> --- a/include/linux/userfaultfd_k.h
> +++ b/include/linux/userfaultfd_k.h
> @@ -178,7 +178,8 @@ static inline bool is_mergeable_vm_userfaultfd_ctx(struct vm_area_struct *vma,
> */
> static inline bool uffd_disable_huge_pmd_share(struct vm_area_struct *vma)
> {
> - return vma->vm_flags & (VM_UFFD_WP | VM_UFFD_MINOR);
> + return vma_test_any_mask(vma,
> + mk_vma_flags_from_masks(VMA_UFFD_WP, VMA_UFFD_MINOR));
> }
>
> /*
> @@ -190,22 +191,23 @@ static inline bool uffd_disable_huge_pmd_share(struct vm_area_struct *vma)
> */
> static inline bool uffd_disable_fault_around(struct vm_area_struct *vma)
> {
> - return vma->vm_flags & (VM_UFFD_WP | VM_UFFD_MINOR);
> + return vma_test_any_mask(vma,
> + mk_vma_flags_from_masks(VMA_UFFD_WP, VMA_UFFD_MINOR));
> }
>
> static inline bool userfaultfd_missing(struct vm_area_struct *vma)
> {
> - return vma->vm_flags & VM_UFFD_MISSING;
> + return vma_test_any_mask(vma, VMA_UFFD_MISSING);
> }
>
> static inline bool userfaultfd_wp(struct vm_area_struct *vma)
> {
> - return vma->vm_flags & VM_UFFD_WP;
> + return vma_test_any_mask(vma, VMA_UFFD_WP);
> }
>
> static inline bool userfaultfd_minor(struct vm_area_struct *vma)
> {
> - return vma->vm_flags & VM_UFFD_MINOR;
> + return vma_test_any_mask(vma, VMA_UFFD_MINOR);
> }
>
> static inline bool userfaultfd_pte_wp(struct vm_area_struct *vma,
> @@ -222,7 +224,7 @@ static inline bool userfaultfd_huge_pmd_wp(struct vm_area_struct *vma,
>
> static inline bool userfaultfd_armed(struct vm_area_struct *vma)
> {
> - return vma->vm_flags & __VM_UFFD_FLAGS;
> + return vma_test_any_mask(vma, __VMA_UFFD_FLAGS);
> }
>
> static inline bool vma_has_uffd_without_event_remap(struct vm_area_struct *vma)
> --
> 2.54.0
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: configurable block error injection
From: Daniel Gomez @ 2026-06-02 9:58 UTC (permalink / raw)
To: Christoph Hellwig, Jens Axboe
Cc: Jonathan Corbet, linux-block, linux-doc, bpf, linux-kselftest,
Luis Chamberlain, Masami Hiramatsu, Brendan Gregg, GOST
In-Reply-To: <20260602054615.3788425-1-hch@lst.de>
On 02/06/2026 07.45, Christoph Hellwig wrote:
> Hi all,
>
> this series adds a new configurable block error injection facility.
> We already have a few to inject block errors, but unfortunately most
> of them are either not very useful or hard to use, or both:
>
> - The fail_make_request failure injection point can't distinguish
> different commands, different ranges in the file and can only injection
> plain I/O errors.
> - the should_fail_bio 'dynamic' failure injection has all the same issues
> as fail_make_request
> - dm-error can only fail all command in the table using BLK_STS_IOERR
> and requires setting up a new block device
> - dm-flakey and dm-dust allow all kinds of configurability, but still
> don't have good error selection, no good support for non-read/write
> commands and are limited to the dm table alignment requirements,
> which for zoned devices enforces setting them up for an entire zone.
> They also once again require setting up a stacked block device,
> which is really annoying in harnesses like xfstests
>
> This series adds a new debugfs-based block layer error injection
> that allows to configure what operations and ranges the injection
> applied to, and what status to return. It also allows to configure a
> failure ratio similar to the xfs errortag injection.
I wonder if the block layer would be interested in moving block error
injection off the should_fail() fault injection framework and extending
the ALLOW_ERROR_INJECTION annotation instead and offloading all the
debugfs configuration logic (block/error-injection.c) into eBPF?
I talked about moderr [1] at LPC 2025. It's a simple error injection
tool in eBPF for the module subsystem. The suggested direction there was
to generalize the tool to ideally to no tool at all, and leverage
bpftrace to describe the error injection conditions a given
subsystem needs to be tested under. That would let blktests, for
example, absorb that and simplify the configuration logic this series
adds in the kernel for debugfs.
A previous attempt to add inline error injection [2] was rejected as too
intrusive / source-polluting; the eBPF approach solves that, since the
injection logic lives in a standalone tool/script rather than in the
kernel sources.
What do you guys think?
[1] https://lpc.events/event/19/contributions/2204/
[2] https://lore.kernel.org/all/20210512064629.13899-1-mcgrof@kernel.org/
^ permalink raw reply
* Re: configurable block error injection
From: Keith Busch @ 2026-06-02 9:43 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, Jonathan Corbet, linux-block, linux-doc, bpf,
linux-kselftest
In-Reply-To: <20260602054615.3788425-1-hch@lst.de>
On Tue, Jun 02, 2026 at 07:45:32AM +0200, Christoph Hellwig wrote:
> Hi all,
>
> this series adds a new configurable block error injection facility.
> We already have a few to inject block errors, but unfortunately most
> of them are either not very useful or hard to use, or both:
Looks great! I just have some comments on patch 8/9, but for the rest:
Reviewed-by: Keith Busch <kbusch@kernel.org>
^ permalink raw reply
* Re: [PATCH 8/9] block: add configurable error injection
From: Keith Busch @ 2026-06-02 9:42 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, Jonathan Corbet, linux-block, linux-doc, bpf,
linux-kselftest
In-Reply-To: <20260602054615.3788425-9-hch@lst.de>
On Tue, Jun 03, 2026 at 07:45:40AM +0200, Christoph Hellwig wrote:
> +static int error_inject_add(struct gendisk *disk, enum req_op op,
> + sector_t start, u64 nr_sectors, blk_status_t status,
> + unsigned int chance)
> +{
> + struct blk_error_inject *inj;
> +
> + if (op == REQ_OP_LAST)
> + return -EINVAL;
> + if (status == BLK_STS_OK)
> + return -EINVAL;
> + if (U64_MAX - nr_sectors < start)
> + return -EINVAL;
> +
> + if (!nr_sectors)
> + nr_sectors = U64_MAX;
> +
...
> +
> + inj->op = op;
> + inj->start = start;
> + inj->end = start + nr_sectors - 1;
When nr_sectors is 0, it is reset to U64_MAX so overflows if start > 1.
I think you want to remove overriding nr_sectors to U64_MAX and do:
if (!nr_sectors)
inj->end = U64_MAX;
else if (U64_MAX - nr_sectors < start )
return -EINVAL;
else
inj->end = start + nr_sectors - 1;
> + inj->status = status;
> + inj->chance = chance;
> +
> + /*
> + * Add to the front of the list so that newer entries can partially
> + * override other entries. This also intentional allows duplicate
> + * entries as there is no real reason to reject them.
> + */
> + mutex_lock(&disk->error_injection_lock);
> + if (!disk_live(disk)) {
> + mutex_unlock(&disk->error_injection_lock);
> + return -EINVAL;
I think we've leaked 'inj' in this error case.
> + }
> + list_add(&inj->entry, &disk->error_injection_list);
The __blk_error_inject interates this list with
"list_for_each_entry_rcu", so shouldn't this be list_add_rcu to match?
> + mutex_unlock(&disk->error_injection_lock);
> +
> + bdev_set_flag(disk->part0, BD_MAKE_IT_FAIL);
> + return 0;
> +}
<snip>
> +static const match_table_t opt_tokens = {
> + { Opt_add, "add", },
> + { Opt_removeall, "removeall", },
> + { Opt_op, "op=%s", },
> + { Opt_start, "start=%u" },
> + { Opt_nr_sectors, "nr_sectors=%u" },
Shouldn't start and nr_sectors use %llu?
> +static ssize_t blk_error_injection_write(struct file *file,
> + const char __user *ubuf, size_t count, loff_t *pos)
> +{
...
> + options = memdup_user_nul(ubuf, count);
> + if (!options)
> + return -ENOMEM;
> +
On failure, memdup_user_nul returns an ERR_PTR rather than NULL.
if (IS_ERR(options))
return PTR_ERR(options);
> + case Removeall:
> + if (option_mask & ~Opt_removeall)
> + return -EINVAL;
Leaking "options"? Should this be:
if (option_mask & ~Opt_removeall) {
ret = -EINVAL;
goto out_free_options;
}
?
> + error_inject_removall(disk);
> + break;
> + default:
> + ret = -EINVAL;
> + }
> +
> + if (!ret)
> + ret = count;
> +out_free_options:
> + kfree(options);
> + return ret;
> +}
^ permalink raw reply
* Re: [PATCH v8 2/6] mm/memory-failure: surface unhandlable kernel pages as -ENOTRECOVERABLE
From: David Hildenbrand (Arm) @ 2026-06-02 9:41 UTC (permalink / raw)
To: Miaohe Lin, Breno Leitao
Cc: linux-mm, linux-kernel, linux-doc, linux-kselftest,
linux-trace-kernel, kernel-team, Lance Yang, Andrew Morton,
Lorenzo Stoakes, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Shuah Khan, Naoya Horiguchi,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Jonathan Corbet, Shuah Khan, Liam R. Howlett
In-Reply-To: <33ef8821-c809-b7d1-ea77-6e8a07a6e784@huawei.com>
On 6/2/26 05:08, Miaohe Lin wrote:
> On 2026/6/1 21:22, David Hildenbrand (Arm) wrote:
>> On 6/1/26 14:28, Miaohe Lin wrote:
>>>
>>> Thanks for your patch.
>>>
>>>
>>> Once shake_page finds a lightweight range-based way to shrink slab, slab pages could be freed
>>> into buddy and above PageSlab test should be removed then. Maybe add a TODO or XXX here?
>>>
>>>
>>> I'm not sure but is it safe or a common way to test PageReserved, PageSlab,
>>> PageTable and PageLargeKmalloc without extra page refcnt?
>>
>> Checking typed pages in a racy fashion is fine (PageSlab, PageTable,
>> PageLargeKmalloc).
>
> Got it. Thanks.
>
>> Checking PageReserved in a racy fashion is fine as well. TESTPAGEFLAG() will
>> allow checking it on compound pages.
>
> It seems PageReserved is not intended to be set on compound pages. I see there are PF_NO_COMPOUND
> in its definition: PAGEFLAG(Reserved, reserved, PF_NO_COMPOUND).
>
>>
>> For PageLargeKmalloc, we would want to check the head page, though. The page
>> type is only stored for the head page.
>
> Maybe we should check the head page for PageSlab and PageTable too? alloc_slab_page only
> set PageSlab on the head page and __pagetable_ctor uses __folio_set_pgtable to set PageTable
> on folio.
>
>>
>> So maybe we want to lookup the compound head (if any) and perform the type
>> checks against that?
>
> Maybe we should or we might miss some pages that could have been handled. And
> if compound head is required, should we hold an extra page refcnt to guard against
> possible folio split race?
Races are fine. We might miss some pages, but that can happen on races either way.
I'd just do something like
if (PageReserved(page))
return true;
head = compound_head(page);
return PageSlab(head) || ...;
--
Cheers,
David
^ permalink raw reply
* [linux] Documentation/arch/sparc/oradax/dax-hv-api.txt and Documentation/driver-api/parport-lowlevel.rst : Form feed (^L) characters
From: Xose Vazquez Perez @ 2026-06-02 9:39 UTC (permalink / raw)
To: Jonathan Corbet, DOC ML
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.
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:
^ permalink raw reply
* RE: [External Mail] Re: [PATCH 00/11] net: wwan: t9xx: Add MediaTek T9XX WWAN driver
From: Wu. JackBB (GSM) @ 2026-06-02 9:28 UTC (permalink / raw)
To: Loic Poulain
Cc: Sergey Ryazanov, Johannes Berg, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Wen-Zhi Huang,
Shi-Wei Yeh, Minano Tseng, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, Jonathan Corbet,
Shuah Khan, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <CAFEp6-0ntknHnpsj99YUHpD8R5SMDHf8Upn+yaED-A-sxonscw@mail.gmail.com>
Hi Loic,
>
> Hi Jack,
>
> On Fri, May 29, 2026 at 12:31 PM Jack Wu via B4 Relay
> <devnull+jackbb_wu.compal.com@kernel.org> wrote:
> >
> > T9XX is the PCIe host device driver for MediaTek's
> > t900 modem. The driver uses the WWAN framework
> > infrastructure to create the following control ports
> > and network interfaces for data transactions.
> > * /dev/wwan0at0 - Interface that supports AT commands.
> > * /dev/wwan0mbim0 - Interface conforming to the MBIM
> > protocol.
> > * wwan0-X - Primary network interface for IP traffic.
> >
> > The main blocks in the T9XX driver are:
> > * HW layer - Abstracts the hardware bus operations for
> > the device, and provides generic interfaces for the
> > transaction layer to get the device's information and
> > control the device's behavior. It includes:
> >
> > * PCIe - Implements probe, removal and interrupt
> > handling.
> > * MHCCIF (Modem Host Cross-Core Interface) - Provides
> > interrupt channels for bidirectional event
> > notification such as handshake and port enumeration.
> >
> > * Transaction layer - Implements data transactions for
> > the control plane and the data plane. It includes:
> >
> > * DPMAIF (Data Plane Modem AP Interface) - Controls
> > the hardware that provides uplink and downlink
> > queues for the data path. The data exchange takes
> > place using circular buffers to share data buffer
> > addresses and metadata to describe the packets.
> > * CLDMA (Cross Layer DMA) - Manages the hardware
> > used by the port layer to send control messages to
> > the device using MediaTek's CCCI (Cross-Core
> > Communication Interface) protocol.
> > * TX Services - Dispatch packets from the port layer
> > to the device.
> > * RX Services - Dispatch packets to the port layer
> > when receiving packets from the device.
> >
> > * Port layer - Provides control plane and data plane
> > interfaces to userspace. It includes:
> >
> > * Control Plane - Provides device node interfaces
> > for controlling data transactions.
> > * Data Plane - Provides network link interfaces
> > wwanX (0, 1, 2...) for IP data transactions.
> >
> > * Core logic - Contains the core logic to keep the
> > device working. It includes:
> >
> > * FSM (Finite State Machine) - Monitors the state
> > of the device, and notifies each module when the
> > state changes.
> >
> > The compilation of the T9XX driver is enabled by the
> > CONFIG_MTK_T9XX and CONFIG_MTK_T9XX_PCI config option
> > which depends on CONFIG_WWAN.
>
> Can you specify which userspace counterpart you need (e.g., a
> ModemManager version or a link to the relevant patch series)?
>
The driver is agnostic to the userspace application. We verified
functionality using ModemManager v1.23.4 and v1.25.95, and both
work out of the box.
>
> >
> > ---
> > Jack Wu (11):
> > net: wwan: t9xx: Add PCIe core
> > net: wwan: t9xx: Add control plane transaction layer
> > net: wwan: t9xx: Add control DMA interface
> > net: wwan: t9xx: Add control port
> > net: wwan: t9xx: Add FSM thread
> > net: wwan: t9xx: Add AT & MBIM WWAN ports
> > net: wwan: t9xx: Introduce data plane hardware
> > net: wwan: t9xx: Add data plane transaction layer
> > net: wwan: t9xx: Introduce WWAN interface
> > net: wwan: t9xx: Add power management support
> > net: wwan: t9xx: Add maintainers and documentation
> >
> > .../networking/device_drivers/wwan/t9xx.rst | 48 +
> > MAINTAINERS | 10 +
> > drivers/net/wwan/Kconfig | 17 +
> > drivers/net/wwan/Makefile | 1 +
> > drivers/net/wwan/t9xx/Makefile | 16 +
> > drivers/net/wwan/t9xx/mtk_ctrl_plane.c | 95 +
> > drivers/net/wwan/t9xx/mtk_ctrl_plane.h | 88 +
> > drivers/net/wwan/t9xx/mtk_data_plane.c | 104 +
> > drivers/net/wwan/t9xx/mtk_data_plane.h | 105 +
> > drivers/net/wwan/t9xx/mtk_dev.c | 55 +
> > drivers/net/wwan/t9xx/mtk_dev.h | 114 +
> > drivers/net/wwan/t9xx/mtk_fsm.c | 931 +++++++
> > drivers/net/wwan/t9xx/mtk_fsm.h | 140 +
> > drivers/net/wwan/t9xx/mtk_port.c | 967 +++++++
> > drivers/net/wwan/t9xx/mtk_port.h | 176 ++
> > drivers/net/wwan/t9xx/mtk_port_io.c | 576 +++++
> > drivers/net/wwan/t9xx/mtk_port_io.h | 41 +
> > drivers/net/wwan/t9xx/mtk_utility.h | 33 +
> > drivers/net/wwan/t9xx/mtk_wwan.c | 475 ++++
> > drivers/net/wwan/t9xx/mtk_wwan.h | 17 +
> > drivers/net/wwan/t9xx/pcie/Makefile | 19 +
> > drivers/net/wwan/t9xx/pcie/mtk_cldma.c | 1527 +++++++++++
> > drivers/net/wwan/t9xx/pcie/mtk_cldma.h | 176 ++
> > drivers/net/wwan/t9xx/pcie/mtk_cldma_drv.c | 373 +++
> > drivers/net/wwan/t9xx/pcie/mtk_cldma_drv.h | 174 ++
> > drivers/net/wwan/t9xx/pcie/mtk_cldma_drv_m9xx.c | 177 ++
> > drivers/net/wwan/t9xx/pcie/mtk_cldma_drv_m9xx.h | 101 +
> > drivers/net/wwan/t9xx/pcie/mtk_ctrl_cfg_m9xx.c | 55 +
> > drivers/net/wwan/t9xx/pcie/mtk_dpmaif.c | 2714 ++++++++++++++++++++
> > drivers/net/wwan/t9xx/pcie/mtk_dpmaif.h | 16 +
> > drivers/net/wwan/t9xx/pcie/mtk_dpmaif_drv.c | 1586 ++++++++++++
> > drivers/net/wwan/t9xx/pcie/mtk_dpmaif_drv.h | 268 ++
> > drivers/net/wwan/t9xx/pcie/mtk_dpmaif_drv_m9xx.c | 687 +++++
> > drivers/net/wwan/t9xx/pcie/mtk_dpmaif_reg.h | 387 +++
> > drivers/net/wwan/t9xx/pcie/mtk_dpmaif_reg_m9xx.h | 37 +
> > drivers/net/wwan/t9xx/pcie/mtk_dpmaif_ring.c | 168 ++
> > drivers/net/wwan/t9xx/pcie/mtk_dpmaif_ring.h | 161 ++
> > drivers/net/wwan/t9xx/pcie/mtk_pci.c | 1067 ++++++++
> > drivers/net/wwan/t9xx/pcie/mtk_pci.h | 219 ++
> > drivers/net/wwan/t9xx/pcie/mtk_pci_drv_m9xx.c | 70 +
> > drivers/net/wwan/t9xx/pcie/mtk_pci_reg.h | 72 +
> > drivers/net/wwan/t9xx/pcie/mtk_trans_ctrl.c | 593 +++++
> > drivers/net/wwan/t9xx/pcie/mtk_trans_ctrl.h | 105 +
> > 43 files changed, 14761 insertions(+)
> > ---
> > base-commit: eb3f4b7426cfd2b79d65b7d37155480b32259a11
> > change-id: 20260529-t9xx_driver_v1-1744f8af7739
> >
> > Best regards,
> > --
> > Jack Wu <jackbb_wu@compal.com>
================================================================================================================================================================
This message may contain information which is private, privileged or confidential of Compal Electronics, Inc. If you are not the intended recipient of this message, please notify the sender and destroy/delete the message. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited.
================================================================================================================================================================
^ permalink raw reply
* Re: [PATCH v3 0/2] arm64: cpufeature: Add WORKAROUND_DISABLE_CNP capability
From: Vladimir Murzin @ 2026-06-02 9:28 UTC (permalink / raw)
To: Zeng Heng, 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,
will, Sascha.Bischoff
Cc: linux-arm-kernel, wangkefeng.wang, linux-doc, linux-kernel
In-Reply-To: <20260601112000.1145391-1-zengheng@huaweicloud.com>
Hi,
On 6/1/26 12:19, Zeng Heng wrote:
> From: Zeng Heng <zengheng4@huawei.com>
>
> v2: https://lore.kernel.org/all/20260529063132.766491-1-zengheng@huaweicloud.com/
> v1: https://lore.kernel.org/all/20260526015720.206854-1-zengheng@huaweicloud.com/
>
> Changes in v3:
> - Keep CONFIG_ARM64_WORKAROUND_DISABLE_CNP config and generalise
> ARM64_WORKAROUND_DISABLE_CNP capability.
>
> Changes in v2:
> - Unify CNP disable workaround into ARM64_WORKAROUND_DISABLE_CNP
>
> Zeng Heng (2):
> arm64: cpufeature: Add WORKAROUND_DISABLE_CNP capability
> arm64: kernel: Disable CNP on HiSilicon HIP09
>
> Documentation/arch/arm64/silicon-errata.rst | 2 ++
> arch/arm64/Kconfig | 20 ++++++++++++++++++++
> arch/arm64/include/asm/cpucaps.h | 4 ++--
> arch/arm64/kernel/cpu_errata.c | 17 ++++++++++++-----
> arch/arm64/kernel/cpufeature.c | 2 +-
> arch/arm64/tools/cpucaps | 2 +-
> 6 files changed, 38 insertions(+), 9 deletions(-)
>
> --
> 2.43.0
>
Thanks a lot for going the extra mile and putting everything
together! I have no further comments, but let's give others some
time to chime in.
Cheers
Vladimir
^ permalink raw reply
* 答复: [外部邮件] Re: [PATCH][v2] mm/mempool: Untangle CONFIG_SLUB_DEBUG_ON abuse and switch to static key
From: Li,Rongqing @ 2026-06-02 9:26 UTC (permalink / raw)
To: Vlastimil Babka (SUSE), Jonathan Corbet, Shuah Khan, Harry Yoo,
Andrew Morton, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Cc: Matthew Wilcox, Usama Arif
In-Reply-To: <3674d3a8-b30e-4bf1-a4ab-0f82c494d131@kernel.org>
> On 6/2/26 08:21, lirongqing wrote:
> > From: Li RongQing <lirongqing@baidu.com>
> >
> > The mempool subsystem historically wrapped its debugging logic inside
> > an merely defines compile-time defaults for SLUB and caused two flaws:
> >
> > 1. On production kernels where CONFIG_SLUB_DEBUG=y but
> > CONFIG_SLUB_DEBUG_ON=n, mempool debugging was completely
> compiled out
> > at compile time.
> > 2. On kernels with CONFIG_SLUB_DEBUG_ON=y, mempool debugging stayed
> active
> > even if a user explicitly disabled slub debugging at boot time.
> >
> > Clean up this mess by removing the #ifdef and switching to a runtime
> > static key (mempool_debug_enabled), allowing mempool debugging to be
> > toggled cleanly via its own boot parameter.
> >
> > Suggested-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> > Signed-off-by: Li RongQing <lirongqing@baidu.com>
> > Cc: Vlastimil Babka <vbabka@kernel.org>
> > Cc: Harry Yoo <harry@kernel.org>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Hao Li <hao.li@linux.dev>
> > Cc: Christoph Lameter <cl@gentwo.org>
> > Cc: David Rientjes <rientjes@google.com>
> > Cc: Roman Gushchin <roman.gushchin@linux.dev>
> > Cc: Matthew Wilcox <willy@infradead.org>
> > Cc: Usama Arif <usama.arif@linux.dev>
> > ---
> > Diff with v1:
> > Rewrite commit message, change early_param to __setup
> >
> > Documentation/admin-guide/kernel-parameters.txt | 5 ++++
> > mm/mempool.c | 32
> ++++++++++++++++++-------
> > 2 files changed, 28 insertions(+), 9 deletions(-)
> >
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt
> > b/Documentation/admin-guide/kernel-parameters.txt
> > index 642659b..89b5994 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -3980,6 +3980,11 @@ Kernel parameters
> > Note that even when enabled, there are a few cases where
> > the feature is not effective.
> >
> > + mempool_debug [MM]
> > + Enable mempool debugging. This enables element
> > + poison checking when freeing elements back to the
> > + pool. Useful for debugging mempool corruption.
> > +
> > memtest= [KNL,X86,ARM,M68K,PPC,RISCV,EARLY] Enable memtest
> > Format: <integer>
> > default : 0 <disable>
> > diff --git a/mm/mempool.c b/mm/mempool.c index db23e0e..71e4b54
> 100644
> > --- a/mm/mempool.c
> > +++ b/mm/mempool.c
> > @@ -16,11 +16,28 @@
> > #include <linux/export.h>
> > #include <linux/mempool.h>
> > #include <linux/writeback.h>
> > +#include <linux/static_key.h>
> > +#include <linux/init.h>
> > #include "slab.h"
> >
> > static DECLARE_FAULT_ATTR(fail_mempool_alloc);
> > static DECLARE_FAULT_ATTR(fail_mempool_alloc_bulk);
> >
> > +/*
> > + * Debugging support for mempool using static key.
> > + *
> > + * This allows enabling mempool debug at boot time via:
> > + * mempool_debug
> > + */
> > +static DEFINE_STATIC_KEY_FALSE(mempool_debug_enabled);
> > +
> > +static int __init mempool_debug_setup(char *str) {
> > + static_branch_enable(&mempool_debug_enabled);
> > + return 1;
> > +}
> > +__setup("mempool_debug", mempool_debug_setup);
> > +
> > static int __init mempool_faul_inject_init(void) {
> > int error;
> > @@ -37,7 +54,6 @@ static int __init mempool_faul_inject_init(void) }
> > late_initcall(mempool_faul_inject_init);
> >
> > -#ifdef CONFIG_SLUB_DEBUG_ON
> > static void poison_error(struct mempool *pool, void *element, size_t size,
> > size_t byte)
> > {
> > @@ -73,6 +89,9 @@ static void __check_element(struct mempool *pool,
> > void *element, size_t size)
> >
> > static void check_element(struct mempool *pool, void *element) {
> > + if (!static_branch_unlikely(&mempool_debug_enabled))
> > + return;
>
> With static keys it's better to have the check in the caller of check_element so
> we skip over that call if it's disabled, and not do a call that immediately
> returns. Since there's a single caller, there's no need for an extra inline
> wrapper.
>
Ok, I will change it in next version
Thanks
[Li,Rongqing]
> > +
> > /* Skip checking: KASAN might save its metadata in the element. */
> > if (kasan_enabled())
> > return;
> > @@ -112,6 +131,9 @@ static void __poison_element(void *element, size_t
> > size)
> >
> > static void poison_element(struct mempool *pool, void *element) {
> > + if (!static_branch_unlikely(&mempool_debug_enabled))
> > + return;
>
> Ditto.
>
> > +
> > /* Skip poisoning: KASAN might save its metadata in the element. */
> > if (kasan_enabled())
> > return;
> > @@ -140,14 +162,6 @@ static void poison_element(struct mempool
> *pool,
> > void *element) #endif
> > }
> > }
> > -#else /* CONFIG_SLUB_DEBUG_ON */
> > -static inline void check_element(struct mempool *pool, void *element)
> > -{ -} -static inline void poison_element(struct mempool *pool, void
> > *element) -{ -} -#endif /* CONFIG_SLUB_DEBUG_ON */
> >
> > static __always_inline bool kasan_poison_element(struct mempool *pool,
> > void *element)
^ permalink raw reply
* Re: [PATCH v3 2/2] arm64: kernel: Disable CNP on HiSilicon HIP09
From: Vladimir Murzin @ 2026-06-02 9:24 UTC (permalink / raw)
To: Zeng Heng, 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,
will, Sascha.Bischoff
Cc: linux-arm-kernel, wangkefeng.wang, linux-doc, linux-kernel
In-Reply-To: <20260601112000.1145391-3-zengheng@huaweicloud.com>
On 6/1/26 12:20, Zeng Heng wrote:
> From: Zeng Heng <zengheng4@huawei.com>
>
> HiSilicon HIP09 implements TLB entry matching behavior that deviates
> from the ARM architecture specification when the CNP (Common not Private)
> bit is set in TTBRx_ELx.
>
> When TTBRx.CNP=1, TLB entries may be incorrectly shared between CPU
> cores, leading to TLB conflicts and stale mappings. This affects
> coherency and can result in incorrect translations.
>
> Add the hardware erratum workaround (Hisilicon erratum 162100125) to
> disable CNP on affected HIP09 cores.
>
> Co-developed-by: Tong Tiangen <tongtiangen@huawei.com>
> Signed-off-by: Tong Tiangen <tongtiangen@huawei.com>
> Signed-off-by: Zeng Heng <zengheng4@huawei.com>
> ---
> Documentation/arch/arm64/silicon-errata.rst | 2 ++
> arch/arm64/Kconfig | 16 ++++++++++++++++
> arch/arm64/kernel/cpu_errata.c | 13 ++++++++++---
> 3 files changed, 28 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
> index 211119ce7adc..cd50059edb85 100644
> --- a/Documentation/arch/arm64/silicon-errata.rst
> +++ b/Documentation/arch/arm64/silicon-errata.rst
> @@ -284,6 +284,8 @@ stable kernels.
> +----------------+-----------------+-----------------+-----------------------------+
> | Hisilicon | Hip09 | #162100801 | HISILICON_ERRATUM_162100801 |
> +----------------+-----------------+-----------------+-----------------------------+
> +| Hisilicon | Hip09 | #162100125 | HISILICON_ERRATUM_162100125 |
> ++----------------+-----------------+-----------------+-----------------------------+
> +----------------+-----------------+-----------------+-----------------------------+
> | Qualcomm Tech. | Kryo/Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
> +----------------+-----------------+-----------------+-----------------------------+
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index f297517a83b9..75638e37883d 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1273,6 +1273,22 @@ config HISILICON_ERRATUM_162100801
>
> If unsure, say Y.
>
> +config HISILICON_ERRATUM_162100125
> + bool "Hisilicon erratum 162100125"
> + default y
> + select ARM64_WORKAROUND_DISABLE_CNP
> + help
> + On HiSilicon HIP09, TLB entry matching behavior when CNP
> + (TTBRx.CNP=1) is enabled differs from the ARM architecture
> + specification.
> +
> + TLB entries may be incorrectly shared between CPUs, potentially
> + causing TLB conflicts and stale mappings.
> +
> + Disable CNP support for affected HiSilicon HIP09 cores.
> +
> + If unsure, say Y.
> +
> config QCOM_FALKOR_ERRATUM_1003
> bool "Falkor E1003: Incorrect translation due to ASID change"
> default y
> 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
> +
> const struct arm64_cpu_capabilities arm64_errata[] = {
> #ifdef CONFIG_ARM64_WORKAROUND_CLEAN_CACHE
> {
> @@ -803,10 +811,9 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
> #endif
> #ifdef CONFIG_ARM64_WORKAROUND_DISABLE_CNP
> {
> - /* NVIDIA Carmel */
> - .desc = "NVIDIA Carmel CNP erratum",
> + .desc = "NVIDIA Carmel CNP erratum, or Hisilicon erratum 162100125",
> .capability = ARM64_WORKAROUND_DISABLE_CNP,
> - ERRATA_MIDR_ALL_VERSIONS(MIDR_NVIDIA_CARMEL),
> + ERRATA_MIDR_RANGE_LIST(cnp_erratum_cpus),
> },
> #endif
> #ifdef CONFIG_ARM64_WORKAROUND_TRBE_OVERWRITE_FILL_MODE
> --
> 2.43.0
>
FWIW,
Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
^ permalink raw reply
* Re: [PATCH v3 1/2] arm64: cpufeature: Add WORKAROUND_DISABLE_CNP capability
From: Vladimir Murzin @ 2026-06-02 9:23 UTC (permalink / raw)
To: Zeng Heng, 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,
will, Sascha.Bischoff
Cc: linux-arm-kernel, wangkefeng.wang, linux-doc, linux-kernel
In-Reply-To: <20260601112000.1145391-2-zengheng@huaweicloud.com>
On 6/1/26 12:19, Zeng Heng wrote:
> From: Zeng Heng <zengheng4@huawei.com>
>
> The NVIDIA Carmel CNP erratum is not the only case requiring CNP to be
> disabled. Abstract this into a common WORKAROUND_DISABLE_CNP capability
> to facilitate adding errata for future chips and reduce duplicate
> checks in has_useable_cnp().
>
> This serves as a prerequisite for the subsequent Hisilicon erratum
> 162100125.
>
> Suggested-by: Vladimir Murzin <vladimir.murzin@arm.com>
> Signed-off-by: Zeng Heng <zengheng4@huawei.com>
> ---
> arch/arm64/Kconfig | 4 ++++
> arch/arm64/include/asm/cpucaps.h | 4 ++--
> arch/arm64/kernel/cpu_errata.c | 4 ++--
> arch/arm64/kernel/cpufeature.c | 2 +-
> arch/arm64/tools/cpucaps | 2 +-
> 5 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index fe60738e5943..f297517a83b9 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1315,9 +1315,13 @@ config QCOM_FALKOR_ERRATUM_E1041
>
> If unsure, say Y.
>
> +config ARM64_WORKAROUND_DISABLE_CNP
> + bool
> +
> config NVIDIA_CARMEL_CNP_ERRATUM
> bool "NVIDIA Carmel CNP: CNP on Carmel semantically different than ARM cores"
> default y
> + select ARM64_WORKAROUND_DISABLE_CNP
> help
> If CNP is enabled on Carmel cores, non-sharable TLBIs on a core will not
> invalidate shared TLB entries installed by a different core, as it would
> diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
> index d0d3cdd5763c..25c61cda901c 100644
> --- a/arch/arm64/include/asm/cpucaps.h
> +++ b/arch/arm64/include/asm/cpucaps.h
> @@ -58,8 +58,8 @@ cpucap_is_possible(const unsigned int cap)
> return IS_ENABLED(CONFIG_ARM64_ERRATUM_2658417);
> case ARM64_WORKAROUND_CAVIUM_23154:
> return IS_ENABLED(CONFIG_CAVIUM_ERRATUM_23154);
> - case ARM64_WORKAROUND_NVIDIA_CARMEL_CNP:
> - return IS_ENABLED(CONFIG_NVIDIA_CARMEL_CNP_ERRATUM);
> + case ARM64_WORKAROUND_DISABLE_CNP:
> + return IS_ENABLED(CONFIG_ARM64_WORKAROUND_DISABLE_CNP);
> case ARM64_WORKAROUND_REPEAT_TLBI:
> return IS_ENABLED(CONFIG_ARM64_WORKAROUND_REPEAT_TLBI);
> case ARM64_WORKAROUND_SPECULATIVE_SSBS:
> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> index 5377e4c2eba2..b0db946568b7 100644
> --- a/arch/arm64/kernel/cpu_errata.c
> +++ b/arch/arm64/kernel/cpu_errata.c
> @@ -801,11 +801,11 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
> 1, 0),
> },
> #endif
> -#ifdef CONFIG_NVIDIA_CARMEL_CNP_ERRATUM
> +#ifdef CONFIG_ARM64_WORKAROUND_DISABLE_CNP
> {
> /* NVIDIA Carmel */
> .desc = "NVIDIA Carmel CNP erratum",
> - .capability = ARM64_WORKAROUND_NVIDIA_CARMEL_CNP,
> + .capability = ARM64_WORKAROUND_DISABLE_CNP,
> ERRATA_MIDR_ALL_VERSIONS(MIDR_NVIDIA_CARMEL),
> },
> #endif
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 6d53bb15cf7b..20c5f24f74a9 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1785,7 +1785,7 @@ has_useable_cnp(const struct arm64_cpu_capabilities *entry, int scope)
> if (is_kdump_kernel())
> return false;
>
> - if (cpus_have_cap(ARM64_WORKAROUND_NVIDIA_CARMEL_CNP))
> + if (cpus_have_cap(ARM64_WORKAROUND_DISABLE_CNP))
> return false;
>
> return has_cpuid_feature(entry, scope);
> diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
> index 811c2479e82d..9b85a84f6fd4 100644
> --- a/arch/arm64/tools/cpucaps
> +++ b/arch/arm64/tools/cpucaps
> @@ -120,7 +120,7 @@ WORKAROUND_CAVIUM_TX2_219_PRFM
> WORKAROUND_CAVIUM_TX2_219_TVM
> WORKAROUND_CLEAN_CACHE
> WORKAROUND_DEVICE_LOAD_ACQUIRE
> -WORKAROUND_NVIDIA_CARMEL_CNP
> +WORKAROUND_DISABLE_CNP
> WORKAROUND_PMUV3_IMPDEF_TRAPS
> WORKAROUND_QCOM_FALKOR_E1003
> WORKAROUND_QCOM_ORYON_CNTVOFF
> --
> 2.43.0
>
FWIW,
Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
^ permalink raw reply
* Re: [PATCH v7 07/42] KVM: guest_memfd: Only prepare folios for private pages
From: Suzuki K Poulose @ 2026-06-02 9:10 UTC (permalink / raw)
To: ackerleytng, 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>
On 02/06/2026 09:55, Suzuki K Poulose wrote:
> 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 ?
>
>>
>> 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: ?
>
>> Reviewed-by: Fuad Tabba <tabba@google.com>
>> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
>> ---
>> virt/kvm/guest_memfd.c | 9 ++++++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
>> index 78e5435967341..adf57a3a1f5dd 100644
>> --- a/virt/kvm/guest_memfd.c
>> +++ b/virt/kvm/guest_memfd.c
>> @@ -894,6 +894,7 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct
>> kvm_memory_slot *slot,
>> int *max_order)
>> {
>> pgoff_t index = kvm_gmem_get_index(slot, gfn);
>> + struct inode *inode;
>> struct folio *folio;
>> int r = 0;
>> @@ -901,7 +902,8 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct
>> kvm_memory_slot *slot,
>> if (!file)
>> return -EFAULT;
>> - filemap_invalidate_lock_shared(file_inode(file)->i_mapping);
>> + inode = file_inode(file);
>> + filemap_invalidate_lock_shared(inode->i_mapping);
>> folio = __kvm_gmem_get_pfn(file, slot, index, pfn, max_order);
>> if (IS_ERR(folio)) {
>> @@ -914,7 +916,8 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct
>> kvm_memory_slot *slot,
>> folio_mark_uptodate(folio);
>> }
>> - r = kvm_gmem_prepare_folio(kvm, slot, gfn, folio);
>> + if (kvm_gmem_is_private_mem(inode, index))
>
> Don't we need to make sure the entire folio is private ? Not just the
> page at the index ?
> if (kvm_gmem_range_is_private(, index, folio_nr_pages(folio)) ?
Or rather, we should go through the individual pages and apply the
prepare for ones that are private ?
Suzuki
>
> Suzuki
>
>> + r = kvm_gmem_prepare_folio(kvm, slot, gfn, folio);
>> folio_unlock(folio);
>> @@ -924,7 +927,7 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct
>> kvm_memory_slot *slot,
>> folio_put(folio);
>> out:
>> - filemap_invalidate_unlock_shared(file_inode(file)->i_mapping);
>> + filemap_invalidate_unlock_shared(inode->i_mapping);
>> return r;
>> }
>> EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_gmem_get_pfn);
>>
>
^ permalink raw reply
* Re: [PATCH][v2] mm/mempool: Untangle CONFIG_SLUB_DEBUG_ON abuse and switch to static key
From: Vlastimil Babka (SUSE) @ 2026-06-02 9:10 UTC (permalink / raw)
To: lirongqing, Jonathan Corbet, Shuah Khan, Harry Yoo, Andrew Morton,
Hao Li, Christoph Lameter, David Rientjes, Roman Gushchin,
linux-doc, linux-kernel, linux-mm
Cc: Matthew Wilcox, Usama Arif
In-Reply-To: <20260602062142.1790-1-lirongqing@baidu.com>
On 6/2/26 08:21, lirongqing wrote:
> From: Li RongQing <lirongqing@baidu.com>
>
> The mempool subsystem historically wrapped its debugging logic inside an
> merely defines compile-time defaults for SLUB and caused two flaws:
>
> 1. On production kernels where CONFIG_SLUB_DEBUG=y but
> CONFIG_SLUB_DEBUG_ON=n, mempool debugging was completely compiled out
> at compile time.
> 2. On kernels with CONFIG_SLUB_DEBUG_ON=y, mempool debugging stayed active
> even if a user explicitly disabled slub debugging at boot time.
>
> Clean up this mess by removing the #ifdef and switching to a runtime static
> key (mempool_debug_enabled), allowing mempool debugging to be toggled
> cleanly via its own boot parameter.
>
> Suggested-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> Cc: Vlastimil Babka <vbabka@kernel.org>
> Cc: Harry Yoo <harry@kernel.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Hao Li <hao.li@linux.dev>
> Cc: Christoph Lameter <cl@gentwo.org>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Roman Gushchin <roman.gushchin@linux.dev>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Usama Arif <usama.arif@linux.dev>
> ---
> Diff with v1:
> Rewrite commit message, change early_param to __setup
>
> Documentation/admin-guide/kernel-parameters.txt | 5 ++++
> mm/mempool.c | 32 ++++++++++++++++++-------
> 2 files changed, 28 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 642659b..89b5994 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -3980,6 +3980,11 @@ Kernel parameters
> Note that even when enabled, there are a few cases where
> the feature is not effective.
>
> + mempool_debug [MM]
> + Enable mempool debugging. This enables element
> + poison checking when freeing elements back to the
> + pool. Useful for debugging mempool corruption.
> +
> memtest= [KNL,X86,ARM,M68K,PPC,RISCV,EARLY] Enable memtest
> Format: <integer>
> default : 0 <disable>
> diff --git a/mm/mempool.c b/mm/mempool.c
> index db23e0e..71e4b54 100644
> --- a/mm/mempool.c
> +++ b/mm/mempool.c
> @@ -16,11 +16,28 @@
> #include <linux/export.h>
> #include <linux/mempool.h>
> #include <linux/writeback.h>
> +#include <linux/static_key.h>
> +#include <linux/init.h>
> #include "slab.h"
>
> static DECLARE_FAULT_ATTR(fail_mempool_alloc);
> static DECLARE_FAULT_ATTR(fail_mempool_alloc_bulk);
>
> +/*
> + * Debugging support for mempool using static key.
> + *
> + * This allows enabling mempool debug at boot time via:
> + * mempool_debug
> + */
> +static DEFINE_STATIC_KEY_FALSE(mempool_debug_enabled);
> +
> +static int __init mempool_debug_setup(char *str)
> +{
> + static_branch_enable(&mempool_debug_enabled);
> + return 1;
> +}
> +__setup("mempool_debug", mempool_debug_setup);
> +
> static int __init mempool_faul_inject_init(void)
> {
> int error;
> @@ -37,7 +54,6 @@ static int __init mempool_faul_inject_init(void)
> }
> late_initcall(mempool_faul_inject_init);
>
> -#ifdef CONFIG_SLUB_DEBUG_ON
> static void poison_error(struct mempool *pool, void *element, size_t size,
> size_t byte)
> {
> @@ -73,6 +89,9 @@ static void __check_element(struct mempool *pool, void *element, size_t size)
>
> static void check_element(struct mempool *pool, void *element)
> {
> + if (!static_branch_unlikely(&mempool_debug_enabled))
> + return;
With static keys it's better to have the check in the caller of
check_element so we skip over that call if it's disabled, and not do a call
that immediately returns. Since there's a single caller, there's no need for
an extra inline wrapper.
> +
> /* Skip checking: KASAN might save its metadata in the element. */
> if (kasan_enabled())
> return;
> @@ -112,6 +131,9 @@ static void __poison_element(void *element, size_t size)
>
> static void poison_element(struct mempool *pool, void *element)
> {
> + if (!static_branch_unlikely(&mempool_debug_enabled))
> + return;
Ditto.
> +
> /* Skip poisoning: KASAN might save its metadata in the element. */
> if (kasan_enabled())
> return;
> @@ -140,14 +162,6 @@ static void poison_element(struct mempool *pool, void *element)
> #endif
> }
> }
> -#else /* CONFIG_SLUB_DEBUG_ON */
> -static inline void check_element(struct mempool *pool, void *element)
> -{
> -}
> -static inline void poison_element(struct mempool *pool, void *element)
> -{
> -}
> -#endif /* CONFIG_SLUB_DEBUG_ON */
>
> static __always_inline bool kasan_poison_element(struct mempool *pool,
> void *element)
^ permalink raw reply
* Re: [PATCH v4 07/13] kho: add support for linked-block serialization
From: Mike Rapoport @ 2026-06-02 9:04 UTC (permalink / raw)
To: Pasha Tatashin
Cc: linux-kselftest, shuah, akpm, linux-mm, skhan, linux-doc,
linux-kernel, corbet, dmatlack, kexec, pratyush, skhawaja, graf
In-Reply-To: <178038801491.119771.18384706761138506132.b4-review@b4>
I sent it before seeing v5, so some of those are already addressed, but
please take a look anyway.
On Tue, Jun 02, 2026 at 11:13:34AM +0300, Mike Rapoport wrote:
> On Sat, 30 May 2026 22:19:32 +0000, Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
> > 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 @@
> > [ ... skip 19 lines ... ]
> > + struct list_head list;
> > + struct kho_block_header_ser *ser;
> > +};
> > +
> > +/**
> > + * struct kho_block_set - A set of blocks that belong to the same object.
>
> "same object" sounds off to me. The blocks belong to the same module?
> user?
>
> Thoughts?
>
> > + * @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.
>
> I think it's "... entry in a block"
>
> > [ ... skip 42 lines ... ]
> > +
> > +void kho_block_it_init(struct kho_block_it *it, struct kho_block_set *bs);
> > +void *kho_block_it_next(struct kho_block_it *it);
> > +void *kho_block_it_read(struct kho_block_it *it);
> > +void *kho_block_it_prev(struct kho_block_it *it);
> > +void kho_block_it_finalize(struct kho_block_it *it);
>
> These operate on block sets, should be reflected in the names.
> Can be kho_blocks_ to avoid too long names.
>
> >
> > diff --git a/kernel/liveupdate/kho_block.c b/kernel/liveupdate/kho_block.c
> > new file mode 100644
> > index 000000000000..a4e650af946f
> > --- /dev/null
> > +++ b/kernel/liveupdate/kho_block.c
> > @@ -0,0 +1,384 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +/*
> > + * Copyright (c) 2026, Google LLC.
> > + * Pasha Tatashin <pasha.tatashin@soleen.com>
> > + */
> > +
> > +/**
> > + * DOC: KHO Serialization Blocks
> > + *
> > + * KHO provides a mechanism to preserve stateful data across a kexec handover
> > + * by serializing it into memory blocks. This file provides the common
>
> "This file" does not look good in HTML docs.
>
> > [ ... skip 15 lines ... ]
> > +
> > +/*
> > + * Safeguard limit for the number of serialization blocks. This is used to
> > + * prevent infinite loops and excessive memory allocation in case of memory
> > + * corruption in the preserved state.
> > + */
>
> Can you add how much memory it is and how many entries with, say, 4 u64
> it can accommodate?
>
> > [ ... skip 13 lines ... ]
> > +{
> > + 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);
>
> Don't you want to set count_per_block in _init()?
>
> > [ ... skip 29 lines ... ]
> > + if (!block)
> > + return -ENOMEM;
> > +
> > + block->ser = ser;
> > + last = list_last_entry_or_null(&bs->blocks, struct kho_block, list);
> > + list_add_tail(&block->list, &bs->blocks);
>
> No locks?
>
> > [ ... skip 12 lines ... ]
> > + * @bs: The block set.
> > + * @count: The current number of entries.
> > + *
> > + * This function handles the dynamic expansion of a block set. It allocates
> > + * and links a new serialization block if the provided entry count matches
> > + * the current total capacity of the set.
>
> This is a weird semantics for a generic API. I'd expect _grow() would
> add count - current_count blocks.
>
> > [ ... skip 25 lines ... ]
> > +}
> > +
> > +/**
> > + * kho_block_shrink - Conditionally destroy the last block in a block set.
> > + * @bs: The block set.
> > + * @count: The current number of entries across all blocks.
>
> Maybe
> ... of valid entries?
>
> > + *
> > + * This function checks if the last block in the set is redundant based on the
> > + * total entry count and the capacity of the preceding blocks. If the entry
> > + * count can be accommodated by the blocks that come before the last one, the
> > + * last block is destroyed and removed from the set.
>
> This should mention that it's the caller responsibility to ensure that
> entries are removed in the right order.
>
> > [ ... skip 49 lines ... ]
> > +
> > + fast = phys_to_virt(fast->next);
> > + slow = phys_to_virt(slow->next);
> > +
> > + if (slow == fast) {
> > + pr_err("Cyclic list detected\n");
>
> Maybe "block set is corrupted"?
>
> > + return false;
> > + }
> > + }
> > +
> > + return true;
> > +}
> > +
> > +/**
> > + * kho_block_restore - Restore a block set from a physical address.
> > + * @bs: The block set to restore.
> > + * @head_pa: Physical address of the first block header.
>
> I'd mention that the block set should be allocated and initialized
>
> > [ ... skip 10 lines ... ]
> > + bs->incoming = true;
> > + if (!head_pa)
> > + return 0;
> > +
> > + bs->head_pa = head_pa;
> > + if (!kho_cyclic_blocks_check(bs)) {
>
> if (kho_block_set_cyclic())
>
> reads nicer IMO
>
> > [ ... skip 87 lines ... ]
> > +{
> > + if (!it->block)
> > + return NULL;
> > +
> > + if (it->i == kho_block_count_per_block(it->bs)) {
> > + it->block->ser->count = it->i;
>
> Why iterator updates ser->count?
>
> > + if (list_is_last(&it->block->list, &it->bs->blocks))
> > + return NULL;
> > + it->block = list_next_entry(it->block, list);
> > + it->i = 0;
> > + }
> > +
> > + return (void *)(it->block->ser + 1) + (it->i++ * it->bs->entry_size);
>
> In a month we'll need an LLM's help to understand what it does.
>
> > +}
> > +
> > +/**
> > + * kho_block_it_read - Return the next entry slot for reading.
> > + * @it: The block iterator.
>
> And what is the conceptual difference between this and _it_next()?
>
> > [ ... skip 49 lines ... ]
> > + * @it: The block iterator.
> > + */
> > +void kho_block_it_finalize(struct kho_block_it *it)
> > +{
> > + if (it->block)
> > + it->block->ser->count = it->i;
>
> So, it looks like the intention of _it_next is for write, and this ends a
> write iteration.
>
> I think the names should be adjusted to make it clearer.
>
> --
> Sincerely yours,
> Mike.
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v7 07/42] KVM: guest_memfd: Only prepare folios for private pages
From: Suzuki K Poulose @ 2026-06-02 8:55 UTC (permalink / raw)
To: ackerleytng, 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: <20260522-gmem-inplace-conversion-v7-7-2f0fae496530@google.com>
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 ?
>
> 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: ?
> Reviewed-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
> ---
> virt/kvm/guest_memfd.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index 78e5435967341..adf57a3a1f5dd 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
> @@ -894,6 +894,7 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot,
> int *max_order)
> {
> pgoff_t index = kvm_gmem_get_index(slot, gfn);
> + struct inode *inode;
> struct folio *folio;
> int r = 0;
>
> @@ -901,7 +902,8 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot,
> if (!file)
> return -EFAULT;
>
> - filemap_invalidate_lock_shared(file_inode(file)->i_mapping);
> + inode = file_inode(file);
> + filemap_invalidate_lock_shared(inode->i_mapping);
>
> folio = __kvm_gmem_get_pfn(file, slot, index, pfn, max_order);
> if (IS_ERR(folio)) {
> @@ -914,7 +916,8 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot,
> folio_mark_uptodate(folio);
> }
>
> - r = kvm_gmem_prepare_folio(kvm, slot, gfn, folio);
> + if (kvm_gmem_is_private_mem(inode, index))
Don't we need to make sure the entire folio is private ? Not just the
page at the index ?
if (kvm_gmem_range_is_private(, index, folio_nr_pages(folio)) ?
Suzuki
> + r = kvm_gmem_prepare_folio(kvm, slot, gfn, folio);
>
> folio_unlock(folio);
>
> @@ -924,7 +927,7 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot,
> folio_put(folio);
>
> out:
> - filemap_invalidate_unlock_shared(file_inode(file)->i_mapping);
> + filemap_invalidate_unlock_shared(inode->i_mapping);
> return r;
> }
> EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_gmem_get_pfn);
>
^ permalink raw reply
* Re: [PATCH] PM: sleep: Allow disabling DPM watchdog by default
From: Tomasz Figa @ 2026-06-02 8:37 UTC (permalink / raw)
To: Tzung-Bi Shih
Cc: Rafael J. Wysocki, Jonathan Corbet, Greg Kroah-Hartman,
Danilo Krummrich, Shuah Khan, Pavel Machek, Len Brown, linux-doc,
linux-kernel, linux-pm, driver-core
In-Reply-To: <ah47N8Ng9zfcASmk@google.com>
On Tue, Jun 2, 2026 at 11:09 AM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
>
> On Mon, Jun 01, 2026 at 08:39:42PM +0200, Rafael J. Wysocki wrote:
> > On Thu, May 28, 2026 at 12:32 PM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
> > > diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> > > index e1b550664bab..4f92905f3edf 100644
> > > --- a/drivers/base/power/main.c
> > > +++ b/drivers/base/power/main.c
> > > @@ -527,6 +527,20 @@ module_param(dpm_watchdog_all_cpu_backtrace, bool, 0644);
> > > MODULE_PARM_DESC(dpm_watchdog_all_cpu_backtrace,
> > > "Backtrace all CPUs on DPM watchdog timeout");
> > >
> > > +#ifdef CONFIG_DPM_WATCHDOG_DEFAULT_ENABLED
> > > +static unsigned int __read_mostly dpm_watchdog_enabled = 1;
> > > +#else
> > > +static unsigned int __read_mostly dpm_watchdog_enabled;
> > > +#endif
> > > +
> > > +static int __init dpm_watchdog_setup(char *str)
> > > +{
> > > + if (kstrtouint(str, 0, &dpm_watchdog_enabled) == 0)
> > > + return 1;
> > > + return 0;
> > > +}
> > > +__setup("dpm_watchdog_enabled=", dpm_watchdog_setup);
> >
> > You might as well use a module parameter to allow this to be set or
> > clear at run time. Is there a particular reason why you only want it
> > to be enabled or disabled via the kernel command line?
>
> Thanks for the suggestion. Mainly because in our use cases, we only need
> to set it once at boot time.
>
> Also, I was wondering if we need to consider potential races if the flag
> can be set at runtime. E.g.:
> 1) The flag is set.
> 2) dpm_watchdog_set() is called and the timer is started.
> 3) The flag is then unset.
> 4) The subsequent dpm_watchdog_clear() isn't stop the timer.
>
> Given this, would you still suggest providing the module parameter for
> completeness?
Would that lead to anything bad, though? If I'm remembering correctly,
would that mean that any already ongoing PM operations would still be
subject to the timer, but not any new ones.
My suggestion would also be to actually make the timeout and warning
timeout configurable at runtime.
Best,
Tomasz
>
> >
> > > +
> > > /**
> > > * dpm_watchdog_handler - Driver suspend / resume watchdog handler.
> > > * @t: The timer that PM watchdog depends on.
> > > @@ -570,6 +584,9 @@ static void dpm_watchdog_set(struct dpm_watchdog *wd, struct device *dev)
> > > {
> > > struct timer_list *timer = &wd->timer;
> > >
> > > + if (!dpm_watchdog_enabled)
> > > + return;
> > > +
> > > wd->dev = dev;
> > > wd->tsk = current;
> > > wd->fatal = CONFIG_DPM_WATCHDOG_TIMEOUT == CONFIG_DPM_WATCHDOG_WARNING_TIMEOUT;
> > > @@ -588,6 +605,9 @@ static void dpm_watchdog_clear(struct dpm_watchdog *wd)
> > > {
> > > struct timer_list *timer = &wd->timer;
> > >
> > > + if (!dpm_watchdog_enabled)
> > > + return;
> > > +
> > > timer_delete_sync(timer);
> > > timer_destroy_on_stack(timer);
> > > }
^ permalink raw reply
* Re: [PATCH v4 08/13] liveupdate: defer session block allocation and PA setting
From: Mike Rapoport @ 2026-06-02 8:13 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: <20260530221938.115978-9-pasha.tatashin@soleen.com>
On Sat, 30 May 2026 22:19:33 +0000, Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
> Currently, luo_session_setup_outgoing() allocates the session block and
"liveupdate: defer session block allocation and PA setting"
PA as "Public Assistance"? ;-)
Let's spell it out.
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v4 07/13] kho: add support for linked-block serialization
From: Mike Rapoport @ 2026-06-02 8:13 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: <20260530221938.115978-8-pasha.tatashin@soleen.com>
On Sat, 30 May 2026 22:19:32 +0000, Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
> 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 @@
> [ ... skip 19 lines ... ]
> + struct list_head list;
> + struct kho_block_header_ser *ser;
> +};
> +
> +/**
> + * struct kho_block_set - A set of blocks that belong to the same object.
"same object" sounds off to me. The blocks belong to the same module?
user?
Thoughts?
> + * @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.
I think it's "... entry in a block"
> [ ... skip 42 lines ... ]
> +
> +void kho_block_it_init(struct kho_block_it *it, struct kho_block_set *bs);
> +void *kho_block_it_next(struct kho_block_it *it);
> +void *kho_block_it_read(struct kho_block_it *it);
> +void *kho_block_it_prev(struct kho_block_it *it);
> +void kho_block_it_finalize(struct kho_block_it *it);
These operate on block sets, should be reflected in the names.
Can be kho_blocks_ to avoid too long names.
>
> diff --git a/kernel/liveupdate/kho_block.c b/kernel/liveupdate/kho_block.c
> new file mode 100644
> index 000000000000..a4e650af946f
> --- /dev/null
> +++ b/kernel/liveupdate/kho_block.c
> @@ -0,0 +1,384 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * Copyright (c) 2026, Google LLC.
> + * Pasha Tatashin <pasha.tatashin@soleen.com>
> + */
> +
> +/**
> + * DOC: KHO Serialization Blocks
> + *
> + * KHO provides a mechanism to preserve stateful data across a kexec handover
> + * by serializing it into memory blocks. This file provides the common
"This file" does not look good in HTML docs.
> [ ... skip 15 lines ... ]
> +
> +/*
> + * Safeguard limit for the number of serialization blocks. This is used to
> + * prevent infinite loops and excessive memory allocation in case of memory
> + * corruption in the preserved state.
> + */
Can you add how much memory it is and how many entries with, say, 4 u64
it can accommodate?
> [ ... skip 13 lines ... ]
> +{
> + 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);
Don't you want to set count_per_block in _init()?
> [ ... skip 29 lines ... ]
> + if (!block)
> + return -ENOMEM;
> +
> + block->ser = ser;
> + last = list_last_entry_or_null(&bs->blocks, struct kho_block, list);
> + list_add_tail(&block->list, &bs->blocks);
No locks?
> [ ... skip 12 lines ... ]
> + * @bs: The block set.
> + * @count: The current number of entries.
> + *
> + * This function handles the dynamic expansion of a block set. It allocates
> + * and links a new serialization block if the provided entry count matches
> + * the current total capacity of the set.
This is a weird semantics for a generic API. I'd expect _grow() would
add count - current_count blocks.
> [ ... skip 25 lines ... ]
> +}
> +
> +/**
> + * kho_block_shrink - Conditionally destroy the last block in a block set.
> + * @bs: The block set.
> + * @count: The current number of entries across all blocks.
Maybe
... of valid entries?
> + *
> + * This function checks if the last block in the set is redundant based on the
> + * total entry count and the capacity of the preceding blocks. If the entry
> + * count can be accommodated by the blocks that come before the last one, the
> + * last block is destroyed and removed from the set.
This should mention that it's the caller responsibility to ensure that
entries are removed in the right order.
> [ ... skip 49 lines ... ]
> +
> + fast = phys_to_virt(fast->next);
> + slow = phys_to_virt(slow->next);
> +
> + if (slow == fast) {
> + pr_err("Cyclic list detected\n");
Maybe "block set is corrupted"?
> + return false;
> + }
> + }
> +
> + return true;
> +}
> +
> +/**
> + * kho_block_restore - Restore a block set from a physical address.
> + * @bs: The block set to restore.
> + * @head_pa: Physical address of the first block header.
I'd mention that the block set should be allocated and initialized
> [ ... skip 10 lines ... ]
> + bs->incoming = true;
> + if (!head_pa)
> + return 0;
> +
> + bs->head_pa = head_pa;
> + if (!kho_cyclic_blocks_check(bs)) {
if (kho_block_set_cyclic())
reads nicer IMO
> [ ... skip 87 lines ... ]
> +{
> + if (!it->block)
> + return NULL;
> +
> + if (it->i == kho_block_count_per_block(it->bs)) {
> + it->block->ser->count = it->i;
Why iterator updates ser->count?
> + if (list_is_last(&it->block->list, &it->bs->blocks))
> + return NULL;
> + it->block = list_next_entry(it->block, list);
> + it->i = 0;
> + }
> +
> + return (void *)(it->block->ser + 1) + (it->i++ * it->bs->entry_size);
In a month we'll need an LLM's help to understand what it does.
> +}
> +
> +/**
> + * kho_block_it_read - Return the next entry slot for reading.
> + * @it: The block iterator.
And what is the conceptual difference between this and _it_next()?
> [ ... skip 49 lines ... ]
> + * @it: The block iterator.
> + */
> +void kho_block_it_finalize(struct kho_block_it *it)
> +{
> + if (it->block)
> + it->block->ser->count = it->i;
So, it looks like the intention of _it_next is for write, and this ends a
write iteration.
I think the names should be adjusted to make it clearer.
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v4 03/13] liveupdate: centralize state management into struct luo_ser
From: Mike Rapoport @ 2026-06-02 8:13 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: <20260530221938.115978-4-pasha.tatashin@soleen.com>
On Sat, 30 May 2026 22:19:28 +0000, Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
> diff --git a/kernel/liveupdate/luo_flb.c b/kernel/liveupdate/luo_flb.c
> index 8f5c5dd01cd0..c8dd30b41238 100644
> --- a/kernel/liveupdate/luo_flb.c
> +++ b/kernel/liveupdate/luo_flb.c
> @@ -579,53 +565,18 @@ int __init luo_flb_setup_outgoing(void *fdt_out)
> [ ... skip 18 lines ... ]
> - offset = fdt_subnode_offset(fdt_in, 0, LUO_FDT_FLB_NODE_NAME);
> - if (offset < 0) {
> - pr_err("Unable to get FLB node [%s]\n", LUO_FDT_FLB_NODE_NAME);
> -
> - return -ENOENT;
> + if (flbs_pa) {
I like
if (!flbs_pa)
return;
more
>
> diff --git a/kernel/liveupdate/luo_session.c b/kernel/liveupdate/luo_session.c
> index 8d9201c25412..3b760fefa7b9 100644
> --- a/kernel/liveupdate/luo_session.c
> +++ b/kernel/liveupdate/luo_session.c
> @@ -497,75 +494,34 @@ int luo_session_retrieve(const char *name, struct file **filep)
> [ ... skip 58 lines ... ]
> + if (sessions_pa) {
> + header_ser = phys_to_virt(sessions_pa);
> + luo_session_global.incoming.header_ser = header_ser;
> + luo_session_global.incoming.ser = (void *)(header_ser + 1);
> + luo_session_global.incoming.active = true;
> }
Ditto
--
Sincerely yours,
Mike.
^ 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