On 10/27/26 03:15, Karl Mehltretter wrote:
> On Mon, Oct 26, 2026 at 04:36:14PM +0100, Alistair Popple wrote:
>
> Testing the series on a Jetson Nano exposed this path. A 3 MiB system-heap
> buffer was imported into Tegra DRM and scanned out over HDMI. With
> CONFIG_DMABUF_DEBUG=y the PRIME import succeeded, but scanout immediately
> produced display SMMU faults starting at 0x300000.
>
> Tracing the fault led here:
>
>> @@ -475,7 +475,7 @@ static struct tegra_bo *tegra_bo_import(struct drm_device *drm,
>> * domain, map it first to the DRM device to get an sgt.
>> */
>> if (tegra->domain) {
>> - attach = dma_buf_attach(buf, drm->dev);
>> + attach = dma_buf_sgt_attach(buf, drm->dev);
>
> tegra_bo_import() passes the attachment SGT to iommu_map_sgtable(), which
> uses sg_phys() and sg->length. The SGT mapping contract only guarantees the
> DMA address and length fields. The debug wrapper clears the page-side fields,
> so iommu_map_sgtable() maps zero bytes.
>
> Tegra only treats negative returns as errors and keeps the reserved
> IOVA, which scanout then faults on.
>
> This page-side use predates the series, so the fault is not itself a v2
> regression. Is dma_buf_sgt_attach() valid for this call site, or does Tegra
> need a page/physical mapping type first?
Sharing page/physical to be used with the IOMMU functions through DMA-buf is an absolutely hard NAK from my side.
We still need to figure out how to do this between KVM, IOMMUFD and virtio so that it is limited to only those three.
Regards,
Christian.
>
> Karl
On Mon, Oct 26, 2026 at 11:51:11AM +0530, Jayant Shekhar wrote:
> DCP platforms place the display pipeline under firmware control, so Linux
What is a DCP platform?
> cannot discover display resources through direct register access. The DRM
> driver therefore needs device-tree descriptions of the Qualcomm transport
> wrapper, display topology, IOMMU contexts, and panel connections.
>
> Add bindings for the Qualcomm DCP transport wrapper and VirtIO display
> subsystem. Document the IPCC power-notify resources, transport and
> framebuffer IOMMU contexts, firmware-visible IOVA range, INTF graph, and
> DSI panel connections. The wrapper creates a standard VirtIO-MMIO child
> after the IPCC power-notify sequence has completed.
It's still DT for real hardware, so I wonder why no SoC specific
compatibles were used.
Best regards,
Krzysztof
On Mon, 26 Oct 2026 11:51:11 +0530, Jayant Shekhar wrote:
> DCP platforms place the display pipeline under firmware control, so Linux
> cannot discover display resources through direct register access. The DRM
> driver therefore needs device-tree descriptions of the Qualcomm transport
> wrapper, display topology, IOMMU contexts, and panel connections.
>
> Add bindings for the Qualcomm DCP transport wrapper and VirtIO display
> subsystem. Document the IPCC power-notify resources, transport and
> framebuffer IOMMU contexts, firmware-visible IOVA range, INTF graph, and
> DSI panel connections. The wrapper creates a standard VirtIO-MMIO child
> after the IPCC power-notify sequence has completed.
>
> Assisted-by: LLM
> Signed-off-by: Jayant Shekhar <jayant.shekhar(a)oss.qualcomm.com>
> ---
> .../bindings/display/msm/qcom,dcp-dsi.yaml | 79 ++++++++++++
> .../devicetree/bindings/display/msm/qcom,dcp.yaml | 123 +++++++++++++++++++
> .../bindings/virtio/qcom,dcp-virtio.yaml | 132 +++++++++++++++++++++
> 3 files changed, 334 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/virtio/qcom,dcp-virtio.yaml: iommu-ranges: multiple incompatible types: uint32-array
/usr/local/lib/python3.13/dist-packages/dtschema/schemas/iommu/iommu.yaml: iommu-ranges: multiple incompatible types: uint32-matrix
Could not decode node virtio@9be8000 property iommu-ranges with value b'\x00\x00\x00\x00\x84\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00'
Traceback (most recent call last):
File "/usr/local/bin/dt-validate", line 8, in <module>
sys.exit(main())
~~~~^^
File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb_validate.py", line 443, in main
dtb_diagnostics = sg.check_dtb(filename)
File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb_validate.py", line 331, in check_dtb
dt = self.validator.decode_dtb(f.read(), decode_errors)
File "/usr/local/lib/python3.13/dist-packages/dtschema/validator.py", line 631, in decode_dtb
return [dtschema.dtb.fdt_unflatten(self, dtb)]
~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb.py", line 591, in fdt_unflatten
dt = fdt_scan_node(validator, fdt, '/', offset)
File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb.py", line 320, in fdt_scan_node
node = fdt_scan_node(validator, fdt, nodename, offset)
File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb.py", line 320, in fdt_scan_node
node = fdt_scan_node(validator, fdt, nodename, offset)
File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb.py", line 312, in fdt_scan_node
node_dict = node_props(validator, fdt, nodename, offset)
File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb.py", line 258, in node_props
props_dict[p.name] = prop_value(validator, nodename, p)
~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb.py", line 185, in prop_value
if len(p) / type_format[fmt].size >= min_dim:
~~~~~~~~~~~^^^^^
KeyError: 'uint32-array'
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20261026-jshekhar-dcp…
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
This series adds memory cgroup accounting for dma-buf allocations,
building on T.J. Mercier's earlier series [1] and incorporating
feedback from the v1 and LPC discussions.
Patch 1 introduces the MEMCG_DMABUF stat and charge/uncharge helpers.
Rather than charging at the page level via __GFP_ACCOUNT (which would
require every dma-buf exporter to implement charging, and makes
cross-cgroup transfer impractical without access to backing pages),
we track charges externally on struct dma_buf via a MEMCG_DMABUF stat
counter and route all accounting through a single path, removing the
__GFP_ACCOUNT flag from system-heap allocations to avoid double
counting.
Patch 2 adds a charge_fd field to DMA_HEAP_IOCTL_ALLOC, accepting
either a pidfd or a cgroupfd to identify the target cgroup at
allocation time. If the target cgroup cannot accommodate the charge,
the allocation returns -ENOMEM.
Patches 3-4 add LSM hooks for the two charge_fd flavours:
security_dma_buf_charge_task() gates the pidfd path (target
identified by task credentials) and security_dma_buf_charge_cgroup()
gates the cgroupfd path (target identified by cgroup directory label).
Patches 5-6 implement the SELinux side under a dma_buf object class
with charge_task and charge_cgroup permissions. For charge_cgroup,
the target SID is derived from the cgroup directory's SELinux label.
Patch 7 adds DMA_BUF_IOCTL_XFER_CHARGE, a general ioctl on any
dma-buf fd to transfer charges (or charge) post-allocation. This
covers the double-hop allocator case (SurfaceFlinger -> gralloc) and
works for buffers from any exporter (DRM, V4L2, etc.). If the
receiving cgroup lacks capacity for the charge, the ioctl returns
-ENOMEM and the original charge is preserved.
Patch 8 adds selftests.
Known limitations:
- Single-owner model: a dma-buf carries one memcg charge regardless
of how many processes share it.
- Only memcg accounting. CMA heaps would additionally need dmem
controller integration.
- Charging CMA-backed heaps to memcg charges unreclaimable memory:
when a cgroup hits its limit, try_charge_memcg() may trigger a
reclaim pass that cannot free CMA pages. A future version could
move charging into per-heap callbacks.
- If a transfer of an uncharged buffer fails, the buffer remains
uncharged. The allocator (userspace) is expected to handle this
(e.g., retry, free, ...).
- The LSM hook is intentionally narrow. Broader cgroup access controls
could be a separate effort.
[1] https://lore.kernel.org/cgroups/20230109213809.418135-1-tjmercier@google.co…
Signed-off-by: Albert Esteve <aesteve(a)redhat.com>
---
Changes in v2:
- Move charge_pid_fd to charge_fd, accepting cgroupfd in addition
to pidfd per Christian König.
- New DMA_BUF_IOCTL_XFER_CHARGE ioctl for post-allocation charge
transfer on any dma-buf, not just dma-heap buffers per Christian König
and T.J. Mercier.
- Moved __GFP_ACCOUNT removal to patch 1 per Barry Song.
- dma-buf charge/uncharge helpers take struct dma_buf * directly
to avoid the need for caller to manage size calculations.
- Added test_xfer_charge_cgroupfd_self to dmabuf-heap selftests.
- Added LSM and SELinux hooks for cgroupfd-based charging.
- Rebased to v7.3-rc7.
- Link to v1: https://lore.kernel.org/r/20260512-v2_20230123_tjmercier_google_com-v1-0-63…
---
Albert Esteve (7):
dma-heap: charge dma-buf memory via explicit memcg
security: dma-buf: Add dma_buf_charge_task LSM hook
security: dma-buf: Add dma_buf_charge_cgroup LSM hook
selinux: Restrict cross-cgroup dma-buf charging
selinux: Restrict dma-buf direct cgroup charging
dma-buf: transfer memcg charges via DMA_BUF_IOCTL_XFER_CHARGE
selftests/dmabuf-heaps: Add dma-buf memcg accounting tests
T.J. Mercier (1):
memcg: Add MEMCG_DMABUF accounting infrastructure
Documentation/admin-guide/cgroup-v2.rst | 5 +
drivers/dma-buf/dma-buf.c | 80 ++++++++
drivers/dma-buf/dma-heap.c | 72 ++++++-
drivers/dma-buf/heaps/system_heap.c | 2 -
include/linux/dma-buf.h | 4 +
include/linux/lsm_hook_defs.h | 2 +
include/linux/memcontrol.h | 29 +++
include/linux/security.h | 14 ++
include/uapi/linux/dma-buf.h | 26 +++
include/uapi/linux/dma-heap.h | 7 +
mm/memcontrol.c | 94 +++++++++
security/security.c | 32 +++
security/selinux/hooks.c | 40 ++++
security/selinux/include/classmap.h | 1 +
tools/testing/selftests/cgroup/Makefile | 2 +-
tools/testing/selftests/cgroup/test_memcontrol.c | 145 +++++++++++++-
tools/testing/selftests/dmabuf-heaps/config | 1 +
tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 222 ++++++++++++++++++++-
tools/testing/selftests/dmabuf-heaps/vmtest.sh | 205 +++++++++++++++++++
19 files changed, 974 insertions(+), 9 deletions(-)
---
base-commit: 24a19b953e2a3d0ea5a8c4951a0ab8f32720c907
change-id: 20260508-v2_20230123_tjmercier_google_com-f44fcfb16530
Best regards,
--
Albert Esteve <aesteve(a)redhat.com>
On 10/23/26 02:36, Val Packett wrote:
> On 10/22/26 9:26 AM, Christian König wrote:
>> On 10/21/26 22:16, Val Packett wrote:
>>> On 10/21/26 10:43 AM, Christian König wrote:
>>>> [..]
>>>>> The buffer lifecycle coordination we need this for applies to KVM as well
>>>>> and it generally doesn't make sense to have this as a provider-specific
>>>>> thing since it's not related to the provider in any way, it's just
>>>>> something we want from dmabufs in general.
>>>> I wouldn't put that on the DMA-buf file descriptor where basically anybody can mess with it. That is just an recipe for trouble.
>>>>
>>>> The better approach seems to be putting it into the udmabuf_ioctl(), so that from the very beginning you add the eventfd which signals when the udmabuf is released.
>>>>
>>>> If we need that for more implementations than just udmabuf, we can potentially add it to dma_buf_export_info so that exporters can provide the eventfd file descriptor directly on creation.
>>> Well, we already need it with both udmabuf and gntdev-dmabuf..
>>>
>>> Involving the exporter sounds really annoying when it's not something exporter dependent really.. What if the policy is just "only one eventfd ever" i.e. the first call of the ioctl succeeds but later calls on the same dmabuf return an error?
>> No, exactly that is what I'm trying to avoid.
>>
>> Nobody except the original creater should be able to insert an eventfd here.
>
> If there's no replacement allowed anymore, what could possibly be harmful/undesirable about "someone else" being able to do this?
>
> With a "first caller only" policy, the original creator already can be 100% sure that no one else is able to insert an eventfd:
Ok that sounds like you my argumentation wasn't fully clear: That approach is exactly what I try to avoid!
> If the original creator calls this API before sending the fd to anyone else, well, the original creator *is* the first caller, that's it.
>
> Otherwise, i.e. if the original creator is not interested in this API.. it's unlikely a different process would use it, but if one does for some reason, I don't see any negative consequences from that?
First of all if this gets added as common DMA-buf API the functionality suddenly becomes available to every exporter, not just the ones who explicitly implement it.
That in turn would be rather questionable because lifetime is something only the exporter of a buffer can fully deal with.
For example it is very common that the exporter delegates cleanup from the ->release callback to a work item and your whole approach with the eventfd on the DMA-buf then doesn't work any more.
Then second when the add this as common DMA-buf functionality then it should be usable by everybody and not just the first one who asks. Otherwise you can run into all kind mess with that when you give a DMA-buf where the eventfd slot is already used up to some other process which expects to use that functionality.
For now that functionality only seems to make sense for the original creator and a limited amount of exporters where it actually works. So my suggestion is to either add some functionality to the exporter(s) or add some common functionality to dma_buf_export_info to aid exporters with their implementation.
Apart from that the approach with the eventfd looks perfectly fine to me.
Regards,
Christian.
>
>
>
> Thanks,
> ~val
On Fri, Oct 23, 2026 at 08:39:28AM +0200, Tomeu Vizoso wrote:
> A firmware may drive the core's timers, which need their power domains
> held; the remoteproc driver does not hold them, so let the DSP node
> reference them for a driver that attaches to the running core to hold.
>
> Assisted-by: LLM
> Signed-off-by: Tomeu Vizoso <tomeu(a)tomeuvizoso.net>
>
> ---
>
> v3:
> - Initial version
> ---
> .../devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
> index d6319c8e96f8..80eaef0a19b8 100644
> --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
> @@ -76,6 +76,23 @@ properties:
> # Optional properties:
> # --------------------
>
> + power-domains:
> + description: |
> + Power domains of the SoC timers the running firmware ticks on and
> + times its work out with. The firmware programs these timers itself
> + and makes no power request for them, and the timers' own nodes are
> + reserved for it, so nothing else requests their power; a client
> + driver of the firmware holds them on while it drives the processor.
> + The processor's own power is managed through ti,sci-dev-id, not here.
> + items:
> + - description: power domain of the first timer
first timer
> + - description: power domain of the second timer
second timer
No need to say that power domain is a power domain.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)oss.qualcomm.com>
Best regards,
Krzysztof