Linaro-mm-sig June 2026

linaro-mm-sig@lists.linaro.org

95 participants
462 discussions

Your Guide to Running a Primate-Powered Paradise

by boring.crane.wymi＠hidingmail.net

Ever dreamt of running your own bustling supermarket, but with a delightful simian twist? Look no further than Monkey Mart, a charming and surprisingly addictive management game that’s perfect for a quick pick-me-up or a lengthy play session. This delightful title offers a unique blend of farming, crafting, and entrepreneurial spirit, all wrapped up in an adorable pixel art package. Let’s dive into what makes Monkey Mart such a joy to experience. https://monkeymartfree.com Welcome to the Jungle Aisle: Introduction to Monkey Mart Monkey Mart isn't just another clicker game; it's a vibrant ecosystem where monkeys are the farmers, the craftspeople, and the cashiers. Your goal is simple: grow a variety of crops, process them into sellable goods, and keep your customers happy, all while expanding your monkey empire. The game is incredibly accessible, making it suitable for players of all ages and experience levels. Whether you're a seasoned gamer or just looking for a relaxing way to unwind, Monkey Mart offers a rewarding and engaging experience. You can easily find yourself immersed in this charming world by visiting the official game at Monkey Mart. A Day in the Life of a Monkey Mogul: Understanding the Gameplay The core gameplay loop of Monkey Mart is deceptively simple yet endlessly engaging. You start with a small plot of land and a single monkey. Plant bananas, harvest them, and then have your monkey stock the shelves. As you earn money from sales, you can unlock new crops like corn and coffee, and more importantly, new processing stations. This is where the magic happens! Bananas can be turned into banana smoothies, coffee beans into steaming cups of joe, and corn into popcorn. Each new product opens up new revenue streams and demands a more intricate production line. Soon, you'll be hiring more monkeys, each specializing in a different task: planting, harvesting, processing, or cashiering. The game encourages strategic placement of your monkeys and stations to optimize efficiency. Watch as your little primate team scurries around, diligently working to keep your mart thriving. Upgrading your stations and monkeys is crucial for increasing production speed and capacity, allowing you to serve more customers and expand your inventory. Tips for a Thriving Tropical Mart: Mastering the Mechanics To truly excel in Monkey Mart, a few strategies can help. Firstly, prioritize upgrades. Investing in faster harvesters or more efficient processors early on will significantly boost your income. Secondly, balance your crop production. Don't put all your bananas in one basket! Diversify your crops to offer a wider range of products and appeal to more customers. Thirdly, optimize your layout. Group similar stations together and ensure your monkeys have clear paths to minimize travel time. Experiment with different arrangements to find what works best for your growing mart. Finally, don't forget your cashiers! A long line of waiting customers means lost revenue, so ensure you have enough monkeys at the checkout. Conclusion: More Than Just a Game, It's a Monkey Metropolis! Monkey Mart is more than just a time-killer; it’s a delightful simulation that rewards planning, efficiency, and a touch of entrepreneurial spirit. Its charming visuals, intuitive controls, and satisfying progression system make it a truly enjoyable experience. Whether you're looking to unwind with a casual game or delve into a deeper management challenge, Monkey Mart offers a refreshing and endearing journey into the world of primate-powered retail. So, put on your managerial hat, gather your monkey crew, and get ready to build the most successful monkey mart the jungle has ever seen!

12 hours, 45 minutes

Digital Assets Security, Forensics & Recovery Strategist

by kabuspierre3＠gmail.com

Digital Assets Forensics & Recovery Specialist I am a dedicated Digital Assets Forensics and Recovery Specialist with a strong commitment to helping individuals, businesses, and organizations navigate the complex world of digital asset investigations and recovery. My professional journey has been built on continuous learning, practical experience, and a deep understanding of blockchain technology, cryptocurrency ecosystems, cybersecurity principles, and digital forensic methodologies. Over the years, I have developed expertise in blockchain transaction tracing, cryptocurrency wallet analysis, digital asset investigations, forensic evidence collection, cyber fraud assessment, and asset recovery support. My approach combines technical knowledge with meticulous attention to detail, ensuring that every investigation is conducted professionally, ethically, and in compliance with industry standards. I specialize in analyzing cryptocurrency transactions across multiple blockchain networks, identifying transaction patterns, tracing asset movements, and providing detailed forensic reports that support recovery efforts and dispute resolution. Through the use of advanced analytical techniques and industry-recognized tools, I assist clients in understanding the flow of digital assets and uncovering critical information that may aid in recovery processes. My services are founded on integrity, transparency, confidentiality, and client-focused solutions. I understand the financial and emotional impact that digital asset losses can have on individuals and organizations, which is why I am committed to delivering thorough investigations, clear communication, and professional guidance throughout every stage of the recovery journey. As the digital asset landscape continues to evolve, I remain dedicated to staying at the forefront of emerging technologies, blockchain developments, cybersecurity threats, and forensic best practices. My goal is to provide reliable, professional, and results-oriented digital asset forensic services that help clients protect their interests and make informed decisions. Whether supporting cryptocurrency investigations, forensic analysis, asset tracing, or recovery-related assessments, I bring professionalism, expertise, and a passion for excellence to every engagement. My mission is to contribute to a safer digital financial environment by helping clients navigate complex digital asset challenges with confidence and clarity.

19 hours, 15 minutes

[PATCH] drm/amdkfd: Fix an error handling path in amdgpu_amdkfd_get_dmabuf_info()

by Christophe JAILLET

If the memory allocation fails, the reference on 'dma_buf' still needs to be released, as already done in the other error handling path. Fixes: f54ce9e8cbd3 ("drm/amdkfd: Let driver decide buffer size at AMDKFD_IOC_GET_DMABUF_INFO ioctl") Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> --- Compile tested only --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c index c693c508df1a..e1afdad07c43 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c @@ -603,8 +603,10 @@ int amdgpu_amdkfd_get_dmabuf_info(struct amdgpu_device *adev, int dma_buf_fd, if (*metadata_size <= buffer_size) { *metadata_buffer = kzalloc(*metadata_size, GFP_KERNEL); - if (!*metadata_buffer) - return -ENOMEM; + if (!*metadata_buffer) { + r = -ENOMEM; + goto out_put; + } r = amdgpu_bo_get_metadata(bo, *metadata_buffer, *metadata_size, NULL, &metadata_flags); -- 2.54.0

22 hours, 6 minutes

Re: [PATCH v3 6/9] vfio/pci: Clean up BAR zap and revocation

by Jason Gunthorpe

On Thu, Jun 18, 2026 at 05:02:58PM +0100, Matt Evans wrote: > My understanding is that the sequences above wake a device that happens > to have previously been put into D3, and AFAICT it could only have got > there because of a previous vfio_pci_set_power_state(). Seems its only > caller is from the emulation of PCI_PM_CTRL using > vfio_lock_and_set_power_state(), and this zaps/revokes BAR access before > a transition to D3. Similarly, an attempt to access a BAR via an > ioctl/through vfio_pci_core_do_io_rw() fails the D3 check in > __vfio_pci_memory_enabled(), and besides will try to take the memory_lock. I thought the general design was the bars were made inaccessible before going to a low power state, and remain inaccessible while it is in low power? So the order of D0 doesn't matter. If it is not in D0 then there is no mappings and zap/revoke is a NOP. If is it in D0 then it doesn't matter because D0 is a nop. Jason

2 days, 1 hour

[PATCH] base: Remove unused DMA_FENCE_TRACE Kconfig symbol

by Geert Uytterhoeven

Commit d72277b6c37db66b ("dma-buf: nuke DMA_FENCE_TRACE macros v2") in v5.16 removed all users of DMA_FENCE_TRACE on the premise that the Kconfig symbol did not exist. Apparently one failed to notice the symbol did exist since almost five years before: it was renamed from FENCE_TRACE to DMA_FENCE_TRACE in commit f54d1867005c3323 ("dma-buf: Rename struct fence to dma_fence") in v4.10. Time passed by, so remove the Kconfig symbol, as no one seems to have missed the functionality. Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org> --- drivers/base/Kconfig | 9 --------- 1 file changed, 9 deletions(-) diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index f7d385cbd3ba4b2b..43f20ca95a2a6ba9 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -222,15 +222,6 @@ config DMA_SHARED_BUFFER APIs extension; the file's descriptor can then be passed on to other driver. -config DMA_FENCE_TRACE - bool "Enable verbose DMA_FENCE_TRACE messages" - depends on DMA_SHARED_BUFFER - help - Enable the DMA_FENCE_TRACE printks. This will add extra - spam to the console log, but will make it easier to diagnose - lockup related problems for dma-buffers shared across multiple - devices. - config GENERIC_ARCH_TOPOLOGY bool help -- 2.43.0

2 days, 5 hours

by keepmealive78＠gmail.com

Buy real and fake passport online, Buy ID cards online, (WhatsApp : +49 1575 3756974) Buy driving license, Buy drivers license online, Buy green card, residence permit, IELT, work permit, citizenship, buy Canadian resident permits, apply for Canadian citizenship certificates, buy Canadian ID cards, buy novelty ID cards, buy authentic identity documents. https://buyrealcurrency.com/ https://buyrealcurrency.com/ https://buyrealcurrency.com/product/加拿大居留许可/ https://rushmynewpassport.com/product/buy-canadian-resident-permits/ (WhatsApp : +49 1575 3756974) WeChat ID : Scottbowers44 (Email: authenticnotes5(a)gmail.com) https://counterfeitdocsforsale.com/ Buy fake US dollars (USD), buy fake Chinese yuan (CNY), buy fake RMB/RMB, buy fake Canadian dollars (CAD), buy fake Australian dollars (AUD) Buy fake British pounds (GBP), buy fake Euros (EUR), buy fake Hong Kong dollars ($HK). buy fake US dollars/Australian dollars/Canadian dollars/CNY/Euros/CNY, buy fake Euro banknotes, buy fake Australian dollars, buy fake Canadian dollars, buy fake US dollars, buy fake RMB online, buy fake RMB https://globaltraveldocs.com/ https://rushmynewpassport.com/ We offer all types of visas, travel documents, and passports at the best prices and with exceptional quality. We handle passports for small countries, multinational passports, entry and exit assistance for Southeast Asia, passport activation, expedited naturalization, and second identity planning, giving you an alternative. (WhatsApp : +49 1575 3756974) Email: authenticnotes5(a)gmail.com https://rushmynewpassport.com/ Buy passports online (Email: authenticnotes5(a)gmail.com) buy USA passports, buy Chinese passports, buy Hong Kong passports, buy Taiwan passports, buy diplomatic passports, Buy China travel documents People's Republic of China (PRC) https://rushmynewpassport.com/ https://buyrealcurrency.com/product/buy-real-and-fake-passport/ https://rushmynewpassport.com/buy-real-usa-passport-online/ (WhatsApp : +49 1575 3756974 )

2 days, 6 hours

[PATCH v3 0/4] rust / dma_buf: Add abstractions for dma_fence

by Philipp Stanner

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 (3): rust: error: Add ECANCELED error code rust: Add dma_fence abstractions MAINTAINERS: Add entry for Rust dma-buf MAINTAINERS | 3 + rust/bindings/bindings_helper.h | 1 + rust/helpers/dma_fence.c | 48 ++ rust/helpers/helpers.c | 1 + rust/kernel/dma_buf/dma_fence.rs | 852 +++++++++++++++++++++++++++++++ rust/kernel/dma_buf/mod.rs | 14 + rust/kernel/error.rs | 1 + rust/kernel/lib.rs | 1 + rust/kernel/sync/aref.rs | 39 ++ 9 files changed, 960 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: 848bf57e98e1678ce7a49eb4e0bf0502da95dc07 -- 2.54.0

2 days, 21 hours

Re: [PATCH] drm/drm_crtc: fix race with dma_fence_signal() in ::get_driver_name()

by Philipp Stanner

+Cc Danilo On Thu, 2026-06-18 at 15:03 +0100, André Draszik wrote: > Since commit 541c8f2468b9 ("dma-buf: detach fence ops on signal v3"), > I'm seeing the BUG_ON() triggering in drm_crtc's fence_to_crtc() via > drm_crtc_fence_get_driver_name() regularly: > > Call trace: > panic+0x58/0x5c > die+0x160/0x178 > bug_brk_handler+0x70/0xa4 > call_el1_break_hook+0x3c/0x1a0 > do_el1_brk64+0x24/0x74 > el1_brk64+0x34/0x54 > el1h_64_sync_handler+0x80/0xfc > el1h_64_sync+0x84/0x88 > drm_crtc_fence_get_driver_name+0x60/0x68 (P) > sync_file_get_name+0x184/0x45c > sync_file_ioctl+0x404/0xf70 > __arm64_sys_ioctl+0x124/0x1dc > > This looks to be caused by a code flow similar to the following: > > +++ snip +++ > thread A thread B > > ioctl(SYNC_IOC_FILE_INFO) > sync_file_ioctl() > sync_file_get_name() > dma_fence_signal_timestamp_locked() dma_fence_driver_name() > ops = rcu_dereference(fence->ops) > if (!dma_fence_test_signaled_flag()) > ops->get_driver_name(fence) i.e. > drm_crtc_fence_get_driver_name() > test_and_set_bit(SIGNALED) > RCU_INIT_POINTER(fence->ops, NULL) > drm_crtc_fence_get_driver_name() > BUG_ON(rcu_access_pointer(fence->ops) > != &drm_crtc_fence_ops) Now this looks like a very similar problem that I have recently been concerned with: https://lore.kernel.org/dri-devel/20260612104251.2264707-2-phasta@kernel.or… https://lore.kernel.org/dri-devel/fa0dc9757bf8343516c4b156a2b70ec91b64ef8f.… I continue to believe because of bugs like this and the ones I have quoted in the threads above the robustness of the kernel could be greatly improved if we could get dma_fence fully synchronized with its lock. That said: > +++ snap +++ > > I see two ways to resolve this: > a) simply drop the BUG_ON(). It can not work anymore since above > commit, as it is racy now. > b) pass the original 'ops' pointer obtained in dma_fence_driver_name() > to all callees. > > This patch implements option a), as because: > * I don't see much benefit in passing the extra pointer just for this > BUG_ON() to work. > * Requiring the dma_fence_ops in those callbacks is an implementation > detail of the drm_crtc driver, and therefore upper layers shouldn't > have to care about that. > * The existence of the BUG_ON() doesn't appear to be consistent with > implementations of ::get_driver_name() or ::get_timeline_name() in > the majority of other DRM drivers in the first place. Those that do > have a similar BUG_ON() (i915, xe) probably also need an update > similar to this patch here but I'm not in a position to test those. > > Note that the adjacent drm_crtc_fence_get_timeline_name() has the same > problem and is fixed by this patch as well. > > Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3") > Signed-off-by: André Draszik <andre.draszik(a)linaro.org> > --- > drivers/gpu/drm/drm_crtc.c | 11 +++-------- > 1 file changed, 3 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index 63ead8ba6756..31c8636e7467 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -73,6 +73,9 @@ > * &drm_mode_config_funcs.atomic_check. > */ > > +#define fence_to_crtc(f) container_of((f)->extern_lock, \ > + struct drm_crtc, fence_lock) I agree that macros should be avoided if possible. > + > /** > * drm_crtc_from_index - find the registered CRTC at an index > * @dev: DRM device > @@ -154,14 +157,6 @@ static void drm_crtc_crc_fini(struct drm_crtc *crtc) > #endif > } > > -static const struct dma_fence_ops drm_crtc_fence_ops; > - > -static struct drm_crtc *fence_to_crtc(struct dma_fence *fence) > -{ > - BUG_ON(rcu_access_pointer(fence->ops) != &drm_crtc_fence_ops); +1 BUG_ON is more or less deprecated and should not be used anymore. There needs to be bombastic justification for shooting down the entire kernel. P. > - return container_of(fence->extern_lock, struct drm_crtc, fence_lock); > -} > - > static const char *drm_crtc_fence_get_driver_name(struct dma_fence *fence) > { > struct drm_crtc *crtc = fence_to_crtc(fence); > > --- > base-commit: e2cae00c05d196491c318196792297f2dfbaa02c > change-id: 20260618-linux-drm_crtc_fix2-23a7c354a412 > > Best regards,

3 days, 1 hour

Re: [PATCH] drm/drm_crtc: fix race with dma_fence_signal() in ::get_driver_name()

by Jani Nikula

On Thu, 18 Jun 2026, André Draszik <andre.draszik(a)linaro.org> wrote: > Since commit 541c8f2468b9 ("dma-buf: detach fence ops on signal v3"), > I'm seeing the BUG_ON() triggering in drm_crtc's fence_to_crtc() via > drm_crtc_fence_get_driver_name() regularly: > > Call trace: > panic+0x58/0x5c > die+0x160/0x178 > bug_brk_handler+0x70/0xa4 > call_el1_break_hook+0x3c/0x1a0 > do_el1_brk64+0x24/0x74 > el1_brk64+0x34/0x54 > el1h_64_sync_handler+0x80/0xfc > el1h_64_sync+0x84/0x88 > drm_crtc_fence_get_driver_name+0x60/0x68 (P) > sync_file_get_name+0x184/0x45c > sync_file_ioctl+0x404/0xf70 > __arm64_sys_ioctl+0x124/0x1dc > > This looks to be caused by a code flow similar to the following: > > +++ snip +++ > thread A thread B > > ioctl(SYNC_IOC_FILE_INFO) > sync_file_ioctl() > sync_file_get_name() > dma_fence_signal_timestamp_locked() dma_fence_driver_name() > ops = rcu_dereference(fence->ops) > if (!dma_fence_test_signaled_flag()) > ops->get_driver_name(fence) i.e. > drm_crtc_fence_get_driver_name() > test_and_set_bit(SIGNALED) > RCU_INIT_POINTER(fence->ops, NULL) > drm_crtc_fence_get_driver_name() > BUG_ON(rcu_access_pointer(fence->ops) > != &drm_crtc_fence_ops) > +++ snap +++ > > I see two ways to resolve this: > a) simply drop the BUG_ON(). It can not work anymore since above > commit, as it is racy now. > b) pass the original 'ops' pointer obtained in dma_fence_driver_name() > to all callees. > > This patch implements option a), as because: > * I don't see much benefit in passing the extra pointer just for this > BUG_ON() to work. > * Requiring the dma_fence_ops in those callbacks is an implementation > detail of the drm_crtc driver, and therefore upper layers shouldn't > have to care about that. > * The existence of the BUG_ON() doesn't appear to be consistent with > implementations of ::get_driver_name() or ::get_timeline_name() in > the majority of other DRM drivers in the first place. Those that do > have a similar BUG_ON() (i915, xe) probably also need an update > similar to this patch here but I'm not in a position to test those. > > Note that the adjacent drm_crtc_fence_get_timeline_name() has the same > problem and is fixed by this patch as well. > > Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3") > Signed-off-by: André Draszik <andre.draszik(a)linaro.org> > --- > drivers/gpu/drm/drm_crtc.c | 11 +++-------- > 1 file changed, 3 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index 63ead8ba6756..31c8636e7467 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -73,6 +73,9 @@ > * &drm_mode_config_funcs.atomic_check. > */ > > +#define fence_to_crtc(f) container_of((f)->extern_lock, \ > + struct drm_crtc, fence_lock) > + > /** > * drm_crtc_from_index - find the registered CRTC at an index > * @dev: DRM device > @@ -154,14 +157,6 @@ static void drm_crtc_crc_fini(struct drm_crtc *crtc) > #endif > } > > -static const struct dma_fence_ops drm_crtc_fence_ops; > - > -static struct drm_crtc *fence_to_crtc(struct dma_fence *fence) > -{ > - BUG_ON(rcu_access_pointer(fence->ops) != &drm_crtc_fence_ops); Whether removing the BUG_ON() turns out to be the right choice or not, I couldn't say, but please don't turn this function into a macro, at least not without rationale. (I can't think of any.) BR, Jani. > - return container_of(fence->extern_lock, struct drm_crtc, fence_lock); > -} > - > static const char *drm_crtc_fence_get_driver_name(struct dma_fence *fence) > { > struct drm_crtc *crtc = fence_to_crtc(fence); > > --- > base-commit: e2cae00c05d196491c318196792297f2dfbaa02c > change-id: 20260618-linux-drm_crtc_fix2-23a7c354a412 > > Best regards, -- Jani Nikula, Intel

3 days, 2 hours

Re: [PATCH] dma-fence: use correct callback in dma_fence_timeline_name()

by Christian König

On 6/18/26 14:00, André Draszik wrote: > dma_fence_timeline_name() is a wrapper around > dma_fence_ops::get_timeline_name(). Since the blamed commit below, it > calls an incorrect callback. > > Update it to restore functionality by calling the intended callback. > > Fixes: 62918542b7bf ("dma-fence: Fix sparse warnings due __rcu annotations") > Signed-off-by: André Draszik <andre.draszik(a)linaro.org> I'm like 99% sure we had that already fixed weeks ago, but somehow it looks like that was never merged to drm-misc-fixes. Anyway Reviewed-by: Christian König <christian.koenig(a)amd.com> > --- > drivers/dma-buf/dma-fence.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > index b3bfa6943a8e..5292d714419b 100644 > --- a/drivers/dma-buf/dma-fence.c > +++ b/drivers/dma-buf/dma-fence.c > @@ -1202,7 +1202,7 @@ const char __rcu *dma_fence_timeline_name(struct dma_fence *fence) > /* RCU protection is required for safe access to returned string */ > ops = rcu_dereference(fence->ops); > if (!dma_fence_test_signaled_flag(fence)) > - return (const char __rcu *)ops->get_driver_name(fence); > + return (const char __rcu *)ops->get_timeline_name(fence); > else > return (const char __rcu *)"signaled-timeline"; > } > > --- > base-commit: e2cae00c05d196491c318196792297f2dfbaa02c > change-id: 20260618-linux-drm_crtc_fix-267655a1c89f > > Best regards, > -- > André Draszik <andre.draszik(a)linaro.org> >

3 days, 4 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig June 2026