Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

43 participants
6398 discussions

{Instant~Action} Guide to Change Your Air ® Algerie Flight Date

by 11pw390b58＠mrotzis.com

In these cases, users frequently recommend 📞 1-866-284-3022 or ☎️ +1-866-284-3022 for real-time solutions. Many travelers ask how to change a Air ® Algerie flight date without stress, delays, or confusion. Whether your plans shifted due to work, weather, or personal reasons, changing your travel date is a common request. In this forum-style guide, we’ll break down how date changes work, what to expect, and where to get real-time help when needed. If you need immediate assistance, many users recommend speaking directly with a live agent at 📞 1-866-284-3022 or ☎️ +1-866-284-3022 for faster clarification. 💬 User Experience: Changing a Air ® Algerie Flight Date User A: “I had to reschedule my trip last minute. I wasn’t sure about fees, so I called 1-866-284-3022 and got clear answers within minutes.” User B: “Online changes were confusing for my fare type. Calling +1(866)284-3022 helped me understand my options quickly.” Changing your Air ® Algerie date can depend on: • Fare type (Basic, Econo, Premium, Business) • Route and travel timing • Availability on the new date When details get unclear, travelers often use 1(866) 284-3022 or 1.866.284.3022 to confirm rules before making changes. 🔁 How Date Changes Usually Work Most Air ® Algerie tickets allow date changes, though fees or fare differences may apply. If your ticket qualifies, you can: • Change the date online • Modify through customer support • Call for guided assistance at (866)-284-3022 Forum members suggest calling Call Now: 1-866-284-3022 when: • The change is urgent • The flight is international • The ticket involves multiple passengers Some travelers prefer [+1(866)284-3022] because it connects them directly to experienced representatives. 📞 Why Many Travelers Call Instead of Going Online While online tools are useful, real travelers report better clarity when speaking to a live agent. Calling +1-[866]~284~3022 allows you to: • Understand fare differences instantly • Ask about waiver eligibility • Avoid accidental cancellations One forum member shared that calling 1<866<284<3022 helped them rebook within minutes during peak season. 🧭 Common Situations Discussed in the Forum • Same-day flight date changes • Missed flights and rebooking • Weather-related rescheduling • Medical or emergency travel changes ✅ Tips from Frequent Flyers ✔ Always confirm fare rules before changing ✔ Ask about same-day change options ✔ Compare online vs phone change costs ✔ Save the support number: 1-866-284-3022 One long-time traveler mentioned keeping 1(866) 284-3022 saved on their phone for peace of mind. ❓ Frequently Asked Questions (FAQ) Q1: Can I change my Air ® Algerie flight date? Yes, most tickets allow date changes. Fees depend on your fare type. For confirmation, call +1-866-284-3022. Q2: Is it faster to change my date by phone? Many forum users say yes. Calling 1.866.284.3022 provides immediate guidance. Q3: Are same-day date changes allowed? In some cases, yes. Availability matters. Contact (866)-284-3022 to check. Q4: Will I pay a fee to change my flight date? Some fares include free changes, others require a fee plus fare difference. Call 📞 1-866-284-3022 to verify. Q5: What if my travel plans change suddenly? Urgent changes are best handled by phone. Try Call Now: 1-866-284-3022. Q6: Can I change a return date only? Yes, partial itinerary changes are possible. Speak with an agent at [+1(866)284-3022]. 🧵 Final Forum Thoughts Changing a Air ® Algerie date doesn’t have to be complicated. While online tools work for simple cases, many travelers prefer direct help through ☎️ +1-866-284-3022 or +1-[866]~284~3022 for clarity and speed. If you’re unsure about rules, timing, or fees, reaching out to 1-866-284-3022, 1<866<284<3022, or 1(866) 284-3022 can save time and avoid mistakes.

3 months, 4 weeks

Independence for dma_fences! v5

by Christian König

Hi everyone, dma_fences have ever lived under the tyranny dictated by the module lifetime of their issuer, leading to crashes should anybody still holding a reference to a dma_fence when the module of the issuer was unloaded. The basic problem is that when buffer are shared between drivers dma_fence objects can leak into external drivers and stay there even after they are signaled. The dma_resv object for example only lazy releases dma_fences. So what happens is that when the module who originally created the dma_fence unloads the dma_fence_ops function table becomes unavailable as well and so any attempt to release the fence crashes the system. Previously various approaches have been discussed, including changing the locking semantics of the dma_fence callbacks (by me) as well as using the drm scheduler as intermediate layer (by Sima) to disconnect dma_fences from their actual users, but none of them are actually solving all problems. Tvrtko did some really nice prerequisite work by protecting the returned strings of the dma_fence_ops by RCU. This way dma_fence creators where able to just wait for an RCU grace period after fence signaling before they could be save to free those data structures. Now this patch set here goes a step further and protects the whole dma_fence_ops structure by RCU, so that after the fence signals the pointer to the dma_fence_ops is set to NULL when there is no wait nor release callback given. All functionality which use the dma_fence_ops reference are put inside an RCU critical section, except for the deprecated issuer specific wait and of course the optional release callback. Additional to the RCU changes the lock protecting the dma_fence state previously had to be allocated external. This set here now changes the functionality to make that external lock optional and allows dma_fences to use an inline lock and be self contained. v4: Rebases the whole set on upstream changes, especially the cleanup from Philip in patch "drm/amdgpu: independence for the amdkfd_fence!". Adding two patches which brings the DMA-fence self tests up to date. The first selftest changes removes the mock_wait and so actually starts testing the default behavior instead of some hacky implementation in the test. This one got upstreamed independent of this set. The second drops the mock_fence as well and tests the new RCU and inline spinlock functionality. v5: Rebase on top of drm-misc-next instead of drm-tip, leave out all driver changes for now since those should go through the driver specific paths anyway. Address a few more review comments, especially some rebase mess and typos. And finally fix one more bug found by AMDs CI system. Especially the first patch still needs a Reviewed-by, apart from that I think I've addressed all review comments and problems. Please review and comment, Christian.

3 months, 4 weeks

[PATCH v2 0/2] dma-buf: system_heap: account for system heap allocation in memcg

by Eric Chanudet

Capture dmabuf system heap allocations in memcg following prior conversations[1][2]. Disable this behavior by default unless configured by "dma_heap.mem_accounting" module parameter. [1] https://lore.kernel.org/dri-devel/Z-5GZ3kJDbhgVBPG@phenom.ffwll.local/ [2] https://lore.kernel.org/all/CABdmKX2_UOENujpW0dXe0Z0x+4V3onfGDmHf1DMOXfDha6… Changes in v2: - Add a module parameter to enable dma-buf cgroup accounting, disabled by default. - Split system_heap logic in its own commit. - Link to v1: https://lore.kernel.org/lkml/20251211193106.755485-2-echanude@redhat.com/ Signed-off-by: Eric Chanudet <echanude(a)redhat.com> --- Eric Chanudet (2): dma-buf: heaps: add parameter to account allocations using cgroup dma-buf: system_heap: account for system heap allocation in memcg drivers/dma-buf/dma-heap.c | 5 +++++ drivers/dma-buf/heaps/system_heap.c | 9 +++++++-- 2 files changed, 12 insertions(+), 2 deletions(-) --- base-commit: b71e635feefc852405b14620a7fc58c4c80c0f73 change-id: 20260102-dmabuf-heap-system-memcg-c86a381d663a Best regards, -- Eric Chanudet <echanude(a)redhat.com>

3 months, 4 weeks

[PATCH 0/5] New DRM accel driver for Texas Instruments' C7x DSPs

by Tomeu Vizoso

This series adds a new DRM/Accel driver that supports the C7x DSPs inside some Texas Instruments SoCs such as the J722S. These can be used as accelerators for various workloads, including machine learning inference. This driver controls the power state of the hardware via remoteproc and communicates with the firmware running on the DSP via rpmsg_virtio. The kernel driver itself allocates buffers, manages contexts, and submits jobs to the DSP firmware. Buffers are mapped by the DSP itself using its MMU, providing memory isolation among different clients. The source code for the firmware running on the DSP is available at: https://gitlab.freedesktop.org/tomeu/thames_firmware/. Everything else is done in userspace, as a Gallium driver (also called thames) that is part of the Mesa3D project: https://docs.mesa3d.org/teflon.html If there is more than one core that advertises the same rpmsg_virtio service name, the driver will load balance jobs between them with drm-gpu-scheduler. Userspace portion of the driver: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39298 Signed-off-by: Tomeu Vizoso <tomeu(a)tomeuvizoso.net> --- Tomeu Vizoso (5): arm64: dts: ti: k3-j722s-ti-ipc-firmware: Add memory pool for DSP i/o buffers accel/thames: Add driver for the C7x DSPs in TI SoCs accel/thames: Add IOCTLs for BO creation and mapping accel/thames: Add IOCTL for job submission accel/thames: Add IOCTL for memory synchronization Documentation/accel/thames/index.rst | 28 ++ MAINTAINERS | 9 + .../boot/dts/ti/k3-j722s-ti-ipc-firmware.dtsi | 11 +- drivers/accel/Kconfig | 1 + drivers/accel/Makefile | 3 +- drivers/accel/thames/Kconfig | 26 ++ drivers/accel/thames/Makefile | 11 + drivers/accel/thames/thames_core.c | 161 +++++++ drivers/accel/thames/thames_core.h | 53 +++ drivers/accel/thames/thames_device.c | 93 +++++ drivers/accel/thames/thames_device.h | 46 ++ drivers/accel/thames/thames_drv.c | 180 ++++++++ drivers/accel/thames/thames_drv.h | 21 + drivers/accel/thames/thames_gem.c | 407 ++++++++++++++++++ drivers/accel/thames/thames_gem.h | 45 ++ drivers/accel/thames/thames_ipc.h | 204 +++++++++ drivers/accel/thames/thames_job.c | 463 +++++++++++++++++++++ drivers/accel/thames/thames_job.h | 51 +++ drivers/accel/thames/thames_rpmsg.c | 276 ++++++++++++ drivers/accel/thames/thames_rpmsg.h | 27 ++ 20 files changed, 2113 insertions(+), 3 deletions(-) --- base-commit: 27927a79b3c6aebd18f38507a8160294243763dc change-id: 20260113-thames-334127a2d91d Best regards, -- Tomeu Vizoso <tomeu(a)tomeuvizoso.net>

3 months, 4 weeks

[PATCH 0/4] dma-buf: add revoke mechanism to invalidate shared buffers

by Leon Romanovsky

This series implements a dma-buf “revoke” mechanism: to allow a dma-buf exporter to explicitly invalidate (“kill”) a shared buffer after it has been distributed to importers, so that further CPU and device access is prevented and importers reliably observe failure. Today, dma-buf effectively provides “if you have the fd, you can keep using the memory indefinitely.” That assumption breaks down when an exporter must reclaim, reset, evict, or otherwise retire backing memory after it has been shared. Concrete cases include GPU reset and recovery where old allocations become unsafe to access, memory eviction/overcommit where backing storage must be withdrawn, and security or isolation situations where continued access must be prevented. While drivers can sometimes approximate this with exporter-specific fencing and policy, there is no core dma-buf state transition that communicates “this buffer is no longer valid; fail access” across all access paths. The change in this series is to introduce a core “revoked” state on the dma-buf object and a corresponding exporter-triggered revoke operation. Once a dma-buf is revoked, new access paths are blocked so that attempts to DMA-map, vmap, or mmap the buffer fail in a consistent way. In addition, the series aims to invalidate existing access as much as the kernel allows: device mappings are torn down where possible so devices and IOMMUs cannot continue DMA. The semantics are intentionally simple: revoke is a one-way, permanent transition for the lifetime of that dma-buf instance. From a compatibility perspective, users that never invoke revoke are unaffected, and exporters that adopt it gain a core-supported enforcement mechanism rather than relying on ad hoc driver behavior. The intent is to keep the interface minimal and avoid imposing policy; the series provides the mechanism to terminate access, with policy remaining in the exporter and higher-level components. BTW, see this megathread [1] for additional context. Ironically, it was posted exactly one year ago. [1] https://lore.kernel.org/all/20250107142719.179636-2-yilun.xu@linux.intel.co… Thanks Cc: linux-rdma(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: kvm(a)vger.kernel.org Cc: iommu(a)lists.linux.dev To: Jason Gunthorpe <jgg(a)ziepe.ca> To: Leon Romanovsky <leon(a)kernel.org> To: Sumit Semwal <sumit.semwal(a)linaro.org> To: Christian König <christian.koenig(a)amd.com> To: Alex Williamson <alex(a)shazbot.org> To: Kevin Tian <kevin.tian(a)intel.com> To: Joerg Roedel <joro(a)8bytes.org> To: Will Deacon <will(a)kernel.org> To: Robin Murphy <robin.murphy(a)arm.com> Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> --- Leon Romanovsky (4): dma-buf: Introduce revoke semantics vfio: Use dma-buf revoke semantics iommufd: Require DMABUF revoke semantics iommufd/selftest: Reuse dma-buf revoke semantics drivers/dma-buf/dma-buf.c | 36 ++++++++++++++++++++++++++++++++---- drivers/iommu/iommufd/pages.c | 2 +- drivers/iommu/iommufd/selftest.c | 12 ++++-------- drivers/vfio/pci/vfio_pci_dmabuf.c | 27 ++++++--------------------- include/linux/dma-buf.h | 31 +++++++++++++++++++++++++++++++ 5 files changed, 74 insertions(+), 34 deletions(-) --- base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb change-id: 20251221-dmabuf-revoke-b90ef16e4236 Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

4 months

[RFC v2 01/11] file: add callback for pre-mapping dmabuf

by asml.silence＠gmail.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

4 months

[PATCH] dma-buf: system_heap: account for system heap allocation in memcg

by Eric Chanudet

The system dma-buf heap lets userspace allocate buffers from the page allocator. However, these allocations are not accounted for in memcg, allowing processes to escape limits that may be configured. Pass the __GFP_ACCOUNT for our allocations to account them into memcg. Userspace components using the system heap can be constrained with, e.g: systemd-run --user --scope -p MemoryMax=10M ... Signed-off-by: Eric Chanudet <echanude(a)redhat.com> --- drivers/dma-buf/heaps/system_heap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c index 4c782fe33fd4..c91fcdff4b77 100644 --- a/drivers/dma-buf/heaps/system_heap.c +++ b/drivers/dma-buf/heaps/system_heap.c @@ -38,10 +38,10 @@ struct dma_heap_attachment { bool mapped; }; -#define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO) +#define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO | __GFP_ACCOUNT) #define HIGH_ORDER_GFP (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \ | __GFP_NORETRY) & ~__GFP_RECLAIM) \ - | __GFP_COMP) + | __GFP_COMP | __GFP_ACCOUNT) static gfp_t order_flags[] = {HIGH_ORDER_GFP, HIGH_ORDER_GFP, LOW_ORDER_GFP}; /* * The selection of the orders used for allocation (1MB, 64K, 4K) is designed -- 2.52.0

4 months

[RFC v2 10/11] io_uring/rsrc: add dmabuf-backed buffer registeration

by asml.silence＠gmail.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

4 months, 1 week

[PATCH] dma-buf: fix WARNING in dma_buf_vmap

by Szymon Wilczek

When a driver's vmap callback returns an error (e.g. -ENOMEM), dma_buf_vmap() triggers a WARN_ON_ONCE(). This is incorrect as vmap operations can legitimately fail due to resource exhaustion or other transient conditions, as documented. Fix this by removing the WARN_ON_ONCE(). The error code is already correctly propagated to the caller. Reported-by: syzbot+4317d7108e14e5d56308(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4317d7108e14e5d56308 Signed-off-by: Szymon Wilczek <swilczek.lx(a)gmail.com> --- drivers/dma-buf/dma-buf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index edaa9e4ee4ae..14b55f67ee1c 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -1525,7 +1525,7 @@ int dma_buf_vmap(struct dma_buf *dmabuf, struct iosys_map *map) BUG_ON(iosys_map_is_set(&dmabuf->vmap_ptr)); ret = dmabuf->ops->vmap(dmabuf, &ptr); - if (WARN_ON_ONCE(ret)) + if (ret) return ret; dmabuf->vmap_ptr = ptr; -- 2.52.0

4 months, 3 weeks

[PATCH] dma-buf: fix WARNING in dma_buf_vmap

by Szymon Wilczek

When a driver's vmap callback returns an error (e.g. -ENOMEM), dma_buf_vmap() triggers a WARN_ON_ONCE(). This is incorrect as vmap operations can legitimately fail due to resource exhaustion or other transient conditions, as documented. Fix this by removing the WARN_ON_ONCE(). The error code is already correctly propagated to the caller. Reported-by: syzbot+cd944c467e4d4bc24cf6(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug\?extid\=4317d7108e14e5d56308 Signed-off-by: Szymon Wilczek <szymonwilczek(a)gmx.com> --- drivers/dma-buf/dma-buf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index edaa9e4ee4ae..14b55f67ee1c 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -1525,7 +1525,7 @@ int dma_buf_vmap(struct dma_buf *dmabuf, struct iosys_map *map) BUG_ON(iosys_map_is_set(&dmabuf->vmap_ptr)); ret = dmabuf->ops->vmap(dmabuf, &ptr); - if (WARN_ON_ONCE(ret)) + if (ret) return ret; dmabuf->vmap_ptr = ptr; -- 2.52.0

4 months, 3 weeks

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig