Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

87 participants
7129 discussions

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

by Matt Evans

Hi all, This series is based on previous RFCs/discussions: Tech topic: https://lore.kernel.org/linux-iommu/20250918214425.2677057-1-amastro@fb.com/ RFCv1: https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/ RFCv2: https://lore.kernel.org/kvm/20260312184613.3710705-1-mattev@meta.com/ The background/rationale is covered in more detail in the RFC cover letters. The TL;DR is: The goal is to enable userspace driver designs that use VFIO to export DMABUFs representing subsets of PCI device BARs, and "vend" those buffers from a primary process to other subordinate processes by fd. These processes then mmap() the buffers and their access to the device is isolated to the exported ranges. This is an improvement on sharing the VFIO device fd to subordinate processes, which would allow unfettered access. This is achieved by enabling mmap() of vfio-pci DMABUFs, passed by fd to subordinate processes. Second, a new revocation mechanism is added to allow the primary process to forcibly revoke access to previously-shared BAR spans, even if the subordinate processes haven't cleanly exited. (The related topic of safe delegation of iommufd control to the subordinate processes is not addressed here, and is follow-up work.) As well as isolation and revocation, another advantage to accessing a BAR through a VMA backed by a DMABUF is that it's straightforward to mmap() the buffer with access attributes, such as write-combining. Feedback from the RFCs requested that, instead of creating DMABUF-specific vm_ops and .fault paths, to go the whole way and migrate the existing VFIO PCI BAR mmap() to be backed by a DMABUF too, resulting in a common vm_ops and fault handler for mmap()s of both the VFIO device and explicitly-exported DMABUFs. This will help future iommufd emulation of VFIO Type1 peer-to-peer, making it easier to get a DMABUF for a VFIO BAR as a DMA target. mmap() conversion to use DMABUF underneath has been done for vfio-pci, but not sub-drivers: nvgrace-gpu's mmap() override path is unchanged; I kept this out of scope for now not least because I don't have a thorough test setup for this system. I would prefer to help the nvgrace-gpu maintainers enable BAR mmap() DMABUFs themselves. Notes on patches ================ PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE Later in the series, vfio-pci's mmap() is going to depend on pcim_p2pdma_provider() which depended on CONFIG_PCI_P2PDMA, which in turn depended on ZONE_DEVICE (which isn't available on 32-bit and some archs, because they lack MEMORY_HOTPLUG and friends). VFIO does _not_ require actual P2P to be present for basic mmap() functionality, only for the optional CONFIG_DMA_SHARED_BUFFER feature. This splits out p2pdma_core.c under CONFIG_PCI_P2PDMA_CORE (which currently contains pcim_p2pdma_provider()), and an optional CONFIG_PCI_P2PDMA which depends on ZONE_DEVICE etc. providing P2P functionality in the existing p2pdma.c. vfio/pci: Add a helper to look up PFNs for DMABUFs vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA The first is for a DMABUF VMA fault handler to determine arbitrary-sized PFNs from ranges in DMABUF. Secondly, refactor DMABUF export for use by the existing export feature and add a helper that creates a DMABUF corresponding to a VFIO BAR mmap() request. vfio/pci: Convert BAR mmap() to use a DMABUF The vfio-pci core mmap() creates a DMABUF with the helper, and the vm_ops fault handler uses the other helper to resolve the fault. Because this depends on DMABUF structs/code, CONFIG_VFIO_PCI_CORE needs to depend on CONFIG_DMA_SHARED_BUFFER. The CONFIG_VFIO_PCI_DMABUF still conditionally enables the export support code. NOTE: The user mmap()s a device fd, but the resulting VMA's vm_file becomes that of the DMABUF. The DMABUF takes ownership of the device and put()s it on release, which maintains the existing behaviour of a VMA keeping the VFIO device open. BAR zapping then happens via the existing vfio_pci_dma_buf_move() path, which now needs to unmap PTEs in the DMABUF's address_space. vfio/pci: Provide a user-facing name for BAR mappings There was a request for decent debug naming in /proc/<pid>/maps etc. comparable to the existing VFIO names: since the VMAs are DMABUFs, they have a "dmabuf:" prefix and can't be 100% identical to before. This is a user-visible change, but this patch at least now gives us extra info on the BDF & BAR being mapped. vfio/pci: Clean up BAR zap and revocation In general (see NOTE!) the vfio_pci_zap_bars() is now obsolete, since it unmaps PTEs in the VFIO device address_space which is now unused. This consolidates all calls (e.g. around reset) with the neighbouring vfio_pci_dma_buf_move()s into new functions, to revoke-zap/unrevoke. This makes the "revoke/un-revoke" steps clearer. NOTE: Because drivers can use their own vm_ops and override .mmap, the core must conservatively assume an overridden .mmap might still add PTEs to the VFIO device address_space and therefore still does the zap. A new flag, zap_bars_on_revoke, enables the zap when .mmap is overridden. A driver that does not need the zap can clear this to opt-out, e.g. if the driver calls down to the common mmap (and so uses DMABUFs). vfio/pci: Support mmap() of a VFIO DMABUF Adds mmap() for a DMABUF fd exported from vfio-pci. It was a goal to keep the VFIO device fd lifetime behaviour unchanged with respect to the DMABUFs. An application can close all device fds, and this will revoke/clean up all DMABUFs; no mappings or other access can be performed now. When enabling mmap() of the DMABUFs, this means access through the VMA is also revoked. This complicates the fault handler because whilst the DMABUF exists, it has no guarantee that the corresponding VFIO device is still alive. Adds synchronisation ensuring the vdev is available before vdev->memory_lock is touched; this holds the device registration so that even if the buffer has been cleaned up, vdev hasn't been freed and so the lock can be safely taken. This commit makes VFIO_PCI_CORE depend on PCI_P2PDMA_CORE (commit 1) to bring in (only) the P2PDMA provider code. vfio/pci: Permanently revoke a DMABUF on request By weight, this is mostly a rename of revoked to an enum, status. There are now 3 states for a buffer, usable and revoked temporary/permanent. A new VFIO feature is added, VFIO_DEVICE_FEATURE_DMA_BUF_REVOKE, which takes a DMABUF (exported from the same device) and permanently revokes it. Thus a userspace driver can guarantee any downstream consumers of a shared fd are prevented from accessing a BAR range, and that range can be reused. NOTE: This might block userspace, waiting on importers to detach. The code doing revocation in vfio_pci_dma_buf_move() is moved, unchanged, to a common function for use by ..._move() and this new feature. vfio/pci: Add mmap() attributes to DMABUF feature Adds a new VFIO feature, VFIO_DEVICE_FEATURE_DMA_BUF_MEMATTR. After a DMABUF is exported, this feature is used to set a memory attribute that will be used by future mmap()s of the DMABUF fd. It doesn't affect existing maps. The default is UC, and via the feature one can specify CPU access as WC. The attribute is an enum/scalar rather than bitmap/cumulative. The attributes follow a "try-fail" model where a client can request an attribute and either succeed or fail with ENOENT if it's unknown; if future attributes are platform-specific then their support can be probed. (Since it's just UC/WC for now, there is no reservation or numeric structure to the namespace yet, but we could support system/arch-specific values in future by carving out base + arch-specific + IMPDEF ranges.) Testing ======= (The [RFC ONLY] userspace test program, for QEMU edu-plus, can be found in the GitHub branch below. It at least illustrates how the export, map, revoke, attribute, and close semantics interoperate.) This code has been tested in mapping DMABUFs of single/multiple ranges from multiple BARs, aliasing mmap()s, aliasing ranges across DMABUFs, vm_pgoff > 0, revocation, shutdown/cleanup scenarios, and hugepage mappings. I've lightly tested WC mappings also (by observing resulting PTEs as having the correct attributes...). No regressions observed on the VFIO selftests, or on our internal vfio-pci applications. VFIO on i386 has been build-tested. End === This is based on VFIO next (e.g. at b9285405c5f6). 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/b9285405c5f6...metamev:linux:dev/m… Thanks for reading, Matt ================================================================================ Change log: v3: - Refactor p2pdma.c: split out pcim_p2pdma_provider() into a new p2pdma_core.c under CONFIG_PCI_P2PDMA_CORE. - vfio_pci_dma_buf_find_pfn() cleanups: Rename parameter to priv, remove bad WARN, move unnecessary addition out of inner loop. - vfio_pci_core_mmap_prep_dmabuf() cleanups: Remove uint32_t, remove unnecessary const variable. - Conversion of BAR mmap() to DMABUF: VFIO_PCI_DMABUF depends on VFIO_PCI_CORE. vfio_pci_mmap_huge_fault(): move dev_dbg() outside of lock (argh), remove READ_ONCE(vdev)/move priv->vdev read and improve comment explanation. - On revoke, BAR zap defaults to on if .mmap is overridden by a driver (and implements an opt-out for the hisi_acc_vfio_pci driver, which overrides mmap() with a simple wrapper that ends up using the common DMABUF mmap() rather than custom mappings). - Reworded commit "vfio/pci: Support mmap() of a VFIO DMABUF" message for clarity. Reworded vfio_pci_mmap_huge_fault() comment for accuracy (vdev validity depends on not being revoked). Added comment in mmap() explaining belt-and-braces approach for early detecting a map of a revoked buffer. - Revoke now uses VFIO_DEVICE_FEATURE_DMA_BUF rather than a new ioctl(); instead of the revoke helper taking 'revoked/permanently' bools, it's become vfio_pci_dma_buf_set_status() taking a single status enum. Added a READ_ONCE() for the lockless test of priv->vdev (flags it as intentional, even if it's in practice going to be a single-copy atomic read). - Removed GET on vfio_pci_core_feature_dma_buf_memattr(), removed unnecessary taking of memory_lock, fixed error return values. In particular, removes ENOTSUPP, and uses ENOENT to indicate an unknown attribute enum value was passed to SET. In the discussion here, https://lore.kernel.org/all/20260602131417.41366391@shazbot.org/ we'd agreed on EOPNOTSUPP before I realised that's already used elsewhere. ENOENT uniquely indicates an unknown attribute. v2: https://lore.kernel.org/all/20260527102319.100128-1-mattev@meta.com/ - Rebase on VFIO next, picking up Alex's vfio_pci_dma_buf_move()/vfio_pci_dma_buf_cleanup() fixes, and dropping "vfio/pci: Fix vfio_pci_dma_buf_cleanup() double-put" - Added "PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE" so that the newly-added vfio-pci hard dependency on the P2PDMA provider instead pulls in the _CORE variant and not the full-fat CONFIG_PCI_P2PDMA. This means that the core of vfio-pci does not need ZONE_DEVICE, but if it's available then enabling P2PDMA in turn enables DMABUF export. Fixes basic VFIO operation on 32b or other platforms without ZONE_DEVICE. - Fixed comment inaccuracy in vfio_pci_dma_buf_revoke() and cleaned up vdev validity test. - vfio_pci_dma_buf_find_pfn(): use PAGE_ALIGN(), better span variable naming, OVF check - Made vm_pgoffs use consistent (keeping the resource index at the top and masking where offset is used). For BAR mmap, use new vma_pgoff_adjust to create the DMABUF with the exact mmap()ed span instead of from the start of the BAR with an invisible portion before the mapping. - Added VFIO_DEVICE_FEATURE_DMA_BUF_MEMATTR to set memory attributes, instead of using the export `flags` field. - vfio_pci_ioctl_reset: Moved vfio_pci_zap_revoke_bars() (effectively, vfio_pci_dma_buf_move()) back after D0 transition. Note, if a BAR zap is needed, it's done in this function so now happens after this D0 transition with the _move; it was done before it at the time of the memory_lock taking. - Minimised vfio_pci_dma_buf_mmap() (removed redundant span check), added READ_ONCE for memattr - Misc fixes: comment in DMABUF name generation, removed superfluous READ_ONCE from faulthandler v1: https://lore.kernel.org/kvm/20260416131815.2729131-1-mattev@meta.com/ - Cleanup of the common DMABUF-aware VMA vm_ops fault handler and export code. - Fixed a lot of races, particularly faults racing with DMABUF cleanup (if the VFIO device fds close, for example). - Added nicer human-readable names for VFIO mmap() VMAs RFCv2: Respin based on the feedback/suggestions: https://lore.kernel.org/kvm/20260312184613.3710705-1-mattev@meta.com/ - Transform the existing VFIO BAR mmap path to also use DMABUFs behind the scenes, and then simply share that code for explicitly-mapped DMABUFs. Jason wanted to go that direction to enable iommufd VFIO type 1 emulation to pick up a DMABUF for an IO mapping. - Revoke buffers using a VFIO device fd ioctl RFCv1: https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/ Matt Evans (9): PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE vfio/pci: Add a helper to look up PFNs for DMABUFs vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA vfio/pci: Convert BAR mmap() to use a DMABUF vfio/pci: Provide a user-facing name for BAR mappings vfio/pci: Clean up BAR zap and revocation vfio/pci: Support mmap() of a VFIO DMABUF vfio/pci: Permanently revoke a DMABUF on request vfio/pci: Add mmap() attributes to DMABUF feature MAINTAINERS | 2 +- drivers/pci/Kconfig | 10 +- drivers/pci/Makefile | 1 + drivers/pci/p2pdma.c | 109 +--- drivers/pci/p2pdma.h | 29 + drivers/pci/p2pdma_core.c | 118 ++++ drivers/vfio/pci/Kconfig | 5 +- drivers/vfio/pci/Makefile | 3 +- .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c | 8 + drivers/vfio/pci/vfio_pci_config.c | 30 +- drivers/vfio/pci/vfio_pci_core.c | 213 +++++-- drivers/vfio/pci/vfio_pci_dmabuf.c | 564 +++++++++++++++--- drivers/vfio/pci/vfio_pci_priv.h | 64 +- include/linux/pci-p2pdma.h | 24 +- include/linux/pci.h | 2 +- include/linux/vfio_pci_core.h | 1 + include/uapi/linux/vfio.h | 47 ++ 17 files changed, 958 insertions(+), 272 deletions(-) create mode 100644 drivers/pci/p2pdma.h create mode 100644 drivers/pci/p2pdma_core.c -- 2.50.1 (Apple Git-155)

3 weeks

[PATCH] dma-fence: Make dma_fence_dedup_array() robust against 0-count input

by Baineng Shou

dma_fence_dedup_array() returns 1 when called with num_fences == 0: the for-loop body never executes, j stays at 0, and the final `return ++j` yields 1. This contradicts both the kernel-doc ("Return: Number of unique fences remaining in the array") and the natural expectation that 0 input gives 0 output. All in-tree callers currently filter num_fences == 0 before invoking this helper (__dma_fence_unwrap_merge() bails out via the `if (count == 0 || count == 1)` fast path; amdgpu_userq_wait_*() cannot reach the dedup call with a zero local count because the amdgpu_userq_wait_add_fence() helper guarantees num_fences stays in [0, wait_info->num_fences], and wait_info->num_fences > 0 is enforced at the ioctl entry). However, dma_fence_dedup_array() is EXPORT_SYMBOL_GPL, so any future caller that forgets to pre-filter the zero case will get a misleading return value of 1. Depending on how that caller uses the result, it could dereference an uninitialized fence slot in the array, since the caller's array may have been allocated but not yet populated. Make the contract match the documentation by returning 0 early. This also skips an unnecessary sort() call on an empty array. Signed-off-by: Baineng Shou <shoubaineng(a)gmail.com> --- drivers/dma-buf/dma-fence-unwrap.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/dma-buf/dma-fence-unwrap.c b/drivers/dma-buf/dma-fence-unwrap.c index 53bb40e70b27..364cbf79ad73 100644 --- a/drivers/dma-buf/dma-fence-unwrap.c +++ b/drivers/dma-buf/dma-fence-unwrap.c @@ -97,6 +97,9 @@ int dma_fence_dedup_array(struct dma_fence **fences, int num_fences) { int i, j; + if (!num_fences) + return 0; + sort(fences, num_fences, sizeof(*fences), fence_cmp, NULL); /* -- 2.34.1

3 weeks

[PATCH v2] dma-buf: dma-fence: Fix potential NULL pointer dereference

by Philipp Stanner

The commit mentioned in the fixes tag below introduced a mechanism through which fence producers can fully decouple from fence consumers. This, desirable, mechanism is based on the fence's signaled-bit as the "decoupling point". A sophisticated interaction between RCU and atomic instructions attempts to ensure that fence consumers can still interact with fence producers through the dma_fence_ops (callback pointers into the producer). This is the desired behavior: to check for decoupling, the signaled-bit is first checked. If it's not yet signaled, RCU ensures that the ops pointer cannot yet be NULL. Hereby, dma_fence_signal_timestamp_locked() first sets the signaled-bit, and then sets the ops pointer to NULL. Readers first load the ops pointer, and then check through the signaled-bit whether the pointer can legally be accessed. These set and load operations could occur out of order on weakly ordered platforms. This problem can be solved very elegantly by using the ops pointer itself as the synchronization point. The pointer is either NULL, or cannot become NULL while it is being used thanks to RCU. Replace the signaled-bit check in dma_fence_timeline_name() and dma_fence_driver_name(). Cc: stable(a)vger.kernel.org Fixes: f4cc3ab824d6 ("dma-buf: protected fence ops by RCU v8") Signed-off-by: Philipp Stanner <phasta(a)kernel.org> --- Changes since v1: - Use ops pointer instead of memory barriers. (Christian) - Rephrase commit message. --- drivers/dma-buf/dma-fence.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index c7ea1e75d38a..0a025dfdf131 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -1170,7 +1170,7 @@ const char __rcu *dma_fence_driver_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)) + if (ops) return (const char __rcu *)ops->get_driver_name(fence); else return (const char __rcu *)"detached-driver"; @@ -1203,7 +1203,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)) + if (ops) return (const char __rcu *)ops->get_driver_name(fence); else return (const char __rcu *)"signaled-timeline"; base-commit: cdeb2ccd993ed8647adbbda2c3b103aa717fd6f7 -- 2.54.0

3 weeks

Shred Some Slopes: Getting the Hang of Snow Rider 3D

by careful.earthworm.usil＠hidingmail.com

Feeling the need for speed and a bit of winter fun, even when the weather outside is frightful? Then maybe it’s time to check out Snow Rider 3D. This simple but surprisingly addictive game offers a thrill of downhill skiing and snowboarding right from your browser, no downloads required. Let’s break down how to jump in and start enjoying this surprisingly engaging title. https://snowriderfree.com/ Gameplay: Simple Controls, Endless Possibilities The core gameplay of Snow Rider 3D is deceptively straightforward. You control your character's direction using the left and right arrow keys (or A and D). Your objective? Navigate through a series of procedurally generated slopes littered with obstacles. These obstacles range from simple ramps and rails to more challenging hazards like trees, snowdrifts, and even abandoned shacks. The beauty of Snow Rider 3D lies in its physics. While simple, they feel surprisingly realistic. You'll need to anticipate turns, adjust your speed, and time your jumps to successfully navigate the terrain. A crash will reset you to the beginning of the course, so precision and patience are key. The game offers different levels, each presenting a unique challenge. Some focus on speed and long jumps, while others demand skillful maneuvering through tight spaces. As you progress, you unlock new skins and sleds, adding a touch of customization to your experience. Think of it as a casual time-killer that can quickly turn into an hour-long obsession! Tips for Mastering the Mountain: Alright, so you're ready to hit the slopes. Here are a few tips to help you improve your runs and avoid those frustrating wipeouts: Practice Makes Perfect: Don't get discouraged by early crashes. The more you play, the better you'll understand the physics and learn to anticipate the terrain. Master the Turns: Smooth, controlled turns are essential for maintaining speed and avoiding obstacles. Practice feathering the arrow keys to make subtle adjustments. Timing is Everything: When approaching jumps and ramps, pay close attention to your speed and angle. A well-timed jump can make all the difference. Don't Be Afraid to Slow Down: Sometimes, the fastest route isn't the safest. Don't be afraid to ease off the gas and navigate tricky sections with caution. Consider looking up guides for specific levels of Snow Rider 3D at websites like Snow Rider 3D if you’re really struggling. Experiment with Sleds and Skins: Different sleds may offer slight variations in handling. Try out different options to find one that suits your playstyle. Conclusion: A Fun and Accessible Winter Escape Snow Rider 3D is a surprisingly addictive and accessible game that’s perfect for a quick dose of winter fun. It's simple controls and challenging gameplay make it easy to pick up and play, while its procedural generation ensures that each run is a unique experience. So, whether you're looking for a casual time-killer or a challenging skill-based game, Snow Rider 3D is definitely worth checking out.

3 weeks

Bake Your Way to Billions: A Look at the Addictive World of Store Management Games

by hot.meerkat.lloh＠hidingmail.net

Ever dreamed of running your own bustling enterprise, watching your profits soar, and building an empire from humble beginnings? If so, you've likely stumbled upon the fascinating and surprisingly addictive world of store management games. These titles offer a unique blend of strategy, incremental growth, and the satisfying feeling of seeing your hard work pay off. And when it comes to the purest, most delightful form of this genre, one game stands out: https://cookieclickers.io/ The Sweet Simplicity of Cookie Clicker: A Gateway to Management At its heart, Cookie Clicker is incredibly simple. You start with a single, humble cookie, and your goal is to click it to generate more cookies. These initial clicks are crucial, as they fund your first upgrades. Soon, you’ll be able to purchase "grandmas," who automatically bake cookies for you, freeing up your clicking finger. From there, the sky's the limit! You'll acquire farms, factories, mines, and even portals to other dimensions, all dedicated to the singular purpose of baking more and more cookies. What makes Cookie Clicker so captivating is its elegant progression system. Each new upgrade and building provides a tangible boost to your cookie production, creating a satisfying feedback loop. The numbers on your screen grow exponentially, transforming from humble dozens to mind-boggling septillions and beyond. It’s a masterclass in incremental design, making every new purchase feel impactful and exciting. Beyond the Click: Strategic Thinking and Exponential Growth While the initial appeal of Cookie Clicker might be the simple act of clicking, true mastery lies in strategic decision-making. As your cookie empire expands, you'll be faced with choices: Upgrade Prioritization: Should you invest in another Grandma, a new farm, or a powerful upgrade that boosts all your existing structures? Understanding the cost-benefit analysis of each option is key. Synergies: Many upgrades have synergistic effects, meaning they become more powerful when paired with specific buildings. Discovering these combinations is a delightful puzzle. Ascension and Prestige: Eventually, you’ll unlock the ability to “ascend,” resetting your game but granting you powerful "heavenly chips" that provide permanent bonuses. This meta-progression adds a whole new layer of long-term strategy, encouraging you to rethink your approach with each new playthrough. These elements elevate Cookie Clicker from a simple clicking game to a genuinely engaging management simulation. It teaches you about exponential growth, compound interest (in a fun, cookie-filled way!), and the satisfaction of building something from nothing. Tips for Aspiring Cookie Tycoons If you’re ready to dive into the sweet, sweet world of Cookie Clicker, here are a few friendly tips to get you started: Don't Be Afraid to Click! In the early game, your clicks are your most valuable resource. Keep that finger moving! Invest in Grandmas Early: They're your first step towards automation and a steady cookie income. Always Buy Upgrades: The small boosts they provide add up quickly and are often more cost-effective than new buildings in the short term. Look for Golden Cookies: These appear randomly and offer temporary, powerful buffs. Clicking them can drastically boost your production! Consider Ascending: While it seems daunting to reset your progress, the permanent bonuses you gain make future runs much faster and more efficient. The Endless Appeal of Automation Cookie Clicker, and store management games in general, tap into a fundamental human desire: the joy of creation and the satisfaction of watching systems work efficiently. There's a particular kind of quiet pleasure in setting up a well-oiled machine and observing its output multiply. So, if you're looking for a game that's easy to pick up, surprisingly deep, and immensely satisfying, give Cookie Clicker a try. You might just find yourself baking billions before you know it!

3 weeks, 1 day

[PATCH] fix: dma-buf: fence_chains_init: error unwind path leaks enable_sw_signaling reference

by WenTao Liang

dma_fence_enable_sw_signaling acquires an extra reference on each chain fence. The error unwind loop calls dma_fence_put only once per chain/fence without first signaling the fence to trigger the callback that releases the signaling reference. This prevents the chain fence kref from reaching 0, permanently leaking the chain and its contained fence. Cc: stable(a)vger.kernel.org Fixes: dc2f7e67a28a ("dma-buf: Exercise dma-fence-chain under selftests") Signed-off-by: WenTao Liang <vulab(a)iscas.ac.cn> --- drivers/dma-buf/st-dma-fence-chain.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/st-dma-fence-chain.c b/drivers/dma-buf/st-dma-fence-chain.c index 821023dd34df..7dc18e294387 100644 --- a/drivers/dma-buf/st-dma-fence-chain.c +++ b/drivers/dma-buf/st-dma-fence-chain.c @@ -152,7 +152,10 @@ static int fence_chains_init(struct fence_chains *fc, unsigned int count, unwind: for (i = 0; i < count; i++) { - dma_fence_put(fc->fences[i]); + if (fc->fences[i]) { + dma_fence_signal(fc->fences[i]); + dma_fence_put(fc->fences[i]); + } dma_fence_put(fc->chains[i]); } kvfree(fc->fences); -- 2.39.5 (Apple Git-154)

3 weeks, 1 day

WIZARD GEO COORDINATES RECOVERY HACKER

by lf2225258＠gmail.com

RECOVER YOUR STOLEN CRYPTO / BTC / USDT / ETH WITH THE HELP OF "WIZARD GEO COORDINATES RECOVERY HACKER" I am writing to sincerely express my appreciation for your support and assistance during a very difficult time in my life. Your professionalism and dedication in helping me recover my lost bitcoin. Throughout the entire process, they remained professional and respectful. They were also able to explain difficult technical topics in a simple way, which helped me understand what was happening. Thank you once again for your commitment. I am grateful for your help and wish you continued success in all that you do. Highly recommend his services to anyone who needs his services. CONTACT THEM VIA Email: geovcoordinateshacker(a)gmail.com WhatsApp ( +1 ( 318 ) 203-3657 ) Telegram @Geocoordinateshacker Website: https://geovcoordinateshac.wixsite.c...ordinates-hack I never would have imagined that I could recover my stolen bitcoin to my wallet after losing everything to a fake investment platform.

3 weeks, 1 day

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 )

3 weeks, 2 days

Re: [PATCH] fix: dma-buf: unwrap_merge_complex: dma_fence_get_stub reference leaked on all paths

by Christian König

On 6/26/26 14:28, WenTao Liang wrote: > dma_fence_get_stub() acquires an extra reference on the global stub > fence, but this reference is never released on any execution path. The > stub fence is filtered out inside dma_fence_unwrap_merge (already > signaled), so the extra reference is never consumed. Both success and > error paths fail to call dma_fence_put on the stub. > > Cc: stable(a)vger.kernel.org > Fixes: 245a4a7b531c ("dma-buf: generalize dma_fence unwrap & merging v3") Just drop that, the stub fence is a global dummy and leaking reference to it is harmless. But just in case somebody uses this code as blueprint for this own implementation we should probably clean it up. > Signed-off-by: WenTao Liang <vulab(a)iscas.ac.cn> Reviewed-by: Christian König <christian.koenig(a)amd.com> > --- > drivers/dma-buf/st-dma-fence-unwrap.c | 11 +++++++---- > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/drivers/dma-buf/st-dma-fence-unwrap.c b/drivers/dma-buf/st-dma-fence-unwrap.c > index 72ca632e3981..b9ed85570211 100644 > --- a/drivers/dma-buf/st-dma-fence-unwrap.c > +++ b/drivers/dma-buf/st-dma-fence-unwrap.c > @@ -483,7 +483,7 @@ static int unwrap_merge_order(void *arg) > > static int unwrap_merge_complex(void *arg) > { > - struct dma_fence *fence, *f1, *f2, *f3, *f4, *f5; > + struct dma_fence *fence, *f1, *f2, *f3, *f4, *f5, *stub; > struct dma_fence_unwrap iter; > int err = -ENOMEM; > > @@ -508,10 +508,11 @@ static int unwrap_merge_complex(void *arg) > if (!f4) > goto error_put_f3; > > + stub = dma_fence_get_stub(); > /* Signaled fences should be filtered, the two arrays merged. */ > - f5 = dma_fence_unwrap_merge(f3, f4, dma_fence_get_stub()); > + f5 = dma_fence_unwrap_merge(f3, f4, stub); > if (!f5) > - goto error_put_f4; > + goto error_put_stub; > > err = 0; > dma_fence_unwrap_for_each(fence, &iter, f5) { > @@ -532,8 +533,10 @@ static int unwrap_merge_complex(void *arg) > err = -EINVAL; > } > > + dma_fence_put(stub); > dma_fence_put(f5); > -error_put_f4: > +error_put_stub: > + dma_fence_put(stub); > dma_fence_put(f4); > error_put_f3: > dma_fence_put(f3);

3 weeks, 2 days

[PATCH] fix: dma-buf: unwrap_merge_complex: dma_fence_get_stub reference leaked on all paths

by WenTao Liang

dma_fence_get_stub() acquires an extra reference on the global stub fence, but this reference is never released on any execution path. The stub fence is filtered out inside dma_fence_unwrap_merge (already signaled), so the extra reference is never consumed. Both success and error paths fail to call dma_fence_put on the stub. Cc: stable(a)vger.kernel.org Fixes: 245a4a7b531c ("dma-buf: generalize dma_fence unwrap & merging v3") Signed-off-by: WenTao Liang <vulab(a)iscas.ac.cn> --- drivers/dma-buf/st-dma-fence-unwrap.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/dma-buf/st-dma-fence-unwrap.c b/drivers/dma-buf/st-dma-fence-unwrap.c index 72ca632e3981..b9ed85570211 100644 --- a/drivers/dma-buf/st-dma-fence-unwrap.c +++ b/drivers/dma-buf/st-dma-fence-unwrap.c @@ -483,7 +483,7 @@ static int unwrap_merge_order(void *arg) static int unwrap_merge_complex(void *arg) { - struct dma_fence *fence, *f1, *f2, *f3, *f4, *f5; + struct dma_fence *fence, *f1, *f2, *f3, *f4, *f5, *stub; struct dma_fence_unwrap iter; int err = -ENOMEM; @@ -508,10 +508,11 @@ static int unwrap_merge_complex(void *arg) if (!f4) goto error_put_f3; + stub = dma_fence_get_stub(); /* Signaled fences should be filtered, the two arrays merged. */ - f5 = dma_fence_unwrap_merge(f3, f4, dma_fence_get_stub()); + f5 = dma_fence_unwrap_merge(f3, f4, stub); if (!f5) - goto error_put_f4; + goto error_put_stub; err = 0; dma_fence_unwrap_for_each(fence, &iter, f5) { @@ -532,8 +533,10 @@ static int unwrap_merge_complex(void *arg) err = -EINVAL; } + dma_fence_put(stub); dma_fence_put(f5); -error_put_f4: +error_put_stub: + dma_fence_put(stub); dma_fence_put(f4); error_put_f3: dma_fence_put(f3); -- 2.39.5 (Apple Git-154)

3 weeks, 3 days

← Newer
1
...
8
9
10
11
12
13
14
...
713
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig