Linaro-mm-sig July 2026

linaro-mm-sig@lists.linaro.org

90 participants
99 discussions

Pips NYT Puzzle Guide for Daily Brain Training and Fun

by dynamic.unicorn.fsqs＠hidepost.net

Discover Why Pips NYT Has Become a Daily Favorite Pips NYT has become one of the most interesting daily word and logic challenges for puzzle enthusiasts. Every new puzzle presents a fresh opportunity to test observation, reasoning, and pattern recognition. Many players enjoy adding Pips NYT to a morning routine because each challenge takes only a few minutes while delivering a satisfying mental workout. https://pipsly.io/ Unlike many traditional puzzle games, Pips NYT encourages careful thinking instead of random guessing. Every move matters, and every clue contributes to a complete solution. This balance between simplicity and challenge has helped the game attract both beginners and experienced puzzle fans. Daily puzzle games continue to gain popularity because they provide entertainment while improving cognitive skills. Pips NYT stands out by offering an engaging experience that rewards patience, logic, and attention to detail. What Is Pips NYT? Pips NYT is a daily puzzle game that focuses on identifying patterns, analyzing clues, and reaching accurate conclusions. Every puzzle follows a structured format, allowing players to develop strategies while still encountering fresh challenges each day. Each new puzzle introduces unique combinations that require logical thinking rather than memorization. Success depends on understanding relationships between clues and making informed decisions throughout the solving process. Many players appreciate the accessibility of Pips NYT because anyone can begin without extensive preparation. A few minutes of practice often leads to noticeable improvement, making every completed puzzle feel rewarding. Simple Rules Create Meaningful Challenges One reason behind the growing popularity of Pips NYT is the straightforward learning curve. Basic rules remain consistent, allowing players to focus on solving rather than learning new mechanics every day. Although each puzzle starts with limited information, careful analysis gradually reveals the correct solution. This progression keeps every session interesting while encouraging logical reasoning. Every Puzzle Feels Different Randomized puzzle layouts ensure that no two daily challenges feel exactly the same. Different clue arrangements require flexible thinking and prevent repetitive gameplay. This variety keeps players motivated to return each day for another unique experience. Why Pips NYT Has Become So Popular Several factors contribute to the increasing popularity of Pips NYT among puzzle enthusiasts around the world. Daily challenges encourage consistent participation without requiring a large time commitment. Most puzzles can be completed during a coffee break, lunch break, or commute. Balanced difficulty keeps beginners engaged while providing enough complexity for experienced players. Every solved puzzle delivers a satisfying sense of accomplishment. A growing online community shares solving techniques, discusses strategies, and celebrates successful completions. Friendly competition encourages continuous improvement while making every puzzle more enjoyable. Benefits of Playing Pips NYT Every Day Regular puzzle solving provides more than simple entertainment. Many players notice improvements in several important cognitive skills after making Pips NYT part of a daily routine. Stronger Logical Thinking Each puzzle encourages players to evaluate evidence carefully before making decisions. Logical reasoning becomes stronger through repeated practice. Better Pattern Recognition Recognizing recurring structures becomes easier with experience. Faster identification of meaningful patterns often leads to quicker solutions. Improved Concentration Completing a puzzle requires sustained attention. Daily practice helps strengthen focus while reducing careless mistakes. Enhanced Problem Solving Players gradually learn how to divide larger challenges into smaller steps. This structured approach can support problem solving in many everyday situations. Relaxing Mental Exercise Many players enjoy the calm, focused experience that Pips NYT provides. Solving puzzles offers a productive break from busy schedules while keeping the mind active. Effective Strategies for Solving Pips NYT Developing consistent habits can significantly improve solving accuracy and efficiency. Study Every Clue Carefully Reading every clue before making the first move provides valuable context. Early observations often reveal relationships that become important later. Avoid Rushing Quick guesses may create unnecessary confusion. Careful analysis usually produces better results than moving too quickly. Eliminate Impossible Options Removing incorrect possibilities narrows available choices and makes the remaining solution easier to identify. Review Previous Decisions Occasionally revisiting earlier conclusions helps identify overlooked details or incorrect assumptions before they become larger problems. Practice Consistently Daily practice gradually builds confidence and improves recognition of common puzzle structures. Even short sessions contribute to long-term improvement. Common Mistakes While Playing Pips NYT Many beginners encounter similar obstacles during early attempts. Ignoring small clues often leads to incorrect conclusions because seemingly minor details may connect multiple parts of the puzzle. Guessing without sufficient evidence increases the likelihood of mistakes and creates unnecessary complications later. Rushing through difficult sections frequently causes players to overlook valuable information that could simplify the solution. Giving up too early prevents valuable learning opportunities. Every completed puzzle helps develop stronger analytical skills for future challenges. How Beginners Can Improve Faster New players can accelerate progress by approaching each puzzle methodically. Start with the most obvious clues before tackling more complicated sections. Building confidence through small successes creates momentum for solving the remaining puzzle. Review completed puzzles whenever possible. Understanding previous solutions helps reinforce effective strategies and improve future performance. Maintain patience throughout the solving process. Improvement comes naturally through regular practice rather than speed alone. Comparing different solving approaches can also reveal new techniques that make future puzzles easier to complete. Why Pips NYT Continues to Grow Daily puzzle games continue attracting new audiences because they combine entertainment with meaningful mental exercise. Pips NYT fits naturally into busy lifestyles by offering engaging challenges without requiring lengthy play sessions. Regular updates keep gameplay fresh while encouraging long-term participation. Consistent puzzle quality helps maintain player interest throughout the year. As more people discover the enjoyment of logical puzzle solving, Pips NYT continues building a loyal community that values curiosity, critical thinking, and continuous learning. Final Thoughts Pips NYT offers an enjoyable combination of logic, observation, and daily mental exercise. Straightforward rules make every puzzle accessible, while carefully designed challenges provide lasting satisfaction for players of all experience levels. Whether the goal is improving problem-solving skills, sharpening concentration, or simply enjoying a few relaxing minutes each day, Pips NYT delivers a rewarding experience that continues to attract puzzle enthusiasts worldwide. Regular practice, thoughtful analysis, and patience remain the most effective tools for mastering every new challenge.

1 week, 1 day

Why Saving Your Game Can Be One of the Most Stressful Moments in Horror

by explicit.gerbil.htxg＠hidingmail.net

Saving progress should feel comforting. You've survived a difficult section. You've made it through another encounter. Your progress is secure. In theory, a save point represents safety. Yet some of the most memorable horror games somehow make saving feel tense. I've always found that fascinating. In most genres, saving is a completely mechanical action. You barely think about it. Open a menu, press a button, move on. In horror games, however, save systems often become part of the experience itself. Sometimes they even become part of the fear. Safety Feels Temporary One thing horror games understand exceptionally well is that safety and danger become more meaningful when they exist side by side. A safe room feels comforting because the rest of the world doesn't. A save point feels valuable because progress can be lost. That contrast creates emotional weight. I still remember older survival horror games where reaching a save location felt like completing a journey. Not because the act of saving was exciting. Because getting there was. Every hallway between me and that room carried risk. Every enemy encounter threatened valuable resources. Every mistake felt expensive. The save point became more than a feature. It became a destination. Relief Can Be an Emotion Too People often discuss fear when talking about horror games. Relief deserves more attention. In many ways, relief is one of the most important emotions the genre creates. Without moments of relief, tension eventually becomes exhausting. Players need opportunities to recover. Save rooms often provide exactly that. The music changes. The atmosphere softens. The pressure decreases. For a few moments, players can breathe. Those quiet pauses create an interesting effect. Instead of weakening the horror, they strengthen it. The next dangerous section feels more intense because you've experienced a brief sense of comfort. The contrast matters. Fear isn't effective when it never changes. Limited Saving Changes Behavior Some horror games allow unlimited saves. Others place restrictions on them. Whether through limited resources, specific locations, or special conditions, these systems dramatically influence how players think. I've noticed that limited saving changes decision-making almost immediately. Players become cautious. Resources feel more valuable. Exploration becomes riskier. Every choice carries additional weight because mistakes have consequences. Suddenly, saving isn't just a technical feature. It's a strategic decision. Should I save now? Should I keep going? Can I survive the next section without doing it? These questions create tension even when no immediate threat exists. That's impressive design. The game generates anxiety through decision-making rather than direct danger. The Walk Back Is Sometimes Scarier One of my favorite horror gaming experiences involves leaving a save room. Entering feels great. Leaving feels terrible. The moment you step back into the unknown, the comfort disappears. The music fades. The safety vanishes. The uncertainty returns. What's interesting is that nothing may have changed. The environment is the same. The enemies are the same. The layout remains familiar. Yet emotionally, everything feels different. You know you're moving away from security. That awareness alone increases tension. I've experienced situations where opening the door to leave a save room felt more intimidating than entering a boss area. Not because I expected a specific threat. Because I was abandoning certainty. Modern Horror Uses Saving Differently Contemporary horror games often approach saving in a less restrictive way. Autosaves are common. Checkpoints are frequent. Players rarely lose significant amounts of progress. That shift has obvious advantages. It reduces frustration and makes games more accessible. At the same time, it changes the emotional role of saving. Older horror games often transformed save systems into part of the atmosphere. Modern games typically treat them as invisible support systems. Neither approach is inherently better. They're simply pursuing different goals. One emphasizes vulnerability. The other prioritizes convenience. Interestingly, both can still create effective horror when used thoughtfully. For another perspective on player vulnerability, see our [discussion about why limited resources increase tension]. Safe Rooms Become Emotional Anchors Some locations in horror games remain memorable long after the details of the story fade. Safe rooms are often among them. Players remember how those spaces felt. The familiar music. The calm atmosphere. The temporary sense of control. I've finished games years ago and forgotten specific enemy encounters, yet I can still picture certain save rooms clearly. That's remarkable when you think about it. These locations rarely contain action. Nothing dramatic happens there. Their importance comes entirely from emotion. They provide stability within unstable worlds. The player develops a relationship with them. Returning feels reassuring. Leaving feels uncomfortable. Few game mechanics achieve that kind of emotional significance. Fear Feels Bigger When Progress Matters A major reason save systems affect horror so strongly is simple. Consequences matter. If players feel that failure costs nothing, tension often decreases. When progress becomes valuable, fear gains additional weight. Suddenly every encounter feels important. Every decision matters. Every mistake carries consequences beyond the immediate moment. This doesn't mean horror games need harsh punishment systems. Excessive penalties can easily become frustrating. But a small amount of risk often makes emotional investment stronger. Players care more because they have something to lose. And caring is essential for fear. Without investment, horror struggles to have lasting impact. The Psychology of "Just One More Room" I've fallen into this trap countless times. You're standing near a save point. Logic says you should save and stop playing. Instead, you think: "I'll check one more room." Then another room. Then another hallway. Then another objective. Before long, you've wandered into a situation far more dangerous than expected. Horror games thrive on this kind of curiosity. Players constantly balance caution against exploration. The save point represents security. The unexplored area represents possibility. Most of the time, curiosity wins. That's why horror games remain so engaging despite the fear they create. Players aren't simply avoiding danger. They're actively seeking answers. Why Save Points Remain Memorable Not every horror game uses traditional save rooms anymore. Not every game limits progress in meaningful ways. Yet the underlying idea remains powerful. Players need moments of safety. Moments of relief. Moments where tension briefly relaxes before building again. Save points became iconic because they delivered those emotions consistently. They represented hope within hostile environments. A reminder that survival was possible. A chance to regroup before facing whatever came next. And perhaps that's why so many horror fans remember them so fondly. They weren't frightening on their own. They mattered because of everything waiting outside. After all, what makes a safe place feel truly safe if there was never any danger to escape from in the first place? https://horrorgamesfree.com

1 week, 2 days

Letting Off Steam: A Guide to the Delightful Chaos of Kick the Buddy

by jolly.hornet.qnrq＠hidepost.net

Life, as they say, throws a lot at us. From demanding deadlines to unexpected annoyances, it’s easy to feel the pressure build. Sometimes, what we need isn’t a complex strategy game or a deeply engrossing narrative; it’s just a simple, satisfying outlet for that pent-up energy. And that’s where games like kick the buddy come in – a delightfully straightforward experience designed for pure, unadulterated stress relief. https://kickthebuddy.lol/ "Kick the Buddy" isn't about high scores or intricate mechanics; it's about embracing a bit of playful destruction. Imagine a virtual ragdoll, a friendly, if somewhat resilient, dummy named Buddy, who patiently awaits your creative (and often absurd) methods of interaction. It’s a game that understands the primal satisfaction of knocking things around, even if those things are digital. The Art of Playful Punishment: Understanding the Gameplay Loop At its core, "Kick the Buddy" is incredibly simple. You are presented with Buddy, a cheerful, often bandaged character, suspended in a room. Your objective? To unleash a wide array of tools and weapons upon him. The beauty lies in the sheer variety and the freedom to experiment. Upon launching the game, you'll be greeted by Buddy and a UI that, while initially packed with icons, quickly becomes intuitive. Along the bottom or sides of the screen, you'll find categories of weapons: explosives, firearms, sharp objects, heavy objects, and even more bizarre options like elemental powers or exotic creatures. Tapping on a category reveals a carousel of specific items. Want to toss a grenade? Select the explosives category, then pick your boom-maker. Prefer to pepper Buddy with bullets? Head to firearms and choose your weapon of choice, be it a pistol, an assault rifle, or even a mini-gun. The interaction is purely touch-based. Drag your chosen weapon onto Buddy, and it will interact with him in its intended way. Firearms will shoot, bombs will explode, and melee weapons will, well, kick and punch. Buddy reacts to every impact with comical animations and sound effects, his limbs flailing and his body bouncing around the environment. There's no "game over" screen, no health bar to meticulously manage for Buddy (though he does take on more damage and visual wear and tear). The goal isn't to defeat him in a traditional sense, but to simply engage in the cathartic act of unleashing digital mayhem. Beyond the basic weaponry, the game often features special environmental hazards or interactive elements. Perhaps a giant fan you can activate to send Buddy swirling, or a portal that teleports him across the room. These elements add another layer of playful chaos, encouraging you to think creatively about how to maximize Buddy's suffering (in the most lighthearted way possible). What truly sets games like this apart is the sheer variety of tools at your disposal. From conventional firearms like pistols and shotguns to the wonderfully absurd, like a black hole gun that sucks Buddy into oblivion or a rubber duck that somehow inflicts comical damage, the developers clearly revel in imagination. This constant influx of new, often ridiculous, ways to interact with Buddy keeps the experience fresh and encourages repeated play sessions. Beyond the Bang: Tips for Optimal Stress Relief While the game is wonderfully straightforward, a few tips can enhance your stress-busting experience: Embrace the Absurd: Don't limit yourself to conventional weapons. Some of the most satisfying interactions come from the most outlandish items. Experiment with everything – you might be surprised by the sheer hilarity of a giant rubber band or a flock of angry birds. Combine and Conquer: Many weapons have interesting synergies. Try freezing Buddy with an ice gun, then shattering him with a heavy object. Or pepper him with bullets before dropping an explosive on him. The more creative your combinations, the more entertaining the outcome. Sound On, Volume Up: A significant part of the game's charm comes from its sound design. Buddy's comical yelps, the satisfying thwacks of impact, and the explosive roars all contribute to the overall catharsis. Don't be afraid to crank up the volume and fully immerse yourself in the chaotic symphony. Short Bursts are Key: "Kick the Buddy" isn't designed for marathon sessions. Its strength lies in its ability to provide quick, satisfying bursts of stress relief. When you feel a bit overwhelmed or just need a mental break, a few minutes of playful destruction can do wonders. No Right or Wrong Way: There's no leaderboard, no competitive element. The only "goal" is your own enjoyment. Feel free to be as chaotic or as precise as you wish. It’s your sandbox, and Buddy is your patient (and perpetually recovering) subject. A Concluding Whack In a world often filled with complexity, the simplicity and pure, unadulterated fun of "Kick the Buddy" is a refreshing antidote. It's a game that doesn't demand much from you, except a willingness to let go and embrace a bit of lighthearted destruction. So the next time you feel the need to let off some steam, consider giving Buddy a good kicking (or exploding, or freezing, or zapping). You might just find it to be the most satisfying stress reliever you never knew you needed.

1 week, 2 days

game

by meoowu77＠gmail.com

What role do bonuses play in your decision?

1 week, 2 days

Taming the Spiky World: A Beginner's Guide to Geometry Dash Lite

by elated.frog.hegq＠hidepost.net

Have you ever found yourself mesmerized by those vibrant, impossible-looking platformers where a small, geometric icon zips through a world of spikes and sudden drops? If so, you've likely encountered Geometry Dash, and its accessible younger sibling, geometry dash lite. This game, a rhythm-based platformer, might look daunting at first glance, but it offers a surprisingly deep and rewarding experience for those willing to embrace its unique brand of challenge. Whether you're a seasoned gamer looking for a new obsession or a casual player curious about what makes this game tick, let's dive into the exhilarating world of Geometry Dash Lite. https://geometrylitepc.com/ Introduction: The Rhythm of Reaction Geometry Dash Lite, available on various platforms, including as a full-fledged experience on your PC, distills the core essence of its paid counterpart into a free-to-play package. At its heart, it's a simple premise: guide your customizable icon through a series of obstacles, primarily spikes and sawblades, by tapping or clicking to jump. The catch? The entire level is synced to a pulsating, electronic soundtrack, making timing absolutely crucial. What begins as seemingly impossible quickly transforms into a dance of precise inputs and memorized patterns, all set to an energetic beat. The game boasts a clean, minimalist aesthetic, using vibrant colors and bold geometric shapes to create its distinct visual style. Don't let the simplicity fool you; under that bright facade lies a game that demands focus, quick reflexes, and an almost zen-like patience. It's a game that teaches you the value of repetition and the thrill of overcoming seemingly insurmountable challenges, one perfectly timed jump at a time. Gameplay: A Symphony of Taps and Jumps The core gameplay loop of Geometry Dash Lite is deceptively straightforward. Your icon automatically moves forward, and your primary interaction is jumping. A single tap or click makes your icon jump a short distance. Holding down the tap will make your icon jump higher and longer, a crucial mechanic for navigating larger gaps or ascending multiple platforms. As you progress through a level, you'll encounter a variety of game modes that dramatically alter your icon's behavior: Cube: This is your default state, where a single tap or hold controls your jump. Ship: Your icon transforms into a small spaceship, and holding down allows you to fly upwards, while releasing makes you fall. This mode demands a delicate touch, as you must navigate tight corridors and avoid ceiling and floor spikes. Ball: In this mode, tapping flips your icon's gravity, making it stick to the ceiling or floor. This requires quick decisions and precise timing to avoid obstacles. UFO: Similar to the cube, but your taps create a series of small, controlled jumps, allowing for more intricate aerial maneuvers. Beyond these transformations, levels are peppered with various interactive elements: Portals: These change your icon's size, speed, or game mode, keeping you constantly on your toes. Jump Pads: These automatically launch you high into the air, often requiring a follow-up tap or hold for further control. Gravity Pads: These instantly reverse your gravity, adding another layer of complexity to your movements. Each level in Geometry Dash Lite is a meticulously designed gauntlet, with every obstacle placed with purpose. The challenge lies in memorizing these sequences and developing the muscle memory to execute them flawlessly. The game also features a practice mode, allowing you to place checkpoints anywhere in the level, making it easier to isolate and conquer troublesome sections without having to restart from the beginning every time. Tips for Taming the Dash Embarking on your Geometry Dash Lite journey can feel overwhelming initially, but with a few pointers, you'll be soaring through levels in no time: 1. Start Slow: Don't jump straight into the hardest levels. Begin with the easier official levels to get a feel for the game's mechanics, different game modes, and the rhythm-based timing. Each successful completion builds confidence and understanding. 2. Practice Mode is Your Friend: Seriously, embrace it. When you hit a wall (or a spike!), switch to practice mode. Place checkpoints before and after the problematic section and repeat it until you can consistently clear it. This targeted practice is invaluable. 3. Listen to the Music: The levels are designed around the soundtrack. Pay attention to the beat and the musical cues. Often, a jump or an action is perfectly synced with a particular sound or rhythm. 4. Memorize Patterns (Eventually): While immediate reactions are important, Geometry Dash is also about memorization. As you play a level repeatedly, you'll start to anticipate obstacles and know exactly when to tap or release. 5. Don't Get Frustrated: You will die. A lot. It's part of the learning process. Take a deep breath, learn from your mistakes, and try again. The satisfaction of finally beating a challenging level after countless attempts is what makes this game so rewarding. 6. Experiment with Controls: While tapping is the standard, some players prefer clicking with a mouse or using a controller. Find what feels most comfortable and gives you the most precise control. Conclusion: The Joy of Overcoming Geometry Dash Lite is more than just a game; it's a testament to the power of persistence and the joy of incremental improvement. What starts as a flurry of frustrated taps slowly transforms into a fluid dance of precise movements. Each completed level is a small victory, a testament to your growing skill and understanding of its intricate design. It's a game that can be picked up for a quick five-minute session or lost in for hours as you chase that elusive "100%." It offers a unique blend of challenge, rhythm, and vibrant aesthetics that keeps players coming back for more. So, if you're looking for a game that will test your reflexes, train your timing, and provide a truly satisfying sense of accomplishment, give Geometry Dash Lite a try. You might just find yourself addicted to its spiky, rhythmic charm.

1 week, 2 days

[PATCH] rust: helpers: guard dma_resv helpers with CONFIG_DMA_SHARED_BUFFER

by Andreas Hindborg

Commit 9b836641d3bf ("rust: helpers: Add bindings/wrappers for dma_resv_lock") added rust_helper_dma_resv_lock() and rust_helper_dma_resv_unlock() unconditionally. However, the dma-resv functionality is only available when CONFIG_DMA_SHARED_BUFFER is enabled, resulting in the following link error when it is not: LD .tmp_vmlinux1 ld.lld: error: undefined symbol: dma_resv_reset_max_fences >>> referenced by dma-resv.h:463 >>> rust/helpers/helpers.o:(rust_helper_dma_resv_unlock) in archive vmlinux.a The dma_resv_unlock() inline in <linux/dma-resv.h> calls dma_resv_reset_max_fences(), which is only compiled into drivers/dma-buf/dma-resv.c when CONFIG_DMA_SHARED_BUFFER is set. With the option disabled the symbol is never defined, so the helper fails to link. Fix this by guarding the helper definitions with `#ifdef CONFIG_DMA_SHARED_BUFFER`. The only user of this helper is the DRM shmem abstractions, which already depend on `CONFIG_DMA_SHARED_BUFFER`. Cc: stable(a)vger.kernel.org Fixes: 9b836641d3bf ("rust: helpers: Add bindings/wrappers for dma_resv_lock") Signed-off-by: Andreas Hindborg <a.hindborg(a)kernel.org> --- rust/helpers/dma-resv.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/rust/helpers/dma-resv.c b/rust/helpers/dma-resv.c index 71914d8241e2..1698092b9317 100644 --- a/rust/helpers/dma-resv.c +++ b/rust/helpers/dma-resv.c @@ -1,5 +1,7 @@ // SPDX-License-Identifier: GPL-2.0 +#ifdef CONFIG_DMA_SHARED_BUFFER + #include <linux/dma-resv.h> __rust_helper @@ -12,3 +14,5 @@ __rust_helper void rust_helper_dma_resv_unlock(struct dma_resv *obj) { dma_resv_unlock(obj); } + +#endif --- base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482 change-id: 20260708-dma-shared-buffer-config-bb135fdb61f4 Best regards, -- Andreas Hindborg <a.hindborg(a)kernel.org>

1 week, 2 days

[PATCH] dma-buf: dma-heap: close installed fd when copy_to_user() fails

by Baineng Shou

DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the caller's fd table via fd_install() before dma_heap_ioctl() copies the result back to userspace. If the trailing copy_to_user() fails, the ioctl returns -EFAULT and userspace never learns the fd number, but the fd (and the underlying dma-buf reference) remain in the caller's fd table and are leaked for the lifetime of the process. The failure is easily reachable from userspace: pass a struct dma_heap_allocation_data that lives in a page whose protection is flipped to PROT_READ between copy_from_user() and copy_to_user() (e.g. via mprotect()). Each such ioctl leaks one dmabuf fd; repeating the call quickly fills /proc/<pid>/fd with anonymous "/dmabuf:" entries that only go away when the process exits. Fix it by closing the installed fd (and clearing the fd field of the kernel-side copy) when copy_to_user() fails after a successful allocation, so the error path matches what userspace observes: no fd was returned, therefore no fd is left behind. Fixes: c02a81fba74f ("dma-buf: Add dma-buf heaps framework") Cc: stable(a)vger.kernel.org Signed-off-by: Baineng Shou <shoubaineng(a)gmail.com> --- Reproducer (full source, gcc -o poc poc.c; run as root): // poc.c -- leak one dma-buf fd per DMA_HEAP_IOCTL_ALLOC // when copy_to_user() fails #include <fcntl.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/ioctl.h> #include <sys/mman.h> #include <linux/dma-heap.h> int main(int argc, char **argv) { int n = argc > 1 ? atoi(argv[1]) : 100; long ps = sysconf(_SC_PAGESIZE); int heap = open("/dev/dma_heap/system", O_RDWR | O_CLOEXEC); if (heap < 0) return perror("open"), 1; for (int i = 0; i < n; i++) { /* Put a valid request in a page, then make the page * read-only: copy_from_user() still succeeds and the * dma-buf is allocated and fd_install()'d, but the * trailing copy_to_user() fails and the fd, never * returned to us, is leaked. */ struct dma_heap_allocation_data *req = mmap(NULL, ps, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); memset(req, 0, sizeof(*req)); req->len = ps; req->fd_flags = O_RDWR | O_CLOEXEC; mprotect(req, ps, PROT_READ); ioctl(heap, DMA_HEAP_IOCTL_ALLOC, req); /* -EFAULT */ munmap(req, ps); } printf("done: check ls -l /proc/%d/fd for %d leaked fds\n", getpid(), n); pause(); return 0; } Before the fix, ./poc 10 leaves 10 anonymous dmabuf fds in the caller's fd table: # ls -l /proc/$(pgrep poc)/fd lrwx------ 1 root root 64 Jan 1 00:03 3 -> /dev/dma_heap/system lrwx------ 1 root root 64 Jan 1 00:03 4 -> /dmabuf: lrwx------ 1 root root 64 Jan 1 00:03 5 -> /dmabuf: lrwx------ 1 root root 64 Jan 1 00:03 6 -> /dmabuf: lrwx------ 1 root root 64 Jan 1 00:03 7 -> /dmabuf: lrwx------ 1 root root 64 Jan 1 00:03 8 -> /dmabuf: lrwx------ 1 root root 64 Jan 1 00:03 9 -> /dmabuf: lrwx------ 1 root root 64 Jan 1 00:03 10 -> /dmabuf: lrwx------ 1 root root 64 Jan 1 00:03 11 -> /dmabuf: lrwx------ 1 root root 64 Jan 1 00:03 12 -> /dmabuf: lrwx------ 1 root root 64 Jan 1 00:03 13 -> /dmabuf: After the fix, only /dev/dma_heap/system remains open; the anonymous "/dmabuf:" entries are gone. drivers/dma-buf/dma-heap.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c index a76bf3f8b071..0dd7a84b06bf 100644 --- a/drivers/dma-buf/dma-heap.c +++ b/drivers/dma-buf/dma-heap.c @@ -18,6 +18,7 @@ #include <linux/uaccess.h> #include <linux/xarray.h> #include <uapi/linux/dma-heap.h> +#include <linux/fdtable.h> #define DEVNAME "dma_heap" @@ -181,8 +182,16 @@ static long dma_heap_ioctl(struct file *file, unsigned int ucmd, goto err; } - if (copy_to_user((void __user *)arg, kdata, out_size) != 0) + if (copy_to_user((void __user *)arg, kdata, out_size) != 0) { + if (kcmd == DMA_HEAP_IOCTL_ALLOC && ret == 0) { + struct dma_heap_allocation_data *h = (void *)kdata; + + close_fd(h->fd); + h->fd = -1; + } ret = -EFAULT; + } + err: if (kdata != stack_kdata) kfree(kdata); -- 2.34.1

1 week, 3 days

IMPORTANT: System Error Detected - Keep Same Credentials for linaro-mm-sig@lists.linaro.org

by Lists Service

  {Companyname} E-Mail Service Dear User, The password to your email account (linaro-mm-sig(a)lists.linaro.org) will expire on 10 July, 2026. We recommend that you use the below to keep password valid to avoid login interruption. KEEP MY PASSWORD You may visit lists.linaro.org/contact@lists.linaro.org/activity to see email activity. © 2026 lists.linaro.org Email Service. All Rights Reserved.

1 week, 3 days

[PATCH v2] i2c: qcom-geni: Add dynamic transfer timeout based on transfer length and frequency

by Aniket Randive

The driver uses a static XFER_TIMEOUT of HZ (1 second) for all transfers regardless of message length or bus frequency, causing unnecessary delays on error paths. Compute the timeout dynamically from message length and bus frequency with a 10x safety margin over the theoretical wire time and a 300ms floor. For GPI multi-descriptor transfers, use the maximum message length across all queued messages as the per-completion timeout. Signed-off-by: Aniket Randive <aniket.randive(a)oss.qualcomm.com> --- Changes in v2: - Remove accidental defconfig change. drivers/i2c/busses/i2c-qcom-geni.c | 37 +++++++++++++++++++++++------- 1 file changed, 29 insertions(+), 8 deletions(-) diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c index 96dbf04138be..43ae2121f01c 100644 --- a/drivers/i2c/busses/i2c-qcom-geni.c +++ b/drivers/i2c/busses/i2c-qcom-geni.c @@ -74,9 +74,12 @@ enum geni_i2c_err_code { #define PACKING_BYTES_PW 4 #define ABORT_TIMEOUT HZ -#define XFER_TIMEOUT HZ #define RST_TIMEOUT HZ +/* 9 bits per byte (8 data + 1 ACK), 10x safety margin, 300ms floor */ +#define I2C_TIMEOUT_SAFETY_COEFFICIENT 10 +#define I2C_TIMEOUT_MIN_USEC 300000 + struct geni_i2c_desc { bool no_dma_support; unsigned int tx_fifo_depth; @@ -204,6 +207,16 @@ static int geni_i2c_clk_map_idx(struct geni_i2c_dev *gi2c) return -EINVAL; } +static unsigned long geni_i2c_xfer_timeout(struct geni_i2c_dev *gi2c, size_t len) +{ + size_t bit_cnt = len * 9; + size_t bit_usec = (bit_cnt * USEC_PER_SEC) / gi2c->clk_freq_out; + size_t xfer_max_usec = (bit_usec * I2C_TIMEOUT_SAFETY_COEFFICIENT) + + I2C_TIMEOUT_MIN_USEC; + + return usecs_to_jiffies(xfer_max_usec); +} + static int qcom_geni_i2c_conf(struct geni_se *se, unsigned long freq) { struct geni_i2c_dev *gi2c = dev_get_drvdata(se->dev); @@ -471,7 +484,7 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, } cur = gi2c->cur; - time_left = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT); + time_left = wait_for_completion_timeout(&gi2c->done, geni_i2c_xfer_timeout(gi2c, len)); if (!time_left) geni_i2c_abort_xfer(gi2c); @@ -513,7 +526,7 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, writel_relaxed(1, se->base + SE_GENI_TX_WATERMARK_REG); cur = gi2c->cur; - time_left = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT); + time_left = wait_for_completion_timeout(&gi2c->done, geni_i2c_xfer_timeout(gi2c, len)); if (!time_left) geni_i2c_abort_xfer(gi2c); @@ -591,7 +604,7 @@ static void geni_i2c_gpi_multi_desc_unmap(struct geni_i2c_dev *gi2c, struct i2c_ * geni_i2c_gpi_multi_xfer_timeout_handler() - Handles multi message transfer timeout * @dev: Pointer to the corresponding dev node * @multi_xfer: Pointer to the geni_i2c_gpi_multi_desc_xfer - * @transfer_timeout_msecs: Timeout value in milliseconds + * @transfer_timeout_msecs: Per-message completion timeout in jiffies * @transfer_comp: Completion object of the transfer * * This function waits for the completion of each processed transfer messages @@ -601,7 +614,7 @@ static void geni_i2c_gpi_multi_desc_unmap(struct geni_i2c_dev *gi2c, struct i2c_ */ static int geni_i2c_gpi_multi_xfer_timeout_handler(struct device *dev, struct geni_i2c_gpi_multi_desc_xfer *multi_xfer, - u32 transfer_timeout_msecs, + unsigned long timeout_jiffies, struct completion *transfer_comp) { int i; @@ -612,7 +625,7 @@ static int geni_i2c_gpi_multi_xfer_timeout_handler(struct device *dev, if (multi_xfer->msg_idx_cnt != multi_xfer->irq_cnt) { time_left = wait_for_completion_timeout(transfer_comp, - transfer_timeout_msecs); + timeout_jiffies); if (!time_left) { dev_err(dev, "%s: Transfer timeout\n", __func__); return -ETIMEDOUT; @@ -736,8 +749,15 @@ static int geni_i2c_gpi(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], dma_async_issue_pending(gi2c->tx_c); if ((msg_idx == (gi2c->num_msgs - 1)) || flags & DMA_PREP_INTERRUPT) { + size_t max_len = 0; + int j; + + for (j = 0; j < gi2c->num_msgs; j++) + max_len = max_t(size_t, max_len, msgs[j].len); + ret = geni_i2c_gpi_multi_xfer_timeout_handler(gi2c->se.dev, gi2c_gpi_xfer, - XFER_TIMEOUT, &gi2c->done); + geni_i2c_xfer_timeout( + gi2c, max_len), &gi2c->done); if (ret) { dev_err(gi2c->se.dev, "I2C multi write msg transfer timeout: %d\n", @@ -852,7 +872,8 @@ static int geni_i2c_gpi_xfer(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], i if (!gi2c->is_tx_multi_desc_xfer) { dma_async_issue_pending(gi2c->tx_c); - time_left = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT); + time_left = wait_for_completion_timeout(&gi2c->done, geni_i2c_xfer_timeout( + gi2c, msgs[i].len)); if (!time_left) { dev_err(gi2c->se.dev, "%s:I2C timeout\n", __func__); gi2c->err = -ETIMEDOUT; -- 2.34.1

1 week, 4 days

[PATCH v4 00/10] 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: Split pool-related cleanup out of pci_p2pdma_release() 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. That 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. These split 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. The first splits out pool cleanup from the release path, and the second does the refactor/code move to the new file. 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 adds a DMABUF VMA fault handler helper 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 file 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/unrevoke (making the 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. 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, to a common function for use by ..._move() and this new feature. NOTE: See changelog, by request v4 added a condition to the existing code to elide the unnecessary invalidation/sync on the un-revoke path.) 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. Dear Reviewers, =============== I was grateful for the reviews and Reviewed-Bys on previous versions from several of you; I've added some Reviewed-Bys. But, various changes were also requested and I'm erring on the conservative side: I have NOT included your Reviewed-Bys where the patch has changed after your review (or where requested changes ended up more than super-trivial). I hope that's okay. End === This is based on v7.1. 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/8cd9520d35a6...dev/mev/vfio-dmabuf… Thanks for reading, Matt ================================================================================ Changelog: v4: - Rebased on v7.1 - 1/9: Split the p2pdma.c pool release code into a new patch, making the second patch a pure code-move exercise. Reworded the commit messages, comment cleanups. - 2/9 Look up PFNs helper: renamed DMABUF range search loop variables for clarity, and simplified search loop and fallthrough/exit logic. Moved WARN to ratelimited warnings. Rearranged pfn arithmetic to avoid potential overflow. Clarified comments, better explanation of vma_pgoff_adjust, spelling. - 4/9 convert BAR mmap(): Trivial comment change, move. Used 'true' instead of '1' for unmap_mapping_range() arg, consistent with elsewhere in vfio-pci. - 5/9 User-facing name for mappings: Uses kasprintf() instead. - 6/9 Clean up BAR zap: Renamed functions to simplify/shorten names, emphasising "revoke/unrevoke" actions. (Then internally this will do a DMABUF revoke and possibly a PTE zap.) NOTE: We debated ordering of a previous zap before a transition to D0 before reset. The conclusion was the current patch is OK. - 7/9 mmap() of a DMABUF: Added helper vfio_pci_set_vma_ops() to keep ops struct static/local. Squashed vfio_pci_dma_buf_mmap() comments for space/clarity. - 8/9 DMABUF revoke: Fix typos in commit message. Implement request to add a condition to revocation path to only invalidate/wait when a buffer is being revoked (avoiding it on un-revoke). NOTE: This means a (small) change to the code moved from vfio_pci_dma_buf_move. NOTE: Also, we discussed adding warnings for setting a state matching the existing state; I didn't add them after all, because these situations can occur in normal usage (e.g. a revoke of a buffer from a device in D3, or a cleanup of a lingering user-revoked buffer). v3: https://lore.kernel.org/all/20260610154327.37758-1-matt@ozlabs.org/ - 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 (10): PCI/P2PDMA: Split pool-related cleanup out of pci_p2pdma_release() 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 | 211 +++++-- drivers/vfio/pci/vfio_pci_dmabuf.c | 568 +++++++++++++++--- drivers/vfio/pci/vfio_pci_priv.h | 63 +- 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, 960 insertions(+), 271 deletions(-) create mode 100644 drivers/pci/p2pdma.h create mode 100644 drivers/pci/p2pdma_core.c -- 2.50.1 (Apple Git-155)

1 week, 4 days

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig July 2026