Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

103 participants
7057 discussions

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.

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

6 hours, 32 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

7 hours, 28 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

7 hours, 31 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'

8 hours, 8 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.

15 hours, 28 minutes

Drop, Combine, Explode: The Oddly Satisfying World of Watermelon Puzzles

by quarrelsome.quail.btqn＠hidingmail.net

https://suikagame.lol/ There's something uniquely appealing about watching fruits merge together in slow motion. If you've scrolled through gaming communities lately, you've probably noticed more people talking about watermelon puzzle games, and for good reason. These games tap into something genuinely fun—the simple pleasure of combining things and watching them transform. Suika Game has become the poster child of this genre, and it's worth understanding why so many people find themselves absorbed in dropping cherry tomatoes and strawberries into a physics-based box. What's Actually Happening Here? At its heart, a watermelon puzzle is about merging identical fruits to create bigger ones. You start with small items—grapes or cherries—and your job is to drop them into a container and pair them together. When two matching fruits touch, they combine into the next size up. Two grapes become strawberries, two strawberries become oranges, and the chain continues until you're (hopefully) stacking massive watermelons. The catch? Your container has limited space. It's like a vertical Tetris with physics and gravity. Fruits don't stack neatly in rows—they tumble around realistically, bounce off walls, and settle where they land. This means you need to think strategically about where each piece lands. Drop a fruit carelessly, and it might block the path for future combinations or create an awkward pile that leaves no room for your next move. Each game typically continues until you can't fit any more pieces into the box. Some versions include special mechanics—occasional bombs or special items that clear out sections of fruit. But the core loop remains the same: drop, combine, survive as long as possible. Getting Into the Flow

17 hours, 18 minutes

Why should you buy a dachshund puppy?

by Chong Criston

20 hours, 15 minutes

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

by Philipp Stanner

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 | 870 +++++++++++++++++++++++++++++++ rust/kernel/dma_buf/mod.rs | 14 + rust/kernel/error.rs | 1 + rust/kernel/lib.rs | 1 + rust/kernel/sync/aref.rs | 39 ++ rust/kernel/sync/rcu.rs | 6 + 10 files changed, 986 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

1 day, 6 hours

Re: [PATCH] drm/gem: modernize locks to use scoped_guard()

by Thomas Zimmermann

Hi Am 16.06.26 um 20:19 schrieb Biren Pandya: > Several GEM core functions manually managed mutex_lock() and > mutex_unlock() over single scopes or error paths. This adds boilerplate > and carries the risk of lock leaks if error paths are refactored. > > Modernize these locks by deploying the <linux/cleanup.h> scoped_guard() > macro. This ensures that the locks are reliably dropped when the block > exits, cleanly removing goto out_unlock paths and tightening the > lifecycle. > > Signed-off-by: Biren Pandya <birenpandya(a)gmail.com> > > Compiled locally, but requires IGT validation by the DRM CI. > --- > drivers/gpu/drm/drm_gem.c | 66 ++++++++++++++++++--------------------- > 1 file changed, 30 insertions(+), 36 deletions(-) > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > index 891c3bff5ae0..d3a061d42ba7 100644 > --- a/drivers/gpu/drm/drm_gem.c > +++ b/drivers/gpu/drm/drm_gem.c > @@ -346,13 +346,13 @@ void drm_gem_object_handle_put_unlocked(struct drm_gem_object *obj) > * we checked for a name. > */ > > - mutex_lock(&dev->object_name_lock); > - if (--obj->handle_count == 0) { > - drm_gem_object_handle_free(obj); > - drm_gem_object_exported_dma_buf_free(obj); > - final = true; > + scoped_guard(mutex, &dev->object_name_lock) { > + if (--obj->handle_count == 0) { > + drm_gem_object_handle_free(obj); > + drm_gem_object_exported_dma_buf_free(obj); > + final = true; > + } > } > - mutex_unlock(&dev->object_name_lock); > > if (final) > drm_gem_object_put(obj); > @@ -374,11 +374,8 @@ drm_gem_object_release_handle(int id, void *ptr, void *data) > if (obj->funcs->close) > obj->funcs->close(obj, file_priv); > > - mutex_lock(&file_priv->prime.lock); > - > - drm_prime_remove_buf_handle(&file_priv->prime, id); > - > - mutex_unlock(&file_priv->prime.lock); > + scoped_guard(mutex, &file_priv->prime.lock) > + drm_prime_remove_buf_handle(&file_priv->prime, id); > > drm_vma_node_revoke(&obj->vma_node, file_priv); > > @@ -1021,37 +1018,34 @@ int drm_gem_change_handle_ioctl(struct drm_device *dev, void *data, There have been a number of revisions to this function recently and you want to make sure that you have the latest. At least the code in v7.1 looks different from yours. > goto out; > } > > - mutex_lock(&file_priv->prime.lock); > + scoped_guard(mutex, &file_priv->prime.lock) { > + spin_lock(&file_priv->table_lock); Could this spin lock also use a guard? Best regards Thomas > + ret = idr_alloc(&file_priv->object_idr, obj, handle, handle + 1, > + GFP_NOWAIT); > + spin_unlock(&file_priv->table_lock); > > - spin_lock(&file_priv->table_lock); > - ret = idr_alloc(&file_priv->object_idr, obj, handle, handle + 1, > - GFP_NOWAIT); > - spin_unlock(&file_priv->table_lock); > + if (ret < 0) > + break; > > - if (ret < 0) > - goto out_unlock; > + if (obj->dma_buf) { > + ret = drm_prime_add_buf_handle(&file_priv->prime, obj->dma_buf, > + handle); > + if (ret < 0) { > + spin_lock(&file_priv->table_lock); > + idr_remove(&file_priv->object_idr, handle); > + spin_unlock(&file_priv->table_lock); > + break; > + } > > - if (obj->dma_buf) { > - ret = drm_prime_add_buf_handle(&file_priv->prime, obj->dma_buf, > - handle); > - if (ret < 0) { > - spin_lock(&file_priv->table_lock); > - idr_remove(&file_priv->object_idr, handle); > - spin_unlock(&file_priv->table_lock); > - goto out_unlock; > + drm_prime_remove_buf_handle(&file_priv->prime, args->handle); > } > > - drm_prime_remove_buf_handle(&file_priv->prime, args->handle); > - } > - > - ret = 0; > - > - spin_lock(&file_priv->table_lock); > - idr_remove(&file_priv->object_idr, args->handle); > - spin_unlock(&file_priv->table_lock); > + ret = 0; > > -out_unlock: > - mutex_unlock(&file_priv->prime.lock); > + spin_lock(&file_priv->table_lock); > + idr_remove(&file_priv->object_idr, args->handle); > + spin_unlock(&file_priv->table_lock); > + } > out: > drm_gem_object_put(obj); > > > base-commit: 72c25183cac9bc584c9de21797a5883af44bcc7a -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)

1 day, 6 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig