* [PATCH v8 03/23] iommu/dma: Check atomic pool allocation result directly
From: Aneesh Kumar K.V (Arm) @ 2026-07-17 18:04 UTC (permalink / raw)
To: iommu, linux-arm-kernel, linux-kernel, linux-coco
Cc: Aneesh Kumar K.V (Arm), Robin Murphy, Marek Szyprowski,
Will Deacon, Marc Zyngier, Steven Price, Suzuki K Poulose,
Catalin Marinas, Jiri Pirko, Jason Gunthorpe, Mostafa Saleh,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, Jason Gunthorpe,
Michael Kelley
In-Reply-To: <20260717180442.110954-1-aneesh.kumar@kernel.org>
The non-blocking, non-coherent allocation path uses dma_alloc_from_pool(),
which returns the allocated page and fills cpu_addr only on success.
Do not rely on cpu_addr to detect allocation failure in this path. Check
the returned page directly before using it for the IOMMU mapping.
Fixes: 9420139f516d ("dma-pool: fix coherent pool allocations for IOMMU mappings")
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Tested-by: Michael Kelley <mhklinux@outlook.com>
Tested-by: Mostafa Saleh <smostafa@google.com>
Reviewed-by: Petr Tesarik <ptesarik@suse.com>
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
drivers/iommu/dma-iommu.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 5598ed4bff72..6a45acbbfb0c 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1671,13 +1671,16 @@ void *iommu_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
}
if (IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
- !gfpflags_allow_blocking(gfp) && !coherent)
+ !gfpflags_allow_blocking(gfp) && !coherent) {
page = dma_alloc_from_pool(dev, PAGE_ALIGN(size), &cpu_addr,
- gfp, NULL);
- else
+ gfp, NULL);
+ if (!page)
+ return NULL;
+ } else {
cpu_addr = iommu_dma_alloc_pages(dev, size, &page, gfp, attrs);
- if (!cpu_addr)
- return NULL;
+ if (!cpu_addr)
+ return NULL;
+ }
*handle = __iommu_dma_map(dev, page_to_phys(page), size, ioprot,
dev->coherent_dma_mask);
--
2.43.0
^ permalink raw reply related
* [PATCH v8 02/23] dma-pool: fix page leak in atomic_pool_expand() cleanup
From: Aneesh Kumar K.V (Arm) @ 2026-07-17 18:04 UTC (permalink / raw)
To: iommu, linux-arm-kernel, linux-kernel, linux-coco
Cc: Aneesh Kumar K.V (Arm), Robin Murphy, Marek Szyprowski,
Will Deacon, Marc Zyngier, Steven Price, Suzuki K Poulose,
Catalin Marinas, Jiri Pirko, Jason Gunthorpe, Mostafa Saleh,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, Jason Gunthorpe,
Michael Kelley
In-Reply-To: <20260717180442.110954-1-aneesh.kumar@kernel.org>
atomic_pool_expand() frees the allocated pages from the remove_mapping
error path only when CONFIG_DMA_DIRECT_REMAP is enabled.
When CONFIG_DMA_DIRECT_REMAP is disabled, failures after page allocation,
such as gen_pool_add_virt(), jump to remove_mapping and return without
freeing the pages.
Move __free_pages(page, order) out of the CONFIG_DMA_DIRECT_REMAP block so
that cleanup paths always release the allocation.
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Tested-by: Michael Kelley <mhklinux@outlook.com>
Tested-by: Mostafa Saleh <smostafa@google.com>
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
kernel/dma/pool.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
index 2b2fbb709242..b0303efbc153 100644
--- a/kernel/dma/pool.c
+++ b/kernel/dma/pool.c
@@ -81,6 +81,7 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
{
unsigned int order;
struct page *page = NULL;
+ bool leak_pages = false;
void *addr;
int ret = -ENOMEM;
@@ -115,8 +116,10 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
*/
ret = set_memory_decrypted((unsigned long)page_to_virt(page),
1 << order);
- if (ret)
+ if (ret) {
+ leak_pages = true;
goto remove_mapping;
+ }
ret = gen_pool_add_virt(pool, (unsigned long)addr, page_to_phys(page),
pool_size, NUMA_NO_NODE);
if (ret)
@@ -130,14 +133,15 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
1 << order);
if (WARN_ON_ONCE(ret)) {
/* Decrypt succeeded but encrypt failed, purposely leak */
- goto out;
+ leak_pages = true;
}
remove_mapping:
#ifdef CONFIG_DMA_DIRECT_REMAP
dma_common_free_remap(addr, pool_size);
free_page:
- __free_pages(page, order);
#endif
+ if (!leak_pages)
+ __free_pages(page, order);
out:
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v8 01/23] dma-direct: return struct page from dma_direct_alloc_from_pool()
From: Aneesh Kumar K.V (Arm) @ 2026-07-17 18:04 UTC (permalink / raw)
To: iommu, linux-arm-kernel, linux-kernel, linux-coco
Cc: Aneesh Kumar K.V (Arm), Robin Murphy, Marek Szyprowski,
Will Deacon, Marc Zyngier, Steven Price, Suzuki K Poulose,
Catalin Marinas, Jiri Pirko, Jason Gunthorpe, Mostafa Saleh,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, stable, Michael Kelley,
Jason Gunthorpe
In-Reply-To: <20260717180442.110954-1-aneesh.kumar@kernel.org>
Commit 5b138c534fda ("dma-direct: factor out a dma_direct_alloc_from_pool
helper") changed dma_direct_alloc_from_pool() to return the CPU address
from dma_alloc_from_pool(). That fits dma_direct_alloc(), but
dma_direct_alloc_pages() also uses the helper and expects a struct page *.
Fix this by making dma_direct_alloc_from_pool() return the struct page *
again, and pass the CPU address back through an out-parameter for the
dma_direct_alloc() caller.
Fixes: 5b138c534fda ("dma-direct: factor out a dma_direct_alloc_from_pool helper")
Cc: stable@vger.kernel.org
Tested-by: Michael Kelley <mhklinux@outlook.com>
Tested-by: Mostafa Saleh <smostafa@google.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
kernel/dma/direct.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index d8219efe3273..363d984d90e7 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -164,22 +164,21 @@ static bool dma_direct_use_pool(struct device *dev, gfp_t gfp)
return !gfpflags_allow_blocking(gfp) && !is_swiotlb_for_alloc(dev);
}
-static void *dma_direct_alloc_from_pool(struct device *dev, size_t size,
- dma_addr_t *dma_handle, gfp_t gfp)
+static struct page *dma_direct_alloc_from_pool(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, void **cpu_addr, gfp_t gfp)
{
struct page *page;
u64 phys_limit;
- void *ret;
if (WARN_ON_ONCE(!IS_ENABLED(CONFIG_DMA_COHERENT_POOL)))
return NULL;
gfp |= dma_direct_optimal_gfp_mask(dev, &phys_limit);
- page = dma_alloc_from_pool(dev, size, &ret, gfp, dma_coherent_ok);
+ page = dma_alloc_from_pool(dev, size, cpu_addr, gfp, dma_coherent_ok);
if (!page)
return NULL;
*dma_handle = phys_to_dma_direct(dev, page_to_phys(page));
- return ret;
+ return page;
}
static void *dma_direct_alloc_no_mapping(struct device *dev, size_t size,
@@ -247,8 +246,11 @@ void *dma_direct_alloc(struct device *dev, size_t size,
* the atomic pools instead if we aren't allowed block.
*/
if ((remap || force_dma_unencrypted(dev)) &&
- dma_direct_use_pool(dev, gfp))
- return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
+ dma_direct_use_pool(dev, gfp)) {
+ page = dma_direct_alloc_from_pool(dev, size, dma_handle,
+ &ret, gfp);
+ return page ? ret : NULL;
+ }
/* we always manually zero the memory once we are done */
page = __dma_direct_alloc_pages(dev, size, gfp & ~__GFP_ZERO, true);
@@ -357,7 +359,7 @@ struct page *dma_direct_alloc_pages(struct device *dev, size_t size,
void *ret;
if (force_dma_unencrypted(dev) && dma_direct_use_pool(dev, gfp))
- return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
+ return dma_direct_alloc_from_pool(dev, size, dma_handle, &ret, gfp);
page = __dma_direct_alloc_pages(dev, size, gfp, false);
if (!page)
--
2.43.0
^ permalink raw reply related
* [PATCH v8 00/23] dma-mapping: Track shared DMA state through direct, pool and swiotlb paths
From: Aneesh Kumar K.V (Arm) @ 2026-07-17 18:04 UTC (permalink / raw)
To: iommu, linux-arm-kernel, linux-kernel, linux-coco
Cc: Aneesh Kumar K.V (Arm), Robin Murphy, Marek Szyprowski,
Will Deacon, Marc Zyngier, Steven Price, Suzuki K Poulose,
Catalin Marinas, Jiri Pirko, Jason Gunthorpe, Mostafa Saleh,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
This series tracks confidential-computing shared DMA state through the
dma-direct, dma-pool, and swiotlb paths so that encrypted and decrypted
DMA buffers are handled consistently.
Today, the direct DMA path mostly relies on force_dma_unencrypted() for
shared/decrypted buffer handling. This series consolidates the
force_dma_unencrypted() checks in the top-level functions and ensures
that the remaining DMA interfaces use DMA attributes to make the correct
decisions.
The series separates mapping and allocation state:
- DMA_ATTR_CC_SHARED describes the DMA address attribute requested for a
mapping. It tells the DMA mapping path that the DMA address must target
shared/decrypted memory.
- __DMA_ATTR_ALLOC_CC_SHARED is an internal DMA-mapping attribute used only
by allocation paths after the DMA core decides that the backing pages
must be allocated as shared/decrypted memory.
The series:
- moves swiotlb-backed allocations out of __dma_direct_alloc_pages(),
- uses __DMA_ATTR_ALLOC_CC_SHARED through the dma-direct alloc/free paths
- teaches the atomic DMA pools to track encrypted versus decrypted
state
- tracks swiotlb pool encryption state and enforces strict pool
selection
- centralizes encrypted/decrypted pgprot handling in dma_pgprot() using
DMA attributes
- passes DMA attributes down to dma_capable() so capability checks can
validate whether the selected DMA address encoding matches
DMA_ATTR_CC_SHARED
- makes dma_direct_map_phys() choose the DMA address encoding from
DMA_ATTR_CC_SHARED and fall back to swiotlb when a shared DMA request
cannot use the direct mapping, which lets arm64 and x86 CCA guests stop
relying on SWIOTLB_FORCE for DMA mappings
- use the selected swiotlb pool state to derive the returned DMA
address
- reports CC_ATTR_GUEST_MEM_ENCRYPT for arm64 Realms, powerpc secure
guests, and s390 protected virtualization guests.
Dependency:
This series depends on the pKVM changes posted at:
https://lore.kernel.org/all/20260603110522.3331819-1-smostafa@google.com
Please merge this series only after the pKVM changes above are merged.
Otherwise pKVM will be broken.
Changes since v7:
https://lore.kernel.org/all/20260701054926.825925-1-aneesh.kumar@kernel.org
* Rebased onto dma-mapping-for-next
* Prepared the series on top of the prerequisite pKVM changes, resolving
conflicts so it can be applied directly to the pKVM topic branch once ready.
https://git.gitlab.arm.com/linux-arm/linux-cca/-/commits/scratch/pkvm/testing
* Added comments documenting possible follow-up improvements for CC_SHARED
atomic pools and physical-address-based pool freeing.
* Retained virtual-address-based pool freeing when
CONFIG_DMA_DIRECT_REMAP is disabled.
* Applied pgprot_decrypted() only when expanding a CC_SHARED atomic pool.
Changes since v6:
https://lore.kernel.org/all/20260604083959.1265923-1-aneesh.kumar@kernel.org
* Rebase onto the latest kernel.
* Add __DMA_ATTR_ALLOC_CC_SHARED for allocation paths. DMA_ATTR_CC_SHARED
is now used to describe the requested DMA mapping address attribute,
while __DMA_ATTR_ALLOC_CC_SHARED is used internally when allocating
shared/decrypted backing pages.
* Report CC_ATTR_GUEST_MEM_ENCRYPT for arm64 Realms, powerpc secure
guests, and s390 protected virtualization guests.
* Add CC_ATTR_HOST_MEM_ENCRYPT and swiotlb=force fixes.
Changes since v5:
https://lore.kernel.org/all/20260522042815.370873-1-aneesh.kumar@kernel.org
* Add Tested-by
* Drop the pKVM patch, which has now been posted separately:
https://lore.kernel.org/all/20260603110522.3331819-1-smostafa@google.com
* Remove the DO_NOT_MERGE tag from the s390 change.
* Add a patch to drop the SWIOTLB_FORCE flag.
* Rebase onto the latest kernel.
Changes since v4:
https://lore.kernel.org/all/20260512090408.794195-1-aneesh.kumar@kernel.org
* Add new patches based on Sashiko review:
swiotlb: Preserve allocation virtual address for dynamic pools
dma: free atomic pool pages by physical address
dma: swiotlb: handle set_memory_decrypted() failures
dma: swiotlb: free dynamic pools from process context
iommu/dma: Check atomic pool allocation result directly
* Include pKVM and s390 changes as dependent patches. These are not yet
ready to merge and are waiting for subsystem testing feedback.
* Drop the AMD GART patch because it requires wider testing.
* Update swiotlb_tbl_map_single() to take attrs by reference.
* Switch swiotlb_free() to use rcu_work.
* Avoid calling swiotlb_find_pool() multiple times in the free path.
* Make DMA_ATTR_MMIO imply DMA_ATTR_CC_SHARED for devices requiring unencrypted DMA.
Changes from v3:
https://lore.kernel.org/all/20260427055509.898190-1-aneesh.kumar@kernel.org
* Handle DMA_ATTR_MMIO correctly in dma_direct_map_phys()
* Address most of sashiko review
* Rebase to latest kernel
* drop SWIOTLB_FORCE for s390 and powerpc secure guest.
Changes from v2:
https://lore.kernel.org/all/20260420061415.3650870-1-aneesh.kumar@kernel.org
* pass attrs to dma_capable() and update direct, swiotlb, Xen swiotlb, and
x86 GART paths so the capability checks see the DMA address attr value
DMA_ATTR_CC_SHARED.
* rework dma_direct_map_phys() so DMA_ATTR_CC_SHARED selects
phys_to_dma_unencrypted() while the default path uses
phys_to_dma_encrypted(), with swiotlb fallback when the requested
shared/private state cannot be satisfied by a direct DMA address.
* stop relying on SWIOTLB_FORCE for arm64 and x86 CC guest DMA mappings;
swiotlb is still enabled there, but shared mappings is now selected
through the generic dma_direct_map_phys()/dma_capable() decision instead
of a global force-bounce flag.
Changes from v1:
https://lore.kernel.org/all/20260417085900.3062416-1-aneesh.kumar@kernel.org
* rebased to latest kernel (change from DMA_ATTR_CC_DECRYPTED -> DMA_ATTR_CC_SHARED)
* update the alloc path so DMA_ATTR_CC_SHARED is not a caller-visible attribute.
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Steven Price <steven.price@arm.com>
Cc: Suzuki K Poulose <Suzuki.Poulose@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Jiri Pirko <jiri@resnulli.us>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Mostafa Saleh <smostafa@google.com>
Cc: Petr Tesarik <ptesarik@suse.com>
Cc: Alexey Kardashevskiy <aik@amd.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Xu Yilun <yilun.xu@linux.intel.com>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s390@vger.kernel.org
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
Cc: Sven Schnelle <svens@linux.ibm.com>
Cc: x86@kernel.org
Aneesh Kumar K.V (Arm) (23):
dma-direct: return struct page from dma_direct_alloc_from_pool()
dma-pool: fix page leak in atomic_pool_expand() cleanup
iommu/dma: Check atomic pool allocation result directly
dma: free atomic pool pages by physical address
swiotlb: Preserve allocation virtual address for dynamic pools
s390: Expose protected virtualization through cc_platform_has()
dma-direct: swiotlb: handle swiotlb alloc/free outside
__dma_direct_alloc_pages
coco: arm64: s390: powerpc: Mark secure guests with
CC_ATTR_GUEST_MEM_ENCRYPT
dma-mapping: Add internal shared allocation attribute
dma-direct: use __DMA_ATTR_ALLOC_CC_SHARED in alloc/free paths
dma-pool: track decrypted atomic pools and select them via attrs
dma: swiotlb: pass mapping attributes by reference
dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
dma-mapping: make dma_pgprot() honor __DMA_ATTR_ALLOC_CC_SHARED
dma-direct: pass attrs to dma_capable() for DMA_ATTR_CC_SHARED checks
dma-direct: Move dma_direct_map_phys() to dma/direct.c
dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED
dma-direct: set decrypted flag for remapped DMA allocations
dma-direct: select DMA address encoding from
__DMA_ATTR_ALLOC_CC_SHARED
dma-direct: rename ret to cpu_addr in alloc helpers
dma: swiotlb: free dynamic pools from process context
dma: swiotlb: handle set_memory_decrypted() failures
swiotlb: remove unused SWIOTLB_FORCE flag
Documentation/core-api/dma-attributes.rst | 29 ++
arch/arm64/mm/init.c | 5 +-
arch/powerpc/platforms/pseries/cc_platform.c | 1 +
arch/powerpc/platforms/pseries/svm.c | 2 +-
arch/s390/Kconfig | 1 +
arch/s390/mm/init.c | 17 +-
arch/x86/kernel/amd_gart_64.c | 30 +-
arch/x86/kernel/pci-dma.c | 4 +-
drivers/iommu/dma-iommu.c | 20 +-
drivers/xen/swiotlb-xen.c | 8 +-
include/linux/dma-direct.h | 20 +-
include/linux/dma-map-ops.h | 3 +-
include/linux/dma-mapping.h | 8 +
include/linux/swiotlb.h | 25 +-
include/trace/events/dma.h | 3 +-
kernel/dma/direct.c | 326 ++++++++++++++-----
kernel/dma/direct.h | 56 +---
kernel/dma/mapping.c | 25 +-
kernel/dma/pool.c | 237 ++++++++++----
kernel/dma/swiotlb.c | 292 +++++++++++++----
20 files changed, 810 insertions(+), 302 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH 5/6] configfs: Allow the registration of const struct configfs_attribute
From: Thomas Weißschuh @ 2026-07-17 15:35 UTC (permalink / raw)
To: Breno Leitao
Cc: Andreas Hindborg, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Matthew Brost,
Thomas Hellström, Rodrigo Vivi, David Airlie, Simona Vetter,
Dan Williams, Rafael J. Wysocki, Len Brown, rust-for-linux,
linux-kernel, intel-xe, dri-devel, linux-coco, linux-acpi
In-Reply-To: <alnrJJNb1hwDrAxI@gmail.com>
On 2026-07-17 01:43:36-0700, Breno Leitao wrote:
> On Thu, Jul 16, 2026 at 07:09:30PM +0200, Thomas Weißschuh wrote:
> > The attribute structure defined in driver code never need to be
> > modified. Allow them to be marked as const.
> >
> > As there are many drivers which use these attributes, prepare for a
> > phased transition by using a union of const and non-const attributes.
>
> How many drivers need to be migrated? Isn't this a mechanism move?
The actual constification of the attribute will happen with a central
change to the CONFIGFS_ATTR* macros. But all users of the macro
will need to be prepared to handle the constness.
I have a branch with the full conversion here:
https://git.kernel.org/pub/scm/linux/kernel/git/thomas.weissschuh/linux.git/log/?h=b4/configfs-const
73 files changed, 241 insertions(+), 248 deletions(-)
Most driver changes are really trivial. But a few do more interesting
things. My goal is to heavily reduce the amount of patches in this
branch by merging patches to the same subsystem.
The last four patches will be the finalization going again through
the configfs tree.
Thomas
^ permalink raw reply
* Re: [PATCH 07/15] modules: Document the global async_probe parameter
From: Nikolay Borisov @ 2026-07-17 13:44 UTC (permalink / raw)
To: Dan Williams, linux-coco
Cc: linux-pci, driver-core, ankita, Saravana Kannan, Luis Chamberlain
In-Reply-To: <20260705220819.2472765-8-djbw@kernel.org>
On 7/6/26 01:08, Dan Williams wrote:
> In preparation for adding another /sys/module/module/parameters entry,
> document the existing async_probe parameter.
>
> Cc: Saravana Kannan <saravanak@google.com>
> Cc: Luis Chamberlain <mcgrof@kernel.org>
> Signed-off-by: Dan Williams <djbw@kernel.org>
> ---
> Documentation/ABI/stable/sysfs-module | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/ABI/stable/sysfs-module b/Documentation/ABI/stable/sysfs-module
> index 41b1f16e8795..397c5c850894 100644
> --- a/Documentation/ABI/stable/sysfs-module
> +++ b/Documentation/ABI/stable/sysfs-module
> @@ -45,3 +45,13 @@ Date: Jun 2005
> Description:
> If the module source has MODULE_VERSION, this file will contain
> the version of the source code.
> +
> +What: /sys/module/module/parameters/async_probe
> +Description:
> + (RW) Emits "1" if drivers from loadable modules attempt async
> + probing by default. Emits "0" if drivers from loadable modules
nit: I think there is some tautology happening here, i.e a module is a
driver, no ? I.e perhaps just remove the driver word so this reads
"emits 1 if modules atempts async probing".
> + attempt synchronous probing by default. This value is overridden
> + (in priority order) by: the module's built-in "PROBE_FORCE_*"
> + requests, the "driver_async_probe=..." kernel command line, the
> + "async_probe" module option, then this default. Write a valid
> + boolean value to toggle this policy.
^ permalink raw reply
* Re: [PATCH v2] x86/virt/tdx: Formalize SEAMCALL version encoding support
From: Dave Hansen @ 2026-07-17 13:10 UTC (permalink / raw)
To: Nikolay Borisov, Xu Yilun, Kiryl Shutsemau
Cc: x86, linux-kernel, rick.p.edgecombe, dave.hansen, yilun.xu,
chao.gao, djbw, linux-coco, peter.fang, xiaoyao.li
In-Reply-To: <90685b93-e13e-4509-98f3-4509381d4981@suse.com>
On 7/17/26 01:21, Nikolay Borisov wrote:
> At the end of the day the layout of args is the software API that is
> presented to the rest of the system, the ABI is a low level detail
> handled in TDX_MODULE_CALL.
Yep, that's my basic view of it too.
I don't feel strongly about where the structure is translated over to
the hardware registers of the actual module ABI call, as long as it's
consistent and centralized.
^ permalink raw reply
* [PATCH linux-6.12.y v1 1/2] iommu/amd: Use maximum Event log buffer size when SNP is enabled on Family 0x19
From: Liam Merwick @ 2026-07-17 10:49 UTC (permalink / raw)
To: stable
Cc: vasant.hegde, joerg.roedel, iommu, dheerajkumar.srivastava, bp,
Michael.Roth, sashal, linux-coco, liam.merwick
In-Reply-To: <20260717104909.3850331-1-liam.merwick@oracle.com>
From: Vasant Hegde <vasant.hegde@amd.com>
commit 58c0ac6125d89bf6ec65a521eaeb52a0e8e20a9f upstream.
Due to CVE-2023-20585, the Event log buffer must use the maximum supported
size (512K) on Milan/Genoa (Family 0x19) systems when SNP is enabled,
to mitigate a potential security vulnerability. All other systems continue to
use the default Event log buffer size (8K).
Apply the errata fix by making the following changes:
* Introduce new global variable (amd_iommu_evtlog_size) to have event log
buffer size. Adjust variable size for family 0x19.
* Since 'iommu_snp_enable()' must be called after the core IOMMU subsystem
is initialized, it cannot be moved to the early init stage. The SNP errata
must also be applied after the 'iommu_snp_enable()' check. Therefore,
'alloc_event_buffer()' and 'iommu_enable_event_buffer()' are now called
in the IOMMU_ENABLED state, after the errata is applied.
* Adjust alloc_event_buffer() and iommu_enable_event_buffer() to handle
all IOMMU instances.
* Also rename EVT_* macros to make it more readable.
Link: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3016.html
Cc: Borislav Petkov <bp@alien8.de>
Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Cc: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
Tested-by: Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
(cherry picked from commit 58c0ac6125d89bf6ec65a521eaeb52a0e8e20a9f)
Conflicts:
drivers/iommu/amd/init.c
[ Conflicts in alloc_event_buffer() and iommu_enable_event_buffer()
due to lack of upstream AMD IOMMU kdump buffer reuse code.
Similarly, do not add a kdump check when allocating an
event log buffer in state_next(). ]
Signed-off-by: Liam Merwick <liam.merwick@oracle.com>
---
drivers/iommu/amd/amd_iommu.h | 2 +
drivers/iommu/amd/amd_iommu_types.h | 10 ++--
drivers/iommu/amd/init.c | 77 +++++++++++++++++++++--------
drivers/iommu/amd/iommu.c | 2 +-
4 files changed, 67 insertions(+), 24 deletions(-)
diff --git a/drivers/iommu/amd/amd_iommu.h b/drivers/iommu/amd/amd_iommu.h
index 6fac9ee8dd3e..af734668386f 100644
--- a/drivers/iommu/amd/amd_iommu.h
+++ b/drivers/iommu/amd/amd_iommu.h
@@ -11,6 +11,8 @@
#include "amd_iommu_types.h"
+extern int amd_iommu_evtlog_size;
+
irqreturn_t amd_iommu_int_thread(int irq, void *data);
irqreturn_t amd_iommu_int_thread_evtlog(int irq, void *data);
irqreturn_t amd_iommu_int_thread_pprlog(int irq, void *data);
diff --git a/drivers/iommu/amd/amd_iommu_types.h b/drivers/iommu/amd/amd_iommu_types.h
index 7f13b314abbc..d622fa0091a5 100644
--- a/drivers/iommu/amd/amd_iommu_types.h
+++ b/drivers/iommu/amd/amd_iommu_types.h
@@ -15,6 +15,7 @@
#include <linux/mutex.h>
#include <linux/msi.h>
#include <linux/list.h>
+#include <linux/sizes.h>
#include <linux/spinlock.h>
#include <linux/pci.h>
#include <linux/irqreturn.h>
@@ -132,7 +133,6 @@
#define MMIO_STATUS_GALOG_INT_MASK BIT(10)
/* event logging constants */
-#define EVENT_ENTRY_SIZE 0x10
#define EVENT_TYPE_SHIFT 28
#define EVENT_TYPE_MASK 0xf
#define EVENT_TYPE_ILL_DEV 0x1
@@ -240,8 +240,12 @@
#define MMIO_CMD_SIZE_512 (0x9ULL << MMIO_CMD_SIZE_SHIFT)
/* constants for event buffer handling */
-#define EVT_BUFFER_SIZE 8192 /* 512 entries */
-#define EVT_LEN_MASK (0x9ULL << 56)
+#define EVTLOG_ENTRY_SIZE 0x10
+#define EVTLOG_SIZE_SHIFT 56
+#define EVTLOG_SIZE_DEF SZ_8K /* 512 entries */
+#define EVTLOG_LEN_MASK_DEF (0x9ULL << EVTLOG_SIZE_SHIFT)
+#define EVTLOG_SIZE_MAX SZ_512K /* 32K entries */
+#define EVTLOG_LEN_MASK_MAX (0xFULL << EVTLOG_SIZE_SHIFT)
/* Constants for PPR Log handling */
#define PPR_LOG_ENTRIES 512
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index 78e9ceda2338..570471e10586 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -133,6 +133,8 @@ struct ivhd_entry {
u8 uid;
} __attribute__((packed));
+int amd_iommu_evtlog_size = EVTLOG_SIZE_DEF;
+
/*
* An AMD IOMMU memory definition structure. It defines things like exclusion
* ranges for devices and regions that should be unity mapped.
@@ -855,30 +857,41 @@ void *__init iommu_alloc_4k_pages(struct amd_iommu *iommu, gfp_t gfp,
}
/* allocates the memory where the IOMMU will log its events to */
-static int __init alloc_event_buffer(struct amd_iommu *iommu)
+static int __init alloc_event_buffer(void)
{
- iommu->evt_buf = iommu_alloc_4k_pages(iommu, GFP_KERNEL,
- EVT_BUFFER_SIZE);
+ struct amd_iommu *iommu;
- return iommu->evt_buf ? 0 : -ENOMEM;
+ for_each_iommu(iommu) {
+ iommu->evt_buf = iommu_alloc_4k_pages(iommu, GFP_KERNEL,
+ amd_iommu_evtlog_size);
+ if (!iommu->evt_buf)
+ return -ENOMEM;
+ }
+
+ return 0;
}
-static void iommu_enable_event_buffer(struct amd_iommu *iommu)
+static void iommu_enable_event_buffer(void)
{
+ struct amd_iommu *iommu;
u64 entry;
- BUG_ON(iommu->evt_buf == NULL);
+ for_each_iommu(iommu) {
+ BUG_ON(iommu->evt_buf == NULL);
- entry = iommu_virt_to_phys(iommu->evt_buf) | EVT_LEN_MASK;
+ entry = iommu_virt_to_phys(iommu->evt_buf);
+ entry |= (amd_iommu_evtlog_size == EVTLOG_SIZE_DEF) ?
+ EVTLOG_LEN_MASK_DEF : EVTLOG_LEN_MASK_MAX;
- memcpy_toio(iommu->mmio_base + MMIO_EVT_BUF_OFFSET,
- &entry, sizeof(entry));
+ memcpy_toio(iommu->mmio_base + MMIO_EVT_BUF_OFFSET,
+ &entry, sizeof(entry));
- /* set head and tail to zero manually */
- writel(0x00, iommu->mmio_base + MMIO_EVT_HEAD_OFFSET);
- writel(0x00, iommu->mmio_base + MMIO_EVT_TAIL_OFFSET);
+ /* set head and tail to zero manually */
+ writel(0x00, iommu->mmio_base + MMIO_EVT_HEAD_OFFSET);
+ writel(0x00, iommu->mmio_base + MMIO_EVT_TAIL_OFFSET);
- iommu_feature_enable(iommu, CONTROL_EVT_LOG_EN);
+ iommu_feature_enable(iommu, CONTROL_EVT_LOG_EN);
+ }
}
/*
@@ -891,7 +904,7 @@ static void iommu_disable_event_buffer(struct amd_iommu *iommu)
static void __init free_event_buffer(struct amd_iommu *iommu)
{
- iommu_free_pages(iommu->evt_buf, get_order(EVT_BUFFER_SIZE));
+ iommu_free_pages(iommu->evt_buf, get_order(amd_iommu_evtlog_size));
}
static void free_ga_log(struct amd_iommu *iommu)
@@ -1828,9 +1841,6 @@ static int __init init_iommu_one_late(struct amd_iommu *iommu)
if (alloc_command_buffer(iommu))
return -ENOMEM;
- if (alloc_event_buffer(iommu))
- return -ENOMEM;
-
iommu->int_enabled = false;
init_translation_status(iommu);
@@ -2754,7 +2764,6 @@ static void early_enable_iommu(struct amd_iommu *iommu)
iommu_init_flags(iommu);
iommu_set_device_table(iommu);
iommu_enable_command_buffer(iommu);
- iommu_enable_event_buffer(iommu);
iommu_set_exclusion_range(iommu);
iommu_enable_gt(iommu);
iommu_enable_ga(iommu);
@@ -2812,7 +2821,6 @@ static void early_enable_iommus(void)
iommu_disable_event_buffer(iommu);
iommu_disable_irtcachedis(iommu);
iommu_enable_command_buffer(iommu);
- iommu_enable_event_buffer(iommu);
iommu_enable_ga(iommu);
iommu_enable_xt(iommu);
iommu_enable_irtcachedis(iommu);
@@ -2928,6 +2936,7 @@ static void amd_iommu_resume(void)
/* re-load the hardware */
enable_iommus();
+ iommu_enable_event_buffer();
amd_iommu_enable_interrupts();
}
@@ -3242,6 +3251,23 @@ static void iommu_snp_enable(void)
#endif
}
+static void amd_iommu_apply_erratum_snp(void)
+{
+#ifdef CONFIG_KVM_AMD_SEV
+ if (!amd_iommu_snp_en)
+ return;
+
+ /* Errata fix for Family 0x19 */
+ if (boot_cpu_data.x86 != 0x19)
+ return;
+
+ /* Set event log buffer size to max */
+ amd_iommu_evtlog_size = EVTLOG_SIZE_MAX;
+ pr_info("Applying erratum: Increase Event log size to 0x%x\n",
+ amd_iommu_evtlog_size);
+#endif
+}
+
/****************************************************************************
*
* AMD IOMMU Initialization State Machine
@@ -3278,6 +3304,17 @@ static int __init state_next(void)
case IOMMU_ENABLED:
register_syscore_ops(&amd_iommu_syscore_ops);
iommu_snp_enable();
+
+ amd_iommu_apply_erratum_snp();
+
+ /* Allocate/enable event log buffer */
+ ret = alloc_event_buffer();
+ if (ret) {
+ init_state = IOMMU_INIT_ERROR;
+ break;
+ }
+ iommu_enable_event_buffer();
+
ret = amd_iommu_init_pci();
init_state = ret ? IOMMU_INIT_ERROR : IOMMU_PCI_INIT;
break;
@@ -3865,7 +3902,7 @@ int amd_iommu_snp_disable(void)
return 0;
for_each_iommu(iommu) {
- ret = iommu_make_shared(iommu->evt_buf, EVT_BUFFER_SIZE);
+ ret = iommu_make_shared(iommu->evt_buf, amd_iommu_evtlog_size);
if (ret)
return ret;
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 65d61b9c7382..f87db7a39d2f 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -1003,7 +1003,7 @@ static void iommu_poll_events(struct amd_iommu *iommu)
iommu_print_event(iommu, iommu->evt_buf + head);
/* Update head pointer of hardware ring-buffer */
- head = (head + EVENT_ENTRY_SIZE) % EVT_BUFFER_SIZE;
+ head = (head + EVTLOG_ENTRY_SIZE) % amd_iommu_evtlog_size;
writel(head, iommu->mmio_base + MMIO_EVT_HEAD_OFFSET);
}
--
2.52.0
^ permalink raw reply related
* [PATCH linux-6.12.y v1 2/2] iommu/amd: Use maximum PPR log buffer size when SNP is enabled on Family 0x19
From: Liam Merwick @ 2026-07-17 10:49 UTC (permalink / raw)
To: stable
Cc: vasant.hegde, joerg.roedel, iommu, dheerajkumar.srivastava, bp,
Michael.Roth, sashal, linux-coco, liam.merwick
In-Reply-To: <20260717104909.3850331-1-liam.merwick@oracle.com>
From: Vasant Hegde <vasant.hegde@amd.com>
commit 1f44aab79bac31f459422dfb213e907bb386509c upstream.
Due to CVE-2023-20585, the PPR log buffer must use the maximum supported
size (512K) on Genoa (Family 0x19, model >= 0x10) systems when SNP is
enabled, to mitigate a potential security vulnerability. Note that Family
0x19 models below 0x10 (Milan) do not support PPR when SNP is enabled.
Hence the PPR log size increase is only applied for model >= 0x10.
All other systems continue to use the default PPR log buffer size (8K).
Apply the errata fix by making the following changes:
- Introduce global new variable (amd_iommu_pprlog_size) to have PPR log buffer
size. Adjust variable size for Genoa family.
- Extend 'amd_iommu_apply_erratum_snp()' to also set the PPR log buffer
size to maximum for Family 0x19 model >= 0x10 when SNP is enabled.
- Rename PPR_* macros to make it more readable.
Link: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3016.html
Cc: Borislav Petkov <bp@alien8.de>
Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Cc: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
Tested-by: Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
(cherry picked from commit 1f44aab79bac31f459422dfb213e907bb386509c)
[ Modify amd_iommu_free_ppr_log() due to different iommu_free_pages() API. ]
Signed-off-by: Liam Merwick <liam.merwick@oracle.com>
---
drivers/iommu/amd/amd_iommu.h | 1 +
drivers/iommu/amd/amd_iommu_types.h | 11 ++++++-----
drivers/iommu/amd/init.c | 13 ++++++++++++-
drivers/iommu/amd/ppr.c | 10 ++++++----
4 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/amd/amd_iommu.h b/drivers/iommu/amd/amd_iommu.h
index af734668386f..6118487a69e0 100644
--- a/drivers/iommu/amd/amd_iommu.h
+++ b/drivers/iommu/amd/amd_iommu.h
@@ -12,6 +12,7 @@
#include "amd_iommu_types.h"
extern int amd_iommu_evtlog_size;
+extern int amd_iommu_pprlog_size;
irqreturn_t amd_iommu_int_thread(int irq, void *data);
irqreturn_t amd_iommu_int_thread_evtlog(int irq, void *data);
diff --git a/drivers/iommu/amd/amd_iommu_types.h b/drivers/iommu/amd/amd_iommu_types.h
index d622fa0091a5..09131d067a8a 100644
--- a/drivers/iommu/amd/amd_iommu_types.h
+++ b/drivers/iommu/amd/amd_iommu_types.h
@@ -248,11 +248,12 @@
#define EVTLOG_LEN_MASK_MAX (0xFULL << EVTLOG_SIZE_SHIFT)
/* Constants for PPR Log handling */
-#define PPR_LOG_ENTRIES 512
-#define PPR_LOG_SIZE_SHIFT 56
-#define PPR_LOG_SIZE_512 (0x9ULL << PPR_LOG_SIZE_SHIFT)
-#define PPR_ENTRY_SIZE 16
-#define PPR_LOG_SIZE (PPR_ENTRY_SIZE * PPR_LOG_ENTRIES)
+#define PPRLOG_ENTRY_SIZE 0x10
+#define PPRLOG_SIZE_SHIFT 56
+#define PPRLOG_SIZE_DEF SZ_8K /* 512 entries */
+#define PPRLOG_LEN_MASK_DEF (0x9ULL << PPRLOG_SIZE_SHIFT)
+#define PPRLOG_SIZE_MAX SZ_512K /* 32K entries */
+#define PPRLOG_LEN_MASK_MAX (0xFULL << PPRLOG_SIZE_SHIFT)
/* PAGE_SERVICE_REQUEST PPR Log Buffer Entry flags */
#define PPR_FLAG_EXEC 0x002 /* Execute permission requested */
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index 570471e10586..7fa340281b9f 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -134,6 +134,7 @@ struct ivhd_entry {
} __attribute__((packed));
int amd_iommu_evtlog_size = EVTLOG_SIZE_DEF;
+int amd_iommu_pprlog_size = PPRLOG_SIZE_DEF;
/*
* An AMD IOMMU memory definition structure. It defines things like exclusion
@@ -3265,6 +3266,16 @@ static void amd_iommu_apply_erratum_snp(void)
amd_iommu_evtlog_size = EVTLOG_SIZE_MAX;
pr_info("Applying erratum: Increase Event log size to 0x%x\n",
amd_iommu_evtlog_size);
+
+ /*
+ * Set PPR log buffer size to max.
+ * (Family 0x19, model < 0x10 doesn't support PPR when SNP is enabled).
+ */
+ if (boot_cpu_data.x86_model >= 0x10) {
+ amd_iommu_pprlog_size = PPRLOG_SIZE_MAX;
+ pr_info("Applying erratum: Increase PPR log size to 0x%x\n",
+ amd_iommu_pprlog_size);
+ }
#endif
}
@@ -3906,7 +3917,7 @@ int amd_iommu_snp_disable(void)
if (ret)
return ret;
- ret = iommu_make_shared(iommu->ppr_log, PPR_LOG_SIZE);
+ ret = iommu_make_shared(iommu->ppr_log, amd_iommu_pprlog_size);
if (ret)
return ret;
diff --git a/drivers/iommu/amd/ppr.c b/drivers/iommu/amd/ppr.c
index 7c67d69f0b8c..42d895bd1c44 100644
--- a/drivers/iommu/amd/ppr.c
+++ b/drivers/iommu/amd/ppr.c
@@ -20,7 +20,7 @@
int __init amd_iommu_alloc_ppr_log(struct amd_iommu *iommu)
{
iommu->ppr_log = iommu_alloc_4k_pages(iommu, GFP_KERNEL | __GFP_ZERO,
- PPR_LOG_SIZE);
+ amd_iommu_pprlog_size);
return iommu->ppr_log ? 0 : -ENOMEM;
}
@@ -33,7 +33,9 @@ void amd_iommu_enable_ppr_log(struct amd_iommu *iommu)
iommu_feature_enable(iommu, CONTROL_PPR_EN);
- entry = iommu_virt_to_phys(iommu->ppr_log) | PPR_LOG_SIZE_512;
+ entry = iommu_virt_to_phys(iommu->ppr_log);
+ entry |= (amd_iommu_pprlog_size == PPRLOG_SIZE_DEF) ?
+ PPRLOG_LEN_MASK_DEF : PPRLOG_LEN_MASK_MAX;
memcpy_toio(iommu->mmio_base + MMIO_PPR_LOG_OFFSET,
&entry, sizeof(entry));
@@ -48,7 +50,7 @@ void amd_iommu_enable_ppr_log(struct amd_iommu *iommu)
void __init amd_iommu_free_ppr_log(struct amd_iommu *iommu)
{
- iommu_free_pages(iommu->ppr_log, get_order(PPR_LOG_SIZE));
+ iommu_free_pages(iommu->ppr_log, get_order(amd_iommu_pprlog_size));
}
/*
@@ -201,7 +203,7 @@ void amd_iommu_poll_ppr_log(struct amd_iommu *iommu)
raw[0] = raw[1] = 0UL;
/* Update head pointer of hardware ring-buffer */
- head = (head + PPR_ENTRY_SIZE) % PPR_LOG_SIZE;
+ head = (head + PPRLOG_ENTRY_SIZE) % amd_iommu_pprlog_size;
writel(head, iommu->mmio_base + MMIO_PPR_HEAD_OFFSET);
/* Handle PPR entry */
--
2.52.0
^ permalink raw reply related
* [PATCH linux-6.12.y v1 0/2] Backporting SEV-SNP CVE-2023-20585 to linux-stable
From: Liam Merwick @ 2026-07-17 10:49 UTC (permalink / raw)
To: stable
Cc: vasant.hegde, joerg.roedel, iommu, dheerajkumar.srivastava, bp,
Michael.Roth, sashal, linux-coco, liam.merwick
Two commits from Linux 7.1-rc3 fix CVE-2023-20585 which affects SEV-SNP.
"Insufficient checks of the RMP on host buffer access in IOMMU may allow an
attacker with privileges and a compromised hypervisor to trigger an out of
bounds condition without RMP checks, resulting in a potential loss of
confidential guest integrity." [1]
These are suitable candidates for stable branches but stable@vger.kernel.org
wasn't CC'ed at the time.
1f44aab79bac ("iommu/amd: Use maximum PPR log buffer size when SNP is enabled on Family 0x19") [v7.1-rc3~24^2~2]
58c0ac6125d8 ("iommu/amd: Use maximum Event log buffer size when SNP is enabled on Family 0x19") [v7.1-rc3~24^2~3]
The upstream commits apply cleanly to linux-7.0.y and linux-6.18.y
and an AUTOSEL email[2] was sent (but not pulled so far).
[ The AI analysis in the AUTOSEL patch said that the patches didn't apply
cleanly to linux-6.18.y but that is not my experience. ]
There are conflicts applying them to linux-6.12.y due to the lack of upstream
AMD IOMMU kdump buffer reuse code, introduced to v6.18 by commit
f32fe7cb0198 ("iommu/amd: Add support to remap/unmap IOMMU buffers for kdump")
so I have included patches here which address those.
Tested on AMD machines with Zen4 (impacted) and Zen5 (not impacted) CPUs.
[1] https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3016.html
[2] https://lore.kernel.org/all/20260520111944.3424570-59-sashal@kernel.org
Vasant Hegde (2):
iommu/amd: Use maximum Event log buffer size when SNP is enabled on Family 0x19
iommu/amd: Use maximum PPR log buffer size when SNP is enabled on Family 0x19
drivers/iommu/amd/amd_iommu.h | 3 +
drivers/iommu/amd/amd_iommu_types.h | 21 ++++---
drivers/iommu/amd/init.c | 90 ++++++++++++++++++++++-------
drivers/iommu/amd/iommu.c | 2 +-
drivers/iommu/amd/ppr.c | 10 ++--
5 files changed, 92 insertions(+), 34 deletions(-)
--
2.52.0
^ permalink raw reply
* Re: [PATCH 00/32] x86/msr: Drop 32-bit MSR interfaces
From: Ingo Molnar @ 2026-07-17 9:38 UTC (permalink / raw)
To: Juergen Gross
Cc: Sean Christopherson, Arnd Bergmann, linux-kernel, linux-pm,
linux-edac@vger.kernel.org, x86, linux-acpi, kvm, linux-coco,
linux-pci, virtualization, linux-ide, dri-devel, linux-fbdev,
linux-crypto, open list:GPIO SUBSYSTEM, linux-hyperv, linux-hwmon,
linux-perf-users, linux-mtd, platform-driver-x86,
Rafael J . Wysocki, Daniel Lezcano, Zhang Rui,
lukasz.luba@arm.com, Jason Baron, Borislav Petkov, Tony Luck,
Yazen Ghannam, Len Brown, Pavel Machek, Thomas Gleixner,
Ingo Molnar, Dave Hansen, H. Peter Anvin, Paolo Bonzini,
Kirill A. Shutemov, Rick Edgecombe, Pu Wen, Bjorn Helgaas,
Ajay Kaher, Alexey Makhalov, Broadcom internal kernel review list,
Viresh Kumar, Reinette Chatre, Dave Martin, James Morse,
Babu Moger, Tony W Wang-oc, Damien Le Moal, Niklas Cassel,
Dave Airlie, Helge Deller, linux-geode, Olivia Mackall,
Herbert Xu, Linus Walleij, Bartosz Golaszewski,
Greg Kroah-Hartman, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Guenter Roeck, Peter Zijlstra,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Josh Poimboeuf, Pawan Gupta, Vitaly Kuznetsov,
Andy Lutomirski, Boris Ostrovsky, Huang Rui, Mario Limonciello,
Perry Yuan, K Prateek Nayak, srinivas.pandruvada@linux.intel.com,
Artem Bityutskiy, Artem Bityutskiy, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, Ashok Raj, Hans de Goede,
Ilpo Järvinen, Rajneesh Bhardwaj, David E Box, xen-devel
In-Reply-To: <99228803-b8b7-47a3-b77c-6fdf3b785730@suse.com>
* Juergen Gross <jgross@suse.com> wrote:
> On 02.07.26 12:07, Ingo Molnar wrote:
> >
> > * Sean Christopherson <seanjc@google.com> wrote:
> >
> > > > Note that the individual patches are IMO significantly easier to review
> > > > through the actual 32-bit => 64-bit variable assignment changes done
> > > > in isolation (which sometimes include minor cleanups), while
> > > > the Coccinelle semantic patch:
> > > >
> > > > { a(b,c) => c = a(b) }
> > > >
> > > > which changes both the function signature and the order of terms as
> > > > well, is just a single add-on treewide patch.
> > >
> > > Is the plan for subsystem maintainers to pick up the relevant patches,
> > > and then do the treewide change one release cycle later?
> >
> > I'll try to keep the patches in a single tree (tip:x86/msr)
> > in the hope of not prolonging the pain two cycles - but it's
> > of course fine for maintainers to pick up the patches too
> > (most of them are standalone), we'll sort it all out in the end.
>
> Ingo, would you be fine with me posting patch updates just as replies to the
> original patch emails? This would speed things up, as I wouldn't need to wait
> for more review input of all the patches before sending out new versions.
Sure, that works for me too. I've picked up a couple of -v2 patches
already.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 5/6] configfs: Allow the registration of const struct configfs_attribute
From: Breno Leitao @ 2026-07-17 8:43 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Andreas Hindborg, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Matthew Brost,
Thomas Hellström, Rodrigo Vivi, David Airlie, Simona Vetter,
Dan Williams, Rafael J. Wysocki, Len Brown, rust-for-linux,
linux-kernel, intel-xe, dri-devel, linux-coco, linux-acpi
In-Reply-To: <20260716-configfs-const-base-v1-5-c545a4053cb5@weissschuh.net>
On Thu, Jul 16, 2026 at 07:09:30PM +0200, Thomas Weißschuh wrote:
> The attribute structure defined in driver code never need to be
> modified. Allow them to be marked as const.
>
> As there are many drivers which use these attributes, prepare for a
> phased transition by using a union of const and non-const attributes.
How many drivers need to be migrated? Isn't this a mechanism move?
^ permalink raw reply
* Re: [PATCH 6/6] samples: configfs: constify the configfs_attribute structures
From: Breno Leitao @ 2026-07-17 8:42 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Andreas Hindborg, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Matthew Brost,
Thomas Hellström, Rodrigo Vivi, David Airlie, Simona Vetter,
Dan Williams, Rafael J. Wysocki, Len Brown, rust-for-linux,
linux-kernel, intel-xe, dri-devel, linux-coco, linux-acpi
In-Reply-To: <20260716-configfs-const-base-v1-6-c545a4053cb5@weissschuh.net>
On Thu, Jul 16, 2026 at 07:09:31PM +0200, Thomas Weißschuh wrote:
> To show that the transition machinery works, constify the sample code.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Breno Leitao <leitao@debian.org>
^ permalink raw reply
* Re: [PATCH v2] x86/virt/tdx: Formalize SEAMCALL version encoding support
From: Nikolay Borisov @ 2026-07-17 8:21 UTC (permalink / raw)
To: Xu Yilun, Kiryl Shutsemau
Cc: Dave Hansen, x86, linux-kernel, rick.p.edgecombe, dave.hansen,
yilun.xu, chao.gao, djbw, linux-coco, peter.fang, xiaoyao.li
In-Reply-To: <almwGwoUzoA96XnG@yilunxu-OptiPlex-7050>
On 7/17/26 07:31, Xu Yilun wrote:
>>> struct tdx_module_args {
>>> union {
>>> u64 rax;
>>> struct {
>>> u16 function_nr;
>>> u8 version
>>> u8 padding0;
>>> u32 flags;
>>> };
>>> };
>>> u64 rcx;
>>> u64 rdx;
>>> ...
>>> }
>>
>> This union doesn't match the ABI it is supposed to represent.
>>
>> RAX is:
>>
>> 15:0 Leaf number
>> 23:16 Version number
>> 24 INTERRUPT_MODE
>> 62:25 Reserved
>> 63 P-SEAMLDR select
>>
>> In your layout INTERRUPT_MODE ends up somewhere in padding0 and the
>> P-SEAMLDR bit is BIT(31) of 'flags'. Nothing lines up with the spec.
>>
>> To describe the format properly the struct would need bitfields, and we
>> generally discourage bitfields for ABI-defined layouts. Without
>
> I agree that to describe each part of RAX clearly we need bitfields, and
> bitfields is not good for args.rax. So args.rax is not generally good
> to me, worse than a separate u64.
>
>> bitfields it degrades into masks and shifts on a u64 -- which is
>> exactly what composing 'fn' with a macro is. The union doesn't add
>> anything on top of that, it only hides where the bits are.
>
> [..]
>
>>> The truth of the matter is that 'fn' *IS* the RAX from the TDX ABI.
>>> We're carrying it around the kernel in that format, and it just doesn't
>>> work very well.
>>>
>>> The alternative is to carry the logical pieces of RAX around the kernel
>>> and them assemble RAX out of them in one (or very few) places. *Not* to
>>> build RAX in the TDX module ABI early far from the TDX module ABI layer
>>> itself.
>>
>> I don't see what delaying the assembly buys us.
>>
>> The SEAMCALL helper is where we decide what we want from the call: the
>> leaf, the version, the operands. Nothing below it adds information --
>> sc_retry() and __seamcall_dirty_cache() only retry on entropy failure
>> and track cache state. There is no layer further down that is in a
>> better position to compose RAX than the helper itself.
>>
>> And it is not "far from the TDX module ABI layer". The tdh_*() helpers
>> are the C representation of the ABI functions. They are the ABI layer.
>
> I wanna advance the progress, so if I have to choose I sort of like
> *args.version*, or even args.interrupt_mode in future. True this does
> not exactly match the registers' layout of TDX module ABI, but I also
> don't see big problems. Using fn instead of args.rax at the first place
> already shows we don't have to be too strictly aligned to ABI. We are
> defining SW APIs.
>
> To me the args.version scheme clearly defines 3 components that we want
> from SW POV:
>
> the leaf fn
> the version args.version
> the operands args.rcx
> ...
> args.r15
>
> The TDX module SPEC tells us each value of these components, we simply
> fill them in. No extra bit-or.
Just my .2 cent FWIW:
At the end of the day the layout of args is the software API that is
presented to the rest of the system, the ABI is a low level detail
handled in TDX_MODULE_CALL. Let's bury all the ugly handling in the asm
and present a simpler interface to the rest of the kernel
Exposing a raw representation of RAX is somewhat cumbersome because of
the reasons already listed so "converting" that to 3 variables in the
structure seems same to me.
<snip>
^ permalink raw reply
* Re: [PATCH 2/6] configfs: Constify is_visible/is_visible_bin in configfs_group_operations
From: Breno Leitao @ 2026-07-17 8:12 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Andreas Hindborg, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Matthew Brost,
Thomas Hellström, Rodrigo Vivi, David Airlie, Simona Vetter,
Dan Williams, Rafael J. Wysocki, Len Brown, rust-for-linux,
linux-kernel, intel-xe, dri-devel, linux-coco, linux-acpi
In-Reply-To: <20260716-configfs-const-base-v1-2-c545a4053cb5@weissschuh.net>
On Thu, Jul 16, 2026 at 07:09:27PM +0200, Thomas Weißschuh wrote:
> These callbacks are never meant to modify their configfs_attribute
> structure. Enforce this in the type system.
>
> As there are only two implementers of these callbacks, adapt them right
> away, avoiding a phased transition.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Breno Leitao <leitao@debian.org>
^ permalink raw reply
* Re: [PATCH v2] x86/virt/tdx: Formalize SEAMCALL version encoding support
From: Xu Yilun @ 2026-07-17 4:31 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: Dave Hansen, x86, linux-kernel, rick.p.edgecombe, dave.hansen,
yilun.xu, chao.gao, djbw, linux-coco, peter.fang, xiaoyao.li
In-Reply-To: <alSxrcseFHNrttoy@thinkstation>
> > struct tdx_module_args {
> > union {
> > u64 rax;
> > struct {
> > u16 function_nr;
> > u8 version
> > u8 padding0;
> > u32 flags;
> > };
> > };
> > u64 rcx;
> > u64 rdx;
> > ...
> > }
>
> This union doesn't match the ABI it is supposed to represent.
>
> RAX is:
>
> 15:0 Leaf number
> 23:16 Version number
> 24 INTERRUPT_MODE
> 62:25 Reserved
> 63 P-SEAMLDR select
>
> In your layout INTERRUPT_MODE ends up somewhere in padding0 and the
> P-SEAMLDR bit is BIT(31) of 'flags'. Nothing lines up with the spec.
>
> To describe the format properly the struct would need bitfields, and we
> generally discourage bitfields for ABI-defined layouts. Without
I agree that to describe each part of RAX clearly we need bitfields, and
bitfields is not good for args.rax. So args.rax is not generally good
to me, worse than a separate u64.
> bitfields it degrades into masks and shifts on a u64 -- which is
> exactly what composing 'fn' with a macro is. The union doesn't add
> anything on top of that, it only hides where the bits are.
[..]
> > The truth of the matter is that 'fn' *IS* the RAX from the TDX ABI.
> > We're carrying it around the kernel in that format, and it just doesn't
> > work very well.
> >
> > The alternative is to carry the logical pieces of RAX around the kernel
> > and them assemble RAX out of them in one (or very few) places. *Not* to
> > build RAX in the TDX module ABI early far from the TDX module ABI layer
> > itself.
>
> I don't see what delaying the assembly buys us.
>
> The SEAMCALL helper is where we decide what we want from the call: the
> leaf, the version, the operands. Nothing below it adds information --
> sc_retry() and __seamcall_dirty_cache() only retry on entropy failure
> and track cache state. There is no layer further down that is in a
> better position to compose RAX than the helper itself.
>
> And it is not "far from the TDX module ABI layer". The tdh_*() helpers
> are the C representation of the ABI functions. They are the ABI layer.
I wanna advance the progress, so if I have to choose I sort of like
*args.version*, or even args.interrupt_mode in future. True this does
not exactly match the registers' layout of TDX module ABI, but I also
don't see big problems. Using fn instead of args.rax at the first place
already shows we don't have to be too strictly aligned to ABI. We are
defining SW APIs.
To me the args.version scheme clearly defines 3 components that we want
from SW POV:
the leaf fn
the version args.version
the operands args.rcx
...
args.r15
The TDX module SPEC tells us each value of these components, we simply
fill them in. No extra bit-or.
>
> We also don't carry the pieces "around the kernel" today. The
> composition already happens in exactly one place -- a macro next to the
> leaf defines. Call sites don't open-code shifts.
>
> That said, I'm okay with RAX living in the struct as a plain u64
> instead of a separate 'fn' argument, if you prefer the structure to
> carry all the registers. But its composition should stay early, in the
> helper, where the decisions about the call are made:
>
> args.rax = TDH_VP_INIT | SEAMCALL_LEAF_VER(1);
This is the scheme that is most aligned with ABI layout. But I assume we
don't really see it worth the massive code churn, is it?
^ permalink raw reply
* Re: [PATCH 00/15] Device Evidence and Trust for PCI Security Protocol (TDISP)
From: Jason Gunthorpe @ 2026-07-16 18:51 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Dan Williams (nvidia), linux-coco, linux-pci, driver-core, ankita,
Aaron Tomlin, Alistair Francis, Aneesh Kumar K.V, Arnd Bergmann,
Bjorn Helgaas, Daniel Gomez, Danilo Krummrich, Dexuan Cui,
Donald Hunter, Greg Kroah-Hartman, Jakub Kicinski,
Luis Chamberlain, Lukas Wunner, Petr Pavlu, Rafael J. Wysocki,
Robin Murphy, Sami Tolvanen, Samuel Ortiz, Saravana Kannan,
Will Deacon, Xu Yilun
In-Reply-To: <0cc44c9e-fc2a-4c95-a574-de833117f6dc@amd.com>
On Wed, Jul 15, 2026 at 07:04:44PM +1000, Alexey Kardashevskiy wrote:
> On 9/7/26 23:36, Jason Gunthorpe wrote:
> > On Wed, Jul 08, 2026 at 07:45:09PM -0700, Dan Williams (nvidia) wrote:
> > > > force_dma_unencrypted() does not *prevent* device access to private
> > > > memory and provides no security properties on its own. It's only
> > > > purpose is to inform the DMA API what the HW restrictions are for
> > > > doing DMA.
> > >
> > > Right, to be clear, this mode's security properties come from never
> > > asking the TSM to enable private DMA while the device is in RUN.
> >
> > Ok, that's a twist I hadn't thought about. I don't see a reason to
> > support a driver probed with RUN but T=1 DMA disabled by the TSM.
>
> afaik you cannot have RUN and T=0 DMA at the same time.
Right, that's a great point. The devices we are making simply won't
do T=0 DMA once they are in RUN, I expect that to be the norm.
So if you disable T=1 DMA at the TSM then the device doesn't work
anymore because there was no standard way to tell the device it
shouldn't do T=1.
> I configure my hw to allow "accept" (== T=1 for DMA and MMIO) but
> still only allow unencrypted guest memory for DMA (set vTOM to 0 to
> say "all unencrypted) if the driver was loaded with "trust" other
> than "full" (and this series does not call the enable_dma() hook if
> not "full", Dan is changing it though) so the module parameter
> works...
Yeah, this would be an interesting configuration from the TSM -
support T=1 but change the T=1 translation so that only shared memory
is mapped. vTOM on AMD and other tricks on other arches.
But AFIAK this isn't generally supported so I'd just leave it out for
now.
> > I guess
> > - The active trust level should be RO visible to the driver, iommu, etc
> > It should be stable under a bound driver
> >
> > - The "dma require unencrypted" property needs to RO visible to the
> > DMA API and stable under a bound driver. This would input where
> > force_dma_unecrpyted() is in the flow [the name should align with
> > all the other per-device DMA API specific properties like seg
> > limit, boundary, mask, etc]
> >
> > - The requested trust policy should be internal to the driver core and
> > be converted to the active trust level right before probe
> >
> > - We should have ways to enable/disable all DMA before/after probe,
>
> "echo 1 > unlock" should do that (but also stops encrypted MMIO) or we want a finer knob?
You shouldn't be able to unlock while a driver is bind. I'm aruging we
should also be able to keep the device in run and block all DMA
through the TSM.
> > TSM is sensitive to accept, not the trust level
>
> This makes the module's "trust" parameter useless, right?
Yes, ideally it should act based on callbacks I think
Jason
^ permalink raw reply
* Re: [PATCH v8 09/46] KVM: guest_memfd: Introduce function to check GFN private/shared status
From: Ackerley Tng @ 2026-07-16 17:20 UTC (permalink / raw)
To: Binbin Wu
Cc: aik, andrew.jones, brauner, chao.p.peng, david, jmattson,
jthoughton, michael.roth, oupton, pankaj.gupta, qperret,
rick.p.edgecombe, rientjes, shivankg, steven.price, tabba, willy,
wyihan, yan.y.zhao, forkloop, pratyush, suzuki.poulose,
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, Barry Song, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Youngjun Park, Qi Zheng, Shakeel Butt, Kiryl Shutsemau,
Baoquan He, Jason Gunthorpe, Vlastimil Babka, kvm, linux-kernel,
linux-trace-kernel, linux-doc, linux-kselftest, linux-mm,
linux-coco
In-Reply-To: <1b59fec2-a464-4429-8532-880394912af5@linux.intel.com>
Binbin Wu <binbin.wu@linux.intel.com> writes:
> On 6/19/2026 8:31 AM, Ackerley Tng via B4 Relay wrote:
>> From: Ackerley Tng <ackerleytng@google.com>
>>
>> Introduce function for KVM to check the private/shared status of guest
> ^
> Nit: a
> > memory at a given GFN.
>>
For v9, I added the "a" in the commit messsage body but retained
"Introduce function" in the header (save characters, and make it sound
like a headline).
>>
>> [...snip...]
>>
^ permalink raw reply
* [PATCH 5/6] configfs: Allow the registration of const struct configfs_attribute
From: Thomas Weißschuh @ 2026-07-16 17:09 UTC (permalink / raw)
To: Andreas Hindborg, Breno Leitao, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Matthew Brost,
Thomas Hellström, Rodrigo Vivi, David Airlie, Simona Vetter,
Dan Williams, Rafael J. Wysocki, Len Brown
Cc: rust-for-linux, linux-kernel, intel-xe, dri-devel, linux-coco,
linux-acpi, Thomas Weißschuh
In-Reply-To: <20260716-configfs-const-base-v1-0-c545a4053cb5@weissschuh.net>
The attribute structure defined in driver code never need to be
modified. Allow them to be marked as const.
As there are many drivers which use these attributes, prepare for a
phased transition by using a union of const and non-const attributes.
After all drivers have been migrated to the const variant, the non-const
one can be replaced by the const one and the transition machinery will
be removed again.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
fs/configfs/dir.c | 4 ++--
include/linux/configfs.h | 5 ++++-
rust/kernel/configfs.rs | 8 ++++++--
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
index 9a5c2bc4065d..c2152288517c 100644
--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -632,8 +632,8 @@ static int populate_attrs(struct config_item *item)
ops = t->ct_group_ops;
- if (t->ct_attrs) {
- for (i = 0; (attr = t->ct_attrs[i]) != NULL; i++) {
+ if (t->ct_attrs_const) {
+ for (i = 0; (attr = t->ct_attrs_const[i]) != NULL; i++) {
if (ops && ops->is_visible && !ops->is_visible(item, attr, i))
continue;
diff --git a/include/linux/configfs.h b/include/linux/configfs.h
index eff2fb22ab70..5bead9173ec1 100644
--- a/include/linux/configfs.h
+++ b/include/linux/configfs.h
@@ -66,7 +66,10 @@ struct config_item_type {
struct module *ct_owner;
const struct configfs_item_operations *ct_item_ops;
const struct configfs_group_operations *ct_group_ops;
- struct configfs_attribute **ct_attrs;
+ union {
+ struct configfs_attribute **ct_attrs;
+ const struct configfs_attribute *const *ct_attrs_const;
+ };
const struct configfs_bin_attribute *const *ct_bin_attrs;
};
diff --git a/rust/kernel/configfs.rs b/rust/kernel/configfs.rs
index f99a6e376fa3..2ef9cce693b9 100644
--- a/rust/kernel/configfs.rs
+++ b/rust/kernel/configfs.rs
@@ -756,7 +756,9 @@ pub const fn new_with_child_ctor<const N: usize, Child>(
ct_owner: owner.as_ptr(),
ct_group_ops: GroupOperationsVTable::<Data, Child>::vtable_ptr(),
ct_item_ops: ItemOperationsVTable::<$tpe, Data>::vtable_ptr(),
- ct_attrs: core::ptr::from_ref(attributes).cast_mut().cast(),
+ __bindgen_anon_1: bindings::config_item_type__bindgen_ty_1 {
+ ct_attrs_const: core::ptr::from_ref(attributes).cast(),
+ },
ct_bin_attrs: core::ptr::null(),
}),
_p: PhantomData,
@@ -773,7 +775,9 @@ pub const fn new<const N: usize>(
ct_owner: owner.as_ptr(),
ct_group_ops: core::ptr::null(),
ct_item_ops: ItemOperationsVTable::<$tpe, Data>::vtable_ptr(),
- ct_attrs: core::ptr::from_ref(attributes).cast_mut().cast(),
+ __bindgen_anon_1: bindings::config_item_type__bindgen_ty_1 {
+ ct_attrs_const: core::ptr::from_ref(attributes).cast(),
+ },
ct_bin_attrs: core::ptr::null(),
}),
_p: PhantomData,
--
2.55.0
^ permalink raw reply related
* [PATCH 6/6] samples: configfs: constify the configfs_attribute structures
From: Thomas Weißschuh @ 2026-07-16 17:09 UTC (permalink / raw)
To: Andreas Hindborg, Breno Leitao, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Matthew Brost,
Thomas Hellström, Rodrigo Vivi, David Airlie, Simona Vetter,
Dan Williams, Rafael J. Wysocki, Len Brown
Cc: rust-for-linux, linux-kernel, intel-xe, dri-devel, linux-coco,
linux-acpi, Thomas Weißschuh
In-Reply-To: <20260716-configfs-const-base-v1-0-c545a4053cb5@weissschuh.net>
To show that the transition machinery works, constify the sample code.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
samples/configfs/configfs_sample.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/samples/configfs/configfs_sample.c b/samples/configfs/configfs_sample.c
index c1b108ec4ea0..9788ec9b8e30 100644
--- a/samples/configfs/configfs_sample.c
+++ b/samples/configfs/configfs_sample.c
@@ -84,7 +84,7 @@ CONFIGFS_ATTR_RO(childless_, showme);
CONFIGFS_ATTR(childless_, storeme);
CONFIGFS_ATTR_RO(childless_, description);
-static struct configfs_attribute *childless_attrs[] = {
+static const struct configfs_attribute *const childless_attrs[] = {
&childless_attr_showme,
&childless_attr_storeme,
&childless_attr_description,
@@ -92,7 +92,7 @@ static struct configfs_attribute *childless_attrs[] = {
};
static const struct config_item_type childless_type = {
- .ct_attrs = childless_attrs,
+ .ct_attrs_const = childless_attrs,
.ct_owner = THIS_MODULE,
};
@@ -148,7 +148,7 @@ static ssize_t simple_child_storeme_store(struct config_item *item,
CONFIGFS_ATTR(simple_child_, storeme);
-static struct configfs_attribute *simple_child_attrs[] = {
+static const struct configfs_attribute *const simple_child_attrs[] = {
&simple_child_attr_storeme,
NULL,
};
@@ -164,7 +164,7 @@ static const struct configfs_item_operations simple_child_item_ops = {
static const struct config_item_type simple_child_type = {
.ct_item_ops = &simple_child_item_ops,
- .ct_attrs = simple_child_attrs,
+ .ct_attrs_const = simple_child_attrs,
.ct_owner = THIS_MODULE,
};
@@ -205,7 +205,7 @@ static ssize_t simple_children_description_show(struct config_item *item,
CONFIGFS_ATTR_RO(simple_children_, description);
-static struct configfs_attribute *simple_children_attrs[] = {
+static const struct configfs_attribute *const simple_children_attrs[] = {
&simple_children_attr_description,
NULL,
};
@@ -230,7 +230,7 @@ static const struct configfs_group_operations simple_children_group_ops = {
static const struct config_item_type simple_children_type = {
.ct_item_ops = &simple_children_item_ops,
.ct_group_ops = &simple_children_group_ops,
- .ct_attrs = simple_children_attrs,
+ .ct_attrs_const = simple_children_attrs,
.ct_owner = THIS_MODULE,
};
@@ -283,7 +283,7 @@ static ssize_t group_children_description_show(struct config_item *item,
CONFIGFS_ATTR_RO(group_children_, description);
-static struct configfs_attribute *group_children_attrs[] = {
+static const struct configfs_attribute *const group_children_attrs[] = {
&group_children_attr_description,
NULL,
};
@@ -298,7 +298,7 @@ static const struct configfs_group_operations group_children_group_ops = {
static const struct config_item_type group_children_type = {
.ct_group_ops = &group_children_group_ops,
- .ct_attrs = group_children_attrs,
+ .ct_attrs_const = group_children_attrs,
.ct_owner = THIS_MODULE,
};
--
2.55.0
^ permalink raw reply related
* [PATCH 2/6] configfs: Constify is_visible/is_visible_bin in configfs_group_operations
From: Thomas Weißschuh @ 2026-07-16 17:09 UTC (permalink / raw)
To: Andreas Hindborg, Breno Leitao, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Matthew Brost,
Thomas Hellström, Rodrigo Vivi, David Airlie, Simona Vetter,
Dan Williams, Rafael J. Wysocki, Len Brown
Cc: rust-for-linux, linux-kernel, intel-xe, dri-devel, linux-coco,
linux-acpi, Thomas Weißschuh
In-Reply-To: <20260716-configfs-const-base-v1-0-c545a4053cb5@weissschuh.net>
These callbacks are never meant to modify their configfs_attribute
structure. Enforce this in the type system.
As there are only two implementers of these callbacks, adapt them right
away, avoiding a phased transition.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
drivers/gpu/drm/xe/xe_configfs.c | 4 ++--
drivers/virt/coco/guest/report.c | 4 ++--
include/linux/configfs.h | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_configfs.c b/drivers/gpu/drm/xe/xe_configfs.c
index 32102600a148..a5f696e7b329 100644
--- a/drivers/gpu/drm/xe/xe_configfs.c
+++ b/drivers/gpu/drm/xe/xe_configfs.c
@@ -843,7 +843,7 @@ static struct configfs_item_operations xe_config_device_ops = {
};
static bool xe_config_device_is_visible(struct config_item *item,
- struct configfs_attribute *attr, int n)
+ const struct configfs_attribute *attr, int n)
{
struct xe_config_group_device *dev = to_xe_config_group_device(item);
@@ -938,7 +938,7 @@ static struct configfs_attribute *xe_config_sriov_attrs[] = {
};
static bool xe_config_sriov_is_visible(struct config_item *item,
- struct configfs_attribute *attr, int n)
+ const struct configfs_attribute *attr, int n)
{
struct xe_config_group_device *dev = to_xe_config_group_device(item->ci_parent);
diff --git a/drivers/virt/coco/guest/report.c b/drivers/virt/coco/guest/report.c
index b254a1416286..96e89ddf4989 100644
--- a/drivers/virt/coco/guest/report.c
+++ b/drivers/virt/coco/guest/report.c
@@ -381,7 +381,7 @@ static struct configfs_item_operations tsm_report_item_ops = {
};
static bool tsm_report_is_visible(struct config_item *item,
- struct configfs_attribute *attr, int n)
+ const struct configfs_attribute *attr, int n)
{
guard(rwsem_read)(&tsm_rwsem);
if (!provider.ops)
@@ -394,7 +394,7 @@ static bool tsm_report_is_visible(struct config_item *item,
}
static bool tsm_report_is_bin_visible(struct config_item *item,
- struct configfs_bin_attribute *attr, int n)
+ const struct configfs_bin_attribute *attr, int n)
{
guard(rwsem_read)(&tsm_rwsem);
if (!provider.ops)
diff --git a/include/linux/configfs.h b/include/linux/configfs.h
index ef65c75beeaa..5d3fc8822a1d 100644
--- a/include/linux/configfs.h
+++ b/include/linux/configfs.h
@@ -220,8 +220,8 @@ struct configfs_group_operations {
struct config_group *(*make_group)(struct config_group *group, const char *name);
void (*disconnect_notify)(struct config_group *group, struct config_item *item);
void (*drop_item)(struct config_group *group, struct config_item *item);
- bool (*is_visible)(struct config_item *item, struct configfs_attribute *attr, int n);
- bool (*is_bin_visible)(struct config_item *item, struct configfs_bin_attribute *attr,
+ bool (*is_visible)(struct config_item *item, const struct configfs_attribute *attr, int n);
+ bool (*is_bin_visible)(struct config_item *item, const struct configfs_bin_attribute *attr,
int n);
};
--
2.55.0
^ permalink raw reply related
* [PATCH 4/6] configfs: Constify configfs_bin_attribute
From: Thomas Weißschuh @ 2026-07-16 17:09 UTC (permalink / raw)
To: Andreas Hindborg, Breno Leitao, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Matthew Brost,
Thomas Hellström, Rodrigo Vivi, David Airlie, Simona Vetter,
Dan Williams, Rafael J. Wysocki, Len Brown
Cc: rust-for-linux, linux-kernel, intel-xe, dri-devel, linux-coco,
linux-acpi, Thomas Weißschuh
In-Reply-To: <20260716-configfs-const-base-v1-0-c545a4053cb5@weissschuh.net>
The configfs_bin_attribute structures defined by driver are never
modified. Make them const.
As there are only two users of these attributes, adapt them in the same
commit to avoid a phased transition.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
drivers/acpi/acpi_configfs.c | 2 +-
drivers/virt/coco/guest/report.c | 2 +-
include/linux/configfs.h | 64 ++++++++++++++++++++--------------------
rust/kernel/configfs.rs | 4 +--
4 files changed, 36 insertions(+), 36 deletions(-)
diff --git a/drivers/acpi/acpi_configfs.c b/drivers/acpi/acpi_configfs.c
index 12ffec795803..6071699c7165 100644
--- a/drivers/acpi/acpi_configfs.c
+++ b/drivers/acpi/acpi_configfs.c
@@ -91,7 +91,7 @@ static ssize_t acpi_table_aml_read(struct config_item *cfg,
CONFIGFS_BIN_ATTR(acpi_table_, aml, NULL, MAX_ACPI_TABLE_SIZE);
-static struct configfs_bin_attribute *acpi_table_bin_attrs[] = {
+static const struct configfs_bin_attribute *const acpi_table_bin_attrs[] = {
&acpi_table_attr_aml,
NULL,
};
diff --git a/drivers/virt/coco/guest/report.c b/drivers/virt/coco/guest/report.c
index 96e89ddf4989..ad400fbe53f0 100644
--- a/drivers/virt/coco/guest/report.c
+++ b/drivers/virt/coco/guest/report.c
@@ -356,7 +356,7 @@ static struct configfs_attribute *tsm_report_attrs[] = {
NULL,
};
-static struct configfs_bin_attribute *tsm_report_bin_attrs[] = {
+static const struct configfs_bin_attribute *const tsm_report_bin_attrs[] = {
[TSM_REPORT_INBLOB] = &tsm_report_attr_inblob,
[TSM_REPORT_OUTBLOB] = &tsm_report_attr_outblob,
[TSM_REPORT_AUXBLOB] = &tsm_report_attr_auxblob,
diff --git a/include/linux/configfs.h b/include/linux/configfs.h
index 5d3fc8822a1d..eff2fb22ab70 100644
--- a/include/linux/configfs.h
+++ b/include/linux/configfs.h
@@ -67,7 +67,7 @@ struct config_item_type {
const struct configfs_item_operations *ct_item_ops;
const struct configfs_group_operations *ct_group_ops;
struct configfs_attribute **ct_attrs;
- struct configfs_bin_attribute **ct_bin_attrs;
+ const struct configfs_bin_attribute *const *ct_bin_attrs;
};
/**
@@ -160,41 +160,41 @@ struct configfs_bin_attribute {
ssize_t (*write)(struct config_item *, const void *, size_t);
};
-#define CONFIGFS_BIN_ATTR(_pfx, _name, _priv, _maxsz) \
-static struct configfs_bin_attribute _pfx##attr_##_name = { \
- .cb_attr = { \
- .ca_name = __stringify(_name), \
- .ca_mode = S_IRUGO | S_IWUSR, \
- .ca_owner = THIS_MODULE, \
- }, \
- .cb_private = _priv, \
- .cb_max_size = _maxsz, \
- .read = _pfx##_name##_read, \
- .write = _pfx##_name##_write, \
+#define CONFIGFS_BIN_ATTR(_pfx, _name, _priv, _maxsz) \
+static const struct configfs_bin_attribute _pfx##attr_##_name = { \
+ .cb_attr = { \
+ .ca_name = __stringify(_name), \
+ .ca_mode = S_IRUGO | S_IWUSR, \
+ .ca_owner = THIS_MODULE, \
+ }, \
+ .cb_private = _priv, \
+ .cb_max_size = _maxsz, \
+ .read = _pfx##_name##_read, \
+ .write = _pfx##_name##_write, \
}
-#define CONFIGFS_BIN_ATTR_RO(_pfx, _name, _priv, _maxsz) \
-static struct configfs_bin_attribute _pfx##attr_##_name = { \
- .cb_attr = { \
- .ca_name = __stringify(_name), \
- .ca_mode = S_IRUGO, \
- .ca_owner = THIS_MODULE, \
- }, \
- .cb_private = _priv, \
- .cb_max_size = _maxsz, \
- .read = _pfx##_name##_read, \
+#define CONFIGFS_BIN_ATTR_RO(_pfx, _name, _priv, _maxsz) \
+static const struct configfs_bin_attribute _pfx##attr_##_name = { \
+ .cb_attr = { \
+ .ca_name = __stringify(_name), \
+ .ca_mode = S_IRUGO, \
+ .ca_owner = THIS_MODULE, \
+ }, \
+ .cb_private = _priv, \
+ .cb_max_size = _maxsz, \
+ .read = _pfx##_name##_read, \
}
-#define CONFIGFS_BIN_ATTR_WO(_pfx, _name, _priv, _maxsz) \
-static struct configfs_bin_attribute _pfx##attr_##_name = { \
- .cb_attr = { \
- .ca_name = __stringify(_name), \
- .ca_mode = S_IWUSR, \
- .ca_owner = THIS_MODULE, \
- }, \
- .cb_private = _priv, \
- .cb_max_size = _maxsz, \
- .write = _pfx##_name##_write, \
+#define CONFIGFS_BIN_ATTR_WO(_pfx, _name, _priv, _maxsz) \
+static const struct configfs_bin_attribute _pfx##attr_##_name = { \
+ .cb_attr = { \
+ .ca_name = __stringify(_name), \
+ .ca_mode = S_IWUSR, \
+ .ca_owner = THIS_MODULE, \
+ }, \
+ .cb_private = _priv, \
+ .cb_max_size = _maxsz, \
+ .write = _pfx##_name##_write, \
}
/*
diff --git a/rust/kernel/configfs.rs b/rust/kernel/configfs.rs
index b33fb2e9adf1..f99a6e376fa3 100644
--- a/rust/kernel/configfs.rs
+++ b/rust/kernel/configfs.rs
@@ -757,7 +757,7 @@ pub const fn new_with_child_ctor<const N: usize, Child>(
ct_group_ops: GroupOperationsVTable::<Data, Child>::vtable_ptr(),
ct_item_ops: ItemOperationsVTable::<$tpe, Data>::vtable_ptr(),
ct_attrs: core::ptr::from_ref(attributes).cast_mut().cast(),
- ct_bin_attrs: core::ptr::null_mut(),
+ ct_bin_attrs: core::ptr::null(),
}),
_p: PhantomData,
}
@@ -774,7 +774,7 @@ pub const fn new<const N: usize>(
ct_group_ops: core::ptr::null(),
ct_item_ops: ItemOperationsVTable::<$tpe, Data>::vtable_ptr(),
ct_attrs: core::ptr::from_ref(attributes).cast_mut().cast(),
- ct_bin_attrs: core::ptr::null_mut(),
+ ct_bin_attrs: core::ptr::null(),
}),
_p: PhantomData,
}
--
2.55.0
^ permalink raw reply related
* [PATCH 3/6] configfs: Treat attribute structures as const internally
From: Thomas Weißschuh @ 2026-07-16 17:09 UTC (permalink / raw)
To: Andreas Hindborg, Breno Leitao, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Matthew Brost,
Thomas Hellström, Rodrigo Vivi, David Airlie, Simona Vetter,
Dan Williams, Rafael J. Wysocki, Len Brown
Cc: rust-for-linux, linux-kernel, intel-xe, dri-devel, linux-coco,
linux-acpi, Thomas Weißschuh
In-Reply-To: <20260716-configfs-const-base-v1-0-c545a4053cb5@weissschuh.net>
The configfs core never modifies the attribute structures defined in
driver core.
Reflect this in the types used internally in the configfs core.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
fs/configfs/configfs_internal.h | 10 +++++-----
fs/configfs/dir.c | 6 +++---
fs/configfs/file.c | 6 +++---
fs/configfs/inode.c | 2 +-
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/fs/configfs/configfs_internal.h b/fs/configfs/configfs_internal.h
index acdeea8e2d69..4bc19cd8d666 100644
--- a/fs/configfs/configfs_internal.h
+++ b/fs/configfs/configfs_internal.h
@@ -104,17 +104,17 @@ static inline struct config_item * to_item(struct dentry * dentry)
return ((struct config_item *) sd->s_element);
}
-static inline struct configfs_attribute * to_attr(struct dentry * dentry)
+static inline const struct configfs_attribute * to_attr(struct dentry * dentry)
{
struct configfs_dirent * sd = dentry->d_fsdata;
- return ((struct configfs_attribute *) sd->s_element);
+ return ((const struct configfs_attribute *) sd->s_element);
}
-static inline struct configfs_bin_attribute *to_bin_attr(struct dentry *dentry)
+static inline const struct configfs_bin_attribute *to_bin_attr(struct dentry *dentry)
{
- struct configfs_attribute *attr = to_attr(dentry);
+ const struct configfs_attribute *attr = to_attr(dentry);
- return container_of(attr, struct configfs_bin_attribute, cb_attr);
+ return container_of_const(attr, struct configfs_bin_attribute, cb_attr);
}
static inline struct config_item *configfs_get_config_item(struct dentry *dentry)
diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
index 3c88f13f1ca2..9a5c2bc4065d 100644
--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -461,7 +461,7 @@ static struct dentry * configfs_lookup(struct inode *dir,
*/
if ((sd->s_type & CONFIGFS_NOT_PINNED) &&
!strcmp(configfs_get_name(sd), dentry->d_name.name)) {
- struct configfs_attribute *attr = sd->s_element;
+ const struct configfs_attribute *attr = sd->s_element;
umode_t mode = (attr->ca_mode & S_IALLUGO) | S_IFREG;
dentry->d_fsdata = configfs_get(sd);
@@ -622,8 +622,8 @@ static int populate_attrs(struct config_item *item)
{
const struct config_item_type *t = item->ci_type;
const struct configfs_group_operations *ops;
- struct configfs_attribute *attr;
- struct configfs_bin_attribute *bin_attr;
+ const struct configfs_attribute *attr;
+ const struct configfs_bin_attribute *bin_attr;
int error = 0;
int i;
diff --git a/fs/configfs/file.c b/fs/configfs/file.c
index a48cece775a3..6460b000c593 100644
--- a/fs/configfs/file.c
+++ b/fs/configfs/file.c
@@ -41,8 +41,8 @@ struct configfs_buffer {
struct config_item *item;
struct module *owner;
union {
- struct configfs_attribute *attr;
- struct configfs_bin_attribute *bin_attr;
+ const struct configfs_attribute *attr;
+ const struct configfs_bin_attribute *bin_attr;
};
};
@@ -291,7 +291,7 @@ static int __configfs_open_file(struct inode *inode, struct file *file, int type
{
struct dentry *dentry = file->f_path.dentry;
struct configfs_fragment *frag = to_frag(file);
- struct configfs_attribute *attr;
+ const struct configfs_attribute *attr;
struct configfs_buffer *buffer;
int error;
diff --git a/fs/configfs/inode.c b/fs/configfs/inode.c
index 68290fe0e374..69f1f24e890f 100644
--- a/fs/configfs/inode.c
+++ b/fs/configfs/inode.c
@@ -178,7 +178,7 @@ struct inode *configfs_create(struct dentry *dentry, umode_t mode)
*/
const unsigned char * configfs_get_name(struct configfs_dirent *sd)
{
- struct configfs_attribute *attr;
+ const struct configfs_attribute *attr;
BUG_ON(!sd || !sd->s_element);
--
2.55.0
^ permalink raw reply related
* [PATCH 1/6] rust: configfs: remove mutability from some field initializers
From: Thomas Weißschuh @ 2026-07-16 17:09 UTC (permalink / raw)
To: Andreas Hindborg, Breno Leitao, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Matthew Brost,
Thomas Hellström, Rodrigo Vivi, David Airlie, Simona Vetter,
Dan Williams, Rafael J. Wysocki, Len Brown
Cc: rust-for-linux, linux-kernel, intel-xe, dri-devel, linux-coco,
linux-acpi, Thomas Weißschuh
In-Reply-To: <20260716-configfs-const-base-v1-0-c545a4053cb5@weissschuh.net>
These fields do not require mutable pointers.
Use regular immutable ones.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
rust/kernel/configfs.rs | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/rust/kernel/configfs.rs b/rust/kernel/configfs.rs
index 2339c6467325..b33fb2e9adf1 100644
--- a/rust/kernel/configfs.rs
+++ b/rust/kernel/configfs.rs
@@ -754,8 +754,8 @@ pub const fn new_with_child_ctor<const N: usize, Child>(
Self {
item_type: Opaque::new(bindings::config_item_type {
ct_owner: owner.as_ptr(),
- ct_group_ops: GroupOperationsVTable::<Data, Child>::vtable_ptr().cast_mut(),
- ct_item_ops: ItemOperationsVTable::<$tpe, Data>::vtable_ptr().cast_mut(),
+ ct_group_ops: GroupOperationsVTable::<Data, Child>::vtable_ptr(),
+ ct_item_ops: ItemOperationsVTable::<$tpe, Data>::vtable_ptr(),
ct_attrs: core::ptr::from_ref(attributes).cast_mut().cast(),
ct_bin_attrs: core::ptr::null_mut(),
}),
@@ -771,8 +771,8 @@ pub const fn new<const N: usize>(
Self {
item_type: Opaque::new(bindings::config_item_type {
ct_owner: owner.as_ptr(),
- ct_group_ops: core::ptr::null_mut(),
- ct_item_ops: ItemOperationsVTable::<$tpe, Data>::vtable_ptr().cast_mut(),
+ ct_group_ops: core::ptr::null(),
+ ct_item_ops: ItemOperationsVTable::<$tpe, Data>::vtable_ptr(),
ct_attrs: core::ptr::from_ref(attributes).cast_mut().cast(),
ct_bin_attrs: core::ptr::null_mut(),
}),
--
2.55.0
^ permalink raw reply related
* [PATCH 0/6] configfs: Allow the registration of const struct configfs_attribute
From: Thomas Weißschuh @ 2026-07-16 17:09 UTC (permalink / raw)
To: Andreas Hindborg, Breno Leitao, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Matthew Brost,
Thomas Hellström, Rodrigo Vivi, David Airlie, Simona Vetter,
Dan Williams, Rafael J. Wysocki, Len Brown
Cc: rust-for-linux, linux-kernel, intel-xe, dri-devel, linux-coco,
linux-acpi, Thomas Weißschuh
The attribute structure defined in driver code never need to be
modified. Allow them to be marked as const.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
Thomas Weißschuh (6):
rust: configfs: remove mutability from some field initializers
configfs: Constify is_visible/is_visible_bin in configfs_group_operations
configfs: Treat attribute structures as const internally
configfs: Constify configfs_bin_attribute
configfs: Allow the registration of const struct configfs_attribute
samples: configfs: constify the configfs_attribute structures
drivers/acpi/acpi_configfs.c | 2 +-
drivers/gpu/drm/xe/xe_configfs.c | 4 +--
drivers/virt/coco/guest/report.c | 6 ++--
fs/configfs/configfs_internal.h | 10 +++---
fs/configfs/dir.c | 10 +++---
fs/configfs/file.c | 6 ++--
fs/configfs/inode.c | 2 +-
include/linux/configfs.h | 73 ++++++++++++++++++++------------------
rust/kernel/configfs.rs | 20 ++++++-----
samples/configfs/configfs_sample.c | 16 ++++-----
10 files changed, 78 insertions(+), 71 deletions(-)
---
base-commit: c8d07eca6270b3f41c0e528a470895f1bd42e2b7
change-id: 20260716-configfs-const-base-6955b043560b
Best regards,
--
Thomas Weißschuh <linux@weissschuh.net>
^ 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