Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

122 participants
7042 discussions

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

by André Draszik

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); - 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, -- André Draszik <andre.draszik(a)linaro.org>

2 days, 14 hours

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!

2 days, 17 hours

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.

2 days, 19 hours

[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

3 days, 7 hours

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

by André Draszik

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

[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 days, 8 hours

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.

3 days, 16 hours

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

3 days, 18 hours

Why should you buy a dachshund puppy?

by Chong Criston

3 days, 21 hours

[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

4 days, 7 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig