Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

21 participants
3586 discussions

Re: [PATCH v5 4/5] rust: Add dma_fence abstractions

by Philipp Stanner

On Fri, 2026-07-17 at 14:14 -0300, Daniel Almeida wrote: > > > > > > + try_pin_init!(Self { > > > > + // SAFETY: `dma_fence_context_alloc()` merely works on a global atomic. > > > > + // Parameter `1` is the number of contexts we want to allocate. > > > > + nr: unsafe { bindings::dma_fence_context_alloc(1) }, > > > > + seqno: AtomicU64::new(0), > > > > > > Do we really need to force a 0 here? i.e.: can’t we take the initial seqno > > > as an argument? > > > > We could. What would that be useful for? > > > On Mali, the hardware syncobj starts at 0. If you see a 0, is this the default > state, or should you signal seqno 0? > > This problem goes away if we can have seqnos starting at a custom value, like > 1. It seems like the C machinery also special-cases 0 in a few other places too. ACK. > > > > > Hm, no, we don't. > > > > For the most part that's irrelevant, since all critical components then > > only get set in new_fence(). Correct typization is enforced through T. > > > > The notable exception is the fence_ctx reference itself. > > > > What should we do about it? > > > > We could keep the fctx field as a MaybeUninit and set it later. Or we > > check through the fctx identifier number whether it's the correct one > > in new_fence(), but then new_fence() could fail with some error, and > > it's probably better to have it be completely fail-free. > > Agree about the fail-free part. > > The problem I see here is that new_fence() will use "seqno" and "nr" from > whatever context called new_fence(), but DriverFenceAllocation has some other > (possibly unrelated) context as its DriverFenceData::fctx. > > The lifetimes are apparently broken too, because 'a is the lifetime of the > context where new_fence_allocation was called, meaning that the context that > actually called new_fence() can drop, even though it provided the state for > dma_fence_init(). > > I guess this can be solved by moving new_fence() to impl DriverFenceAllocation? > That already has a context, and most importantly, the right context. Yes that is / was broken. Having the wrong fctx would cause wrong container_of() calls and therefore explode. Fixed it locally following your suggestion of creating fences on the allocation object. > > […] > > > > + > > > > +/// The receiving counterpart of a [`DriverFence`], designed to register callbacks > > > > +/// on, check the signalled state etc. A [`Fence`] cannot be signalled. > > > > +/// A [`Fence`] is always refcounted. > > > > > > I would explain this a tad better. > > > > What exactly? The refcounting? The dualism between DriverFence and > > Fence? :) > > For example, you say “a Fence cannot be signaled”. A person seeing this > code for the first time might ask why. Specially if they start by reading the > docs for Fence first. > > I think explaining a bit more about the DriverFence/Fence/refcounting as you > said is already enough to settle it. OK, I flesh that out a bit. > > > […] > > > > + let ret = unsafe { bindings::dma_fence_is_signaled(fence) }; > > > > + > > > > + // To guarantee that an API caller can 100% rely on the signalling being > > > > + // completed (i.e., all fence callbacks ran), we have to take the lock. > > > > + // > > > > + // The reason is that the C dma_fence backend currently does not carefully > > > > + // synchronize the `dma_fence_is_signaled()` function with the proper > > > > + // spinlock. This can lead to the function returning `true` while fence > > > > + // callbacks are still being executed. This can be mitigated by guarding > > > > + // the entire function with the spinlock. > > > > + // > > > > + // See commit c8a5d5ea3ba6a. > > > > + > > > > + // SAFETY: `fence` is valid because `self` is valid. `flag_ptr` is > > > > + // merely a pointer to an integer, which lives as long as this function. > > > > + unsafe { bindings::dma_fence_lock_irqsave(fence, flag_ptr) }; > > > > > > Shouldn’t this be before the “is_signaled” ffi call? Or is this > > > only about ensuring all callbacks have run? i.e.: is “ret” valid even > > > though it was computed before taking the lock? > > > > OK, this is where it gets ugly. > > > > So during the last weeks I've been struggling to get the C backend into > > better shape. One issue from my POV is that the C dma_fence spinlock > > does not protect the fence state; there is insistence that the lock > > shall only protect the callback list. > > > > The function dma_fence_is_signaled() has an unlocked fast path check: > > > > https://elixir.bootlin.com/linux/v7.2-rc3/source/include/linux/dma-fence.h#… > > > > whereas setting of that bit is done under lock-protection: > > > > https://elixir.bootlin.com/linux/v7.2-rc3/source/drivers/dma-buf/dma-fence.… > > > > > > This can lead to funny races like in the commit mentioned in the > > comment block above (c8a5d5ea3ba6a). > > > > And it also leads to weird hacks like this: > > > > https://elixir.bootlin.com/linux/v7.2-rc3/source/drivers/gpu/drm/amd/amdgpu… > > > > > > Now, in principle I agree with you that a pattern like this: > > > > dma_fence_lock_irqsave(…); > > let signaled = dma_fence_is_signaled_locked(…); > > dma_fence_unlock_irqrestore(…); > > > > would be better. > > > > However, lengthy discussions with Christian seem to settle at the point > > where Christian sees the very strict requirement of never calling fence > > callbacks under lock protection, and where he views > > dma_fence_is_signaled_locked() as a broken function that should be > > removed. > > > > He's currently working on removing all bits where fence callbacks are > > invoked under lock protection: > > > > https://lore.kernel.org/dri-devel/20260624122917.2483-1-christian.koenig@am… > > > > There's been a ton of discussions and proposals about that in recent > > weeks > > > > https://lore.kernel.org/dri-devel/20260608142436.265820-2-phasta@kernel.org/ > > https://lore.kernel.org/dri-devel/20260612104251.2264707-2-phasta@kernel.or… > > > > > > So tl;dr: The weird code you're commenting on above ensures that > > > > a) the fence->ops->is_signaled() callback is not called under lock > > protection and > > b) taking and releasing the lock guarantees that all callbacks are > > really finished, i.e. they have run. > > > > > > (I continue to believe that setting the bit under lock protection and > > reading it without lock is fundamentally broken and needs to be fixed, > > but fixes are being rejected because of claimed performance regressions > > years ago when this was tried, because checking the bit is some sort of > > fast path check for.. parties that spin on dma_fence_is_signaled() ??) > > I see, there is a lot more context on this then. Can you merely add a comment > saying it’s ok to call dma_fence_is_signaled() without the locks? Otherwise > people might try to “fix” this down the line... I tried to make it clear with the comment above: // To guarantee that an API caller can 100% rely on the signalling being // completed (i.e., all fence callbacks ran), we have to take the lock. // // The reason is that the C dma_fence backend currently does not carefully // synchronize the `dma_fence_is_signaled()` function with the proper // spinlock. This can lead to the function returning `true` while fence // callbacks are still being executed. This can be mitigated by guarding // the entire function with the spinlock. // // See commit c8a5d5ea3ba6a. I can try to make it more explicit. Actually, I suppose with our design in Rust we would not actually need this lock-unlock, because we ensure that it does not matter whether a callback already ran. But since we don't know who will be working on this in 5 years, adding this or that exotic callback, or maybe registering callbacks on his own fence, I put this sequence there for robustness. So if the function returns true, you really know that all callbacks are gone forever. > > > > > > > > > > > > > > […] > > > > > > > > > > + /// The API user's data. This must either not need drop, or must delay its > > > > + /// drop by a grace period. It is essential that the data only performs > > > > + /// operations legal in atomic context in its [`Drop`] implementation. > > > > + #[pin] > > > > + data: T::FenceDataType, > > > > +} > > > > + > > > > > > > > […] > > > > > > + > > > > + // DriverFenceData is repr(C) and a Fence is its first member. > > > > > > > + let fence_data_ptr = fence_ptr as *mut DriverFenceData<'a, T>; > > > > > > Without a “CAST:” keyword, I think this will trigger the linter? > > > > > > > Didn't see a complaint from clippy nor compiler. > > I recommend the CAST thing anyways. It’s being adopted in other parts of the kernel > crate. I can write a CAST comment, no problem. Thx P.

2 months

Re: [RFC PATCH net-next 08/13] drm/amdkfd: add GPU instruction emitter and disassembler

by Andrew Lunn

On Mon, Jul 20, 2026 at 10:05:33PM +0200, Natalie Vock wrote: > On 7/19/26 19:58, Taehee Yoo wrote: > > Add the AMD GCN (gfx9/gfx10) instruction encoder used to build the GPU > > shaders that knod dispatches, plus a matching disassembler used for > > debugging the generated code. > > Is it really necessary to have a full-on compiler and disassembler in the > kernel driver? This patch is massive and I'm wondering how much benefit it > really provides. Is there really no way to move GPU compilation out of the > kernel, one way or another? Could you get acceptable perf with a static > shader that interprets BPF programs at runtime? Such a shader can be > compiled beforehand and just embedded into the kernel - there's prior art > there with the CWSR trap handler in amdkfd. > > In case you really, really need to compile the BPF to native ISA, could you > still have userspace take care of that in one way or another? There was a long and painful discussion about P4, and offloading it to hardware. The proponents of that wanted to do the compilation stage in user space to produce a binary blob, but it was hard to prove that the P4 passed to the kernel for software processing, and the binary blob passed to the hardware actually where the same. It opened up the path for closed source P4 where the kernel never got to see the actual P4 code. So it was not really offload, but kernel bypass. So having a compiler in the kernel is probably the correct way to go, if you want to be friendly to open source. The other option is to get the GPU to do the compilation itself, so you pass BPF byte codes to the GPU and it generates its own native code. I've no idea if that is possible, but clang can target OpenMP, so maybe it is possible to move this compiler into the GPU? Andrew

2 months

[PATCH v2 0/2] drm/drm_crtc: dma_fence_ops fixes

by André Draszik

Hi, These patches fix two issues in the drm/drm_crtc driver. Initially I was hitting the BUG_ON() in a scenario as explained in the commit message of what is now the second patch in this series. For the reasons outlines there, the BUG_ON() should just be removed. After posting, sashiko.dev noticed another issue, that was previously masked by the now-removed BUG_ON(). Since we can't have a loud BUG() be replaced with silent data corruption or worse, I've also added a patch to address this issue highlighted by sashiko.dev. I believe its observation and analysis to be correct. Cheers, Andre' Signed-off-by: André Draszik <andre.draszik(a)linaro.org> --- Changes in v2: - add new patch 1 to address sashiko observation - original patch 1 becomes patch 2 - patch 2: - don't turn fence_to_crtc() into macro (Jani, Philipp) - update commit message to include reference to deprecated use of BUG - Link to v1: https://lore.kernel.org/r/20260618-linux-drm_crtc_fix2-v1-1-c03e77b36f34@li… --- André Draszik (2): drm/drm_crtc: ensure dma_fence_ops remain valid during device unbind drm/drm_crtc: fix race with dma_fence_signal() in ::get_driver_name() drivers/gpu/drm/drm_crtc.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- base-commit: b9810cd75b9fb56a3425d391cba3f608502bd474 change-id: 20260618-linux-drm_crtc_fix2-23a7c354a412 Best regards, -- André Draszik <andre.draszik(a)linaro.org>

2 months

Re: [PATCH v5 0/9] vfio/pci: Add mmap() for DMABUFs

by Matt Evans

Hi David, On 16/07/2026 22:23, David Matlack wrote: > On 2026-07-16 03:51 PM, Matt Evans wrote: >> Hi David, >> >> On 15/07/2026 19:12, David Matlack wrote: >>> On Wed, Jul 15, 2026 at 10:47 AM Matt Evans <matt(a)ozlabs.org> wrote: >>> >>>> This is based on v7.2-rc3. >>>> >>>> These commits are on GitHub for easier browsing, along with >>>> "[RFC ONLY] selftests: vfio: Add standalone vfio_dmabuf_mmap_test": >>>> >>>> https://github.com/metamev/linux/compare/v7.2-rc3...dev/mev/vfio-dmabuf-mma… >>> >>> It'd be great to have this test upstream. I'm happy to review it when >>> you're ready. Looks like it just needs to be redone to use the VFIO >>> selftests library and kselftests harness. AI could probably do the >>> conversion pretty quick :) >> >> For sure, I'd intended to catch up with you on best approach here. :) >> >> Aside from the organic structure of the test (the open-coded VFIO >> device/group setup/init needs to go), the main issue is that it relies >> on a hacked/out of tree QEMU "EDU++" device with a second larger BAR >> (containing freely read-writable memory). A subset of tests run with >> the in-tree EDU device, but coverage is too low. >> >> The desirable properties are: >> >> - Having a BAR that is pure memory (all locations present, writable >> without disruptive side-effects) so that mapping aliases can be >> constructed and detected. This is good to test things like non-zero >> vm_pgoffs and VA space presentation of physically-discontiguous DMABUFs. >> >> - BAR >> hugepage size so we can eyeball huge mappings work (or better, >> mechanically test for them). At least 32MB would tick this box for 4K, >> 16K page systems. >> >> - Something QEMU supports*, so one can run the test in a VM/TCG system. >> >> There were some real device models in QEMU that could be used this way, >> but needed a fair bit of setup; I didn't want to rathole >> vfio_dmabuf_mmap_test on including a ton of device-specific code for >> some video card or similar. >> >> I'll dig more for a simple target that provides these properties -- >> obviously it would be better to point this test at an off-the-shelf >> device (including silicon!). And, proposing EDU extensions to the QEMU >> folks may be useful (there're uses for a better EDU in other contexts too). >> >> Since this test uses MMIO for a specific [class of] function, my first >> thought is it should be another VFIO driver-type test sibling of >> vfio_pci_driver_test. For example, we could extend the driver-type >> tests' backend struct vfio_pci_driver_ops for functions capable of >> providing a Big Memory BAR, like QEMU EDU++. EDU can also memcpy, so >> could also support vfio_pci_driver_test. >> >> The spirit of the device backends hiding setup of a complex device is >> handy, and it's plausible that several backends could provide this "big >> memory BAR" service. What do you think, any concerns with extending >> vfio_pci_driver_ops like that? > > I wouldn't recommend leveraging the driver framework unless absolutely > necessary. It makes the test harder to run. > > The biggest issue I see with the proposed properties is being able to > treat the BAR as memory. That obviously will depend on the device and > may require device-specific setup. If we decide that treating the BAR as > memory is truly required then using the driver framework is the way to > go. But I'm hoping we can avoid that requirement. > > Instead, I think you can get pretty far by inspecting /proc/pid/pagemap > to determine if the mmap() set things up correctly, without actually > accessing the BAR. You can use /proc/pid/pagemap to look up the PFN and > PAGEMAP_SCAN to detect huge pages. Hmm, possible, although that's quite a different test at that point. I agree never touching the device has advantages, but it's harder to test certain things if we _never_ do MMIO. The mitigation effort to get coverage may not be the right tradeoff vs easier running. I can think of some "easy" VFIO bugs that would be challenging to properly verify in userspace (e.g. PFNs all having some undesired offset). The current test method is harder to fool per unit effort in writing it. Though, I will have a think about this no-touch flavour of test. What were you picturing regarding populating the VMA PTEs in order to inspect the result via /proc/pid/pagemap, whilst still upholding the principle of not touching the device? For example, madvise(MADV_POPULATE_WRITE) won't work on the VFIO BAR regions because they're VM_PFNMAP/VM_IO. > With that requirement gone, then all you really need is a device with a > large enough BAR. And even that it not a hard requirement. I'm sure > there are plenty of test cases that could work with smaller BARs. The > few tests that want to exercise huge mappings can inspect the device BAR > sizes first, and if they're all too small, SKIP() the test. > > If you structure the test this way, then it's easy for the test to be > used. It can be run against any device for the basic functional > coverage, and can be run against a device with a larger BAR for full > coverage of huge mappings. > > Does QEMU emulate any devices that have 32MB or larger BARs? Yep, looks like `-device pci-testdev,membar=64M,membar-backed=on` or even `-device bochs-display,vgamem=64M` would be suitable. So I'll also try moving the existing test over to one of these to at least remove the EDU++ device dependency. (bochs-display has >1 BAR, and some MMIO regs which are nice for a quick kick-the-tyres access test.) Cheers, Matt

2 months, 1 week

Re: [PATCH v5 0/9] vfio/pci: Add mmap() for DMABUFs

by David Laight

On Thu, 16 Jul 2026 21:23:22 +0000 David Matlack <dmatlack(a)google.com> wrote: > On 2026-07-16 03:51 PM, Matt Evans wrote: > > Hi David, > > > > On 15/07/2026 19:12, David Matlack wrote: > > > On Wed, Jul 15, 2026 at 10:47 AM Matt Evans <matt(a)ozlabs.org> wrote: > > > > > >> This is based on v7.2-rc3. > > >> > > >> These commits are on GitHub for easier browsing, along with > > >> "[RFC ONLY] selftests: vfio: Add standalone vfio_dmabuf_mmap_test": > > >> > > >> https://github.com/metamev/linux/compare/v7.2-rc3...dev/mev/vfio-dmabuf-mma… > > > > > > It'd be great to have this test upstream. I'm happy to review it when > > > you're ready. Looks like it just needs to be redone to use the VFIO > > > selftests library and kselftests harness. AI could probably do the > > > conversion pretty quick :) > > > > For sure, I'd intended to catch up with you on best approach here. :) > > > > Aside from the organic structure of the test (the open-coded VFIO > > device/group setup/init needs to go), the main issue is that it relies > > on a hacked/out of tree QEMU "EDU++" device with a second larger BAR > > (containing freely read-writable memory). A subset of tests run with > > the in-tree EDU device, but coverage is too low. > > > > The desirable properties are: > > > > - Having a BAR that is pure memory (all locations present, writable > > without disruptive side-effects) so that mapping aliases can be > > constructed and detected. This is good to test things like non-zero > > vm_pgoffs and VA space presentation of physically-discontiguous DMABUFs. > > > > - BAR >> hugepage size so we can eyeball huge mappings work (or better, > > mechanically test for them). At least 32MB would tick this box for 4K, > > 16K page systems. > > > > - Something QEMU supports*, so one can run the test in a VM/TCG system. > > > > There were some real device models in QEMU that could be used this way, > > but needed a fair bit of setup; I didn't want to rathole > > vfio_dmabuf_mmap_test on including a ton of device-specific code for > > some video card or similar. > > > > I'll dig more for a simple target that provides these properties -- > > obviously it would be better to point this test at an off-the-shelf > > device (including silicon!). And, proposing EDU extensions to the QEMU > > folks may be useful (there're uses for a better EDU in other contexts too). > > > > Since this test uses MMIO for a specific [class of] function, my first > > thought is it should be another VFIO driver-type test sibling of > > vfio_pci_driver_test. For example, we could extend the driver-type > > tests' backend struct vfio_pci_driver_ops for functions capable of > > providing a Big Memory BAR, like QEMU EDU++. EDU can also memcpy, so > > could also support vfio_pci_driver_test. > > > > The spirit of the device backends hiding setup of a complex device is > > handy, and it's plausible that several backends could provide this "big > > memory BAR" service. What do you think, any concerns with extending > > vfio_pci_driver_ops like that? > > I wouldn't recommend leveraging the driver framework unless absolutely > necessary. It makes the test harder to run. > > The biggest issue I see with the proposed properties is being able to > treat the BAR as memory. That obviously will depend on the device and > may require device-specific setup. If we decide that treating the BAR as > memory is truly required then using the driver framework is the way to > go. But I'm hoping we can avoid that requirement. Could you run a test where only a known part of the BAR can be treated as memory? A large BAR is likely to have some areas that can be accessed as memory. David > > Instead, I think you can get pretty far by inspecting /proc/pid/pagemap > to determine if the mmap() set things up correctly, without actually > accessing the BAR. You can use /proc/pid/pagemap to look up the PFN and > PAGEMAP_SCAN to detect huge pages. > > With that requirement gone, then all you really need is a device with a > large enough BAR. And even that it not a hard requirement. I'm sure > there are plenty of test cases that could work with smaller BARs. The > few tests that want to exercise huge mappings can inspect the device BAR > sizes first, and if they're all too small, SKIP() the test. > > If you structure the test this way, then it's easy for the test to be > used. It can be run against any device for the basic functional > coverage, and can be run against a device with a larger BAR for full > coverage of huge mappings. > > Does QEMU emulate any devices that have 32MB or larger BARs? >

2 months, 1 week

[PATCH 0/5] drm/sched: Introduce the miracle of locking to entity

by Philipp Stanner

Both Tvrtko [1] and I [2] have recently proposed some improvals for drm_sched. While taking Tvrtko's feedback into account for my patch, I realized that both his and my patch can be fully replaced with a bigger and far more beautiful series. If I am not mistaken, it turns out that the entire entity->entity_idle completion is also nothing but a workaround around the grave mistake of not using the greatest helper with parallel programming that exists in computer science: Locking. This series adds locking to the last_scheduled field and all checks related to detect the idleness of the entity. As before, the job_scheduled event queue causes the periodic checks. This way, we can get rid of memory barriers, RCU, a few lines of code, make things more readable, understandable... Tested with drm-sched-unit tests. I'm a bit busy right now, but wanted to show you guys the idea. Before merging I'd test it more exhaustively with Nouveau. Greetings, Philipp [1] https://lore.kernel.org/dri-devel/20260611123423.39819-1-tvrtko.ursulin@iga… [2] https://lore.kernel.org/dri-devel/20260626081942.2122144-2-phasta@kernel.or… Philipp Stanner (5): drm/sched: Protect entity->last_scheduled with spinlock drm/sched: Lock spsc_queue in drm_sched_entity_pop_job() drm/sched: Avoid lock cycle for sched_entity drm/sched: Lock drm_sched_entity_is_idle() drm/sched: Remove entity->entity_idle drivers/gpu/drm/scheduler/sched_entity.c | 75 +++++++++++------------- drivers/gpu/drm/scheduler/sched_main.c | 2 - drivers/gpu/drm/scheduler/sched_rq.c | 5 +- include/drm/gpu_scheduler.h | 16 ++--- 4 files changed, 41 insertions(+), 57 deletions(-) base-commit: be4f10d44757211fd656fa57f37034657f26c883 -- 2.54.0

2 months, 1 week

[PATCH v3 0/2] dma-buf: fix fd leak when copy_to_user() fails after fd_install()

by Baineng Shou

Several drivers call dma_buf_fd() — which internally calls fd_install() — before copy_to_user() returns the fd number to userspace. If copy_to_user() fails, the fd is already published in the caller's fd table but the ioctl returns an error, so userspace never learns the fd number. Worse, the window between fd_install() and copy_to_user() allows other threads to observe and manipulate the fd (dup, close, SCM_RIGHTS), making any "close it on the failure path" fix unsafe. The fix is to split the allocation into three steps: reserve an fd with get_unused_fd_flags() (not yet visible to other threads), do copy_to_user(), and only then publish the fd with fd_install() via the new dma_buf_fd_install() helper. On copy_to_user() failure, put_unused_fd() + dma_buf_put() cleanly unwind with no user-visible side effects. Patch 1 introduces dma_buf_fd_install() in dma-buf.c (wrapping fd_install() together with the DMA_BUF_TRACE call to preserve export tracing) and applies the fix to dma-heap. Patch 2 applies the same fix to fastrpc, which even had a comment acknowledging the problem could not be fixed before. v1: https://lore.kernel.org/dri-devel/20260703080922.1838362-1-shoubaineng@gmai… v2: https://lore.kernel.org/dri-devel/20260710105430.3059661-1-shoubaineng@gmai… Changes in v3: - Split into two patches (dma-heap + fastrpc separately) - Add dma_buf_fd_install() to preserve trace_dma_buf_fd tracepoint (spotted by T.J. Mercier and sashiko-bot on v2) - Add fastrpc fix using the new helper (suggested by T.J. Mercier) Baineng Shou (2): dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds misc: fastrpc: don't publish fd before copy_to_user() succeeds drivers/dma-buf/dma-buf.c | 20 ++++++++++ drivers/dma-buf/dma-heap.c | 80 +++++++++++++++++++------------------- drivers/misc/fastrpc.c | 16 +++----- include/linux/dma-buf.h | 1 + 4 files changed, 67 insertions(+), 50 deletions(-) -- 2.34.1

2 months, 1 week

[PATCH v5 0/5] rust / dma_buf: Add abstractions for dma_fence

by Philipp Stanner

Changes since v4: - Fix an uninitialized memory bug for FenceCbRegistration with ManuallyDrop. - Return FenceCtx as impl PinInit - Make FenceCtx return an impl PinInit<T, Error> (Danilo) - Reformat some comments - Adjust the docu for rcu_barrier(), so that it matches the C side's docu and our docu for rcu::synchronize_rcu(). Changes since v3: - Add a FIXME for an encountered Rust compiler bug. (Gary) - Add new Rust files also to DRM drivers & common infrastructure MAINTAINERS file. (Danilo) - Reposition ECANCELED error code. (Miguel) - Replace refcounted FenceCtx in DriverFenceData with a reference plus life time. (Boris) - Re-add rcu_barrier() patch, since we now can use it for dropping the fence context. (Danilo) - Add forgotten R-b from Alice, and Acks for MAINTAINERS from Christian and Sumit. Changes since v2: - Don't drop DriverFenceData as a whole, but only the members we really want to drop. Gives more robustness. (Gary). - Break apart large pin_init_from_closure(). (Danilo, Onur) - Remove rcu_barrier() and synchronize_rcu() from FenceCtx::drop(). FenceCtx might drop in atomic context, where you must not perform those operations. With the current way C dma_fence is designed, the driver must wait for a grace period manually until it unloads. - Repair the DriverFenceBorrow implementation, properly injecting a life time into it. (Danilo) - Fix memory layout bug for rcu_head. (Onur) - Drop RCU patches, since this series doesn't need them anymore. Changes since v1: - Remove unnecessary mutable references (Alice) - Split up unsafe comments where possible (Danilo) - Remove PhantomData + implement FenceCtx ops trait (Boris) - Consistently call FenceCtx generic data `T`. FenceDataType is derived from that. (Boris) - Add abstractions for call_rcu() and synchronize_rcu() (Danilo) - Add ECANCELED error code in Rust (Alice) - Remove the rcu_barrier() from FenceCtx::drop() – because we now use call_rcu(), there can be no UAF access to the FenceCtx anymore. In any case, it is illegal to use either call_rcu() or synchronize_rcu() in FenceCtx::drop(), because our new drop_driver_fence_data() can run in atomic context and might put the last fence_ctx reference. So we now only have to guard against module unload, which it seems either the driver or Rust driver-core / module unload infrastructure must solve. - Minor formatting etc. changes - Add C helpers to MAINTAINERS. (Danilo) - Ensure that `Fence::is_signaled()` is fully synchronized, i.e., all callbacks really have run. See [1] and [2]. (Myself, Christian König) Changes since the RFCs: - Include support for ForeignOwnable for ARef, so that a Fence can be stuffed into an XArray et al. (Code by Danilo) - Implement ForeignOwnable (with new borrow type) for DriverFence, so that it can be stuffed into an XArray. - Include the rcu::RcuBox data type to defer dropping data with RCU (Cody by Alice) - Port DmaFence to RcuBox to make UAF bugs through later, new dma_fence callbacks (backend_ops) impossible. - Force users to pass their fence data in an RcuBox (or have it not need drop()) through a Sealed trait. - Document the rules for the user's DriverFence::data's drop implementation very clearly (deadlock danger). - rustfmt, Clippy. - Various style suggestions, safety comments, etc. (Önur) - Add __rust_helper prefix to helper functions. (Önur) Changes in RFC v3: - Omit JobQueue patches for now - Completely redesign the memory layout: Instead of a Fence refcounting a DriverFence, both now live in the same allocation to allow for future support the dma_fence backend_ops callbacks which need to do container_of. (mostly Boris's feedback) - Allow for pre-allocating fences to avoid deadlocks when submitting jobs to a GPU. (Boris) - Simultaneously, allow for pre-preparing fence callback objects, so the driver can allocate them when it sees fit. (code largely stolen and inspired by Daniel). - Signal fences on drop, ensure synchronization. - Force users to set an error code when signalling. - Write more documentation - A ton of minor other changes. [1] https://lore.kernel.org/dri-devel/20260608142436.265820-2-phasta@kernel.org/ [2] https://lore.kernel.org/dri-devel/20260612104251.2264707-2-phasta@kernel.or… Alright, so since the last RFCs did not reveal significant design issues, I decided to transition this series to a v1 and hope that we can get it upstream. This now includes code for more common infrastructure that dma_fence needs, contributed by Danilo and Alice. --- Old cover letter for RFC: So, this is the spiritual successor of the first / second RFC [1]. v2 also contained code for drm::JobQueue, but mostly to show how the fence code would be used. JobQueue is under heavy rework right now, so I don't want to bother your eyes with it. The docstring examples should show how Rust fences are supposed to be used, though. This v3 contains a huge amount of highly valuable feedback from a variety of people, notably Boris, but also from Alice, Gary and Danilo. There are some TODOs open (a better trait for fence backend_ops and RCU support), but my hope is that this effort is now finally approaching its end. I would greatly appreciate feedback and especially more information about what might be missing to make this usable, which is obviously where Daniel's and Boris's feedback will be valuable once more. Please regard this patch just as what it's titled: an RFC, to discuss a bit more and to inform a broader community about what the current state is and where this is heading at. Many regards, Philipp [1] https://lore.kernel.org/rust-for-linux/20260203081403.68733-2-phasta@kernel… Danilo Krummrich (1): rust: types: implement ForeignOwnable for ARef<T> Philipp Stanner (4): rust: error: Add ECANCELED error code rust: sync: Add abstraction for rcu_barrier() rust: Add dma_fence abstractions MAINTAINERS: Add entry for Rust dma-buf MAINTAINERS | 5 + rust/bindings/bindings_helper.h | 1 + rust/helpers/dma_fence.c | 48 ++ rust/helpers/helpers.c | 1 + rust/kernel/dma_buf/dma_fence.rs | 894 +++++++++++++++++++++++++++++++ rust/kernel/dma_buf/mod.rs | 14 + rust/kernel/error.rs | 1 + rust/kernel/lib.rs | 1 + rust/kernel/sync/aref.rs | 40 ++ rust/kernel/sync/rcu.rs | 20 + 10 files changed, 1025 insertions(+) create mode 100644 rust/helpers/dma_fence.c create mode 100644 rust/kernel/dma_buf/dma_fence.rs create mode 100644 rust/kernel/dma_buf/mod.rs base-commit: a73a398a68ca9b9e5116a617562471f16b8310c4 -- 2.54.0

2 months, 1 week

[PATCH v3 00/11] dma-buf: heaps: Add support for Tegra VPR

by Thierry Reding

This series adds support for the video protection region (VPR) used on Tegra SoC devices. It's a special region of memory that is protected from accesses by the CPU and used to store DRM protected content (both decrypted stream data as well as decoded video frames). Patches 1 through 3 add DT binding documentation for the VPR and add the VPR to the list of memory-region items for display, host1x and NVDEC. New set_memory_device() and set_memory_normal() helpers are defined in patch 4 and will subsequently be used to set the memory type of the VPR to make sure it won't be accessed by the CPU once it's made part of the protected region. Patch 5 adds bitmap_allocate(), which is like bitmap_allocate_region() but works on sizes that are not a power of two. Patch 6 introduces new APIs needed by the Tegra VPR implementation that allow CMA areas to be dynamically created at runtime rather than using the fixed, system-wide list. This is used in this driver specifically because it can use an arbitrary number of these areas (though they are currently limited to 4). Patch 7 adds some infrastructure for DMA heap implementations to provide information through debugfs. The Tegra VPR implementation is added in patch 8. See its commit message for more details about the specifics of this implementation. Finally, patches 9-11 add the VPR placeholder node on Tegra234 and Tegra264 and hook it up to the host1x node so that it can make use of this region. Changes in v3: - Link to v2: https://patch.msgid.link/20260122161009.3865888-1-thierry.reding@kernel.org - introduce set_memory_device() and set_memory_normal() - rename VPR nodes to "protected" - add Tegra264 placeholder nodes Changes in v2: - Link to v1: https://patch.msgid.link/20250902154630.4032984-1-thierry.reding@gmail.com - Tegra VPR implementation is now more optimized to reduce the number of (very slow) resize operations, and allows cross-chunk allocations - dynamic CMA areas are now trackd separately from static ones, but the global number of CMA pages accounts for all areas Thierry Signed-off-by: Thierry Reding <treding(a)nvidia.com> --- Chun Ng (1): arm64/mm: Add set_memory_device() and set_memory_normal() Thierry Reding (10): dt-bindings: reserved-memory: Document Tegra VPR dt-bindings: display: tegra: Document memory regions dt-bindings: gpu: host1x: Document memory-regions for NVDEC bitmap: Add bitmap_allocate() function mm/cma: Allow dynamically creating CMA areas dma-buf: heaps: Add debugfs support dma-buf: heaps: Add support for Tegra VPR arm64: tegra: Add VPR placeholder node on Tegra234 arm64: tegra: Hook up VPR to host1x arm64: tegra: Add VPR placeholder node on Tegra264 .../display/tegra/nvidia,tegra124-vic.yaml | 8 + .../bindings/display/tegra/nvidia,tegra186-dc.yaml | 10 + .../bindings/display/tegra/nvidia,tegra20-dc.yaml | 10 +- .../display/tegra/nvidia,tegra20-host1x.yaml | 7 + .../bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml | 8 + .../nvidia,tegra-video-protection-region.yaml | 76 ++ arch/arm/mm/dma-mapping.c | 2 +- arch/arm64/boot/dts/nvidia/tegra234.dtsi | 45 + arch/arm64/boot/dts/nvidia/tegra264.dtsi | 33 + arch/arm64/include/asm/set_memory.h | 2 + arch/arm64/mm/pageattr.c | 16 + arch/s390/mm/init.c | 2 +- drivers/dma-buf/dma-heap.c | 56 + drivers/dma-buf/heaps/Kconfig | 7 + drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/tegra-vpr.c | 1242 ++++++++++++++++++++ include/linux/bitmap.h | 25 +- include/linux/cma.h | 8 +- include/linux/dma-heap.h | 2 + include/linux/set_memory.h | 11 + include/trace/events/tegra_vpr.h | 57 + kernel/dma/contiguous.c | 2 +- mm/cma.c | 187 ++- mm/cma.h | 5 +- 24 files changed, 1775 insertions(+), 47 deletions(-) --- base-commit: 703daa6d046136affd69f2a2e08f36ac4a7d5b2c change-id: 20260507-tegra-vpr-cd4bc2509c4c Best regards, -- Thierry Reding <treding(a)nvidia.com>

2 months, 1 week

(no subject)

by None

From Dmitry.Guzman(a)mobileye.com Wed Jul 15 14:45:58 2026 Date: Wed, 15 Jul 2026 14:45:58 +0300 From: Dmitry Guzman <Dmitry.Guzman(a)mobileye.com> To: Aniket Randive <aniket.randive(a)oss.qualcomm.com> Cc: mukesh.savaliya(a)oss.qualcomm.com, viken.dadhaniya(a)oss.qualcomm.com, andi.shyti(a)kernel.org, sumit.semwal(a)linaro.org, christian.koenig(a)amd.com, linux-i2c(a)vger.kernel.org, linux-arm-msm(a)vger.kernel.org, linux-kernel(a)vger.kernel.org, linux-media(a)vger.kernel.org, dri-devel(a)lists.freedesktop.org, linaro-mm-sig(a)lists.linaro.org, naresh.maramaina(a)oss.qualcomm.com Subject: Re: [PATCH V5] i2c: qcom-geni: Add dynamic transfer timeout based on transfer length and frequency Message-Id: <20260715144558.abf5078829bfd2a0973019a9(a)mobileye.com> In-Reply-To: <20260715101805.3615166-1-aniket.randive(a)oss.qualcomm.com> References: <20260715101805.3615166-1-aniket.randive(a)oss.qualcomm.com> Organization: MobilEye X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Sylpheed-Account-Id: 1 X-Sylpheed-Reply: #mh/Mailbox/inbox/15 X-Sylpheed-Compose-AutoWrap: FALSE X-Sylpheed-Compose-CheckSpell: FALSE X-Sylpheed-Compose-SpellLang: en X-Sylpheed-Compose-UseSigning: FALSE X-Sylpheed-Compose-UseEncryption: FALSE On Wed, 15 Jul 2026 15:48:05 +0530 Aniket Randive <aniket.randive(a)oss.qualcomm.com> wrote: > This replaces the fixed 1-second timeout with a transfer-specific > timeout while preserving sufficient margin for software overheads and > bus-level delays. > The dynamic timeout may be useful for any I2C bus controller, not only for qcom-geni. Structure i2c_adapter already has field "timeout". Isn't it worth to move the timeout calculation to i2c-core, so that the core updates the timeout field in i2c_adapter structure, and the controller driver just uses this value, instead of duplicating the calculation in every driver that will use this feature? Also, such parameters as I2C_TIMEOUT_SAFETY_COEFFICIENT and I2C_TIMEOUT_MIN_USEC may be configurable by user (for example, in device tree) for more flexibility. Best regards, -- Dmitry Guzman <Dmitry.Guzman(a)mobileye.com>

2 months, 1 week

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig