summaryrefslogtreecommitdiff
path: root/tools/lib/python/kdoc/python_version.py
diff options
context:
space:
mode:
authorPavel Begunkov <asml.silence@gmail.com>2026-10-16 10:26:55 +0100
committerJens Axboe <axboe@kernel.dk>2026-10-16 08:23:04 -0600
commitf57b957778a33d98e15e394ab426e93c3ead659c (patch)
tree19f1392314cf5919fa5158847e3558ba9c5595a8 /tools/lib/python/kdoc/python_version.py
parentaeef964d73dbfd7f477182bac934cdb4087d1724 (diff)
io_uring/dma-buf: allow cloning registered dma-bufs
One problem that was brought up is that the file table size is often a limiting factor when working with dma-bufs, which is quite an old problem. With a single io_uring people can work it around by closing the dma-buf fd after registration, but for more complex cases we need a way to dynamically register it into another ring. We also need to deduplicate internal registrations as each creates a new attachment and related structures, which could involve large allocations and iommu mappings. Solve it by enabling io_uring buffer cloning. I made dma-bufs registered for io_uring not cloneable between rings because the implementation could modify parts of struct io_buf_dma without any locking and sharing it would've created races. That was an optimisation that got dropped at some point for simplicity, so we can safely enable cloning back as long as IORING_SETUP_IOPOLL rejection is honoured. Kill the uncloneable flag as unused as well. Reported-by: William Power <william.power@intel.com> Reported-by: Tushar Gohad <tushar.gohad@intel.com> Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://patch.msgid.link/b76cf21ee0e2362489c864e43781b20d95fd75f7.1792142588.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'tools/lib/python/kdoc/python_version.py')
0 files changed, 0 insertions, 0 deletions