summaryrefslogtreecommitdiff
path: root/io_uring/opdef.h
diff options
context:
space:
mode:
authorJoerg Roedel <jroedel@suse.de>2023-01-25 13:54:58 +0300
committerJoerg Roedel <jroedel@suse.de>2023-01-25 13:54:58 +0300
commitff489fe002ab20daf0985f119682474cfda83496 (patch)
treeee367a7703f1570680524e4fc6dafc7e11a0bc09 /io_uring/opdef.h
parent5cef282e295f7cf623672470d040716d1e3eacf2 (diff)
parent429f27e36874e34727a1f8495be2ea3a7060732c (diff)
downloadlinux-ff489fe002ab20daf0985f119682474cfda83496.tar.xz
Merge branch 'iommu-memory-accounting' into core
Merge patch-set from Jason: "Let iommufd charge IOPTE allocations to the memory cgroup" Description: IOMMUFD follows the same design as KVM and uses memory cgroups to limit the amount of kernel memory a iommufd file descriptor can pin down. The various internal data structures already use GFP_KERNEL_ACCOUNT to charge its own memory. However, one of the biggest consumers of kernel memory is the IOPTEs stored under the iommu_domain and these allocations are not tracked. This series is the first step in fixing it. The iommu driver contract already includes a 'gfp' argument to the map_pages op, allowing iommufd to specify GFP_KERNEL_ACCOUNT and then having the driver allocate the IOPTE tables with that flag will capture a significant amount of the allocations. Update the iommu_map() API to pass in the GFP argument, and fix all call sites. Replace iommu_map_atomic(). Audit the "enterprise" iommu drivers to make sure they do the right thing. Intel and S390 ignore the GFP argument and always use GFP_ATOMIC. This is problematic for iommufd anyhow, so fix it. AMD and ARM SMMUv2/3 are already correct. A follow up series will be needed to capture the allocations made when the iommu_domain itself is allocated, which will complete the job. Link: https://lore.kernel.org/linux-iommu/0-v3-76b587fe28df+6e3-iommu_map_gfp_jgg@nvidia.com/
Diffstat (limited to 'io_uring/opdef.h')
0 files changed, 0 insertions, 0 deletions