Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

105 participants
7061 discussions

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

by Philipp Stanner

On Tue, 2026-06-23 at 15:33 +0100, André Draszik wrote: > > However, if my issue were to be solved with barriers, the > > test_and_set_bit() in dma_fence_signal_timestamp_locked() would have to > > be replaced with the more weakly ordered test_bit() and set_bit(), > > maybe creating other pitfalls. > > For the avoidance of doubts, I'm not saying that all the issues you raised > can be solved by barriers instead of appropriate locks (I don't know enough > about the code and issues in general here). I'm not saying that you're saying that. I'm just cautioning you that this change could be tricky. > > I do think however that appropriate locks will fix the ordering issue > highlighted by sashiko (i.e. +1 for your argument). Barriers would fix this > specific issue, too, but that is not a statement about any wider issues. > > > The ordering issue in the get_*_name() functions plays into that. > > Setting the bit would then be done after setting the ops-pointer to > > NULL. So one would have to try to move the NULL set, too. > > > > Long story short, this is painful and subtle. > > > > But I think what we are realizing over and over again is that dma_fence > > has many subtleties to its API contract, and the implementation's > > sparring use of spinlocks leads to workarounds where people take locks > > manually or have to do an RCU dance. > > > > Note that Christian is strongly opposed to guarding everything with > > locks, in part for supposedly occuring deadlocks in the fence callbacks > > when the driver needs to take its own locks. > > ww_mutex could help against deadlocks, but might affect performance, in case > these are all critical code paths (IDK), You can't use sleepable locks in fences. They fire in interrupt context left and right ;) Despite, that wouldn't even solve the reported problem. The tl;dr is: there is fence_ops->enable_signaling(), which is currently being called with the fence lock held. So the driver, in that callback, cannot take a driver-specific lock IF there is another driver party (like an IRQ) taking first the driver lock and then the fence lock. Which is why Christian König wants to remove the fence lock being held in enable_signaling(). One reason why that, supposedly, is currently not a problem is that without fence->inline_lock, you can protect the fctx with the same lock and do fctx list manipulations in enable_signaling() with lock protection. If you have a big bowl of popcorn available, you could checkout this thread: https://lore.kernel.org/dri-devel/20260608142436.265820-2-phasta@kernel.org/ ;p My own thinking is: If everyone used inline_lock, and if we could rely on everyone being able to do the necessary work in enable_signaling() without said lock- inversion, then we could perfectly synchronize all actions related to dma_fence, including driver and, thus, fence_ops unload. The only thing blocking really might be enable_signaling (the other callbacks already take the lock). The more difficult question would be how to implement that in a backwards compatible manner, i.e., for those who don't have inline_lock. Another idea for the distant future might be to question the existence of those callbacks. Userspace often is sort of decoupled from the hardware fences through intermediate fences already. > > > The community discussion regarding that problem is currently in some > > sort of dead end, where none of us seems to know what the correct path > > forward is. > > Please ignore if the following doesn't make sense, I'm just a bystander :-) > How about at least adding the required barriers and related changes, and > taking it from there? This would solve some immediate and easy to hit > issues on Arm64? If they turn out to be insufficient, code can still > be changed. > I am in support of that, which is why I posted that RFC for feedback about the appropriate memory barriers. > > BTW, thanks Philipp for all these details, much appreciated. You're welcome. If you'd find a clever solution, probably everyone would be happy. P. > > Cheers, > A.

1 hour, 24 minutes

Dive into the World of io Games: Instant Fun, Endless Competition

by improved.leopard.gfes＠hidingmail.net

Ever found yourself with a few minutes to spare, craving a quick dose of gaming excitement without the commitment of a huge download or complex tutorial? Look no further than the fascinating world of io games. These browser-based gems offer a unique blend of simplicity, accessibility, and surprisingly deep competitive play. If you're new to this genre or just looking for a fresh perspective, this guide will walk you through how to jump in and start enjoying the thrill. https://iogamesweb.com/ What are io Games? A Quick Introduction At their core, io games are characterized by their minimalist design, often taking place in a large, persistent arena where many players compete simultaneously. They are typically free-to-play, accessible directly through your web browser, and don't require any installation. This "jump in and play" philosophy is a huge part of their appeal. From slithering snakes to territorial circles, the variety is surprisingly vast, ensuring there's usually something for everyone. Getting Started: The Gameplay Loop The beauty of io games lies in their straightforward mechanics. Most titles will greet you with a simple interface: a nickname entry, a “play” button, and perhaps a server selection. Once you're in, you'll generally find yourself controlling a small entity on a larger map, alongside dozens, if not hundreds, of other players. The core gameplay loop is often about growth and dominance. In many io games, you'll collect "food" or resources scattered across the map to grow larger, stronger, or gain new abilities. This growth directly translates to power, allowing you to outmaneuver or defeat smaller opponents. However, beware! Even the biggest player can be taken down by a clever smaller one, adding a layer of strategic depth and constant tension. The controls are usually very simple, often just using the mouse to move and a few keyboard keys for special actions, making them incredibly intuitive even for non-gamers. Tips for Success and Maximum Enjoyment While io games are easy to pick up, mastering them requires a bit of practice and strategic thinking. Here are a few tips to enhance your experience: Start Small, Think Big: Don't rush into confrontations when you're tiny. Focus on safe growth and observe the patterns of larger players. ** situational Awareness:** Always keep an eye on your surroundings. Other players are constantly looking for opportunities, and knowing where they are can save you from an untimely demise. Learn the Map: Familiarize yourself with the layout, choke points, and resource rich areas. This knowledge gives you a significant advantage. Experiment with Strategies: There's often more than one way to win. Try aggressive tactics, defensive plays, or a mix of both to find what suits your style and the specific game. Don't Be Afraid to Lose: Death is a common occurrence in io games. It's part of the learning process. Each loss teaches you something new about the game's mechanics and other players' strategies. Conclusion: Endless Fun at Your Fingertips io games offer a fantastic avenue for quick, competitive, and highly addictive entertainment. Their accessibility and simple yet engaging gameplay loops make them perfect for a short break or an extended gaming session. So, next time you're looking for some instant fun, head over to your browser and dive into the exciting, ever-evolving world of io games. You might just find your new favorite pastime!

4 hours, 41 minutes

HIRE A LEGIT CRYPT0 REC0VERY EXPERT-T0 RECLIAM ST0LEN CRYPT0: HIRE RAPID DIGITAL REC0VERY

by realross038＠gmail.com

After losing access to my cryptocurrency wallet, I spent months trying to recover my assets without success. I then contacted RAPID DIGITAL RECOVERY for guidance. Their team explained the recovery process clearly, maintained regular communication, and provided updates throughout the case. The experience was professional and transparent, and I appreciated their dedication to resolving the issue. Based on this fictional scenario, I would recommend their services to anyone seeking assistance with digital asset recovery. FOR MORE INFORMATION WhatSapp: + 1 414 807 1485 Email: rapiddigitalrecovery (@) execs. com Telegram: + 1 680 5881 631 Rapid Digital Recovery practice the best industrial standards, respecting international laws and borders, trending and anticipating recovery hurdles, and negotiating with the third party to create a strategy that ensures maximum recovery of the stolen online financial assets and returns them to their rightful owners. Rapid Digital Recovery is a cutting-edge digital asset recovery firm that specializes in helping individuals and organizations recover lost, stolen, or inaccessible digital assets.

7 hours, 11 minutes

Re: [PATCH v2] dma-buf: Split sgl into page-aligned 2G chunks

by Pranjal Shrivastava

On Tue, Jun 23, 2026 at 09:44:46AM +0100, David Laight wrote: Hi David, > On Tue, 23 Jun 2026 01:54:59 +0000 > David Hu <xuehaohu(a)google.com> wrote: > > > Currently, `fill_sg_entry()` splits the scatterlist using `UINT_MAX`. > > This creates a non-page-aligned DMA length (`0xFFFFFFFF`) for the > > first entry, resulting in non-page-aligned DMA addresses for all > > subsequent entries. > > There is a separate issue of whether this code is even needed at all. > Where can transfers over 2G (never mind 4G) actually come from. > > The read, write and similar system calls limit transfers to INT_MAX > (even on 64bit) and a lot of driver code will need fixing it longer > lengths are allowed though. > io_uring better enforce the same limits. > So the transfers can come directly from userspace. > > Not only that but you also need a single physically contiguous buffer. > Good luck allocating that! > > Now maybe there are some peer-to-peer places where the large buffer > is device memory, but they will be unusual and probably need > special treatment anyway. > I agree that traditional VFS read/write face the MAX_RW_COUNT limit (~2GB), and io_uring has its limits, but I'm a little confused by the push to enforce these limits here in the SGL code? File I/O seems to be only one side of the picture. In my view, this fix is necessary and certainly has a use-case: For example, the RDMA subsystem has the capability to import dmabufs [1], which gives rise to use cases for dmabuf beyond standard file ops (via VFS/io_uring). In these scenarios, GPU HBM can be exported as dmabufs. With recent GPUs, HBM capacity can be in the order of hundreds of GBs [2]. RDMA can employ infrastructure like the vfio-dmabuf-exporter [3] or similar dmabuf exporters to frequently move huge blocks of data via P2PDMA. If we restrict incoming dmabuf transfers to fit within VFS-centric limits (2GB), we impose unnecessary overhead on the RDMA stack, forcing it to manage a significantly higher number of memory registrations. By cleanly splitting these massive contiguous device buffers into page-aligned SGL entries, we directly improve the efficiency of P2P transfers and memory registration. Since this change doesn't seem to have a negative impact on standard file I/O or break existing VFS constraints, I'm curious why we shouldn't support splitting these >4GB P2P transfers? Am I missing something? Thanks, Praan [1] https://elixir.bootlin.com/linux/v7.1.1/source/drivers/infiniband/core/umem… [2] https://nvdam.widen.net/s/fdvdqvfvj2/hopper-h200-nvl-product-brief (Table 2-2) [3] https://elixir.bootlin.com/linux/v7.1.1/source/drivers/vfio/pci/vfio_pci_dm…

12 hours, 2 minutes

Re: [PATCH v3 1/9] PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE

by Robin Murphy

On 12/06/2026 3:31 pm, Matt Evans wrote: > Hi Kevin, Pranjal, (+Robin, hi!) Oh hey there! :) > On 12/06/2026 04:39, Tian, Kevin wrote: >>> From: Pranjal Shrivastava <praan(a)google.com> >>> Sent: Friday, June 12, 2026 2:38 AM >>> >>> On Wed, Jun 10, 2026 at 04:43:15PM +0100, Matt Evans wrote: >>>> --- a/drivers/pci/Kconfig >>>> +++ b/drivers/pci/Kconfig >>>> @@ -206,11 +206,7 @@ config PCIE_TPH >>>> config PCI_P2PDMA >>>> bool "PCI peer-to-peer transfer support" >>>> depends on ZONE_DEVICE >>>> - # >>>> - # The need for the scatterlist DMA bus address flag means PCI >>> P2PDMA >>>> - # requires 64bit >>>> - # >>>> - depends on 64BIT >>>> + select PCI_P2PDMA_CORE >>>> select GENERIC_ALLOCATOR >>>> select NEED_SG_DMA_FLAGS >>>> help >>> >>> Nit: Did we drop depends on 64BIT intentionally here? I guess the full >>> PCI_P2PDMA stack still selects NEED_SG_DMA_FLAGS? IIRC, >>> NEED_SG_DMA_FLAGS doesn't select 64BIT? >> >> seems that comment is stale. According to the commit msg: >> >> " it would make vfio-pci only available if CONFIG_ZONE_DEVICE is >> present (e.g. 64-bit systems), " >> >> so it sounds a redundant dependency hence is removed. > > This was intentional. In practice there is still a dependency on 64BIT > for PCI_P2PDMA, but it is because of ZONE_DEVICE (and mem hotplug). The > key need is PCI_P2PDMA_CORE is available on !64BIT for VFIO, but I > didn't see a requirement from PCI_P2PDMA itself (as opposed to its > dependencies). If I've missed one, I can put it back... > > But NEED_SG_DMA_FLAGS doesn't smell quite right; I see from comments in > > af2880ec44021 ("scatterlist: add dedicated config for DMA flags") > > that it assumes 64BIT, but it seems to be missing a "depends on 64BIT". > > Robin -- should that depend on 64BIT? Indeed, looking at the history it seems like that was overlooked, but it worked out at the time since the only selector of NEED_SG_DMA_FLAGS was PCI_P2PDMA as you say. If we're now generalising then moving the explicit 64BIT dependency to NEED_SG_DMA_FLAGS itself sounds like the right thing to do. Cheers, Robin.

15 hours, 10 minutes

[PATCH] dma-buf/dma-fence: Set better string for dma_fence_driver_name()

by Philipp Stanner

dma_fence_driver_name() reports that a driver whose fence is already signaled is a "detached-driver". This is incorrect, the driver might still be loaded and running. Rename that string to something more descriptive. Signed-off-by: Philipp Stanner <phasta(a)kernel.org> --- Just compile-tested. --- 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 c7ea1e75d38a..9c3dfa7b0066 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -1173,7 +1173,7 @@ const char __rcu *dma_fence_driver_name(struct dma_fence *fence) if (!dma_fence_test_signaled_flag(fence)) return (const char __rcu *)ops->get_driver_name(fence); else - return (const char __rcu *)"detached-driver"; + return (const char __rcu *)"driver-whose-fence-is-signaled"; } EXPORT_SYMBOL(dma_fence_driver_name); -- 2.54.0

19 hours, 22 minutes

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

by Pranjal Shrivastava

On Thu, Jun 18, 2026 at 05:06:27PM +0100, Matt Evans wrote: > Hi Praan, > > On 12/06/2026 20:39, Pranjal Shrivastava wrote: > >> [...] > >> diff --git a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c > >> index 86362ec424a5..51990f6d66d5 100644 > >> --- a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c > >> +++ b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c > >> @@ -1692,6 +1692,14 @@ static int hisi_acc_vfio_pci_probe(struct pci_dev *pdev, const struct pci_device > >> if (ret) > >> goto out_put_vdev; > >> > >> + /* > >> + * hisi_acc_vfio_pci_mmap() calls down to > >> + * vfio_pci_core_mmap(), so BAR mappings are still > >> + * DMABUF-backed. They don't require a zap on revoke, so opt > >> + * out: > >> + */ > >> + hisi_acc_vdev->core_device.zap_bars_on_revoke = false; > >> + > > > > This seems to be happening after we vfio_pci_core_register_device, which > > could be slightly problematic if another device in the same group races > > to trigger a hot reset before we can set this to false. Could we > > initialize this flag before registration instead? > > Remember it is a safe default, so in the event of a driver not managing > to opt-out before it's required then all that happens is a redundant > unmap_mapping_range(). The default-safe was a nice suggestion from Alex > on v2. > Ack. I see. That makes sense. Thanks, Praan

20 hours, 19 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

20 hours, 22 minutes

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

by Philipp Stanner

On Tue, 2026-06-23 at 12:37 +0100, André Draszik wrote: > Hi, > > On Thu, 2026-06-18 at 17:56 +0200, Philipp Stanner wrote: > > +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. > > On top of that, sashiko highlighted (via my other patch) that the existing > code is missing some memory barriers: > > https://sashiko.dev/#/patchset/20260618-linux-drm_crtc_fix-v1-1-801f29c9853… > > I believe Lock synchronization would resolve that (as would adding explicit > memory barriers). That is being discussed in the thread I linked, where Gary lists which barriers you would need for (presumably correct) lockless magic. However, if my issue were to be solved with barriers, the test_and_set_bit() in dma_fence_signal_timestamp_locked() would have to be replaced with the more weakly ordered test_bit() and set_bit(), maybe creating other pitfalls. The ordering issue in the get_*_name() functions plays into that. Setting the bit would then be done after setting the ops-pointer to NULL. So one would have to try to move the NULL set, too. Long story short, this is painful and subtle. But I think what we are realizing over and over again is that dma_fence has many subtleties to its API contract, and the implementation's sparring use of spinlocks leads to workarounds where people take locks manually or have to do an RCU dance. Note that Christian is strongly opposed to guarding everything with locks, in part for supposedly occuring deadlocks in the fence callbacks when the driver needs to take its own locks. The community discussion regarding that problem is currently in some sort of dead end, where none of us seems to know what the correct path forward is. drm_sched users (and future users in Rust) use intermediate fences which decouple e.g. userspace from the actual hardware fences. So one path forward might be to question the callbacks in general and think about some sort of replacement for them. > > [...] > > > > > > Does the CRTC or DRM device need to be kept alive for the RCU grace period, > > or should the fence hold a proper reference to prevent the use-after-free > > when get_driver_name() and get_timeline_name() access the freed CRTC > > structure? > > Do you guys have any preference on that? It appears the use-after-free > should be resolved before merging the removal of the BUG_ON(), and I'd like > to progress on this. My understanding of the current situation is that as an issuer of dma_fence's you, in general, should wait for a grace period until you perform operations like driver unload, or, more generally, have fence- related resources and such being accessed through callbacks go away. Danilo has recently mentioned some life-time inconsistencies between wider kernel device model and DRM device model that might be related to that discussion, and which made him object against some RCU requirements. Maybe he's got the time to share some details with you that are relevant to your work. P. > > Cheers, > Andre'

20 hours, 59 minutes

Unlocking the Daily Puzzle: A Guide to the Connections Game

by graceful.earthworm.hsos＠hidingmail.com

In the ever-expanding world of daily word puzzles, one game has carved out a delightful niche for itself with its unique blend of logic and linguistic intuition: the Connections Game. If you're looking for a fresh, engaging challenge that's more about thoughtful categorization than rapid word association, then Connections is a fantastic game to dive into. It’s the kind of puzzle that rewards careful consideration and the ability to spot subtle patterns, making it a perfect brain-teaser for your morning coffee or an evening wind-down. https://connectionsgamefree.com How to Play: The Art of Grouping The premise of Connections is elegantly simple, yet surprisingly deep. You're presented with 16 words, and your goal is to sort them into four groups of four. Each group shares a common thread or category. The catch? You don’t know what those categories are, and some words might seem to fit into multiple groups at first glance, leading to delightful red herrings. When you start a new game, you'll see the 16 words laid out in a grid. To play, you simply select four words that you believe belong together. Once you’ve made your selection, you submit your guess. If you’re correct, the group will collapse, and its category will be revealed. If you're incorrect, you'll lose one of your precious four mistakes. The game ends when you've successfully grouped all four sets of words, or when you run out of mistakes. The difficulty of the categories varies – some are straightforward, while others require a more lateral way of thinking, making each day's puzzle a fresh adventure. Tips for Becoming a Connections Master To truly enjoy and excel at the Connections Game, here are a few friendly tips that have helped many players, including myself: Don't Rush: Unlike some timed word games, Connections encourages contemplation. Take your time to read all 16 words several times. Don’t jump to conclusions with the first obvious connection you see. Look for the Obvious First (Sometimes): While red herrings are common, sometimes there's a truly obvious group staring you in the face. These "easy" groups can help you clear some clutter and focus on the trickier words. Consider Word Forms: Pay attention to whether words are nouns, verbs, adjectives, or even proper nouns. This can be a huge clue. For example, a group might consist of "verbs related to speaking" or "types of cheeses." Think Broadly and Narrowly: Some categories are very specific (e.g., "Things you find in a toolbox"), while others are more abstract (e.g., "Words that precede 'Light'"). Try to think about both the common dictionary definition and potential idiomatic uses. The "One Away" Clue: If you make an incorrect guess and get the "One Away!" notification, it means three of your chosen words belong to a group, and one does not. This is a powerful clue! Identify the outlier and try swapping it for another word. Look for Synonyms or Antonyms: Sometimes the connection is simply a set of synonyms, or perhaps a group of words that are all antonyms of a particular concept. Conclusion: A Rewarding Daily Ritual Connections is more than just a puzzle; it's a daily exercise in linguistic deduction and pattern recognition. It’s a game that challenges your vocabulary and your ability to think critically about the relationships between words. Whether you’re a seasoned word-game enthusiast or just looking for a delightful new brain-teaser, Connections offers a satisfying and rewarding experience. So, gather your wits, embrace the challenge, and enjoy the delightful "aha!" moments that come with solving each day's unique puzzle.

1 day, 4 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig