* Re: [PATCH v10 28/30] KVM: arm64: selftests: Skip impossible invalid value tests
From: Ben Horgan @ 2026-03-24 14:54 UTC (permalink / raw)
To: Mark Brown, Marc Zyngier, Joey Gouly, Catalin Marinas,
Suzuki K Poulose, Will Deacon, Paolo Bonzini, Jonathan Corbet,
Shuah Khan, Oliver Upton
Cc: Dave Martin, Fuad Tabba, Mark Rutland, linux-arm-kernel, kvmarm,
linux-kernel, kvm, linux-doc, linux-kselftest, Peter Maydell,
Eric Auger
In-Reply-To: <20260306-kvm-arm64-sme-v10-28-43f7683a0fb7@kernel.org>
Hi Mark,
On 3/6/26 17:01, Mark Brown wrote:
> The set_id_regs test currently assumes that there will always be invalid
> values available in bitfields for it to generate but this may not be the
> case if the architecture has defined meanings for every possible value for
> the bitfield. An assert added in commit bf09ee918053e ("KVM: arm64:
> selftests: Remove ARM64_FEATURE_FIELD_BITS and its last user") refuses to
> run for single bit fields which will show the issue most readily but there
> is no reason wider ones can't show the same issue.
>
> Rework the tests for invalid value to check if an invalid value can be
> generated and skip the test if not, removing the assert.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> tools/testing/selftests/kvm/arm64/set_id_regs.c | 63 +++++++++++++++++++++----
> 1 file changed, 53 insertions(+), 10 deletions(-)
>
> diff --git a/tools/testing/selftests/kvm/arm64/set_id_regs.c b/tools/testing/selftests/kvm/arm64/set_id_regs.c
> index bfca7be3e766..928e7d9e5ab7 100644
> --- a/tools/testing/selftests/kvm/arm64/set_id_regs.c
> +++ b/tools/testing/selftests/kvm/arm64/set_id_regs.c
> @@ -317,11 +317,12 @@ uint64_t get_safe_value(const struct reg_ftr_bits *ftr_bits, uint64_t ftr)
> }
>
> /* Return an invalid value to a given ftr_bits an ftr value */
> -uint64_t get_invalid_value(const struct reg_ftr_bits *ftr_bits, uint64_t ftr)
> +uint64_t get_invalid_value(const struct reg_ftr_bits *ftr_bits, uint64_t ftr,
> + bool *skip)
> {
> uint64_t ftr_max = ftr_bits->mask >> ftr_bits->shift;
>
> - TEST_ASSERT(ftr_max > 1, "This test doesn't support single bit features");
> + *skip = false;
>
> if (ftr_bits->sign == FTR_UNSIGNED) {
> switch (ftr_bits->type) {
> @@ -329,42 +330,81 @@ uint64_t get_invalid_value(const struct reg_ftr_bits *ftr_bits, uint64_t ftr)
> ftr = max((uint64_t)ftr_bits->safe_val + 1, ftr + 1);
> break;
> case FTR_LOWER_SAFE:
> + if (ftr == ftr_max)
> + *skip = true;
> ftr++;
> break;
> case FTR_HIGHER_SAFE:
> + if (ftr == 0)
> + *skip = true;
> ftr--;
> break;
> case FTR_HIGHER_OR_ZERO_SAFE:
> - if (ftr == 0)
> + switch (ftr) {
> + case 0:
> ftr = ftr_max;
> - else
> + break;
> + case 1:
> + *skip = true;
> + break;
> + default:
> ftr--;
> + break;
> + }
> break;
> default:
> + *skip = true;
> break;
> }
> } else if (ftr != ftr_max) {
> switch (ftr_bits->type) {
> case FTR_EXACT:
> ftr = max((uint64_t)ftr_bits->safe_val + 1, ftr + 1);
> + if (ftr >= ftr_max)
> + *skip = true;
> break;
> case FTR_LOWER_SAFE:
> ftr++;
> break;
> case FTR_HIGHER_SAFE:
> - ftr--;
> + /* FIXME: "need to check for the actual highest." */
> + if (ftr == ftr_max)
> + *skip = true;
> + else
> + ftr--;
> break;
> case FTR_HIGHER_OR_ZERO_SAFE:
> - if (ftr == 0)
> - ftr = ftr_max - 1;
> - else
> + switch (ftr) {
> + case 0:
> + if (ftr_max > 1)
> + ftr = ftr_max - 1;
> + else
> + *skip = true;
> + break;
> + case 1:
> + *skip = true;
> + break;
> + default:
> ftr--;
> + break;
> + }
> break;
> default:
> + *skip = true;
> break;
> }
> } else {
> - ftr = 0;
> + switch (ftr_bits->type) {
> + case FTR_LOWER_SAFE:
> + if (ftr == 0)
> + *skip = true;
> + else
> + ftr = 0;
> + break;
> + default:
> + *skip = true;
> + break;
> + }
> }
I hacked up a quick loop to check what this function is doing.
With a mask=0x1 I see some value returned that have bits set
outside of the mask.
safe_val ftr out
UNSIGNED
FTR_EXACT
0x0 0x0 0x1
0x0 0x1 0x2 # out of range
0x1 0x0 0x2 # out of range
0x1 0x1 0x2 # out of range
FTR_LOWER_SAFE
0x0 0x0 0x1
0x0 0x1 SKIP
0x1 0x0 0x1
0x1 0x1 SKIP
FTR_HIGHER_SAFE
0x0 0x0 SKIP
0x0 0x1 0x0
0x1 0x0 SKIP
0x1 0x1 0x0
FTR_HIGHER_OR_ZERO_SAFE
0x0 0x0 0x1
0x0 0x1 SKIP
0x1 0x0 0x1
0x1 0x1 SKIP
SIGNED
FTR_EXACT
0x0 0x0 SKIP
0x0 0x1 SKIP
0x1 0x0 SKIP
0x1 0x1 SKIP
FTR_LOWER_SAFE
0x0 0x0 0x1
0x0 0x1 0x0
0x1 0x0 0x1
0x1 0x1 0x0
FTR_HIGHER_SAFE
0x0 0x0 0xffffffffffffffff # out of range
0x0 0x1 SKIP
0x1 0x0 0xffffffffffffffff # out of range
0x1 0x1 SKIP
FTR_HIGHER_OR_ZERO_SAFE
0x0 0x0 SKIP
0x0 0x1 SKIP
0x1 0x0 SKIP
0x1 0x1 SKIP
Thanks,
Ben
>
> return ftr;
> @@ -399,12 +439,15 @@ static void test_reg_set_fail(struct kvm_vcpu *vcpu, uint64_t reg,
> uint8_t shift = ftr_bits->shift;
> uint64_t mask = ftr_bits->mask;
> uint64_t val, old_val, ftr;
> + bool skip;
> int r;
>
> val = vcpu_get_reg(vcpu, reg);
> ftr = (val & mask) >> shift;
>
> - ftr = get_invalid_value(ftr_bits, ftr);
> + ftr = get_invalid_value(ftr_bits, ftr, &skip);
> + if (skip)
> + return;
>
> old_val = val;
> ftr <<= shift;
>
^ permalink raw reply
* Re: [PATCH V9 6/8] dax: Add dax_set_ops() for setting dax_operations at bind time
From: Jonathan Cameron @ 2026-03-24 14:53 UTC (permalink / raw)
To: John Groves
Cc: John Groves, Miklos Szeredi, Dan Williams, Bernd Schubert,
Alison Schofield, John Groves, Jonathan Corbet, Shuah Khan,
Vishal Verma, Dave Jiang, Matthew Wilcox, Jan Kara,
Alexander Viro, David Hildenbrand, Christian Brauner,
Darrick J . Wong, Randy Dunlap, Jeff Layton, Amir Goldstein,
Stefan Hajnoczi, Joanne Koong, Josef Bacik, Bagas Sanjaya,
Chen Linxuan, James Morse, Fuad Tabba, Sean Christopherson,
Shivank Garg, Ackerley Tng, Gregory Price, Aravind Ramesh,
Ajay Joshi, venkataravis@micron.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev,
linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org
In-Reply-To: <0100019d1d4814db-1e36cd9c-09c3-4e60-b48f-2b5c3cb9e406-000000@email.amazonses.com>
On Tue, 24 Mar 2026 00:39:16 +0000
John Groves <john@jagalactic.com> wrote:
> From: John Groves <John@Groves.net>
>
> Add a new dax_set_ops() function that allows drivers to set the
> dax_operations after the dax_device has been allocated. This is needed
> for fsdev_dax where the operations need to be set during probe and
> cleared during unbind.
>
> The fsdev driver uses devm_add_action_or_reset() for cleanup consistency,
> avoiding the complexity of mixing devm-managed resources with manual
> cleanup in a remove() callback. This ensures cleanup happens automatically
> in the correct reverse order when the device is unbound.
>
> Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> Signed-off-by: John Groves <john@groves.net>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply
* Re: [PATCH V9 5/8] dax: Add dax_operations for use by fs-dax on fsdev dax
From: Jonathan Cameron @ 2026-03-24 14:51 UTC (permalink / raw)
To: John Groves, nvdimm@lists.linux.dev
Cc: John Groves, Miklos Szeredi, Dan Williams, Bernd Schubert,
Alison Schofield, John Groves, Jonathan Corbet, Shuah Khan,
Vishal Verma, Dave Jiang, Matthew Wilcox, Jan Kara,
Alexander Viro, David Hildenbrand, Christian Brauner,
Darrick J . Wong, Randy Dunlap, Jeff Layton, Amir Goldstein,
Stefan Hajnoczi, Joanne Koong, Josef Bacik, Bagas Sanjaya,
Chen Linxuan, James Morse, Fuad Tabba, Sean Christopherson,
Shivank Garg, Ackerley Tng, Gregory Price, Aravind Ramesh,
Ajay Joshi, venkataravis@micron.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org,
linux-fsdevel@vger.kernel.org
In-Reply-To: <0100019d1d47e459-48f2a4e6-edab-4002-bde3-2ba642deccaf-000000@email.amazonses.com>
On Tue, 24 Mar 2026 00:39:04 +0000
John Groves <john@jagalactic.com> wrote:
> From: John Groves <John@Groves.net>
>
> fsdev: Add dax_operations for use by famfs.
>
> This replicates the functionality from drivers/nvdimm/pmem.c that
> conventional fs-dax file systems (e.g. xfs) use to support dax
> read/write/mmap to a daxdev - without which famfs can't sit atop a
> daxdev.
>
> - These methods are based on pmem_dax_ops from drivers/nvdimm/pmem.c
> - fsdev_dax_direct_access() returns the hpa, pfn and kva. The kva was
> newly stored as dev_dax->virt_addr by dev_dax_probe().
> - The hpa/pfn are used for mmap (dax_iomap_fault()), and the kva is used
> for read/write (dax_iomap_rw())
> - fsdev_dax_recovery_write() and dev_dax_zero_page_range() have not been
> tested yet. I'm looking for suggestions as to how to test those.
> - dax-private.h: add dev_dax->cached_size, which fsdev needs to
> remember. The dev_dax size cannot change while a driver is bound
> (dev_dax_resize returns -EBUSY if dev->driver is set). Caching the size
> at probe time allows fsdev's direct_access path can use it without
> acquiring dax_dev_rwsem (which isn't exported anyway).
>
> Signed-off-by: John Groves <john@groves.net>
The indent of trailing parameter lines is very random in here.
Pick a style and stick to it. Few other trivial things inline.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> ---
> drivers/dax/dax-private.h | 1 +
> drivers/dax/fsdev.c | 84 +++++++++++++++++++++++++++++++++++++++
> 2 files changed, 85 insertions(+)
> diff --git a/drivers/dax/fsdev.c b/drivers/dax/fsdev.c
> index c75478d3d548..be3d2b0e8418 100644
> --- a/drivers/dax/fsdev.c
> +++ b/drivers/dax/fsdev.c
> +static long __fsdev_dax_direct_access(struct dax_device *dax_dev, pgoff_t pgoff,
> + long nr_pages, enum dax_access_mode mode, void **kaddr,
> + unsigned long *pfn)
> +{
> + struct dev_dax *dev_dax = dax_get_private(dax_dev);
> + size_t size = nr_pages << PAGE_SHIFT;
> + size_t offset = pgoff << PAGE_SHIFT;
> + void *virt_addr = dev_dax->virt_addr + offset;
> + phys_addr_t phys;
> + unsigned long local_pfn;
> +
> + phys = dax_pgoff_to_phys(dev_dax, pgoff, nr_pages << PAGE_SHIFT);
> + if (phys == -1) {
> + dev_dbg(&dev_dax->dev,
> + "pgoff (%#lx) out of range\n", pgoff);
> + return -EFAULT;
> + }
> +
> + if (kaddr)
> + *kaddr = virt_addr;
> +
> + local_pfn = PHYS_PFN(phys);
Trivial but if !pfn, local_pfn not used so...
if (pfn)
*pfn = PHYS_PFN(phys);
Obviously ignore this if it becomes used in some later patch.
> + if (pfn)
> + *pfn = local_pfn;
> +
> + /*
> + * Use cached_size which was computed at probe time. The size cannot
> + * change while the driver is bound (resize returns -EBUSY).
Might be worth capturing somewhere in code that using the value from
probe means you don't need locking.
> + */
> + return PHYS_PFN(min(size, dev_dax->cached_size - offset));
> +}
> +
> +static int fsdev_dax_zero_page_range(struct dax_device *dax_dev,
> + pgoff_t pgoff, size_t nr_pages)
Three tabs
> +{
> + void *kaddr;
> +
> + WARN_ONCE(nr_pages > 1, "%s: nr_pages > 1\n", __func__);
> + __fsdev_dax_direct_access(dax_dev, pgoff, 1, DAX_ACCESS, &kaddr, NULL);
> + fsdev_write_dax(kaddr, ZERO_PAGE(0), 0, PAGE_SIZE);
> + return 0;
> +}
> +
> +static long fsdev_dax_direct_access(struct dax_device *dax_dev,
> + pgoff_t pgoff, long nr_pages, enum dax_access_mode mode,
Why that indent? Two tabs and a couple of spaces...
Either two tabs, or align after (
> + void **kaddr, unsigned long *pfn)
> +{
> + return __fsdev_dax_direct_access(dax_dev, pgoff, nr_pages, mode,
> + kaddr, pfn);
> +}
> +
> +static size_t fsdev_dax_recovery_write(struct dax_device *dax_dev, pgoff_t pgoff,
> + void *addr, size_t bytes, struct iov_iter *i)
two tabs....
> +{
> + return _copy_from_iter_flushcache(addr, bytes, i);
> +}
> +
> +static const struct dax_operations dev_dax_ops = {
> + .direct_access = fsdev_dax_direct_access,
> + .zero_page_range = fsdev_dax_zero_page_range,
> + .recovery_write = fsdev_dax_recovery_write,
> +};
^ permalink raw reply
* [PATCH] Documentation/admin-guide/mm/damon: fix 'parametrs' typo
From: Cheng-Han Wu @ 2026-03-24 14:48 UTC (permalink / raw)
To: sj, corbet, damon, linux-mm, linux-doc, linux-kernel; +Cc: skhan, Cheng-Han Wu
Fix the misspelling of "parametrs" as "parameters" in
reclaim.rst and lru_sort.rst.
Signed-off-by: Cheng-Han Wu <hank20010209@gmail.com>
---
Documentation/admin-guide/mm/damon/lru_sort.rst | 2 +-
Documentation/admin-guide/mm/damon/reclaim.rst | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/mm/damon/lru_sort.rst b/Documentation/admin-guide/mm/damon/lru_sort.rst
index 20a8378d5a94..4f6a644be2ff 100644
--- a/Documentation/admin-guide/mm/damon/lru_sort.rst
+++ b/Documentation/admin-guide/mm/damon/lru_sort.rst
@@ -75,7 +75,7 @@ Make DAMON_LRU_SORT reads the input parameters again, except ``enabled``.
Input parameters that updated while DAMON_LRU_SORT is running are not applied
by default. Once this parameter is set as ``Y``, DAMON_LRU_SORT reads values
-of parametrs except ``enabled`` again. Once the re-reading is done, this
+of parameters except ``enabled`` again. Once the re-reading is done, this
parameter is set as ``N``. If invalid parameters are found while the
re-reading, DAMON_LRU_SORT will be disabled.
diff --git a/Documentation/admin-guide/mm/damon/reclaim.rst b/Documentation/admin-guide/mm/damon/reclaim.rst
index 8eba3da8dcee..1f54a2d270f5 100644
--- a/Documentation/admin-guide/mm/damon/reclaim.rst
+++ b/Documentation/admin-guide/mm/damon/reclaim.rst
@@ -67,7 +67,7 @@ Make DAMON_RECLAIM reads the input parameters again, except ``enabled``.
Input parameters that updated while DAMON_RECLAIM is running are not applied
by default. Once this parameter is set as ``Y``, DAMON_RECLAIM reads values
-of parametrs except ``enabled`` again. Once the re-reading is done, this
+of parameters except ``enabled`` again. Once the re-reading is done, this
parameter is set as ``N``. If invalid parameters are found while the
re-reading, DAMON_RECLAIM will be disabled.
--
2.53.0
^ permalink raw reply related
* Re: [PATCH V9 4/8] dax: Save the kva from memremap
From: Jonathan Cameron @ 2026-03-24 14:40 UTC (permalink / raw)
To: John Groves
Cc: John Groves, Miklos Szeredi, Dan Williams, Bernd Schubert,
Alison Schofield, John Groves, Jonathan Corbet, Shuah Khan,
Vishal Verma, Dave Jiang, Matthew Wilcox, Jan Kara,
Alexander Viro, David Hildenbrand, Christian Brauner,
Darrick J . Wong, Randy Dunlap, Jeff Layton, Amir Goldstein,
Stefan Hajnoczi, Joanne Koong, Josef Bacik, Bagas Sanjaya,
Chen Linxuan, James Morse, Fuad Tabba, Sean Christopherson,
Shivank Garg, Ackerley Tng, Gregory Price, Aravind Ramesh,
Ajay Joshi, venkataravis@micron.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev,
linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Ira Weiny
In-Reply-To: <0100019d1d47a813-6b74d7e9-5171-4382-bfa5-67bf9667c62a-000000@email.amazonses.com>
On Tue, 24 Mar 2026 00:38:48 +0000
John Groves <john@jagalactic.com> wrote:
> From: John Groves <john@groves.net>
>
> Save the kva from memremap because we need it for iomap rw support.
>
> Prior to famfs, there were no iomap users of /dev/dax - so the virtual
> address from memremap was not needed.
>
> Reviewed-by: Ira Weiny <ira.weiny@intel.com>
> Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> Signed-off-by: John Groves <john@groves.net>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply
* Re: [PATCH V9 3/8] dax: add fsdev.c driver for fs-dax on character dax
From: Jonathan Cameron @ 2026-03-24 14:39 UTC (permalink / raw)
To: John Groves
Cc: John Groves, Miklos Szeredi, Dan Williams, Bernd Schubert,
Alison Schofield, John Groves, Jonathan Corbet, Shuah Khan,
Vishal Verma, Dave Jiang, Matthew Wilcox, Jan Kara,
Alexander Viro, David Hildenbrand, Christian Brauner,
Darrick J . Wong, Randy Dunlap, Jeff Layton, Amir Goldstein,
Stefan Hajnoczi, Joanne Koong, Josef Bacik, Bagas Sanjaya,
Chen Linxuan, James Morse, Fuad Tabba, Sean Christopherson,
Shivank Garg, Ackerley Tng, Gregory Price, Aravind Ramesh,
Ajay Joshi, venkataravis@micron.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev,
linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org
In-Reply-To: <0100019d1d476420-6b0bf60e-3b3a-4868-8f5f-484cd55d4709-000000@email.amazonses.com>
On Tue, 24 Mar 2026 00:38:31 +0000
John Groves <john@jagalactic.com> wrote:
> From: John Groves <john@groves.net>
>
> The new fsdev driver provides pages/folios initialized compatibly with
> fsdax - normal rather than devdax-style refcounting, and starting out
> with order-0 folios.
>
> When fsdev binds to a daxdev, it is usually (always?) switching from the
> devdax mode (device.c), which pre-initializes compound folios according
> to its alignment. Fsdev uses fsdev_clear_folio_state() to switch the
> folios into a fsdax-compatible state.
>
> A side effect of this is that raw mmap doesn't (can't?) work on an fsdev
> dax instance. Accordingly, The fsdev driver does not provide raw mmap -
> devices must be put in 'devdax' mode (drivers/dax/device.c) to get raw
> mmap capability.
>
> In this commit is just the framework, which remaps pages/folios compatibly
> with fsdax.
>
> Enabling dax changes:
>
> - bus.h: add DAXDRV_FSDEV_TYPE driver type
> - bus.c: allow DAXDRV_FSDEV_TYPE drivers to bind to daxdevs
> - dax.h: prototype inode_dax(), which fsdev needs
>
> Suggested-by: Dan Williams <dan.j.williams@intel.com>
> Suggested-by: Gregory Price <gourry@gourry.net>
> Signed-off-by: John Groves <john@groves.net>
I was kind of thinking you'd go with a hidden KCONFIG option with default
magic to do the same build condition to you had in the Makefil, but one the
user can opt in or out for is also fine.
Comments on that below. Meh, I think this is better anyway :)
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig
> index d656e4c0eb84..7051b70980d5 100644
> --- a/drivers/dax/Kconfig
> +++ b/drivers/dax/Kconfig
> @@ -61,6 +61,17 @@ config DEV_DAX_HMEM_DEVICES
> depends on DEV_DAX_HMEM && DAX
> def_bool y
>
> +config DEV_DAX_FSDEV
> + tristate "FSDEV DAX: fs-dax compatible devdax driver"
> + depends on DEV_DAX && FS_DAX
> + help
> + Support fs-dax access to DAX devices via a character device
> + interface. Unlike device_dax (which pre-initializes compound folios
> + based on device alignment), this driver leaves folios at order-0 so
> + that fs-dax filesystems can manage folio order dynamically.
> +
> + Say M if unsure.
Fine like this, but if you wanted to hide it in interests of not
confusing users...
config DEV_DAX_FSDEV
tristate
depends on DEV_DAX && FS_DAX
default DEV_DAX
> +
> config DEV_DAX_KMEM
> tristate "KMEM DAX: map dax-devices as System-RAM"
> default DEV_DAX
> +}
^ permalink raw reply
* Re: [PATCH v4 07/21] mm: have mmap_action_complete() handle the rmap lock and unmap
From: Vlastimil Babka (SUSE) @ 2026-03-24 14:38 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <8d1ee8ebd3542d006a47e8382fb80cf5b57ecf10.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> Rather than have the callers handle this both the rmap lock release and
> unmapping the VMA on error, handle it within the mmap_action_complete()
> logic where it makes sense to, being careful not to unlock twice.
>
> This simplifies the logic and makes it harder to make mistake with this,
> while retaining correct behaviour with regard to avoiding deadlocks.
>
> Also replace the call_action_complete() function with a direct invocation
> of mmap_action_complete() as the abstraction is no longer required.
>
> Also update the VMA tests to reflect this change.
>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Nice simplification.
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 06/21] mm/vma: remove superfluous map->hold_file_rmap_lock
From: Vlastimil Babka (SUSE) @ 2026-03-24 14:31 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <42c3fbb701e361a17193ecda0d2dabcc326288a5.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> We don't need to reference this field, it's confusing as it duplicates
> mmap_action->hide_from_rmap_until_complete, so thread the mmap_action
> through to __mmap_new_vma() instead and use the same field consistently.
>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 05/21] mm: switch the rmap lock held option off in compat layer
From: Vlastimil Babka (SUSE) @ 2026-03-24 14:26 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <dda74230d26a1fcd79a3efab61fa4101dd1cac64.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> In the mmap_prepare compatibility layer, we don't need to hold the rmap
> lock, as we are being called from an .mmap handler.
>
> The .mmap_prepare hook, when invoked in the VMA logic, is called prior to
> the VMA being instantiated, but the completion hook is called after the VMA
> is linked into the maple tree, meaning rmap walkers can reach it.
>
> The mmap hook does not link the VMA into the tree, so this cannot happen.
>
> Therefore it's safe to simply disable this in the mmap_prepare
> compatibility layer.
>
> Also update VMA tests code to reflect current compatibility layer state.
>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
a typo fix below, Andrew can fix locally?
> ---
> mm/util.c | 6 ++++-
> tools/testing/vma/include/dup.h | 42 +++++++++++++++++----------------
> 2 files changed, 27 insertions(+), 21 deletions(-)
>
> diff --git a/mm/util.c b/mm/util.c
> index a2cfa0d77c35..182f0f5cc400 100644
> --- a/mm/util.c
> +++ b/mm/util.c
> @@ -1204,6 +1204,7 @@ int compat_vma_mmap(struct file *file, struct vm_area_struct *vma)
>
> .action.type = MMAP_NOTHING, /* Default */
> };
> + struct mmap_action *action = &desc.action;
> int err;
>
> err = vfs_mmap_prepare(file, &desc);
> @@ -1214,8 +1215,11 @@ int compat_vma_mmap(struct file *file, struct vm_area_struct *vma)
> if (err)
> return err;
>
> + /* being invoked from .mmmap means we don't have to enforce this. */
.mmap
> + action->hide_from_rmap_until_complete = false;
> +
> set_vma_from_desc(vma, &desc);
> - err = mmap_action_complete(vma, &desc.action);
> + err = mmap_action_complete(vma, action);
> if (err) {
> const size_t len = vma_pages(vma) << PAGE_SHIFT;
>
^ permalink raw reply
* Re: [PATCH V9 2/8] dax: Factor out dax_folio_reset_order() helper
From: Jonathan Cameron @ 2026-03-24 14:23 UTC (permalink / raw)
To: John Groves
Cc: John Groves, Miklos Szeredi, Dan Williams, Bernd Schubert,
Alison Schofield, John Groves, Jonathan Corbet, Shuah Khan,
Vishal Verma, Dave Jiang, Matthew Wilcox, Jan Kara,
Alexander Viro, David Hildenbrand, Christian Brauner,
Darrick J . Wong, Randy Dunlap, Jeff Layton, Amir Goldstein,
Stefan Hajnoczi, Joanne Koong, Josef Bacik, Bagas Sanjaya,
Chen Linxuan, James Morse, Fuad Tabba, Sean Christopherson,
Shivank Garg, Ackerley Tng, Gregory Price, Aravind Ramesh,
Ajay Joshi, venkataravis@micron.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev,
linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Ira Weiny
In-Reply-To: <0100019d1d47285f-eedfbde4-0f74-4356-b694-4b44fab92f2c-000000@email.amazonses.com>
On Tue, 24 Mar 2026 00:38:15 +0000
John Groves <john@jagalactic.com> wrote:
> From: John Groves <John@Groves.net>
>
> Both fs/dax.c:dax_folio_put() and drivers/dax/fsdev.c:
> fsdev_clear_folio_state() (the latter coming in the next commit after this
> one) contain nearly identical code to reset a compound DAX folio back to
> order-0 pages. Factor this out into a shared helper function.
>
> The new dax_folio_reset_order() function:
> - Clears the folio's mapping and share count
> - Resets compound folio state via folio_reset_order()
> - Clears PageHead and compound_head for each sub-page
> - Restores the pgmap pointer for each resulting order-0 folio
> - Returns the original folio order (for callers that need to advance by
> that many pages)
>
> Two intentional differences from the original dax_folio_put() logic:
>
> 1. folio->share is cleared unconditionally. This is correct because the DAX
> subsystem maintains the invariant that share != 0 only when mapping == NULL
> (enforced by dax_folio_make_shared()). dax_folio_put() ensures share has
> reached zero before calling this helper, so the unconditional clear is safe.
>
> 2. folio->pgmap is now explicitly restored for order-0 folios. For the
> dax_folio_put() caller this is a no-op (reads and writes back the same
> field). It is intentional for the upcoming fsdev_clear_folio_state()
> caller, which converts previously-compound folios and needs pgmap
> re-established for all pages regardless of order.
>
> This simplifies fsdev_clear_folio_state() from ~50 lines to ~15 lines.
>
> Suggested-by: Jonathan Cameron <jonathan.cameron@huawei.com>
A couple of trivial "if you are respinning" line length of comments
comments inline.
Subject to DAX folk sanity checking the new comments match their
expectations.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Reviewed-by: Ira Weiny <ira.weiny@intel.com>
> Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> Signed-off-by: John Groves <john@groves.net>
> ---
> fs/dax.c | 74 ++++++++++++++++++++++++++++++++++-----------
> include/linux/dax.h | 1 +
> 2 files changed, 57 insertions(+), 18 deletions(-)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index 289e6254aa30..eba86802a7a7 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -378,6 +378,59 @@ static void dax_folio_make_shared(struct folio *folio)
> folio->share = 1;
> }
>
> +/**
> + * dax_folio_reset_order - Reset a compound DAX folio to order-0 pages
> + * @folio: The folio to reset
> + *
> + * Splits a compound folio back into individual order-0 pages,
> + * clearing compound state and restoring pgmap pointers.
> + *
> + * Returns: the original folio order (0 if already order-0)
> + */
> +int dax_folio_reset_order(struct folio *folio)
> +{
> + struct dev_pagemap *pgmap = page_pgmap(&folio->page);
> + int order = folio_order(folio);
> +
> + /*
> + * DAX maintains the invariant that folio->share != 0 only when
> + * folio->mapping == NULL (enforced by dax_folio_make_shared()).
> + * Equivalently: folio->mapping != NULL implies folio->share == 0.
> + * Callers ensure share has been decremented to zero before
> + * calling here, so unconditionally clearing both fields is
> + * correct.
If you happen to spin again, wrap is a bit short of standard 80 chars.
* DAX maintains the invariant that folio->share != 0 only when
* folio->mapping == NULL (enforced by dax_folio_make_shared()).
* Equivalently: folio->mapping != NULL implies folio->share == 0.
* Callers ensure share has been decremented to zero before calling here,
* so unconditionally clearing both fields is correct.
> + */
> + folio->mapping = NULL;
> + folio->share = 0;
> +
> + if (!order) {
> + /*
> + * Restore pgmap explicitly even for order-0 folios. For
> + * the dax_folio_put() caller this is a no-op (same value),
> + * but fsdev_clear_folio_state() may call this on folios
> + * that were previously compound and need pgmap
> + * re-established.
> + */
* Restore pgmap explicitly even for order-0 folios. For the
* dax_folio_put() caller this is a no-op (same value), but
* fsdev_clear_folio_state() may call this on folios that were
* previously compound and need pgmap re-established.
*/
> + folio->pgmap = pgmap;
> + return 0;
> + }
> +
> + folio_reset_order(folio);
> +
> + for (int i = 0; i < (1UL << order); i++) {
> + struct page *page = folio_page(folio, i);
> + struct folio *f = (struct folio *)page;
> +
> + ClearPageHead(page);
> + clear_compound_head(page);
> + f->mapping = NULL;
> + f->share = 0;
> + f->pgmap = pgmap;
> + }
> +
> + return order;
> +}
^ permalink raw reply
* Re: [PATCH V9 1/8] dax: move dax_pgoff_to_phys from [drivers/dax/] device.c to bus.c
From: Jonathan Cameron @ 2026-03-24 14:18 UTC (permalink / raw)
To: John Groves
Cc: John Groves, Miklos Szeredi, Dan Williams, Bernd Schubert,
Alison Schofield, John Groves, Jonathan Corbet, Shuah Khan,
Vishal Verma, Dave Jiang, Matthew Wilcox, Jan Kara,
Alexander Viro, David Hildenbrand, Christian Brauner,
Darrick J . Wong, Randy Dunlap, Jeff Layton, Amir Goldstein,
Stefan Hajnoczi, Joanne Koong, Josef Bacik, Bagas Sanjaya,
Chen Linxuan, James Morse, Fuad Tabba, Sean Christopherson,
Shivank Garg, Ackerley Tng, Gregory Price, Aravind Ramesh,
Ajay Joshi, venkataravis@micron.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev,
linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Ira Weiny
In-Reply-To: <0100019d1d46d094-cc0a4b79-3bd2-43e8-a08d-ab8cd21266a6-000000@email.amazonses.com>
On Tue, 24 Mar 2026 00:37:53 +0000
John Groves <john@jagalactic.com> wrote:
> From: John Groves <john@groves.net>
>
> This function will be used by both device.c and fsdev.c, but both are
> loadable modules. Moving to bus.c puts it in core and makes it available
> to both.
>
> No code changes - just relocated.
>
> Reviewed-by: Ira Weiny <ira.weiny@intel.com>
> Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> Signed-off-by: John Groves <john@groves.net>
Obviously this is a straight forward code move... But I can't resist
commenting on what is moving (feel free to ignore! or maybe a follow
up patch if you agree.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> ---
> drivers/dax/bus.c | 24 ++++++++++++++++++++++++
> drivers/dax/device.c | 23 -----------------------
> 2 files changed, 24 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
> index c94c09622516..e4bd5c9f006c 100644
> --- a/drivers/dax/bus.c
> +++ b/drivers/dax/bus.c
> @@ -1417,6 +1417,30 @@ static const struct device_type dev_dax_type = {
> .groups = dax_attribute_groups,
> };
>
> +/* see "strong" declaration in tools/testing/nvdimm/dax-dev.c */
> +__weak phys_addr_t dax_pgoff_to_phys(struct dev_dax *dev_dax, pgoff_t pgoff,
> + unsigned long size)
> +{
> + int i;
> +
> + for (i = 0; i < dev_dax->nr_range; i++) {
Modernize as:
for (int i = 0; ...
> + struct dev_dax_range *dax_range = &dev_dax->ranges[i];
> + struct range *range = &dax_range->range;
> + unsigned long long pgoff_end;
> + phys_addr_t phys;
> +
> + pgoff_end = dax_range->pgoff + PHYS_PFN(range_len(range)) - 1;
> + if (pgoff < dax_range->pgoff || pgoff > pgoff_end)
We have in_range() (linux/minmax.h) available for these case of a start to start + length - 1
check. I think this is same:
if (!in_range(pgoff, dax_range->pgoff, PHYS_PFN(range_len(range)))
> + continue;
> + phys = PFN_PHYS(pgoff - dax_range->pgoff) + range->start;
> + if (phys + size - 1 <= range->end)
> + return phys;
> + break;
> + }
> + return -1;
> +}
> +EXPORT_SYMBOL_GPL(dax_pgoff_to_phys);
> +
^ permalink raw reply
* Re: [RFC PATCH v1 1/1] This patch set introces a new action: DAMOS_COLLAPSE.
From: SeongJae Park @ 2026-03-24 14:12 UTC (permalink / raw)
To: Gutierrez Asier
Cc: SeongJae Park, artem.kuzin, stepanov.anatoly, wangkefeng.wang,
yanquanmin1, zuoze1, damon, akpm, ljs, Liam.Howlett, vbabka, rppt,
surenb, mhocko, corbet, skhan, linux-doc, linux-mm, linux-kernel
In-Reply-To: <48580762-eec3-49b6-b17a-59fa486bebec@huawei-partners.com>
On Tue, 24 Mar 2026 16:57:22 +0300 Gutierrez Asier <gutierrez.asier@huawei-partners.com> wrote:
>
>
> On 3/24/2026 3:39 AM, SeongJae Park wrote:
> > Hello Asier,
> >
> > On Mon, 23 Mar 2026 14:56:45 +0000 <gutierrez.asier@huawei-partners.com> wrote:
> >
> >> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> >>
> >> For DAMOS_HUGEPAGE and DAMOS_NOHUGEPAGE to work, khugepaged should be
> >> working, since it relies on hugepage_madvise to add a new slot. This
> >> slot should be picked up by khugepaged and eventually collapse (or
> >> not, if we are using DAMOS_NOHUGEPAGE) the pages. If THP is not
> >> enabled, khugepaged will not be working, and therefore no collapse
> >> will happen.
> >>
> >> DAMOS_COLLAPSE eventually calls madvise_collapse, which will collapse
> >> the address range synchronously.
> >>
> >> This new action may be required to support autotuning with hugepage as
> >> a goal[1].
> >>
> >> [1]: https://lore.kernel.org/damon/20260313000816.79933-1-sj@kernel.org/
> >>
> >> ---------
> >> Benchmarks:
> >>
> >> T n: THP never
> >> T m: THP madvise
> >> D h: DAMON action hugepage
> >> D c: DAMON action collapse
> >>
> >> +------------------+----------+----------+----------+
> >> | | T n, D h | T m, D h | T n, D c |
> >> +------------------+----------+----------+----------+
> >> | Total memory use | 2.07 | 2.09 | 2.07 |
> >> | Huge pages | 0 | 1.3 | 1.25 |
> >> +------------------+----------+----------+----------+
> >
> > Thank you for sharing the benchmark results! But, I'm having a hard time to
> > understand what this really means. Could you please further clarify the setup
> > of the benchmarks and interpretation of the results?
> I will fix the cover in the next version, which I will submit soon.
>
> I tested the patch in a physical server with MariaDB 10.5. I run
> sysbench to load the server.
>
> I check 3 scenarios:
> - DAMON action hugepage for the database task, THP as never
> - DAMON action hugepage, THP madvise
> - DAMON action collapse, THP never
>
> I compared the memory consumption, both in overall in the server and
> anonymous huge page consumption. The results are in the table
>
> T n: THP never
> T m: THP madvise
> D h: DAMON action hugepage
> D c: DAMON action collapse
Thank you for sharing the details of the setup, Asier.
>
> +------------------+----------+----------+----------+
> | | T n, D h | T m, D h | T n, D c |
> +------------------+----------+----------+----------+
> | Total memory use | 2.07 | 2.09 | 2.07 |
> | Huge pages | 0 | 1.3 | 1.25 |
> +------------------+----------+----------+----------+
Could you please further share interpretation of the results? What these
results mean? Does it show some benefit of DAMOS_COLLAPSE?
Also, how is the performance? Does it show some difference?
> >
> >>
> >> Changes
> >> ---------
> >> v1-v2:
> >> Added benchmarks
> >> Added damos_filter_type documentation for new action to fix kernel-doc
> >
> > Please add Changelog on the commentary section [1]. Also, please consider
> > adding links to previous versions.
> >
> >>
> >> Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> >> ---
> >> Documentation/mm/damon/design.rst | 4 ++++
> >> include/linux/damon.h | 2 ++
> >> mm/damon/sysfs-schemes.c | 4 ++++
> >> mm/damon/vaddr.c | 3 +++
> >> tools/testing/selftests/damon/sysfs.py | 11 ++++++-----
> >> 5 files changed, 19 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
> >> index 838b14d22519..405142641e55 100644
> >> --- a/Documentation/mm/damon/design.rst
> >> +++ b/Documentation/mm/damon/design.rst
> >> @@ -467,6 +467,10 @@ that supports each action are as below.
> >> Supported by ``vaddr`` and ``fvaddr`` operations set. When
> >> TRANSPARENT_HUGEPAGE is disabled, the application of the action will just
> >> fail.
> >> + - ``collapse``: Call ``madvise()`` for the region with ``MADV_COLLAPSE``.
> >> + Supported by ``vaddr`` and ``fvaddr`` operations set. When
> >> + TRANSPARENT_HUGEPAGE is disabled, the application of the action will just
> >> + fail.
> >> - ``lru_prio``: Prioritize the region on its LRU lists.
> >> Supported by ``paddr`` operations set.
> >> - ``lru_deprio``: Deprioritize the region on its LRU lists.
> >> diff --git a/include/linux/damon.h b/include/linux/damon.h
> >> index d9a3babbafc1..6941113968ec 100644
> >> --- a/include/linux/damon.h
> >> +++ b/include/linux/damon.h
> >> @@ -121,6 +121,7 @@ struct damon_target {
> >> * @DAMOS_PAGEOUT: Reclaim the region.
> >> * @DAMOS_HUGEPAGE: Call ``madvise()`` for the region with MADV_HUGEPAGE.
> >> * @DAMOS_NOHUGEPAGE: Call ``madvise()`` for the region with MADV_NOHUGEPAGE.
> >> + * @DAMOS_COLLAPSE: Call ``madvise()`` for the region with MADV_COLLAPSE.
> >> * @DAMOS_LRU_PRIO: Prioritize the region on its LRU lists.
> >> * @DAMOS_LRU_DEPRIO: Deprioritize the region on its LRU lists.
> >> * @DAMOS_MIGRATE_HOT: Migrate the regions prioritizing warmer regions.
> >> @@ -140,6 +141,7 @@ enum damos_action {
> >> DAMOS_PAGEOUT,
> >> DAMOS_HUGEPAGE,
> >> DAMOS_NOHUGEPAGE,
> >> + DAMOS_COLLAPSE,
> >> DAMOS_LRU_PRIO,
> >> DAMOS_LRU_DEPRIO,
> >> DAMOS_MIGRATE_HOT,
> >> diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
> >> index 5186966dafb3..aa08a8f885fb 100644
> >> --- a/mm/damon/sysfs-schemes.c
> >> +++ b/mm/damon/sysfs-schemes.c
> >> @@ -2041,6 +2041,10 @@ static struct damos_sysfs_action_name damos_sysfs_action_names[] = {
> >> .action = DAMOS_NOHUGEPAGE,
> >> .name = "nohugepage",
> >> },
> >> + {
> >> + .action = DAMOS_COLLAPSE,
> >> + .name = "collapse",
> >> + },
> >> {
> >> .action = DAMOS_LRU_PRIO,
> >> .name = "lru_prio",
> >> diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c
> >> index b069dbc7e3d2..dd5f2d7027ac 100644
> >> --- a/mm/damon/vaddr.c
> >> +++ b/mm/damon/vaddr.c
> >> @@ -903,6 +903,9 @@ static unsigned long damon_va_apply_scheme(struct damon_ctx *ctx,
> >> case DAMOS_NOHUGEPAGE:
> >> madv_action = MADV_NOHUGEPAGE;
> >> break;
> >> + case DAMOS_COLLAPSE:
> >> + madv_action = MADV_COLLAPSE;
> >> + break;
> >> case DAMOS_MIGRATE_HOT:
> >> case DAMOS_MIGRATE_COLD:
> >> return damos_va_migrate(t, r, scheme, sz_filter_passed);
> >> diff --git a/tools/testing/selftests/damon/sysfs.py b/tools/testing/selftests/damon/sysfs.py
> >> index 3aa5c91548a5..c6476e63f4fb 100755
> >> --- a/tools/testing/selftests/damon/sysfs.py
> >> +++ b/tools/testing/selftests/damon/sysfs.py
> >> @@ -123,11 +123,12 @@ def assert_scheme_committed(scheme, dump):
> >> 'pageout': 2,
> >> 'hugepage': 3,
> >> 'nohugeapge': 4,
> >> - 'lru_prio': 5,
> >> - 'lru_deprio': 6,
> >> - 'migrate_hot': 7,
> >> - 'migrate_cold': 8,
> >> - 'stat': 9,
> >> + 'collapse': 5
> >
> > Comman is missed?
> >
> >> + 'lru_prio': 6,
> >> + 'lru_deprio': 7,
> >> + 'migrate_hot': 8,
> >> + 'migrate_cold': 9,
> >> + 'stat': 10,
> >> }
> >> assert_true(dump['action'] == action_val[scheme.action], 'action', dump)
> >> assert_true(dump['apply_interval_us'] == scheme. apply_interval_us,
> >> --
> >> 2.43.0
> >
> > Other than the selftest part, code looks good. Please consider dropping RFC
> > tag from the next spin. Clarifying more details about the test would be
> > helpful, though.
> >
> > [1] https://docs.kernel.org/process/submitting-patches.html#commentary
> >
> >
> > Thanks,
> > SJ
> >
>
> SJ, should I remove the RFC tag for the next version?
If you feel comfortable with it, please do so.
Thanks,
SJ
[...]
^ permalink raw reply
* Re: [RFC PATCH v1 1/1] This patch set introces a new action: DAMOS_COLLAPSE.
From: Gutierrez Asier @ 2026-03-24 13:57 UTC (permalink / raw)
To: SeongJae Park
Cc: artem.kuzin, stepanov.anatoly, wangkefeng.wang, yanquanmin1,
zuoze1, damon, akpm, ljs, Liam.Howlett, vbabka, rppt, surenb,
mhocko, corbet, skhan, linux-doc, linux-mm, linux-kernel
In-Reply-To: <20260324003952.86819-1-sj@kernel.org>
On 3/24/2026 3:39 AM, SeongJae Park wrote:
> Hello Asier,
>
> On Mon, 23 Mar 2026 14:56:45 +0000 <gutierrez.asier@huawei-partners.com> wrote:
>
>> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
>>
>> For DAMOS_HUGEPAGE and DAMOS_NOHUGEPAGE to work, khugepaged should be
>> working, since it relies on hugepage_madvise to add a new slot. This
>> slot should be picked up by khugepaged and eventually collapse (or
>> not, if we are using DAMOS_NOHUGEPAGE) the pages. If THP is not
>> enabled, khugepaged will not be working, and therefore no collapse
>> will happen.
>>
>> DAMOS_COLLAPSE eventually calls madvise_collapse, which will collapse
>> the address range synchronously.
>>
>> This new action may be required to support autotuning with hugepage as
>> a goal[1].
>>
>> [1]: https://lore.kernel.org/damon/20260313000816.79933-1-sj@kernel.org/
>>
>> ---------
>> Benchmarks:
>>
>> T n: THP never
>> T m: THP madvise
>> D h: DAMON action hugepage
>> D c: DAMON action collapse
>>
>> +------------------+----------+----------+----------+
>> | | T n, D h | T m, D h | T n, D c |
>> +------------------+----------+----------+----------+
>> | Total memory use | 2.07 | 2.09 | 2.07 |
>> | Huge pages | 0 | 1.3 | 1.25 |
>> +------------------+----------+----------+----------+
>
> Thank you for sharing the benchmark results! But, I'm having a hard time to
> understand what this really means. Could you please further clarify the setup
> of the benchmarks and interpretation of the results?
I will fix the cover in the next version, which I will submit soon.
I tested the patch in a physical server with MariaDB 10.5. I run
sysbench to load the server.
I check 3 scenarios:
- DAMON action hugepage for the database task, THP as never
- DAMON action hugepage, THP madvise
- DAMON action collapse, THP never
I compared the memory consumption, both in overall in the server and
anonymous huge page consumption. The results are in the table
T n: THP never
T m: THP madvise
D h: DAMON action hugepage
D c: DAMON action collapse
+------------------+----------+----------+----------+
| | T n, D h | T m, D h | T n, D c |
+------------------+----------+----------+----------+
| Total memory use | 2.07 | 2.09 | 2.07 |
| Huge pages | 0 | 1.3 | 1.25 |
+------------------+----------+----------+----------+
>
>>
>> Changes
>> ---------
>> v1-v2:
>> Added benchmarks
>> Added damos_filter_type documentation for new action to fix kernel-doc
>
> Please add Changelog on the commentary section [1]. Also, please consider
> adding links to previous versions.
>
>>
>> Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
>> ---
>> Documentation/mm/damon/design.rst | 4 ++++
>> include/linux/damon.h | 2 ++
>> mm/damon/sysfs-schemes.c | 4 ++++
>> mm/damon/vaddr.c | 3 +++
>> tools/testing/selftests/damon/sysfs.py | 11 ++++++-----
>> 5 files changed, 19 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
>> index 838b14d22519..405142641e55 100644
>> --- a/Documentation/mm/damon/design.rst
>> +++ b/Documentation/mm/damon/design.rst
>> @@ -467,6 +467,10 @@ that supports each action are as below.
>> Supported by ``vaddr`` and ``fvaddr`` operations set. When
>> TRANSPARENT_HUGEPAGE is disabled, the application of the action will just
>> fail.
>> + - ``collapse``: Call ``madvise()`` for the region with ``MADV_COLLAPSE``.
>> + Supported by ``vaddr`` and ``fvaddr`` operations set. When
>> + TRANSPARENT_HUGEPAGE is disabled, the application of the action will just
>> + fail.
>> - ``lru_prio``: Prioritize the region on its LRU lists.
>> Supported by ``paddr`` operations set.
>> - ``lru_deprio``: Deprioritize the region on its LRU lists.
>> diff --git a/include/linux/damon.h b/include/linux/damon.h
>> index d9a3babbafc1..6941113968ec 100644
>> --- a/include/linux/damon.h
>> +++ b/include/linux/damon.h
>> @@ -121,6 +121,7 @@ struct damon_target {
>> * @DAMOS_PAGEOUT: Reclaim the region.
>> * @DAMOS_HUGEPAGE: Call ``madvise()`` for the region with MADV_HUGEPAGE.
>> * @DAMOS_NOHUGEPAGE: Call ``madvise()`` for the region with MADV_NOHUGEPAGE.
>> + * @DAMOS_COLLAPSE: Call ``madvise()`` for the region with MADV_COLLAPSE.
>> * @DAMOS_LRU_PRIO: Prioritize the region on its LRU lists.
>> * @DAMOS_LRU_DEPRIO: Deprioritize the region on its LRU lists.
>> * @DAMOS_MIGRATE_HOT: Migrate the regions prioritizing warmer regions.
>> @@ -140,6 +141,7 @@ enum damos_action {
>> DAMOS_PAGEOUT,
>> DAMOS_HUGEPAGE,
>> DAMOS_NOHUGEPAGE,
>> + DAMOS_COLLAPSE,
>> DAMOS_LRU_PRIO,
>> DAMOS_LRU_DEPRIO,
>> DAMOS_MIGRATE_HOT,
>> diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
>> index 5186966dafb3..aa08a8f885fb 100644
>> --- a/mm/damon/sysfs-schemes.c
>> +++ b/mm/damon/sysfs-schemes.c
>> @@ -2041,6 +2041,10 @@ static struct damos_sysfs_action_name damos_sysfs_action_names[] = {
>> .action = DAMOS_NOHUGEPAGE,
>> .name = "nohugepage",
>> },
>> + {
>> + .action = DAMOS_COLLAPSE,
>> + .name = "collapse",
>> + },
>> {
>> .action = DAMOS_LRU_PRIO,
>> .name = "lru_prio",
>> diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c
>> index b069dbc7e3d2..dd5f2d7027ac 100644
>> --- a/mm/damon/vaddr.c
>> +++ b/mm/damon/vaddr.c
>> @@ -903,6 +903,9 @@ static unsigned long damon_va_apply_scheme(struct damon_ctx *ctx,
>> case DAMOS_NOHUGEPAGE:
>> madv_action = MADV_NOHUGEPAGE;
>> break;
>> + case DAMOS_COLLAPSE:
>> + madv_action = MADV_COLLAPSE;
>> + break;
>> case DAMOS_MIGRATE_HOT:
>> case DAMOS_MIGRATE_COLD:
>> return damos_va_migrate(t, r, scheme, sz_filter_passed);
>> diff --git a/tools/testing/selftests/damon/sysfs.py b/tools/testing/selftests/damon/sysfs.py
>> index 3aa5c91548a5..c6476e63f4fb 100755
>> --- a/tools/testing/selftests/damon/sysfs.py
>> +++ b/tools/testing/selftests/damon/sysfs.py
>> @@ -123,11 +123,12 @@ def assert_scheme_committed(scheme, dump):
>> 'pageout': 2,
>> 'hugepage': 3,
>> 'nohugeapge': 4,
>> - 'lru_prio': 5,
>> - 'lru_deprio': 6,
>> - 'migrate_hot': 7,
>> - 'migrate_cold': 8,
>> - 'stat': 9,
>> + 'collapse': 5
>
> Comman is missed?
>
>> + 'lru_prio': 6,
>> + 'lru_deprio': 7,
>> + 'migrate_hot': 8,
>> + 'migrate_cold': 9,
>> + 'stat': 10,
>> }
>> assert_true(dump['action'] == action_val[scheme.action], 'action', dump)
>> assert_true(dump['apply_interval_us'] == scheme. apply_interval_us,
>> --
>> 2.43.0
>
> Other than the selftest part, code looks good. Please consider dropping RFC
> tag from the next spin. Clarifying more details about the test would be
> helpful, though.
>
> [1] https://docs.kernel.org/process/submitting-patches.html#commentary
>
>
> Thanks,
> SJ
>
SJ, should I remove the RFC tag for the next version?
--
Asier Gutierrez
Huawei
^ permalink raw reply
* Re: (sashiko review) [RFC PATCH v2 1/1] mm/damon: support MADV_COLLAPSE via DAMOS_COLLAPSE scheme action
From: Gutierrez Asier @ 2026-03-24 13:49 UTC (permalink / raw)
To: SeongJae Park
Cc: artem.kuzin, stepanov.anatoly, wangkefeng.wang, yanquanmin1,
zuoze1, damon, akpm, ljs, Liam.Howlett, vbabka, rppt, surenb,
mhocko, corbet, skhan, linux-doc, linux-mm, linux-kernel
In-Reply-To: <20260324004119.87026-1-sj@kernel.org>
Hi SJ,
On 3/24/2026 3:41 AM, SeongJae Park wrote:
> On Mon, 23 Mar 2026 17:29:36 -0700 SeongJae Park <sj@kernel.org> wrote:
>
>> Forwarding Sashiko review for doing discussions via mails.
>>
>> # review url: https://sashiko.dev/#/patchset/20260323145646.4165053-2-gutierrez.asier@huawei-partners.com
>> # start of sashiko.dev inline review
>> commit eaed291e6fae91842b1836c68bab867d53525db5
>> Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
>>
>> mm/damon: support MADV_COLLAPSE via DAMOS_COLLAPSE scheme action
>>
>> This commit introduces a new DAMON action, DAMOS_COLLAPSE. It allows
>> DAMON to synchronously collapse an address range by calling madvise
>> with MADV_COLLAPSE.
>>
>> Link: https://lore.kernel.org/damon/20260313000816.79933-1-sj@kernel.org/
>>
>> [ ... ]
>>> diff --git a/tools/testing/selftests/damon/sysfs.py b/tools/testing/selftests/damon/sysfs.py
>>> index 3aa5c91548a5..c6476e63f4fb 100755
>>> --- a/tools/testing/selftests/damon/sysfs.py
>>> +++ b/tools/testing/selftests/damon/sysfs.py
>>> @@ -123,11 +123,12 @@ def assert_scheme_committed(scheme, dump):
>>> 'pageout': 2,
>>> 'hugepage': 3,
>>> 'nohugeapge': 4,
>>> - 'lru_prio': 5,
>>> - 'lru_deprio': 6,
>>> - 'migrate_hot': 7,
>>> - 'migrate_cold': 8,
>>> - 'stat': 9,
>>> + 'collapse': 5
>>> + 'lru_prio': 6,
>>
>> Will this cause a Python syntax error when executing the selftest? It looks
>> like there is a missing comma after 'collapse': 5, which might break the
>> execution of the DAMON sysfs test suite.
>
> I think sashiko is correct. We need to add a comma.
I will fix it. Missed it, my bad
>
>
> Thanks,
> SJ
>
> [...]
>
--
Asier Gutierrez
Huawei
^ permalink raw reply
* Re: [PATCH net-next v2] docs/mlx5: Fix typo subfuction
From: Tariq Toukan @ 2026-03-24 13:43 UTC (permalink / raw)
To: Ryohei Kinugawa, rrameshbabu, saeedm, leon, tariqt, mbloch, davem,
edumazet, kuba, pabeni, horms, corbet, skhan
Cc: netdev, linux-rdma, linux-doc, joe
In-Reply-To: <20260324053416.70166-1-ryohei.kinugawa@gmail.com>
On 24/03/2026 7:34, Ryohei Kinugawa wrote:
> Fix two typos:
> - 'Subfunctons' -> 'Subfunctions'
> - 'subfuction' -> 'subfunction'
>
> Reviewed-by: Joe Damato <joe@dama.to>
> Signed-off-by: Ryohei Kinugawa <ryohei.kinugawa@gmail.com>
> ---
> .../device_drivers/ethernet/mellanox/mlx5/kconfig.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst
> index 34e911480108..b45d6871492c 100644
> --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst
> +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst
> @@ -114,13 +114,13 @@ Enabling the driver and kconfig options
> **CONFIG_MLX5_SF=(y/n)**
>
> | Build support for subfunction.
> -| Subfunctons are more light weight than PCI SRIOV VFs. Choosing this option
> +| Subfunctions are more light weight than PCI SRIOV VFs. Choosing this option
> | will enable support for creating subfunction devices.
>
>
> **CONFIG_MLX5_SF_MANAGER=(y/n)**
>
> -| Build support for subfuction port in the NIC. A Mellanox subfunction
> +| Build support for subfunction port in the NIC. A Mellanox subfunction
> | port is managed through devlink. A subfunction supports RDMA, netdevice
> | and vdpa device. It is similar to a SRIOV VF but it doesn't require
> | SRIOV support.
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Thanks.
^ permalink raw reply
* Re: [PATCH] docs: Document pahole v1.26 requirement for KF_IMPLICIT_ARGS kfuncs
From: Jonathan Corbet @ 2026-03-24 13:43 UTC (permalink / raw)
To: zhidao su, workflows; +Cc: linux-kernel, linux-doc, bpf, Shuah Khan, zhidao su
In-Reply-To: <20260324062028.2479059-1-suzhidao@xiaomi.com>
zhidao su <soolaugust@gmail.com> writes:
> Since Linux 7.0, kfuncs annotated with KF_IMPLICIT_ARGS require pahole
> v1.26 or later. Without it, such kfuncs have incorrect BTF prototypes in
> vmlinux, causing BPF programs to fail with 'func_proto incompatible with
> vmlinux' error.
>
> This affects all sched_ext kfuncs (e.g. scx_bpf_create_dsq,
> scx_bpf_dispatch) and other KF_IMPLICIT_ARGS kfuncs across the kernel.
> Ubuntu 24.04 LTS ships pahole v1.25 by default, causing 23/30 sched_ext
> selftests to fail on affected systems.
>
> Document this requirement in Documentation/process/changes.rst so users
> understand the failure mode and can upgrade pahole appropriately.
>
> Signed-off-by: zhidao su <suzhidao@xiaomi.com>
> ---
> Documentation/process/changes.rst | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
> index 6b373e193548..141a4576c24d 100644
> --- a/Documentation/process/changes.rst
> +++ b/Documentation/process/changes.rst
> @@ -145,6 +145,11 @@ Since Linux 5.2, if CONFIG_DEBUG_INFO_BTF is selected, the build system
> generates BTF (BPF Type Format) from DWARF in vmlinux, a bit later from kernel
> modules as well. This requires pahole v1.22 or later.
>
> +Since Linux 7.0, kfuncs annotated with KF_IMPLICIT_ARGS require pahole v1.26
> +or later. Without it, such kfuncs will have incorrect BTF prototypes in
> +vmlinux, causing BPF programs to fail to load with a "func_proto incompatible
> +with vmlinux" error. Many sched_ext kfuncs are affected.
This seems like reasonable information, but is there a reason to not
just raise the minimum pahole version to 1.26 and be done with it?
Thanks,
jon
^ permalink raw reply
* RE: [PATCH v2 7/9] accel/neutron: Add job submission IOCTL
From: Ioana Ciocoi Radulescu @ 2026-03-24 13:38 UTC (permalink / raw)
To: Frank Li, Oded Gabbay, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sumit Semwal,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Christian König
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org,
Jiwei Fu, Forrest Shi, Alexandru Iulian Taran, Daniel Baluta
In-Reply-To: <20260306170259.296712-1-Frank.Li@nxp.com>
On Friday, March 6, 2026 at 7:03 PM, Frank Li wrote:
> > + if (appstatus & APPSTATUS_FAULTCAUSE_MASK) {
> > + dev_err(ndev->dev, "Neutron halted due to fault: 0x%lx\n",
> > + FIELD_GET(APPSTATUS_FAULTCAUSE_MASK,
> appstatus));
> > + return neutron_job_err_handler(ndev);
>
> AI: neutron_job_err_handler() returns void, not int. Remove 'return'.
Ok, will fix.
>
> > + ret = drm_sched_job_init(&job->base, &npriv->sched_entity, 1, NULL,
> > + filp->client_id);
> > + if (ret)
> > + goto out_put_syncobj;
> > +
> > + ret = neutron_push_job(job, syncobj);
> > + if (ret)
> > + goto out_sched_cleanup;
> > +
> > + neutron_put_job(job);
> > + drm_syncobj_put(syncobj);
> > +
> > + return 0;
> > +
> > +out_sched_cleanup:
> > + drm_sched_job_cleanup(&job->base);
> > +out_put_syncobj:
> > + drm_syncobj_put(syncobj);
> > +out_put_gem:
> > + drm_gem_object_put(job->bo);
>
> AI: In the success path, neutron_put_job(job) is called which decrements
> refcnt. But if neutron_push_job() fails and we hit out_sched_cleanup, the job
> refcnt is never decremented. This leaks the job structure.
> Consider: if neutron_push_job() succeeds, it calls kref_get() inside sched_lock.
> If it fails, no kref_get() happens, so don't call
>
> (Need owner do judgment. Not sure if AI said correctly.)
I don't see an issue here, kref_get() is called at a point where
neutron_push_job() can't fail anymore. And if neutron_push_job() fails
earlier, error path looks clean, it frees everything in reverse order,
including the job struct.
Btw, what agent did you use for review?
Thanks,
Ioana
>
> Frank
^ permalink raw reply
* RE: [PATCH v2 4/9] accel/neutron: Add driver for NXP Neutron NPU
From: Ioana Ciocoi Radulescu @ 2026-03-24 13:36 UTC (permalink / raw)
To: Krzysztof Kozlowski, Oded Gabbay, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Sumit Semwal, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Frank Li, Christian König
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org,
Jiwei Fu, Forrest Shi, Alexandru Iulian Taran, Daniel Baluta
In-Reply-To: <110dace9-3ff9-4750-813f-93c6827b105c@kernel.org>
On Friday, March 6, 2026 at 4:22 PM, Krzysztof Kozlowski wrote:
> On 06/03/2026 14:27, Ioana Ciocoi-Radulescu wrote:
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS index
> > 8a5b27b061da..f7a687eb6b54 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -19191,6 +19191,16 @@ S: Orphan
> > F: Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml
> > F: drivers/nfc/nxp-nci
> >
> > +NXP Neutron NPU DRIVER
>
> s/Neutron/NEUTRON/ as everything here is in uppercase
Ok.
>
> > +M: Ioana Ciocoi Radulescu <ruxandra.radulescu@nxp.com>
> > +M: Jiwei Fu <jiwei.fu@nxp.com>
> > +L: dri-devel@lists.freedesktop.org
> > +S: Maintained
> > +T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
> > +F: Documentation/accel/neutron/
> > +F: drivers/accel/neutron/
> > +F: include/uapi/drm/neutron_accel.h
>
>
> >
> > diff --git a/drivers/accel/Makefile b/drivers/accel/Makefile index
> > 1d3a7251b950..698136e12cce 100644
> > --- a/drivers/accel/Makefile
> > +++ b/drivers/accel/Makefile
> > @@ -4,5 +4,6 @@ obj-$(CONFIG_DRM_ACCEL_AMDXDNA) +=
> amdxdna/
> > obj-$(CONFIG_DRM_ACCEL_ARM_ETHOSU) += ethosu/
> > obj-$(CONFIG_DRM_ACCEL_HABANALABS) += habanalabs/
> > obj-$(CONFIG_DRM_ACCEL_IVPU) += ivpu/
> > +obj-$(CONFIG_DRM_ACCEL_NXP_NEUTRON) += neutron/
> > obj-$(CONFIG_DRM_ACCEL_QAIC) += qaic/
> > -obj-$(CONFIG_DRM_ACCEL_ROCKET) += rocket/
> > \ No newline at end of file
>
> You still have patch warnings.
Yeah, so the last line of this Makefile lacked the line ending and vim
fixed that on its own when I edited the file. I can add the neutron line
and leave the rest untouched, just making sure this is what you're
requesting?
>
> > +obj-$(CONFIG_DRM_ACCEL_ROCKET) += rocket/
> > diff --git a/drivers/accel/neutron/Kconfig
> > b/drivers/accel/neutron/Kconfig new file mode 100644 index
> > 000000000000..37b8ecb49804
> > --- /dev/null
> > +++ b/drivers/accel/neutron/Kconfig
> > @@ -0,0 +1,16 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +
> > +config DRM_ACCEL_NXP_NEUTRON
> > + tristate "NXP Neutron NPU"
> > + depends on HAS_IOMEM
> > + depends on DRM_ACCEL
> > + depends on ARCH_MXC
>
> Missing compile test
Will add.
>
> > + select DRM_GEM_DMA_HELPER
> > + select DRM_SCHED
> > + help
> > + Enables driver for NXP Neutron NPU.
> > +
> > + Select this if you have an NXP SoC with Neutron, like i.MX95,
> > + and want to run machine learning applications.
> > +
> > + If built as module, the module is named neutron.
>
> ...
>
> > +
> > + ret = devm_request_threaded_irq(dev, ndev->irq, NULL,
> > + neutron_irq_handler_thread,
> > + IRQF_ONESHOT, KBUILD_MODNAME,
> ndev);
> > + if (ret) {
> > + dev_err(dev, "Failed to request irq %d\n", ndev->irq);
>
> Drop, not needed.
Ok
>
> > + return ret;
> > + }
> > +
> > + ret = of_reserved_mem_device_init(&pdev->dev);
> > + if (ret) {
> > + dev_err(dev, "Failed to initialize reserved memory\n");
> > + return ret;
> > + }
> > +
> > + ret = devm_pm_runtime_enable(dev);
> > + if (ret)
> > + goto free_reserved;
> > +
> > + pm_runtime_set_autosuspend_delay(dev,
> NEUTRON_SUSPEND_DELAY_MS);
> > + pm_runtime_use_autosuspend(dev);
> > +
> > + ret = drm_dev_register(&ndev->base, 0);
> > + if (ret)
> > + goto free_reserved;
> > +
> > + return 0;
> > +
> > +free_reserved:
> > + of_reserved_mem_device_release(&pdev->dev);
> > +
> > + return ret;
> > +}
> > +
> > +static void neutron_remove(struct platform_device *pdev) {
> > + struct neutron_device *ndev = platform_get_drvdata(pdev);
> > +
> > + drm_dev_unregister(&ndev->base);
> > + of_reserved_mem_device_release(&pdev->dev);
> > +}
> > +
> > +static int neutron_runtime_suspend(struct device *dev) {
> > + struct neutron_device *ndev = dev_get_drvdata(dev);
> > +
> > + neutron_disable_irq(ndev);
> > + neutron_shutdown(ndev);
> > +
> > + clk_bulk_disable_unprepare(ndev->num_clks, ndev->clks);
> > +
> > + return 0;
> > +}
> > +
> > +static int neutron_runtime_resume(struct device *dev) {
> > + struct neutron_device *ndev = dev_get_drvdata(dev);
> > + int ret;
> > +
> > + ret = clk_bulk_prepare_enable(ndev->num_clks, ndev->clks);
> > + if (ret)
> > + return ret;
> > +
> > + ret = neutron_boot(ndev);
> > + if (ret) {
> > + clk_bulk_disable_unprepare(ndev->num_clks, ndev->clks);
> > + return ret;
> > + }
> > +
> > + neutron_enable_irq(ndev);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct dev_pm_ops neutron_pm_ops = {
> > + SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> pm_runtime_force_resume)
> > + RUNTIME_PM_OPS(neutron_runtime_suspend,
> neutron_runtime_resume,
> > +NULL) };
> > +
> > +static const struct of_device_id neutron_match_table[] = {
> > + { .compatible = "nxp,imx95-neutron" },
> > + {}
> > +};
> > +
> > +MODULE_DEVICE_TABLE(of, neutron_match_table);
> > +
> > +static struct platform_driver neutron_driver = {
> > + .probe = &neutron_probe,
> > + .remove = &neutron_remove,
> > + .driver = {
> > + .name = "neutron",
> > + .of_match_table =
> of_match_ptr(neutron_match_table),
>
> Drop of_match_ptr. You will have (or you have already same as v1) here
> warning.
Will fix. But how do I get to see the warning here? Tried building with
W=1 and OF support disabled but it didn't complain.
Thanks!
Ioana
>
> > + .pm = pm_ptr(&neutron_pm_ops),
> > + },
> > +};
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v5 00/21] Virtual Swap Space
From: Askar Safin @ 2026-03-24 13:19 UTC (permalink / raw)
To: nphamcs
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, kasong,
kernel-team, 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, riel,
roman.gushchin, rppt, ryan.roberts, shakeel.butt, shikemeng,
surenb, tglx, vbabka, weixugc, ying.huang, yosry.ahmed, yuanchu,
zhengqi.arch, ziy, Kairui Song, Matthew Wilcox
In-Reply-To: <20260320192735.748051-1-nphamcs@gmail.com>
Nhat Pham <nphamcs@gmail.com>:
> We can even perform compressed writeback
> (i.e writing these pages without decompressing them) (see [12]).
> [12]: https://lore.kernel.org/linux-mm/ZeZSDLWwDed0CgT3@casper.infradead.org/
This is supported in zram. The support was added here:
https://lore.kernel.org/all/20251201094754.4149975-1-senozhatsky@chromium.org/ .
It is already in mainline.
--
Askar Safin
^ permalink raw reply
* Re: [PATCH net-next V8 01/14] devlink: Update nested instance locking comment
From: Jiri Pirko @ 2026-03-24 13:05 UTC (permalink / raw)
To: Tariq Toukan
Cc: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller, Donald Hunter, Simon Horman, Jonathan Corbet,
Shuah Khan, Saeed Mahameed, Leon Romanovsky, Mark Bloch,
Chuck Lever, Matthieu Baerts (NGI0), Cosmin Ratiu,
Carolina Jubran, Daniel Zahka, Shay Drory, Kees Cook,
Daniel Jurgens, Moshe Shemesh, Adithya Jayachandran,
Willem de Bruijn, David Wei, Petr Machata, Stanislav Fomichev,
Vadim Fedorenko, netdev, linux-kernel, linux-doc, linux-rdma,
linux-kselftest, Gal Pressman, Jiri Pirko
In-Reply-To: <20260324122848.36731-2-tariqt@nvidia.com>
Tue, Mar 24, 2026 at 01:28:35PM +0100, tariqt@nvidia.com wrote:
>From: Cosmin Ratiu <cratiu@nvidia.com>
>
>In commit [1] a comment about nested instance locking was updated. But
>there's another place where this is mentioned, so update that as well.
>
>[1] commit 0061b5199d7c ("devlink: Reverse locking order for nested
>instances")
>
>Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
>Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
>Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
^ permalink raw reply
* Re: [PATCH net-next V8 03/14] devlink: Migrate from info->user_ptr to info->ctx
From: Jiri Pirko @ 2026-03-24 13:05 UTC (permalink / raw)
To: Tariq Toukan
Cc: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller, Donald Hunter, Simon Horman, Jonathan Corbet,
Shuah Khan, Saeed Mahameed, Leon Romanovsky, Mark Bloch,
Chuck Lever, Matthieu Baerts (NGI0), Cosmin Ratiu,
Carolina Jubran, Daniel Zahka, Shay Drory, Kees Cook,
Daniel Jurgens, Moshe Shemesh, Adithya Jayachandran,
Willem de Bruijn, David Wei, Petr Machata, Stanislav Fomichev,
Vadim Fedorenko, netdev, linux-kernel, linux-doc, linux-rdma,
linux-kselftest, Gal Pressman, Jiri Pirko
In-Reply-To: <20260324122848.36731-4-tariqt@nvidia.com>
Tue, Mar 24, 2026 at 01:28:37PM +0100, tariqt@nvidia.com wrote:
>From: Cosmin Ratiu <cratiu@nvidia.com>
>
>Replace deprecated info->user_ptr[0]/[1] with a typed
>devlink_nl_ctx struct stored in info->ctx. The struct aliases
>the same union memory, so the migration is safe.
>
>There are no functionality changes here.
>
>Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
>Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
^ permalink raw reply
* Re: [PATCH v3 07/24] vfio/pci: Preserve vfio-pci device files across Live Update
From: Yi Liu @ 2026-03-24 13:08 UTC (permalink / raw)
To: David Matlack, Alex Williamson, Bjorn Helgaas
Cc: Adithya Jayachandran, Alexander Graf, Alex Mastro, Andrew Morton,
Ankit Agrawal, Arnd Bergmann, Askar Safin, Borislav Petkov (AMD),
Chris Li, Dapeng Mi, David Rientjes, Feng Tang, Jacob Pan,
Jason Gunthorpe, Jason Gunthorpe, Jonathan Corbet, Josh Hilke,
Kees Cook, Kevin Tian, kexec, kvm, Leon Romanovsky,
Leon Romanovsky, linux-doc, linux-kernel, linux-kselftest,
linux-mm, linux-pci, Li RongQing, Lukas Wunner, Marco Elver,
Michał Winiarski, Mike Rapoport, Parav Pandit,
Pasha Tatashin, Paul E. McKenney, Pawan Gupta,
Peter Zijlstra (Intel), Pranjal Shrivastava, Pratyush Yadav,
Raghavendra Rao Ananta, Randy Dunlap, Rodrigo Vivi,
Saeed Mahameed, Samiullah Khawaja, Shuah Khan, Vipin Sharma,
Vivek Kasireddy, William Tu, Zhu Yanjun
In-Reply-To: <20260323235817.1960573-8-dmatlack@google.com>
On 3/24/26 07:57, David Matlack wrote:
> From: Vipin Sharma <vipinsh@google.com>
>
> Implement the live update file handler callbacks to preserve a vfio-pci
> device across a Live Update. Subsequent commits will enable userspace to
> then retrieve this file after the Live Update.
>
> Live Update support is scoped only to cdev files (i.e. not
> VFIO_GROUP_GET_DEVICE_FD files).
>
> State about each device is serialized into a new ABI struct
> vfio_pci_core_device_ser. The contents of this struct are preserved
> across the Live Update to the next kernel using a combination of
> Kexec-Handover (KHO) to preserve the page(s) holding the struct and the
> Live Update Orchestrator (LUO) to preserve the physical address of the
> struct.
>
> For now the only contents of struct vfio_pci_core_device_ser the
> device's PCI segment number and BDF, so that the device can be uniquely
> identified after the Live Update.
>
> Require that userspace disables interrupts on the device prior to
> freeze() so that the device does not send any interrupts until new
> interrupt handlers have been set up by the next kernel.
>
> Reset the device and restore its state in the freeze() callback. This
> ensures the device can be received by the next kernel in a consistent
> state. Eventually this will be dropped and the device can be preserved
> across in a running state, but that requires further work in VFIO and
> the core PCI layer.
>
> Note that LUO holds a reference to this file when it is preserved. So
> VFIO is guaranteed that vfio_df_device_last_close() will not be called
> on this device no matter what userspace does.
>
> Signed-off-by: Vipin Sharma <vipinsh@google.com>
> Co-developed-by: David Matlack <dmatlack@google.com>
> Signed-off-by: David Matlack <dmatlack@google.com>
> ---
> drivers/vfio/pci/vfio_pci.c | 2 +-
> drivers/vfio/pci/vfio_pci_core.c | 57 +++++----
> drivers/vfio/pci/vfio_pci_liveupdate.c | 156 ++++++++++++++++++++++++-
> drivers/vfio/pci/vfio_pci_priv.h | 4 +
> drivers/vfio/vfio_main.c | 3 +-
> include/linux/kho/abi/vfio_pci.h | 15 +++
> include/linux/vfio.h | 2 +
> 7 files changed, 213 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index 41dcbe4ace67..351480d13f6e 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -125,7 +125,7 @@ static int vfio_pci_open_device(struct vfio_device *core_vdev)
> return 0;
> }
>
> -static const struct vfio_device_ops vfio_pci_ops = {
> +const struct vfio_device_ops vfio_pci_ops = {
> .name = "vfio-pci",
> .init = vfio_pci_core_init_dev,
> .release = vfio_pci_core_release_dev,
> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
> index d43745fe4c84..81f941323641 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -585,9 +585,42 @@ int vfio_pci_core_enable(struct vfio_pci_core_device *vdev)
> }
> EXPORT_SYMBOL_GPL(vfio_pci_core_enable);
>
> +void vfio_pci_core_try_reset(struct vfio_pci_core_device *vdev)
> +{
> + struct pci_dev *pdev = vdev->pdev;
> + struct pci_dev *bridge = pci_upstream_bridge(pdev);
> +
> + lockdep_assert_held(&vdev->vdev.dev_set->lock);
> +
> + if (!vdev->reset_works)
> + return;
> +
> + /*
> + * Try to get the locks ourselves to prevent a deadlock. The
> + * success of this is dependent on being able to lock the device,
> + * which is not always possible.
> + *
> + * We cannot use the "try" reset interface here, since that will
> + * overwrite the previously restored configuration information.
> + */
> + if (bridge && !pci_dev_trylock(bridge))
> + return;
> +
> + if (!pci_dev_trylock(pdev))
> + goto out;
> +
> + if (!__pci_reset_function_locked(pdev))
> + vdev->needs_reset = false;
> +
> + pci_dev_unlock(pdev);
> +out:
> + if (bridge)
> + pci_dev_unlock(bridge);
> +}
> +EXPORT_SYMBOL_GPL(vfio_pci_core_try_reset);
> +
> void vfio_pci_core_disable(struct vfio_pci_core_device *vdev)
> {
> - struct pci_dev *bridge;
> struct pci_dev *pdev = vdev->pdev;
> struct vfio_pci_dummy_resource *dummy_res, *tmp;
> struct vfio_pci_ioeventfd *ioeventfd, *ioeventfd_tmp;
> @@ -687,27 +720,7 @@ void vfio_pci_core_disable(struct vfio_pci_core_device *vdev)
> */
> pci_write_config_word(pdev, PCI_COMMAND, PCI_COMMAND_INTX_DISABLE);
>
> - /*
> - * Try to get the locks ourselves to prevent a deadlock. The
> - * success of this is dependent on being able to lock the device,
> - * which is not always possible.
> - * We can not use the "try" reset interface here, which will
> - * overwrite the previously restored configuration information.
> - */
> - if (vdev->reset_works) {
> - bridge = pci_upstream_bridge(pdev);
> - if (bridge && !pci_dev_trylock(bridge))
> - goto out_restore_state;
> - if (pci_dev_trylock(pdev)) {
> - if (!__pci_reset_function_locked(pdev))
> - vdev->needs_reset = false;
> - pci_dev_unlock(pdev);
> - }
> - if (bridge)
> - pci_dev_unlock(bridge);
> - }
> -
> -out_restore_state:
> + vfio_pci_core_try_reset(vdev);
> pci_restore_state(pdev);
> out:
> pci_disable_device(pdev);
> diff --git a/drivers/vfio/pci/vfio_pci_liveupdate.c b/drivers/vfio/pci/vfio_pci_liveupdate.c
> index 5ea5af46b159..c4ebc7c486e5 100644
> --- a/drivers/vfio/pci/vfio_pci_liveupdate.c
> +++ b/drivers/vfio/pci/vfio_pci_liveupdate.c
> @@ -6,27 +6,178 @@
> * David Matlack <dmatlack@google.com>
> */
>
> +/**
> + * DOC: VFIO PCI Preservation via LUO
> + *
> + * VFIO PCI devices can be preserved over a kexec using the Live Update
> + * Orchestrator (LUO) file preservation. This allows userspace (such as a VMM)
> + * to transfer an in-use device to the next kernel.
> + *
> + * .. note::
> + * The support for preserving VFIO PCI devices is currently *partial* and
> + * should be considered *experimental*. It should only be used by developers
> + * working on expanding the support for the time being.
> + *
> + * To avoid accidental usage while the support is still experimental, this
> + * support is hidden behind a default-disable config option
> + * ``CONFIG_VFIO_PCI_LIVEUPDATE``. Once the kernel support has stabilized and
> + * become complete, this option will be enabled by default when
> + * ``CONFIG_VFIO_PCI`` and ``CONFIG_LIVEUPDATE`` are enabled.
> + *
> + * Usage Example
> + * =============
> + *
> + * VFIO PCI devices can be preserved across a kexec by preserving the file
> + * associated with the device in a LUO session::
> + *
> + * device_fd = open("/dev/vfio/devices/X");
/dev/vfio/devices/vfioX
> + * ...
> + * ioctl(session_fd, LIVEUPDATE_SESSION_PRESERVE_FD, { ..., device_fd, ...});
> + *
> + * .. note::
> + * LUO will hold an extra reference to the device file for as long as it is
> + * preserved, so there is no way for the file to be destroyed or the device
> + * to be unbound from the vfio-pci driver while it is preserved.
> + *
> + * Retrieving the file after kexec is not yet supported.
> + *
> + * Restrictions
> + * ============
> + *
> + * The kernel imposes the following restrictions when preserving VFIO devices:
> + *
> + * * The device must be bound to the ``vfio-pci`` driver.
> + *
> + * * ``CONFIG_VFIO_PCI_ZDEV_KVM`` must not be enabled. This may be relaxed in
> + * the future.
> + *
> + * * The device not be an Intel display device. This may be relaxed in the
> + * future.
> + *
> + * * The device file must have been acquired from the VFIO character device,
> + * not ``VFIO_GROUP_GET_DEVICE_FD``.
how about "The device file descriptor must be obtained by opening the
VFIO device
character device (``/dev/vfio/devices/vfioX``), not via
``VFIO_GROUP_GET_DEVICE_FD``."?
just be aligned with the below words in vfio.rst.
"Traditionally user acquires a device fd via VFIO_GROUP_GET_DEVICE_FD
user can now acquire a device fd by directly opening a character device
/dev/vfio/devices/vfioX"
> + *
> + * * The device must have interrupt disable prior to kexec. Failure to disable
> + * interrupts on the device will cause the ``reboot(LINUX_REBOOT_CMD_KEXEC)``
> + * syscall (to initiate the kexec) to fail.
> + *
> + * Preservation Behavior
> + * =====================
> + *
> + * The eventual goal of this support is to avoid disrupting the workload, state,
> + * or configuration of each preserved device during a Live Update. This would
> + * include allowing the device to perform DMA to preserved memory buffers and
> + * perform P2P DMA to other preserved devices. However, there are many pieces
> + * that still need to land in the kernel.
> + *
> + * For now, VFIO only preserves the following state for for devices:
> + *
> + * * The PCI Segment, Bus, Device, and Function numbers of the device. The
> + * kernel guarantees the these will not change across a kexec when a device
> + * is preserved.
> + *
> + * Since the kernel is not yet prepared to preserve all parts of the device and
> + * its dependencies (such as DMA mappings), VFIO currently resets and restores
> + * preserved devices back into an idle state during kexec, before handing off
> + * control to the next kernel. This will be relaxed in future versions of the
> + * kernel once it is safe to allow the device to keep running across kexec.
> + */
> +
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> +#include <linux/kexec_handover.h>
> #include <linux/kho/abi/vfio_pci.h>
> #include <linux/liveupdate.h>
> #include <linux/errno.h>
> +#include <linux/vfio.h>
maybe follow alphabet order. errno.h would be moved to the top first.
Regards,Yi Liu
^ permalink raw reply
* Re: [PATCH v3 08/24] vfio/pci: Retrieve preserved device files after Live Update
From: Yi Liu @ 2026-03-24 13:08 UTC (permalink / raw)
To: David Matlack, Alex Williamson, Bjorn Helgaas
Cc: Adithya Jayachandran, Alexander Graf, Alex Mastro, Andrew Morton,
Ankit Agrawal, Arnd Bergmann, Askar Safin, Borislav Petkov (AMD),
Chris Li, Dapeng Mi, David Rientjes, Feng Tang, Jacob Pan,
Jason Gunthorpe, Jason Gunthorpe, Jonathan Corbet, Josh Hilke,
Kees Cook, Kevin Tian, kexec, kvm, Leon Romanovsky,
Leon Romanovsky, linux-doc, linux-kernel, linux-kselftest,
linux-mm, linux-pci, Li RongQing, Lukas Wunner, Marco Elver,
Michał Winiarski, Mike Rapoport, Parav Pandit,
Pasha Tatashin, Paul E. McKenney, Pawan Gupta,
Peter Zijlstra (Intel), Pranjal Shrivastava, Pratyush Yadav,
Raghavendra Rao Ananta, Randy Dunlap, Rodrigo Vivi,
Saeed Mahameed, Samiullah Khawaja, Shuah Khan, Vipin Sharma,
Vivek Kasireddy, William Tu, Zhu Yanjun
In-Reply-To: <20260323235817.1960573-9-dmatlack@google.com>
On 3/24/26 07:58, David Matlack wrote:
> From: Vipin Sharma <vipinsh@google.com>
>
> Enable userspace to retrieve preserved VFIO device files from VFIO after
> a Live Update by implementing the retrieve() and finish() file handler
> callbacks.
>
> Use an anonymous inode when creating the file, since the retrieved
> device file is not opened through any particular cdev inode, and the
> cdev inode does not matter in practice.
do we have a list of struct file fields that do not matter?
>
> For now the retrieved file is functionally equivalent a opening the
> corresponding VFIO cdev file. Subsequent commits will leverage the
> preserved state associated with the retrieved file to preserve bits of
> the device across Live Update.
>
> Signed-off-by: Vipin Sharma <vipinsh@google.com>
> Co-developed-by: David Matlack <dmatlack@google.com>
> Signed-off-by: David Matlack <dmatlack@google.com>
> ---
> drivers/vfio/device_cdev.c | 59 ++++++++++++++++++++++----
> drivers/vfio/pci/vfio_pci_liveupdate.c | 52 ++++++++++++++++++++++-
> drivers/vfio/vfio_main.c | 13 ++++++
> include/linux/vfio.h | 11 +++++
> 4 files changed, 124 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/vfio/device_cdev.c b/drivers/vfio/device_cdev.c
> index 8ceca24ac136..edf322315a41 100644
> --- a/drivers/vfio/device_cdev.c
> +++ b/drivers/vfio/device_cdev.c
> @@ -2,6 +2,7 @@
> /*
> * Copyright (c) 2023 Intel Corporation.
> */
> +#include <linux/anon_inodes.h>
> #include <linux/vfio.h>
> #include <linux/iommufd.h>
>
> @@ -16,15 +17,10 @@ void vfio_init_device_cdev(struct vfio_device *device)
> device->cdev.owner = THIS_MODULE;
> }
>
> -/*
> - * device access via the fd opened by this function is blocked until
> - * .open_device() is called successfully during BIND_IOMMUFD.
> - */
> -int vfio_device_fops_cdev_open(struct inode *inode, struct file *filep)
> +static int vfio_device_cdev_open(struct vfio_device *device, struct file **filep)
> {
> - struct vfio_device *device = container_of(inode->i_cdev,
> - struct vfio_device, cdev);
> struct vfio_device_file *df;
> + struct file *file = *filep;
> int ret;
>
> /* Paired with the put in vfio_device_fops_release() */
> @@ -37,22 +33,67 @@ int vfio_device_fops_cdev_open(struct inode *inode, struct file *filep)
> goto err_put_registration;
> }
>
> - filep->private_data = df;
> + /*
> + * Simulate opening the character device using an anonymous inode. The
> + * returned file has the same properties as a cdev file (e.g. operations
> + * are blocked until BIND_IOMMUFD is called).
> + */
> + if (!file) {
> + file = anon_inode_getfile_fmode("[vfio-device-liveupdate]",
> + &vfio_device_fops, NULL,
> + O_RDWR, FMODE_PREAD | FMODE_PWRITE);
> +
> + if (IS_ERR(file)) {
> + ret = PTR_ERR(file);
> + goto err_free_device_file;
> + }
> +
> + *filep = file;
> + }
> +
> + file->private_data = df;
>
> /*
> * Use the pseudo fs inode on the device to link all mmaps
> * to the same address space, allowing us to unmap all vmas
> * associated to this device using unmap_mapping_range().
> */
> - filep->f_mapping = device->inode->i_mapping;
> + file->f_mapping = device->inode->i_mapping;
>
> return 0;
>
> +err_free_device_file:
> + kvfree(df);
any reason to use kvfree()?
Regards,
Yi Liu
^ permalink raw reply
* Re: [PATCH v3 06/24] vfio/pci: Register a file handler with Live Update Orchestrator
From: Yi Liu @ 2026-03-24 13:07 UTC (permalink / raw)
To: David Matlack, Alex Williamson, Bjorn Helgaas
Cc: Adithya Jayachandran, Alexander Graf, Alex Mastro, Andrew Morton,
Ankit Agrawal, Arnd Bergmann, Askar Safin, Borislav Petkov (AMD),
Chris Li, Dapeng Mi, David Rientjes, Feng Tang, Jacob Pan,
Jason Gunthorpe, Jason Gunthorpe, Jonathan Corbet, Josh Hilke,
Kees Cook, Kevin Tian, kexec, kvm, Leon Romanovsky,
Leon Romanovsky, linux-doc, linux-kernel, linux-kselftest,
linux-mm, linux-pci, Li RongQing, Lukas Wunner, Marco Elver,
Michał Winiarski, Mike Rapoport, Parav Pandit,
Pasha Tatashin, Paul E. McKenney, Pawan Gupta,
Peter Zijlstra (Intel), Pranjal Shrivastava, Pratyush Yadav,
Raghavendra Rao Ananta, Randy Dunlap, Rodrigo Vivi,
Saeed Mahameed, Samiullah Khawaja, Shuah Khan, Vipin Sharma,
Vivek Kasireddy, William Tu, Zhu Yanjun
In-Reply-To: <20260323235817.1960573-7-dmatlack@google.com>
On 3/24/26 07:57, David Matlack wrote:
> From: Vipin Sharma <vipinsh@google.com>
>
> Register a live update file handler for vfio-pci device files. Add stub
> implementations of all required callbacks so that registration does not
> fail (i.e. to avoid breaking git-bisect).
>
> This file handler will be extended in subsequent commits to enable a
> device bound to vfio-pci to run without interruption while the host is
> going through a kexec Live Update.
>
> Put this support behind a new Kconfig VFIO_PCI_LIVEUPDATE that is marked
> experimental and default-disabled until more of the device preservation
> support has landed in the kernel.
>
> Signed-off-by: Vipin Sharma <vipinsh@google.com>
> Co-developed-by: David Matlack <dmatlack@google.com>
> Signed-off-by: David Matlack <dmatlack@google.com>
> ---
> MAINTAINERS | 1 +
> drivers/vfio/pci/Kconfig | 11 ++++
> drivers/vfio/pci/Makefile | 1 +
> drivers/vfio/pci/vfio_pci.c | 12 ++++-
> drivers/vfio/pci/vfio_pci_liveupdate.c | 69 ++++++++++++++++++++++++++
> drivers/vfio/pci/vfio_pci_priv.h | 14 ++++++
> include/linux/kho/abi/vfio_pci.h | 28 +++++++++++
> 7 files changed, 135 insertions(+), 1 deletion(-)
> create mode 100644 drivers/vfio/pci/vfio_pci_liveupdate.c
> create mode 100644 include/linux/kho/abi/vfio_pci.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 96ea84948d76..a16a7ecc67a4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -27685,6 +27685,7 @@ F: Documentation/ABI/testing/debugfs-vfio
> F: Documentation/ABI/testing/sysfs-devices-vfio-dev
> F: Documentation/driver-api/vfio.rst
> F: drivers/vfio/
> +F: include/linux/kho/abi/vfio_pci.h
> F: include/linux/vfio.h
> F: include/linux/vfio_pci_core.h
> F: include/uapi/linux/vfio.h
> diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig
> index 1e82b44bda1a..8f087f7b58c3 100644
> --- a/drivers/vfio/pci/Kconfig
> +++ b/drivers/vfio/pci/Kconfig
> @@ -58,6 +58,17 @@ config VFIO_PCI_ZDEV_KVM
> config VFIO_PCI_DMABUF
> def_bool y if VFIO_PCI_CORE && PCI_P2PDMA && DMA_SHARED_BUFFER
>
> +config VFIO_PCI_LIVEUPDATE
> + bool "VFIO PCI support for Live Update (EXPERIMENTAL)"
> + depends on VFIO_PCI && PCI_LIVEUPDATE
> + help
> + Support for preserving devices bound to vfio-pci across a Live
> + Update. This option should only be enabled by developers working on
> + implementing this support. Once enough support has landed in the
> + kernel, this option will no longer be marked EXPERIMENTAL.
> +
> + If you don't know what to do here, say N.
> +
> source "drivers/vfio/pci/mlx5/Kconfig"
>
> source "drivers/vfio/pci/hisilicon/Kconfig"
> diff --git a/drivers/vfio/pci/Makefile b/drivers/vfio/pci/Makefile
> index e0a0757dd1d2..f462df61edb9 100644
> --- a/drivers/vfio/pci/Makefile
> +++ b/drivers/vfio/pci/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_VFIO_PCI_CORE) += vfio-pci-core.o
>
> vfio-pci-y := vfio_pci.o
> vfio-pci-$(CONFIG_VFIO_PCI_IGD) += vfio_pci_igd.o
> +vfio-pci-$(CONFIG_VFIO_PCI_LIVEUPDATE) += vfio_pci_liveupdate.o
> obj-$(CONFIG_VFIO_PCI) += vfio-pci.o
>
> obj-$(CONFIG_MLX5_VFIO_PCI) += mlx5/
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index 0c771064c0b8..41dcbe4ace67 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -170,6 +170,7 @@ static int vfio_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> ret = vfio_pci_core_register_device(vdev);
> if (ret)
> goto out_put_vdev;
> +
a meaningless line here.
> return 0;
>
> out_put_vdev:
> @@ -264,10 +265,14 @@ static int __init vfio_pci_init(void)
>
> vfio_pci_core_set_params(nointxmask, is_disable_vga, disable_idle_d3);
>
> + ret = vfio_pci_liveupdate_init();
> + if (ret)
> + return ret;
> +
> /* Register and scan for devices */
> ret = pci_register_driver(&vfio_pci_driver);
> if (ret)
> - return ret;
> + goto err_liveupdate_cleanup;
>
> vfio_pci_fill_ids();
>
> @@ -275,12 +280,17 @@ static int __init vfio_pci_init(void)
> pr_warn("device denylist disabled.\n");
>
> return 0;
> +
> +err_liveupdate_cleanup:
> + vfio_pci_liveupdate_cleanup();
> + return ret;
> }
> module_init(vfio_pci_init);
>
> static void __exit vfio_pci_cleanup(void)
> {
> pci_unregister_driver(&vfio_pci_driver);
> + vfio_pci_liveupdate_cleanup();
> }
> module_exit(vfio_pci_cleanup);
>
> diff --git a/drivers/vfio/pci/vfio_pci_liveupdate.c b/drivers/vfio/pci/vfio_pci_liveupdate.c
> new file mode 100644
> index 000000000000..5ea5af46b159
> --- /dev/null
> +++ b/drivers/vfio/pci/vfio_pci_liveupdate.c
> @@ -0,0 +1,69 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * Copyright (c) 2026, Google LLC.
> + * Vipin Sharma <vipinsh@google.com>
> + * David Matlack <dmatlack@google.com>
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include <linux/kho/abi/vfio_pci.h>
> +#include <linux/liveupdate.h>
> +#include <linux/errno.h>
> +
> +#include "vfio_pci_priv.h"
> +
> +static bool vfio_pci_liveupdate_can_preserve(struct liveupdate_file_handler *handler,
> + struct file *file)
> +{
> + return false;
> +}
> +
> +static int vfio_pci_liveupdate_preserve(struct liveupdate_file_op_args *args)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static void vfio_pci_liveupdate_unpreserve(struct liveupdate_file_op_args *args)
> +{
> +}
> +
> +static int vfio_pci_liveupdate_retrieve(struct liveupdate_file_op_args *args)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static void vfio_pci_liveupdate_finish(struct liveupdate_file_op_args *args)
> +{
> +}
> +
> +static const struct liveupdate_file_ops vfio_pci_liveupdate_file_ops = {
> + .can_preserve = vfio_pci_liveupdate_can_preserve,
> + .preserve = vfio_pci_liveupdate_preserve,
> + .unpreserve = vfio_pci_liveupdate_unpreserve,
> + .retrieve = vfio_pci_liveupdate_retrieve,
> + .finish = vfio_pci_liveupdate_finish,
> + .owner = THIS_MODULE,
> +};
> +
> +static struct liveupdate_file_handler vfio_pci_liveupdate_fh = {
> + .ops = &vfio_pci_liveupdate_file_ops,
> + .compatible = VFIO_PCI_LUO_FH_COMPATIBLE,
> +};
> +
> +int __init vfio_pci_liveupdate_init(void)
> +{
> + int ret;
> +
> + ret = liveupdate_register_file_handler(&vfio_pci_liveupdate_fh);
> + if (ret && ret != -EOPNOTSUPP)
> + return ret;
> +
> + return 0;
> +}
> +
> +void vfio_pci_liveupdate_cleanup(void)
> +{
> + liveupdate_unregister_file_handler(&vfio_pci_liveupdate_fh);
> +}
> diff --git a/drivers/vfio/pci/vfio_pci_priv.h b/drivers/vfio/pci/vfio_pci_priv.h
> index 27ac280f00b9..cbf46e09da30 100644
> --- a/drivers/vfio/pci/vfio_pci_priv.h
> +++ b/drivers/vfio/pci/vfio_pci_priv.h
> @@ -133,4 +133,18 @@ static inline void vfio_pci_dma_buf_move(struct vfio_pci_core_device *vdev,
> }
> #endif
>
> +#ifdef CONFIG_VFIO_PCI_LIVEUPDATE
> +int __init vfio_pci_liveupdate_init(void);
> +void vfio_pci_liveupdate_cleanup(void);
> +#else
> +static inline int vfio_pci_liveupdate_init(void)
> +{
> + return 0;
> +}
> +
> +static inline void vfio_pci_liveupdate_cleanup(void)
> +{
> +}
> +#endif /* CONFIG_VFIO_PCI_LIVEUPDATE */
> +
> #endif
> diff --git a/include/linux/kho/abi/vfio_pci.h b/include/linux/kho/abi/vfio_pci.h
> new file mode 100644
> index 000000000000..e2412b455e61
> --- /dev/null
> +++ b/include/linux/kho/abi/vfio_pci.h
> @@ -0,0 +1,28 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +/*
> + * Copyright (c) 2025, Google LLC.
would be nice to update 2025 to 2026 now. :)
Regards,
Yi Liu
^ permalink raw reply
* Re: [PATCH v3 03/24] PCI: Require Live Update preserved devices are in singleton iommu_groups
From: Yi Liu @ 2026-03-24 13:07 UTC (permalink / raw)
To: David Matlack, Alex Williamson, Bjorn Helgaas
Cc: Adithya Jayachandran, Alexander Graf, Alex Mastro, Andrew Morton,
Ankit Agrawal, Arnd Bergmann, Askar Safin, Borislav Petkov (AMD),
Chris Li, Dapeng Mi, David Rientjes, Feng Tang, Jacob Pan,
Jason Gunthorpe, Jason Gunthorpe, Jonathan Corbet, Josh Hilke,
Kees Cook, Kevin Tian, kexec, kvm, Leon Romanovsky,
Leon Romanovsky, linux-doc, linux-kernel, linux-kselftest,
linux-mm, linux-pci, Li RongQing, Lukas Wunner, Marco Elver,
Michał Winiarski, Mike Rapoport, Parav Pandit,
Pasha Tatashin, Paul E. McKenney, Pawan Gupta,
Peter Zijlstra (Intel), Pranjal Shrivastava, Pratyush Yadav,
Raghavendra Rao Ananta, Randy Dunlap, Rodrigo Vivi,
Saeed Mahameed, Samiullah Khawaja, Shuah Khan, Vipin Sharma,
Vivek Kasireddy, William Tu, Zhu Yanjun
In-Reply-To: <20260323235817.1960573-4-dmatlack@google.com>
On 3/24/26 07:57, David Matlack wrote:
> Require that Live Update preserved devices are in singleton iommu_groups
> during preservation (outgoing kernel) and retrieval (incoming kernel).
>
> PCI devices preserved across Live Update will be allowed to perform
> memory transactions throughout the Live Update. Thus IOMMU groups for
> preserved devices must remain fixed. Since all current use cases for
> Live Update are for PCI devices in singleton iommu_groups, require that
> as a starting point. This avoids the complexity of needing to enforce
> arbitrary iommu_group topologies while still allowing all current use
> cases.
>
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: David Matlack <dmatlack@google.com>
> ---
> drivers/pci/liveupdate.c | 34 +++++++++++++++++++++++++++++++++-
> 1 file changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/liveupdate.c b/drivers/pci/liveupdate.c
> index bec7b3500057..a3dbe06650ff 100644
> --- a/drivers/pci/liveupdate.c
> +++ b/drivers/pci/liveupdate.c
> @@ -75,6 +75,8 @@
> *
> * * The device must not be a Physical Function (PF).
> *
> + * * The device must be the only device in its IOMMU group.
> + *
> * Preservation Behavior
> * =====================
> *
> @@ -105,6 +107,7 @@
>
> #include <linux/bsearch.h>
> #include <linux/io.h>
> +#include <linux/iommu.h>
> #include <linux/kexec_handover.h>
> #include <linux/kho/abi/pci.h>
> #include <linux/liveupdate.h>
> @@ -222,6 +225,31 @@ static void pci_ser_delete(struct pci_ser *ser, struct pci_dev *dev)
> ser->nr_devices--;
> }
>
> +static int count_devices(struct device *dev, void *__nr_devices)
> +{
> + (*(int *)__nr_devices)++;
> + return 0;
> +}
> +
there was a related discussion on the singleton group check. have you
considered the device_group_immutable_singleton() in below link?
https://lore.kernel.org/linux-iommu/20220421052121.3464100-4-baolu.lu@linux.intel.com/
Regards,
Yi Liu
^ 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