Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

62 participants
6642 discussions

Pips Game Guide Complete Strategy Tips and Winning Methods Explained

by advanced.finch.jkak＠hidingmail.net

What Pips Game Is About Pips is a modern digital puzzle game that focuses on logic, pattern recognition, and quick decision making. The core idea is to complete tasks or solve challenges by placing or matching elements in a structured environment. Each level increases in difficulty and requires more attention to detail. https://pipsly.io/ Core Appeal of Pips The appeal of Pips comes from its simple start and gradually complex gameplay. Early stages are easy to understand, while later stages demand deeper thinking. This balance makes Pips suitable for both new players and experienced puzzle fans. How to Play Pips Game Basic Gameplay Rules In Pips, the main objective is to interact with puzzle elements and complete specific conditions required by each level. Players must analyze the layout and decide the best moves to achieve the goal in the most efficient way. Step by Step Progression The game usually follows a level based system. Each stage presents a new challenge that builds on previous mechanics. Players progress by solving puzzles correctly and unlocking new stages. Precision and observation are key factors for success. Core Mechanics in Pips Game Pattern Recognition System A major mechanic in Pips is identifying patterns. Players must observe repeating structures and predict outcomes based on visual clues. This helps in solving complex puzzles faster and more accurately. Logic Based Decision Making Every action in Pips requires logical thinking. Random moves often lead to failure or inefficient solutions. Players are encouraged to evaluate all possible outcomes before making a move. Progressive Difficulty Design The difficulty in Pips increases gradually. Early levels focus on teaching basic mechanics, while later levels introduce more complex combinations and constraints. This progression helps maintain engagement over time. Strategies for Winning in Pips Game Careful Planning Before Moves One of the most effective strategies in Pips is planning before acting. Observing the full puzzle layout before making any decision helps avoid mistakes and reduces unnecessary steps. Focus on Efficiency Efficiency is important in Pips. Completing levels with fewer moves or faster decisions often leads to better results. Players should aim to find the most direct solution instead of trial and error approaches. Learning From Repeated Attempts Failure is part of the learning process in Pips. Each attempt provides new information about puzzle structure. By analyzing previous mistakes, players can improve their future performance. Common Mistakes in Pips Game Random Movements Without Strategy A frequent mistake is making random moves without understanding the puzzle. This often leads to confusion and longer completion time. Structured thinking is more effective. Ignoring Visual Clues Pips provides visual hints that guide players toward solutions. Ignoring these clues can make puzzles much harder than intended. Careful observation is essential. Rushing Through Levels Speed without accuracy can reduce success in Pips. Rushing often causes errors that require restarting the level. A balanced approach is recommended for better results. Advanced Tips for Pips Game Mastering Pattern Prediction Advanced players improve by predicting patterns before they fully appear. This skill helps in solving higher difficulty levels with greater consistency. Adapting to New Mechanics Quickly As new mechanics are introduced, flexibility becomes important. Players who adapt quickly to changes in rules or structure perform better in later stages. Combining Multiple Strategies High level gameplay in Pips often requires combining several strategies. Logical analysis, pattern recognition, and efficiency planning must work together for optimal performance. Why Pips Game Attracts Players Simple Yet Deep Gameplay Pips attracts attention because it is easy to start but difficult to master. This combination creates long term interest and encourages repeated play. Rewarding Puzzle Experience Each solved level provides a sense of achievement. The satisfaction of completing complex puzzles motivates continued engagement. Suitable for All Skill Levels Pips is designed for a wide range of players. Beginners can enjoy early levels, while advanced players can challenge themselves with more complex stages. Final Thoughts on Pips Game Long Term Engagement Value Pips offers long term entertainment through its evolving puzzle structure. Continuous updates or level variations can keep the experience fresh and engaging. Skill Development Benefits Playing Pips can help improve logical thinking, pattern recognition, and decision making skills. These benefits extend beyond the game environment. Overall Experience Summary Pips stands out as a thoughtful puzzle game that balances simplicity and depth. Its structured design and increasing challenge levels make it appealing for puzzle enthusiasts who enjoy strategic thinking and problem solving.

1 hour, 20 minutes

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

by Pranjal Shrivastava

On Wed, Jun 10, 2026 at 04:43:15PM +0100, Matt Evans wrote: > The P2PDMA code currently provides two features under the same > CONFIG_PCI_P2PDMA option: > > 1. Locate providers via pcim_p2pdma_provider() > 2. Manage actual P2P DMA > > Some drivers (such as vfio-pci) depend on 1, without having a hard > dependency on 2. > > A future commit expands the use of DMABUF in vfio-pci for non-P2P > scenarios, relying on pcim_p2pdma_provider() always being present. If > that depended on CONFIG_PCI_P2PDMA, it would make vfio-pci only > available if CONFIG_ZONE_DEVICE is present (e.g. 64-bit systems), even > when P2P is not needed. > > To resolve this, introduce CONFIG_PCI_P2PDMA_CORE and refactor the > basic provider functionality into a new p2pdma_core.c file. This is > available even if the CONFIG_PCI_P2PDMA feature is disabled (or > unavailable due to !CONFIG_ZONE_DEVICE). Then, drivers can enable any > additional P2P features with the original CONFIG_PCI_P2PDMA (available > when CONFIG_ZONE_DEVICE is set). > > Signed-off-by: Matt Evans <matt(a)ozlabs.org> > --- > 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 +++++++++++++++++++++++++++++++++++++ > include/linux/pci-p2pdma.h | 24 ++++---- > include/linux/pci.h | 2 +- > 8 files changed, 174 insertions(+), 121 deletions(-) > create mode 100644 drivers/pci/p2pdma.h > create mode 100644 drivers/pci/p2pdma_core.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index c2c6d79275c6..b21523b3bd8b 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -20617,7 +20617,7 @@ B: https://bugzilla.kernel.org > C: irc://irc.oftc.net/linux-pci > T: git git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git > F: Documentation/driver-api/pci/p2pdma.rst > -F: drivers/pci/p2pdma.c > +F: drivers/pci/p2pdma* > F: include/linux/pci-p2pdma.h > > PCI POWER CONTROL > diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig > index 33c88432b728..59d70bc84cc9 100644 > --- 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? With the nit (and Bjorn's comments addressed) Reviewed-by: Pranjal Shrivastava <praan(a)google.com> Thanks, Praan

2 hours, 16 minutes

Rolling into the Fun: A Guide to the Addictive World of Slope Game

by specific.salmon.rrgs＠hidingmail.net

Ever found yourself in need of a quick, engaging, and surprisingly challenging game that you can jump into anytime, anywhere? Look no further than the captivating world of Slope Game. This seemingly simple title offers a deceptively deep experience, testing your reflexes and spatial awareness in a way that’s both frustrating and incredibly rewarding. If you've never rolled into its vibrant, geometric landscapes, you're in for a treat! https://slopegamefree.com/ Gameplay: Master the Art of the Tilt Playing Slope Game is refreshingly straightforward. Your primary objective is to keep your ball from falling off the edges of the platforms or colliding with red obstacles. The ball is always moving forward, and your only controls are to steer it left or right. Steering: On a desktop, you'll typically use the A and D keys or the left and right arrow keys to shift the ball's direction. On mobile devices, it’s often a touch-and-drag or tilt-to-steer mechanism. The key is subtlety. Small, precise adjustments are far more effective than wild, sweeping movements, which will often send your ball careening off the edge. Speed: The ball constantly gains speed, which is where the real challenge lies. As you progress, the platforms become narrower, the gaps wider, and the red obstacles more frequent. What was a gentle curve at the start becomes a frantic maneuver later on. Obstacles: Keep a keen eye out for the static and sometimes moving red blocks. Touching these spells instant doom. Learning their patterns and anticipating their appearance is crucial for long-term survival. Tips for Rolling Success While it may seem like pure luck at first, there are definite strategies you can employ to improve your high score: Focus on the Path Ahead: Don't just look at where your ball is; always be scanning the screen for what's coming up next. This allows you to plan your turns and avoid sudden surprises. Small Adjustments are Key: Resist the urge to oversteer. Gentle taps or small nudges are almost always more effective than holding down a direction key, especially as your speed increases. Embrace the Center: Whenever possible, try to keep your ball centered on the path. This gives you the most leeway for unexpected obstacles or sudden turns. Learn from Your Fails: Every time you fall, take a moment to understand why. Did you oversteer? Miss an obstacle? Knowing your weaknesses will help you avoid repeating the same mistakes. Practice Makes Perfect: Like any skill-based game, consistent practice is the best way to improve. Your reflexes will sharpen, and your muscle memory for precise steering will develop over time. Conclusion: A Simple Game, Endless Fun Slope Game embodies the beauty of simplicity in game design. It doesn't rely on flashy graphics or complex storylines, but rather on addictive gameplay that challenges your reflexes and keeps you coming back for "just one more run." Whether you have a few minutes to spare or an hour to dedicate, this game offers a rewarding and endlessly replayable experience. So, if you're looking for a fun and engaging way to test your agility, give Slope Game a try – you might just find your new favorite time-waster.

3 hours, 22 minutes

Unlocking the Joy of Spatial Puzzles: A Deep Dive into Block Blast

by yappy.mink.rxln＠hidingmail.net

Feeling the itch for a satisfying puzzle challenge? Look no further than games like Block Blast. These engaging tile-matching experiences offer a delightful blend of strategy and spatial reasoning, perfect for a quick mental workout or a longer, relaxing session. Let's explore how to get the most out of these captivating games. https://blockblasts.io/ Introduction: What is Block Blasting? At its core, a block-blasting game is about clearing a grid by strategically placing various-shaped blocks. Imagine a blend of Tetris and a jigsaw puzzle, where your goal isn't just to complete lines, but to eliminate entire clusters of blocks. The beauty lies in its simplicity: no complex narratives or intricate controls, just pure, unadulterated puzzle-solving fun. Many versions of this game exist, but for this article, we’ll be focusing on a general approach that applies to most variations, including Block Blast itself. Gameplay: The Fundamentals of Cube Clearing The basic premise is straightforward. You're presented with a grid, typically 8x8 or 10x10, and a queue of three randomly generated blocks at the bottom of your screen. Your task is to drag and drop these blocks onto the grid. The magic happens when you form a complete horizontal or vertical line (or sometimes both) with your placed blocks. Once a line is complete, it disappears, freeing up space and earning you points. The challenge intensifies as the grid fills up. If you run out of space to place any of the three available blocks, the game ends. This creates a constant tension and encourages careful planning. Some games also feature special blocks – perhaps a bomb that clears a small area, or a rotating block that offers more placement options. These additions add another layer of strategic depth, keeping the gameplay fresh and exciting. Tips for Becoming a Block Blast Champion While Block Blast is easy to pick up, mastering it requires a bit of strategy. Here are a few tips to help you maximize your scores and playtime: Look Ahead: Always consider the next few blocks in your queue. Don't just place a block to clear one line if it compromises your ability to place subsequent, larger blocks. Keep the Center Clear: It's tempting to fill up the edges first, but an open center gives you far more flexibility for larger, irregularly shaped blocks. Prioritize Large Blocks: While clearing single lines is good, try to set up opportunities to clear multiple lines simultaneously, or to use your larger blocks effectively. Don't Be Afraid to Sacrifice: Sometimes, you might need to place a block in a less-than-ideal spot to avoid an immediate game over. It's about damage control. Identify Patterns: As you play more, you'll start to recognize common block combinations and how they fit together best. Practice truly makes perfect here. Utilize Special Blocks Wisely: If your game has them, don't just use special blocks impulsively. Save bombs for truly sticky situations, or use rotators to maximize space. Conclusion: A Refreshing Puzzle Experience Games like Block Blast offer a genuinely enjoyable and mentally stimulating experience. They're easy to pick up, yet provide endless opportunities for strategic refinement. Whether you're looking to unwind after a long day or sharpen your problem-solving skills, these block-clearing puzzles are a fantastic choice. So, what are you waiting for? Dive in and start blasting those blocks!

3 hours, 28 minutes

[PATCH net-next v2 0/4] net: devmem: allow rx-buf-size > PAGE_SIZE per binding

by Bobby Eshleman

Every devmem dmabuf binding hands the page_pool PAGE_SIZE niovs today. On NICs that consume one descriptor per netmem, this caps a single RX descriptor at PAGE_SIZE and burns CPU on buffer churn. In this series, we add a bind-time netlink attribute, NETDEV_A_DMABUF_RX_BUF_SIZE, that lets userspace request a larger niov size (power of two >= PAGE_SIZE). Drivers must opt in via queue_mgmt_ops.QCFG_RX_PAGE_SIZE. Selftests use udmabuf, but udmabuf sgtables were previously hardcoded to PAGE_SIZE. This series modifies udmabuf to respect folio sizes in its exported sgtable. The result is that when backing udmabuf with MFD_HUGETLB 2MB pages, the sgtable is populated with 2MB entries, allowing devmem's gen_pool to carve out large (eg. 64K) niovs. Measurements ------------ Setup: kperf devmem RX/TX cuda, 4 flows, 64 MB messages, 60s, dctcp, num-rx-queues=4, dmabuf-rx/tx-size-mb=2048, 10 runs per niov size, mlx5. niov RX dev Gbps RX flow avg Gbps app sys % ----- ---------------- ----------------- ---------------- 4K 300.63 +/- 53.21 75.16 +/- 13.30 54.15 +/- 10.23 16K 321.35 +/- 28.20 80.34 +/- 7.05 41.05 +/- 8.87 32K 347.63 +/- 2.20 86.91 +/- 0.55 44.54 +/- 3.51 64K 332.11 +/- 14.26 83.03 +/- 3.56 35.47 +/- 3.11 RX app sys % drops ~19% from 4K to 64K. kperf support (not yet merged): https://github.com/facebookexperimental/kperf/commit/8837577f920876bce6986e… Signed-off-by: Bobby Eshleman <bobbyeshleman(a)meta.com> --- Changes in v2: - Use NL_SET_ERR_MSG_FMT for sg alignment failure details (Stan) - Keep -E2BIG (not a direct ask, but seemed preferred, Stan) - Update udmabuf commit message and comments explaining why "one sg ent per folio" is useful (Christian) - Set/restore nr_hugepages in py harness (Stan) - Link to v1: https://lore.kernel.org/r/20260603-tcpdm-large-niovs-v1-0-f37a4ac6726c@meta… --- Bobby Eshleman (4): net: devmem: allow rx-buf-size > PAGE_SIZE per dmabuf binding udmabuf: emit one sg entry per pinned folio selftests/net: ncdevmem: add -b option to set rx-buf-size on bind selftests/net: devmem.py: add check_rx_large_niov Documentation/netlink/specs/netdev.yaml | 8 +++ drivers/dma-buf/udmabuf.c | 52 +++++++++++++++++-- include/uapi/linux/netdev.h | 1 + net/core/devmem.c | 51 +++++++++++-------- net/core/devmem.h | 13 +++-- net/core/netdev-genl-gen.c | 5 +- net/core/netdev-genl.c | 19 ++++++- tools/include/uapi/linux/netdev.h | 1 + tools/testing/selftests/drivers/net/hw/config | 1 + tools/testing/selftests/drivers/net/hw/devmem.py | 12 ++++- .../testing/selftests/drivers/net/hw/devmem_lib.py | 58 +++++++++++++++++++++- tools/testing/selftests/drivers/net/hw/ncdevmem.c | 49 ++++++++++++++++-- .../testing/selftests/drivers/net/hw/nk_devmem.py | 11 +++- 13 files changed, 238 insertions(+), 43 deletions(-) --- base-commit: 518d8d0199538a4d6d5e51064044ece71e0c42e7 change-id: 20260602-tcpdm-large-niovs-56523a3a1077 Best regards, -- Bobby Eshleman <bobbyeshleman(a)meta.com>

7 hours, 57 minutes

MUYERN TRUST HAC KER || Private Digital Security

by priyankaragade6＠gmail.com

If you have lost cryptocurrency to fraud, hacks, or scams, time is critical. The faster you act, the higher the chance of recovery. You do not have to face this alone. Join the thousands of clients who have reclaimed their financial freedom with MUYERN TRUST HACKER. Ready to Start Your Recovery? Contact our specialist team today for a confidential, no-obligation case assessment. What App: [ +1.2.0.2.7.0.3.2.2.3.9 ]

9 hours, 16 minutes

MUYERN TRUST HAC KER || Private Digital Security

by priyankaragade6＠gmail.com

9 hours, 17 minutes

Re: [PATCH v3 2/9] vfio/pci: Add a helper to look up PFNs for DMABUFs

by Pranjal Shrivastava

On Wed, Jun 10, 2026 at 04:43:16PM +0100, Matt Evans wrote: > Add vfio_pci_dma_buf_find_pfn(), which a VMA fault handler can use to > find a PFN. > > This supports multi-range DMABUFs, which typically would be used to > represent scattered spans but might even represent overlapping or > aliasing spans of PFNs. > > Because this is intended to be used in vfio_pci_core.c, we also need > to expose the struct vfio_pci_dma_buf in the vfio_pci_priv.h header. > > Signed-off-by: Matt Evans <matt(a)ozlabs.org> > --- > drivers/vfio/pci/vfio_pci_dmabuf.c | 137 ++++++++++++++++++++++++++--- > drivers/vfio/pci/vfio_pci_priv.h | 20 +++++ > 2 files changed, 144 insertions(+), 13 deletions(-) > > diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c > index c16f460c01d6..9e5e865f6fb6 100644 > --- a/drivers/vfio/pci/vfio_pci_dmabuf.c > +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c > @@ -9,19 +9,6 @@ > > MODULE_IMPORT_NS("DMA_BUF"); > > -struct vfio_pci_dma_buf { > - struct dma_buf *dmabuf; > - struct vfio_pci_core_device *vdev; > - struct list_head dmabufs_elm; > - size_t size; > - struct phys_vec *phys_vec; > - struct p2pdma_provider *provider; > - u32 nr_ranges; > - struct kref kref; > - struct completion comp; > - u8 revoked : 1; > -}; > - > static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf, > struct dma_buf_attachment *attachment) > { > @@ -106,6 +93,130 @@ static const struct dma_buf_ops vfio_pci_dmabuf_ops = { > .release = vfio_pci_dma_buf_release, > }; > > +int vfio_pci_dma_buf_find_pfn(struct vfio_pci_dma_buf *priv, > + struct vm_area_struct *vma, > + unsigned long address, Nit: s/address/fault_addr ? > + unsigned int order, > + unsigned long *out_pfn) > +{ > + /* > + * Given a VMA (start, end, pgoffs) and a fault address, > + * search the corresponding DMABUF's phys_vec[] to find the > + * range representing the address's offset into the VMA, and > + * its PFN. > + * > + * The phys_vec[] ranges represent contiguous spans of VAs > + * upwards from the buffer offset 0; the actual PFNs might be > + * in any order, overlap/alias, etc. Calculate an offset of > + * the desired page given VMA start/pgoff and address, then > + * search upwards from 0 to find which span contains it. > + * > + * On success, a valid PFN for a page sized by 'order' is > + * returned into out_pfn. > + * > + * Failure occurs if: > + * - The page would cross the edge of the VMA > + * - The page isn't entirely contained within a range > + * - We find a range, but the final PFN isn't aligned to the > + * requested order. > + * > + * (Upon failure, the caller is expected to try again with a > + * smaller order; the tests above will always succeed for > + * order=0 as the limit case.) > + * > + * It's suboptimal if DMABUFs are created with neigbouring > + * ranges that are physically contiguous, since hugepages > + * can't straddle range boundaries. (The construction of the > + * ranges vector should merge such ranges.) > + * > + * Finally, vma_pgoff_adjust is used for a DMABUF representing > + * a VFIO BAR mmap, which is created from the start of the > + * offset region. > + */ > + > + const unsigned long pagesize = PAGE_SIZE << order; > + unsigned long vma_off = ((vma->vm_pgoff - priv->vma_pgoff_adjust) << > + PAGE_SHIFT) & VFIO_PCI_OFFSET_MASK; > + unsigned long rounded_page_addr = ALIGN_DOWN(address, pagesize); > + unsigned long rounded_page_end = rounded_page_addr + pagesize; > + unsigned long page_buf_offset; > + unsigned long page_buf_offset_end; > + unsigned long range_buf_offset = 0; > + unsigned int i; > + > + if (rounded_page_addr < vma->vm_start || rounded_page_end > vma->vm_end) { > + if (order > 0) > + return -EAGAIN; > + > + /* A fault address outside of the VMA is absurd. */ > + WARN(1, "Fault addr 0x%lx outside VMA 0x%lx-0x%lx\n", > + address, vma->vm_start, vma->vm_end); This could flood dmesg if triggered repeatedly by userspace :( Since a fault outside the VMA is an invalid access that already results in a SIGBUS, we could probably avoid the WARN here? Perhaps pr_warn_ratelimited() should suffice? > + return -EFAULT; > + } > + > + /* > + * page_buff_offset[_end] is the span of DMABUF offsets > + * corresponding to the faulting page: > + */ > + if (unlikely(check_add_overflow(rounded_page_addr - vma->vm_start, > + vma_off, &page_buf_offset) || > + check_add_overflow(page_buf_offset, pagesize, > + &page_buf_offset_end))) > + return -EFAULT; > + > + for (i = 0; i < priv->nr_ranges; i++) { > + size_t range_len = priv->phys_vec[i].len; > + phys_addr_t range_start = priv->phys_vec[i].paddr; > + > + /* > + * If the current range starts after the page's span, > + * this and any future range won't match. Bail early. > + */ > + if (page_buf_offset_end <= range_buf_offset) > + break; > + > + if (page_buf_offset >= range_buf_offset && > + page_buf_offset_end <= range_buf_offset + range_len) { > + /* > + * The faulting page is wholly contained > + * within the span represented by the range. > + * Validate PFN alignment for the order: > + */ > + unsigned long pfn = (range_start + page_buf_offset - > + range_buf_offset) / PAGE_SIZE; Minor nit: I'm aware that decent compilers convert pow(2) divides to >> However, we seem to be using `>> PAGE_SHIFT` across vfio-pci. E.g.: return (pci_resource_start(vdev->pdev, index) >> PAGE_SHIFT) + pgoff; unsigned long pgoff = (addr - vma->vm_start) >> PAGE_SHIFT; Let's consider using the same pattern? > + > + if (IS_ALIGNED(pfn, 1 << order)) { > + *out_pfn = pfn; > + return 0; > + } > + /* Retry with smaller order */ > + return -EAGAIN; > + } > + range_buf_offset += range_len; > + } > + > + /* > + * A hugepage straddling a range boundary will fail to match a > + * range, but the address will (eventually) match when retried > + * with a smaller page. > + */ > + if (order > 0) > + return -EAGAIN; > + > + /* > + * If we get here, the address fell outside of the span > + * represented by the (concatenated) ranges. Setup of a Nit: double space before "Setup" and "But" below. > + * mapping must ensure that the VMA is <= the total size of > + * the ranges, so this should never happen. But, if it does, > + * force SIGBUS for the access and warn. > + */ > + WARN_ONCE(1, "No range for addr 0x%lx, order %d: VMA 0x%lx-0x%lx pgoff 0x%lx, %u ranges, size 0x%zx\n", > + address, order, vma->vm_start, vma->vm_end, vma->vm_pgoff, > + priv->nr_ranges, priv->size); > + > + return -EFAULT; The fall-through logic at the end feels a bit redundant. If we've exhausted the phys_vec list without finding a match, returning -EAGAIN for order > 0 seems like the correct fallback behavior. However, the subsequent WARN_ONCE for the order == 0 seems unnecessary? An out-of-bounds access is an error that should simply return -EFAULT (converting to SIGBUS) without polluting the kernel log with stackdumps? Can we instead convert this to a pr_warn or something? Something like: ret = order ? -EAGAIN : -EFAULT; if (ret == -EFAULT) pr_warn_ratelimited("No range for addr 0x%lx...\n", address); return ret; (with appropriate comments) Thanks, Praan

9 hours, 24 minutes

[PATCH v20 0/4] Rust bindings for gem shmem

by Lyude Paul

Most of this patch series has already been pushed upstream, this is just the second half of the patch series that has not been pushed yet + some additional changes which were required to implement changes requested by the mailing list. This patch series is originally from Asahi, previously posted by Daniel Almeida. The previous version of the patch series can be found here: https://patchwork.freedesktop.org/series/164580/ Branch with patches applied available here: https://gitlab.freedesktop.org/lyudess/linux/-/commits/rust/gem-shmem This patch series applies on top of drm-rust-next Patch-series wide changes since V15: * Fix some major rebasing errors I somehow didn't notice :( * Drop the dependency on LazyInit, use the trick that Alice suggested instead. * Fix dependency ordering so that Tyr can get the vmap stuff first without the other bits. Patch-series wide changes since V16: * Fix ordering one more time (SetOnce::reset() doesn't need to come before adding vmap functions) * Rebase against the latest DeviceContext changes from me that got pushed. Patch-series wide changes since V20: * Lots of Sashiko fixes, excluding the comments that I couldn't prove weren't just bogus. Lyude Paul (4): rust: drm: gem: shmem: Add DmaResvGuard helper rust: drm: gem: shmem: Add vmap functions rust: faux: Allow retrieving a bound Device rust: drm: gem: Introduce shmem::Object::sg_table() rust/kernel/drm/gem/shmem.rs | 546 ++++++++++++++++++++++++++++++++++- rust/kernel/faux.rs | 16 +- 2 files changed, 546 insertions(+), 16 deletions(-) base-commit: 848bf57e98e1678ce7a49eb4e0bf0502da95dc07 -- 2.54.0

12 hours, 54 minutes

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

by Bjorn Helgaas

On Wed, Jun 10, 2026 at 04:43:15PM +0100, Matt Evans wrote: > The P2PDMA code currently provides two features under the same > CONFIG_PCI_P2PDMA option: > > 1. Locate providers via pcim_p2pdma_provider() > 2. Manage actual P2P DMA > > Some drivers (such as vfio-pci) depend on 1, without having a hard > dependency on 2. > > A future commit expands the use of DMABUF in vfio-pci for non-P2P > scenarios, relying on pcim_p2pdma_provider() always being present. If > that depended on CONFIG_PCI_P2PDMA, it would make vfio-pci only > available if CONFIG_ZONE_DEVICE is present (e.g. 64-bit systems), even > when P2P is not needed. > > To resolve this, introduce CONFIG_PCI_P2PDMA_CORE and refactor the > basic provider functionality into a new p2pdma_core.c file. This is > available even if the CONFIG_PCI_P2PDMA feature is disabled (or > unavailable due to !CONFIG_ZONE_DEVICE). Then, drivers can enable any > additional P2P features with the original CONFIG_PCI_P2PDMA (available > when CONFIG_ZONE_DEVICE is set). > > Signed-off-by: Matt Evans <matt(a)ozlabs.org> I thought this was going to be just a code move and new Kconfig option, but it involves a little more than that, e.g., adding pci_p2pdma_release_pool() and tweaking the RCU synchronization. If possible, it would be nice to do that refactoring in a smaller preliminary patch so it's easier to review/bisect/etc and make this one a pure code move. I guess CONFIG_PCI_P2PDMA_CORE selects just part 1 ("Locate providers via pcim_p2pdma_provider()"), right? > +++ b/drivers/pci/p2pdma.h > @@ -0,0 +1,29 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * PCI Peer 2 Peer DMA support. > + */ > + > +#ifndef _PCI_P2PDMA_H > +#define _PCI_P2PDMA_H > + > +#include <linux/genalloc.h> > +#include <linux/pci-p2pdma.h> > +#include <linux/xarray.h> > + > +struct pci_p2pdma { > + struct gen_pool *pool; > + bool p2pmem_published; > + struct xarray map_types; > + struct p2pdma_provider mem[PCI_STD_NUM_BARS]; > +}; > + > +#ifdef CONFIG_PCI_P2PDMA > +void pci_p2pdma_release_pool(struct pci_dev *pdev, struct pci_p2pdma *p2pdma); > +#else > +static inline void pci_p2pdma_release_pool(struct pci_dev *pdev, struct pci_p2pdma *p2pdma) Wrap to fit in 80 columns like the rest of drivers/pci/ > +{ > +} > +#endif > + > +#endif > + Spurious blank line at end. > +++ b/drivers/pci/p2pdma_core.c > @@ -0,0 +1,118 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * PCI Peer 2 Peer DMA support core, providing a bare-bones In this English text, I think I would spell out "Peer to Peer" instead of relying on the "2" homophone. Same in p2pdma.h.

13 hours, 47 minutes

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig