Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

26 participants
6411 discussions

Re: [PATCH RFC 21/26] dma-buf: Add the Physical Address List DMA mapping type

by Jason Gunthorpe

On Sat, May 09, 2026 at 01:31:56PM +0800, Xu Yilun wrote: > > Would you be open to an in-between? The exporter and importer both > > have information that should not leak into each other's drivers. > > > > What if the dmabuf mapping type core code was the only thing that had > > access to *BOTH*? The exporter provides the address data, the importer > > provides the iommu_domain. The core code, and only the core code, has > > both and does the required operation? > > I think that may not work for KVM. On IOMMU side, IOMMUFD acts as the > address space (iova) manager and dma_api/IOMMU driver acts as the > actual page table mapper. But for KVM, it is both. KVM doesn't allow > another component to provide an unknown address space (GPA space) and > say "map it", so doesn't expose to other components about "KVM domain". > > Even if we expose "KVM domain", KVM still acts as the importer and the > mapper, is it wierd to say we trust KVM-the-mapper, but don't trust > KVM-the-as-manager? > > Is it also wierd that we trust IOMMU-the-mapper, but don't trust > IOMMUFD-the-as-manager? There are more IOMMU drivers than IOMMUFD... Yeah, it doesn't work well for kvm, and yes it is really weird and worse that phys in every way.. Jason

23 hours, 47 minutes

Re: [PATCH 9/9] vfio/pci: Add mmap() attributes to DMABUF feature

by Alex Williamson

On Mon, 11 May 2026 16:30:39 +0100 Matt Evans <mattev(a)meta.com> wrote: > Hi Alex, Leon, > > On 27/04/2026 15:36, Alex Williamson wrote: > > > > On Sun, 26 Apr 2026 13:52:15 +0300 > > Leon Romanovsky <leon(a)kernel.org> wrote: > > > >> On Fri, Apr 24, 2026 at 03:31:53PM -0300, Jason Gunthorpe wrote: > >>> On Thu, Apr 16, 2026 at 06:17:52AM -0700, Matt Evans wrote: > >>>> A new field is reserved in vfio_device_feature_dma_buf.flags to > >>>> request CPU-facing memory type attributes for mmap()s of the buffer. > >>>> Add a flag VFIO_DEVICE_FEATURE_DMA_BUF_ATTR_WC, which results in WC > >>>> PTEs for the DMABUF's BAR region. > >>>> > >>>> Signed-off-by: Matt Evans <mattev(a)meta.com> > >>>> --- > >>>> drivers/vfio/pci/vfio_pci_dmabuf.c | 15 +++++++++++++-- > >>>> drivers/vfio/pci/vfio_pci_priv.h | 1 + > >>>> include/uapi/linux/vfio.h | 12 +++++++++--- > >>>> 3 files changed, 23 insertions(+), 5 deletions(-) > >>> > >>> Nice and simple > >>> > >>> Reviewed-by: Jason Gunthorpe <jgg(a)nvidia.com> > >>> > >>>> @@ -1549,8 +1551,12 @@ struct vfio_region_dma_range { > >>>> struct vfio_device_feature_dma_buf { > >>>> __u32 region_index; > >>>> __u32 open_flags; > >>>> - __u32 flags; > >>>> - __u32 nr_ranges; > >>>> + __u32 flags; > >>>> + /* Flags sub-field reserved for attribute enum */ > >>>> +#define VFIO_DEVICE_FEATURE_DMA_BUF_ATTR_MASK (0xfU << 28) > >>>> +#define VFIO_DEVICE_FEATURE_DMA_BUF_ATTR_UC (0 << 28) > >>>> +#define VFIO_DEVICE_FEATURE_DMA_BUF_ATTR_WC (1 << 28) > >>>> + __u32 nr_ranges; > >> > >> Alex, > >> > >> The TPH proposal extends the flags field in a similar way, but I suggested > >> a different approach to conserve bits. At the moment, we spend three bits > >> on a single feature, which feels wasteful. > >> > >> What do you think? > >> https://lore.kernel.org/all/20260409120415.GF86584@unreal/ > > > > I already proposed a very different interface for TPH that decouples > > the dma-buf creation from setting the TPH values: > > > > https://lore.kernel.org/all/20260423132016.4a25e074@shazbot.org/ > > > > This is overall less intrusive than the TPH change proposed, but it > > could still make sense to align this as an operation on the dma-buf, > > that can be probed as a separate feature. Thanks, > > I'll add a VFIO_DEVICE_FEATURE_DMA_BUF_ATTRS in a v2 instead to get in > line with the TPH work, no worries. > > For the benefit of future hackers, how would you describe the criteria > for adding flags to this existing field? What hypothetical feature > characteristics would be appropriate? (Maybe it's that these attrs & > TPH add scalar fields in several bits rather than a simple boolean.) > Two of us have independently added something that's turned out to be > inapproriate so some guidance would be good. I think the question of how we actually expand an arbitrary grab bag of "ATTRS" is the central question in whether we should implement the interface. If we follow the direction I suggested for TPH, maybe this is just a VFIO_DEVICE_FEATURE_DMA_BUF_WC, where it supports only PROBE and SET, with SET taking only the dma-buf fd to implement the one-way promotion from UC -> WC. If we support a generic SET ATTRS feature, we really need to map out how flag bits are indicated as supported and how a user untangles failures from trying to set various attributes. If we end up with a feature indicating each ATTR is available, we might as well have just implemented a feature for each attribute. Thanks, Alex

1 day, 2 hours

Re: [PATCH 9/9] vfio/pci: Add mmap() attributes to DMABUF feature

by Leon Romanovsky

On Mon, May 11, 2026 at 04:30:39PM +0100, Matt Evans wrote: > Hi Alex, Leon, > > On 27/04/2026 15:36, Alex Williamson wrote: > > > > On Sun, 26 Apr 2026 13:52:15 +0300 > > Leon Romanovsky <leon(a)kernel.org> wrote: > > > > > On Fri, Apr 24, 2026 at 03:31:53PM -0300, Jason Gunthorpe wrote: > > > > On Thu, Apr 16, 2026 at 06:17:52AM -0700, Matt Evans wrote: > > > > > A new field is reserved in vfio_device_feature_dma_buf.flags to > > > > > request CPU-facing memory type attributes for mmap()s of the buffer. > > > > > Add a flag VFIO_DEVICE_FEATURE_DMA_BUF_ATTR_WC, which results in WC > > > > > PTEs for the DMABUF's BAR region. > > > > > > > > > > Signed-off-by: Matt Evans <mattev(a)meta.com> > > > > > --- > > > > > drivers/vfio/pci/vfio_pci_dmabuf.c | 15 +++++++++++++-- > > > > > drivers/vfio/pci/vfio_pci_priv.h | 1 + > > > > > include/uapi/linux/vfio.h | 12 +++++++++--- > > > > > 3 files changed, 23 insertions(+), 5 deletions(-) > > > > > > > > Nice and simple > > > > > > > > Reviewed-by: Jason Gunthorpe <jgg(a)nvidia.com> > > > > > @@ -1549,8 +1551,12 @@ struct vfio_region_dma_range { > > > > > struct vfio_device_feature_dma_buf { > > > > > __u32 region_index; > > > > > __u32 open_flags; > > > > > - __u32 flags; > > > > > - __u32 nr_ranges; > > > > > + __u32 flags; > > > > > + /* Flags sub-field reserved for attribute enum */ > > > > > +#define VFIO_DEVICE_FEATURE_DMA_BUF_ATTR_MASK (0xfU << 28) > > > > > +#define VFIO_DEVICE_FEATURE_DMA_BUF_ATTR_UC (0 << 28) > > > > > +#define VFIO_DEVICE_FEATURE_DMA_BUF_ATTR_WC (1 << 28) > > > > > + __u32 nr_ranges; > > > > > > Alex, > > > > > > The TPH proposal extends the flags field in a similar way, but I suggested > > > a different approach to conserve bits. At the moment, we spend three bits > > > on a single feature, which feels wasteful. > > > > > > What do you think? > > > https://lore.kernel.org/all/20260409120415.GF86584@unreal/ > > > > I already proposed a very different interface for TPH that decouples > > the dma-buf creation from setting the TPH values: > > > > https://lore.kernel.org/all/20260423132016.4a25e074@shazbot.org/ > > > > This is overall less intrusive than the TPH change proposed, but it > > could still make sense to align this as an operation on the dma-buf, > > that can be probed as a separate feature. Thanks, > > I'll add a VFIO_DEVICE_FEATURE_DMA_BUF_ATTRS in a v2 instead to get in line > with the TPH work, no worries. > > For the benefit of future hackers, how would you describe the criteria for > adding flags to this existing field? One bit per-feature. > What hypothetical feature characteristics would be appropriate? (Maybe it's that these attrs & TPH > add scalar fields in several bits rather than a simple boolean.) Two of us > have independently added something that's turned out to be inapproriate so > some guidance would be good. Both of you intertwined the signaling bit with the actual data, and that is what led me to prefer a different approach. Thanks > > Thanks! > > > Matt

1 day, 4 hours

From Loss to Recovery: Helping You Take Back Control

by carbideinfos＠gmail.com

JimRecoveryTeam outlines digital hoax tracing and reclamation-related services, mentioning no upfront fees. It also offers confidential consultations.

1 day, 6 hours

Re: [RFC PATCH 04/12] vfio/pci: Allow MMIO regions to be exported through dma-buf

by Jason Gunthorpe

On Thu, May 07, 2026 at 05:16:56PM +1000, Alexey Kardashevskiy wrote: > true but either way dmabuf slicing will be directed by QEMU's > msix-table emulation MR and this slicing needs to match the TDISP > report so I'll have to teach QEMU these reports, right? I am worried > if I miss something obvious, again. Thanks, I don't think so.. It just needs to slice it into the MSI page blindly. When the VM goes to validate the TDISP report against the mappings it will fail to accept the device if there is a mismatch. The only thing qemu could do is fail sooner, but I don't know that is worth the complexity as we do expect all devices to have their MSI range unprotected. Jason

1 day, 10 hours

Re: [PATCH 6/8] drm/panthor: Explicit expansion of locked VM region

by Nicolas Frattaroli

On Tuesday, 5 May 2026 16:05:12 Central European Summer Time Ketil Johnsen wrote: > Currently the panthor_vm_lock_region() function will implicitly expand > an already locked VM region. This can be problematic because the caller > do not reliably know if it needs to call panthor_vm_unlock_region() > or not. > > Worth noting, there is currently no known issues with this as the code > is written today. > > This change introduces panthor_vm_expand_region() which will only work > if there is already a locked VM region. This again means that the > original lock and unlock functions can work as a pair. This pairing is > needed for subsequent protected memory changes. > > Signed-off-by: Ketil Johnsen <ketil.johnsen(a)arm.com> > --- > drivers/gpu/drm/panthor/panthor_mmu.c | 69 +++++++++++++++++++-------- > 1 file changed, 50 insertions(+), 19 deletions(-) > While trying this series, I attempted my usual `modprobe -r panthor && modprobe panthor protected_heap_name=default_cma_region`. Unfortunately, it oopses when attempting to unmap the sg for a bo labeled "FW section" on panthor module unload, and I bisected it to this patch. The oops: [ 598.515550] Unable to handle kernel paging request at virtual address 0000000000400267 [ 598.516864] Mem abort info: [ 598.517676] ESR = 0x0000000096000004 [ 598.518560] EC = 0x25: DABT (current EL), IL = 32 bits [ 598.520414] SET = 0, FnV = 0 [ 598.521275] EA = 0, S1PTW = 0 [ 598.522099] FSC = 0x04: level 0 translation fault [ 598.523069] Data abort info: [ 598.524311] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 598.525566] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 598.526850] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 598.527905] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000104056000 [ 598.529019] [0000000000400267] pgd=0000000000000000, p4d=0000000000000000 [ 598.530170] Internal error: Oops: 0000000096000004 [#1] SMP [ 598.531158] Modules linked in: btusb btrtl btmtk btintel btbcm bluetooth ecdh_generic ecc kpp snd_soc_hdmi_codec cfg80211 r8169 rfkill_gpio pwm_fan rfkill snd_soc_es8316 rtc_hym8563 rk805_pwrkey at24 fusb302 tcpm aux_hpd_bridge display_connector snd_soc_simple_card phy_rockchip_samsung_hdptx phy_rockchip_usbdp rockchip_thermal typec phy_rockchip_naneng_combphy rockchip_saradc industrialio_triggered_buffer kfifo_buf rockchipdrm inno_hdmi dw_dp hantro_vpu rockchip_vdec dw_mipi_dsi2 v4l2_jpeg v4l2_vp9 rockchip_rga dw_mipi_dsi v4l2_h264 synopsys_hdmirx v4l2_dv_timings spi_rockchip_sfc videobuf2_dma_contig videobuf2_dma_sg v4l2_mem2mem videobuf2_memops dw_hdmi_qp onboard_usb_dev analogix_dp videobuf2_v4l2 videobuf2_common snd_soc_rockchip_i2s_tdm dw_hdmi videodev mc drm_display_helper nvme cec panthor(-) drm_gpuvm drm_exec gpu_sched drm_dp_aux_bus drm_dma_helper drm_client_lib nvme_core drm_kms_helper drm pci_endpoint_test backlight snd_soc_audio_graph_card snd_soc_simple_card_utils fuse dm_mod [ 598.541237] CPU: 6 UID: 0 PID: 806 Comm: modprobe Not tainted 7.1.0-rc2-00726-g8ab0a3092b56-dirty #2 PREEMPT [ 598.542733] Hardware name: Radxa ROCK 5T (DT) [ 598.543746] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 598.544991] pc : dma_unmap_sg_attrs (kernel/dma/mapping.c:0) [ 598.546021] lr : panthor_gem_free_object (include/linux/dma-mapping.h:565 drivers/gpu/drm/panthor/panthor_gem.c:308 drivers/gpu/drm/panthor/panthor_gem.c:469) panthor [ 598.547180] sp : ffff80008835bb90 [ 598.548123] x29: ffff80008835bb90 x28: ffff00012610bf00 x27: 0000000000000000 [ 598.549412] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 598.550696] x23: ffff000127194600 x22: ffff0001271943d0 x21: ffff000118671000 [ 598.551984] x20: ffff000127194200 x19: ffff000127194600 x18: 00000000002ab980 [ 598.553273] x17: 00000000002ab980 x16: ffffa39a6b372a04 x15: 0000000000000000 [ 598.554568] x14: 0000000000000010 x13: 0000000000000000 x12: 000000000000003c [ 598.555864] x11: 0000000000000002 x10: ffff000100a5d000 x9 : ffff000118671000 [ 598.557164] x8 : ffff000102f8b490 x7 : ffff000149569000 x6 : ffff000149569000 [ 598.558461] x5 : ffff000100faa7e8 x4 : 0000000000000000 x3 : 0000000000000000 [ 598.559763] x2 : 0000000000000010 x1 : ffff000127194000 x0 : 000000000040000f [ 598.561069] Call trace: [ 598.561961] dma_unmap_sg_attrs (kernel/dma/mapping.c:0) (P) [ 598.563038] panthor_gem_free_object (include/linux/dma-mapping.h:565 drivers/gpu/drm/panthor/panthor_gem.c:308 drivers/gpu/drm/panthor/panthor_gem.c:469) panthor [ 598.564218] drm_gem_object_free (drivers/gpu/drm/drm_gem.c:1148) drm [ 598.565386] panthor_kernel_bo_destroy (include/linux/kref.h:65 include/drm/drm_gem.h:565 include/drm/drm_gem.h:578 drivers/gpu/drm/panthor/panthor_gem.c:1317) panthor [ 598.566575] panthor_fw_unplug (drivers/gpu/drm/panthor/panthor_fw.c:1306) panthor [ 598.567705] panthor_device_unplug (drivers/gpu/drm/panthor/panthor_device.c:103) panthor [ 598.568878] panthor_remove (drivers/gpu/drm/panthor/panthor_drv.c:1846) panthor [ 598.569991] platform_remove (drivers/base/platform.c:1435) [ 598.571029] device_release_driver_internal (drivers/base/dd.c:619 drivers/base/dd.c:1352 drivers/base/dd.c:1375) [ 598.572209] driver_detach (drivers/base/dd.c:1438) [ 598.573237] bus_remove_driver (drivers/base/bus.c:825) [ 598.574304] driver_unregister (drivers/base/driver.c:277) [ 598.575363] platform_driver_unregister (drivers/base/platform.c:920) [ 598.576494] cleanup_module (drivers/gpu/drm/panthor/panthor_devfreq.c:134) panthor [ 598.577617] __arm64_sys_delete_module (kernel/module/main.c:863 kernel/module/main.c:804 kernel/module/main.c:804) [ 598.578751] invoke_syscall (arch/arm64/kernel/syscall.c:35 arch/arm64/kernel/syscall.c:49) [ 598.579794] el0_svc_common (arch/arm64/kernel/syscall.c:121) [ 598.580842] do_el0_svc (arch/arm64/kernel/syscall.c:140) [ 598.581862] el0_svc (arch/arm64/kernel/entry-common.c:723) [ 598.582853] el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:742) [ 598.583949] el0t_64_sync (arch/arm64/kernel/entry.S:594) Kind regards, Nicolas Frattaroli

1 day, 11 hours

Re: [PATCH 1/8] dma-heap: Add proper kref handling on dma-buf heaps

by Maxime Ripard

On Tue, May 05, 2026 at 06:40:21PM +0200, Boris Brezillon wrote: > On Tue, 5 May 2026 17:39:13 +0200 > Maxime Ripard <mripard(a)kernel.org> wrote: > > > Hi Boris, > > > > On Tue, May 05, 2026 at 05:20:48PM +0200, Boris Brezillon wrote: > > > Hi Ketil, > > > > > > On Tue, 5 May 2026 16:05:07 +0200 > > > Ketil Johnsen <ketil.johnsen(a)arm.com> wrote: > > > > > > > From: John Stultz <jstultz(a)google.com> > > > > > > > > Add proper reference counting on the dma_heap structure. While > > > > existing heaps are built-in, we may eventually have heaps loaded > > > > from modules, and we'll need to be able to properly handle the > > > > references to the heaps > > > > > > It's weird that this "heap as module" thing is mentioned here, but > > > actual robustness to make this safe is not added in the commit or any > > > of the following ones. > > > > > > > > > > > Signed-off-by: John Stultz <jstultz(a)google.com> > > > > Signed-off-by: T.J. Mercier <tjmercier(a)google.com> > > > > Signed-off-by: Yong Wu <yong.wu(a)mediatek.com> > > > > [Yong: Just add comment for "minor" and "refcount"] > > > > Signed-off-by: Yunfei Dong <yunfei.dong(a)mediatek.com> > > > > [Yunfei: Change reviewer's comments] > > > > Signed-off-by: Florent Tomasin <florent.tomasin(a)arm.com> > > > > [Florent: Rebase] > > > > Signed-off-by: Ketil Johnsen <ketil.johnsen(a)arm.com> > > > > [Ketil: Rebase] > > > > --- > > > > drivers/dma-buf/dma-heap.c | 29 +++++++++++++++++++++++++++++ > > > > include/linux/dma-heap.h | 2 ++ > > > > 2 files changed, 31 insertions(+) > > > > > > > > diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c > > > > index ac5f8685a6494..9fd365ddbd517 100644 > > > > --- a/drivers/dma-buf/dma-heap.c > > > > +++ b/drivers/dma-buf/dma-heap.c > > > > @@ -12,6 +12,7 @@ > > > > #include <linux/dma-heap.h> > > > > #include <linux/err.h> > > > > #include <linux/export.h> > > > > +#include <linux/kref.h> > > > > #include <linux/list.h> > > > > #include <linux/nospec.h> > > > > #include <linux/syscalls.h> > > > > @@ -31,6 +32,7 @@ > > > > * @heap_devt: heap device node > > > > * @list: list head connecting to list of heaps > > > > * @heap_cdev: heap char device > > > > + * @refcount: reference counter for this heap device > > > > * > > > > * Represents a heap of memory from which buffers can be made. > > > > */ > > > > @@ -41,6 +43,7 @@ struct dma_heap { > > > > dev_t heap_devt; > > > > struct list_head list; > > > > struct cdev heap_cdev; > > > > + struct kref refcount; > > > > }; > > > > > > > > static LIST_HEAD(heap_list); > > > > @@ -248,6 +251,7 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info) > > > > if (!heap) > > > > return ERR_PTR(-ENOMEM); > > > > > > > > + kref_init(&heap->refcount); > > > > heap->name = exp_info->name; > > > > heap->ops = exp_info->ops; > > > > heap->priv = exp_info->priv; > > > > @@ -313,6 +317,31 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info) > > > > } > > > > EXPORT_SYMBOL_NS_GPL(dma_heap_add, "DMA_BUF_HEAP"); > > > > > > > > +static void dma_heap_release(struct kref *ref) > > > > +{ > > > > + struct dma_heap *heap = container_of(ref, struct dma_heap, refcount); > > > > + unsigned int minor = MINOR(heap->heap_devt); > > > > + > > > > + mutex_lock(&heap_list_lock); > > > > + list_del(&heap->list); > > > > + mutex_unlock(&heap_list_lock); > > > > + > > > > + device_destroy(dma_heap_class, heap->heap_devt); > > > > + cdev_del(&heap->heap_cdev); > > > > + xa_erase(&dma_heap_minors, minor); > > > > + > > > > + kfree(heap); > > > > > > That's actually problematic, because cdev_del() doesn't guarantee that > > > all opened FDs have been closed [1], it just guarantees that no new ones > > > can materialize. In order to make that safe, we'd need a > > > > > > 1. kref_get_unless_zero() in dma_heap_open(), with proper locking around > > > the xa_load() to protect against the heap removal that's happening > > > here > > > 2. a dma_heap_put() in a new dma_heap_close() implementation > > > 3. a guarantee that heap implementations won't go away until the last > > > ref is dropped, which means ops and all the data needed for this heap > > > to satisfy ioctl()s (and more generally every passed at > > > dma_heap_add() time) have to stay valid until the last ref is > > > dropped. Alternatively, we could restrict this only to in-flight > > > ioctl()s, and have the ops replaced by some dummy ops using RCU or a > > > rwlock. But I guess live dmabufs allocated on this heap have to > > > retain the heap and its implementation anyway. > > > > > > For record, #3 is already not satisfied by the current tee_heap > > > implementation (tee_dma_heap objects can vanish before the dma_heap > > > object is gone). The other implementations seem to be fine because they > > > are statically linked, and they either have exp_info.priv set to NULL, > > > or something that's never released. > > > > That statement won't hold for long, see: > > https://lore.kernel.org/r/20260427-dma-buf-heaps-as-modules-v5-0-b6f5678fee… > > > > However, all upstream heaps can be loaded as module, but not unloaded. > > So once you get a reference to it, you can assume it will live forever. > > That's why we didn't merge that patch before, even though it was discussed: > > > > https://lore.kernel.org/all/CANDhNCqk9Uk4aXHhUsL4hR1GHNmWZnH3C9Np-A02wdi+J3… > > Hm, not too sure that makes the tee_heap implementation sane WRT > tee_heap removal though, unless we have a guarantee that > tee_device_unregister() will never be called... I missed that part. You're totally right then :) Maxime

1 day, 14 hours

Demir Döner Merdivenler

by firmadan＠hotmail.com

Modern mimarinin vazgeçilmez yapı elemanlarından biri haline gelen demir döner merdivenler, hem estetik görünümü hem de uzun ömürlü kullanımıyla yaşam alanlarına değer katmaktadır. Özellikle dar alanlarda maksimum kullanım avantajı sunan bu merdiven sistemleri, evlerden iş yerlerine, dubleks dairelerden villa projelerine kadar birçok farklı alanda tercih edilmektedir. Dayanıklı metal yapısı sayesinde yüksek taşıma kapasitesine sahip olan demir döner merdiven modelleri, güvenli kullanım sunarken dekoratif tasarımlarıyla da dikkat çeker. Klasik, modern, endüstriyel veya minimalist dekorasyon stillerine uyum sağlayabilen bu özel merdivenler, mekânın atmosferini tamamen değiştirebilir. Demir döner merdivenlerin en önemli avantajlarından biri yer tasarrufu sağlamasıdır. Geleneksel düz merdivenlere göre daha az alan kaplayan spiral tasarım, özellikle küçük metrekareli alanlarda büyük avantaj sunar. Bu sayede hem kullanışlı hem de şık bir geçiş alanı oluşturulur. Üretim aşamasında kullanılan kaliteli demir malzeme, paslanmaya ve deformasyona karşı yüksek direnç sağlar. Elektrostatik boya uygulamaları sayesinde merdiven yüzeyi uzun yıllar ilk günkü görünümünü korur. İç mekân kullanımının yanı sıra dış mekân projelerinde de tercih edilen demir döner merdivenler, hava koşullarına dayanıklı yapısıyla güven verir. Kişiye özel ölçülerde üretilebilen modeller sayesinde her projeye uygun çözümler sunulabilir. Basamak genişliği, korkuluk tasarımı, renk seçenekleri ve merdiven çapı tamamen ihtiyaca göre şekillendirilebilir. Ahşap basamak detaylarıyla sıcak bir görünüm elde edilebilirken tamamen metal tasarımlarla modern ve güçlü bir atmosfer oluşturulabilir. Demir döner merdivenler sadece bir geçiş aracı değil, aynı zamanda dekoratif bir mimari unsur olarak da öne çıkar. Özellikle loft daireler, teras bağlantıları, çatı katları ve mağaza iç tasarımlarında estetik görünümüyle dikkat çekmektedir. Hem fonksiyonel hem de görsel açıdan güçlü bir çözüm arayanlar için ideal seçenekler arasında yer alır. Uzun ömürlü kullanım, sağlam yapı, estetik görünüm ve alan tasarrufu avantajlarını bir araya getiren demir döner merdiven sistemleri, modern yaşam alanlarının vazgeçilmez tercihleri arasında yer almaktadır. Siz de yaşam alanınıza özel tasarlanmış kaliteli ve şık bir merdiven çözümü ile mekânlarınıza değer katabilirsiniz. Demir döner merdiven https://fakrocatimerdivenleri.com/doner-merdivenler/

1 day, 14 hours

Fakro Çatı Merdivenleri

by firmadan＠hotmail.com

Fakro çatı merdivenleri, modern yaşam alanlarında çatı katına güvenli, konforlu ve pratik erişim sağlamak için geliştirilmiş yenilikçi çözümler arasında yer almaktadır. Dayanıklı yapısı, estetik tasarımı ve uzun ömürlü kullanım avantajı ile dikkat çeken Fakro çatı merdivenleri; evler, dubleks daireler, villalar, ofisler ve depo alanları için ideal bir kullanım sunar. Kullanılmadığı zaman katlanabilir yapısı sayesinde minimum alan kaplayan bu sistemler, yaşam alanlarında ekstra yer tasarrufu sağlamaktadır. Fakro’nun geliştirdiği çatı merdiveni modelleri; ahşap, metal ve makaslı sistem seçenekleriyle farklı ihtiyaçlara hitap eder. Isı yalıtımlı kapak yapıları sayesinde enerji kaybını minimum seviyeye indirirken, özellikle kış aylarında iç mekan sıcaklığının korunmasına yardımcı olur. Kaymaz basamak yapısı ve sağlam menteşe sistemi ise kullanıcı güvenliğini üst seviyeye taşır. Böylece hem güvenli hem de ergonomik bir kullanım deneyimi elde edilir. Kurulum açısından oldukça pratik olan Fakro çatı merdivenleri, tavan boşluklarına uyum sağlayan özel ölçü seçenekleri ile üretilmektedir. Tavana tam entegre olan yapısı sayesinde dekoratif açıdan da estetik bir görünüm sunar. Açılıp kapanma mekanizmasının kolay çalışması, günlük kullanım sırasında büyük avantaj sağlar. Özellikle dar alanlarda maksimum verim almak isteyen kullanıcılar için son derece işlevsel bir çözüm oluşturur. Fakro ahşap çatı merdivenleri doğal görünümü ile yaşam alanlarına sıcak bir atmosfer kazandırırken, metal çatı merdivenleri yüksek taşıma kapasitesi ve dayanıklılığı ile öne çıkar. Makaslı alüminyum modeller ise kompakt yapıları sayesinde küçük tavan girişlerinde bile rahat kullanım imkanı sunmaktadır. Her modelde kalite standartlarının yüksek tutulması, ürünlerin uzun yıllar sorunsuz kullanılmasına katkı sağlar. Fakro çatı merdivenleri https://www.fakrocatimerdivenleri.com

1 day, 14 hours

Re: [PATCH] accel/ivpu: Reject PRIME export of userptr BOs

by Christian König

Hi Zivi, On 5/8/26 18:28, Ziyi Guo wrote: > Userptr BOs wrap pinned user pages in a private dma-buf solely for > internal use by the NPU driver. Allowing userspace to re-export such a > BO via DRM_IOCTL_PRIME_HANDLE_TO_FD would expose those pages to other > drivers through an interface that was never intended to be shared. > > Override the driver's prime_handle_to_fd callback to detect dma-bufs > backed by ivpu_gem_userptr_dmabuf_ops and reject the export with > -EINVAL. > > Signed-off-by: Ziyi Guo <n7l8m4(a)u.northwestern.edu> first of all thanks a lot for pointing that out! The patch which orginally added that somehow slipped through the cracks. Then @Karol and @Jacek, using DMA-buf like that is a pretty big NO-GO from the DMA-buf side! Using page which you don't own (especially file system backend ones) in a DMA-buf is absolutely *NOT* something you can do. I hope that it is not the case here, but if you also allow to mmap() them then you have create a massive security problem which can lead to random file system corruptions. Regards, Christian. > --- > drivers/accel/ivpu/ivpu_drv.c | 1 + > drivers/accel/ivpu/ivpu_gem.c | 28 +++++++++++++++++++++++++++ > drivers/accel/ivpu/ivpu_gem.h | 3 +++ > drivers/accel/ivpu/ivpu_gem_userptr.c | 5 +++++ > 4 files changed, 37 insertions(+) > > diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c > index 2801378e3e19..086d4c769b33 100644 > --- a/drivers/accel/ivpu/ivpu_drv.c > +++ b/drivers/accel/ivpu/ivpu_drv.c > @@ -545,6 +545,7 @@ static const struct drm_driver driver = { > > .gem_create_object = ivpu_gem_create_object, > .gem_prime_import = ivpu_gem_prime_import, > + .prime_handle_to_fd = ivpu_gem_prime_handle_to_fd, > > .ioctls = ivpu_drm_ioctls, > .num_ioctls = ARRAY_SIZE(ivpu_drm_ioctls), > diff --git a/drivers/accel/ivpu/ivpu_gem.c b/drivers/accel/ivpu/ivpu_gem.c > index 4f2005a8d496..82079f372b39 100644 > --- a/drivers/accel/ivpu/ivpu_gem.c > +++ b/drivers/accel/ivpu/ivpu_gem.c > @@ -12,6 +12,7 @@ > #include <drm/drm_cache.h> > #include <drm/drm_debugfs.h> > #include <drm/drm_file.h> > +#include <drm/drm_prime.h> > #include <drm/drm_utils.h> > > #include "ivpu_drv.h" > @@ -249,6 +250,33 @@ struct drm_gem_object *ivpu_gem_prime_import(struct drm_device *dev, > return ERR_PTR(ret); > } > > +int ivpu_gem_prime_handle_to_fd(struct drm_device *dev, struct drm_file *file_priv, > + u32 handle, u32 flags, int *prime_fd) > +{ > + struct ivpu_device *vdev = to_ivpu_device(dev); > + struct dma_buf *dmabuf; > + int fd; > + > + dmabuf = drm_gem_prime_handle_to_dmabuf(dev, file_priv, handle, flags); > + if (IS_ERR(dmabuf)) > + return PTR_ERR(dmabuf); > + > + if (ivpu_gem_is_userptr_dma_buf(dmabuf)) { > + ivpu_dbg(vdev, IOCTL, "Exporting userptr BO is not allowed\n"); > + dma_buf_put(dmabuf); > + return -EINVAL; > + } > + > + fd = dma_buf_fd(dmabuf, flags); > + if (fd < 0) { > + dma_buf_put(dmabuf); > + return fd; > + } > + > + *prime_fd = fd; > + return 0; > +} > + > static struct ivpu_bo *ivpu_bo_alloc(struct ivpu_device *vdev, u64 size, u32 flags) > { > struct drm_gem_shmem_object *shmem; > diff --git a/drivers/accel/ivpu/ivpu_gem.h b/drivers/accel/ivpu/ivpu_gem.h > index 0c3350f22b55..bfd15ce02354 100644 > --- a/drivers/accel/ivpu/ivpu_gem.h > +++ b/drivers/accel/ivpu/ivpu_gem.h > @@ -29,6 +29,9 @@ void ivpu_bo_unbind_all_bos_from_context(struct ivpu_device *vdev, struct ivpu_m > > struct drm_gem_object *ivpu_gem_create_object(struct drm_device *dev, size_t size); > struct drm_gem_object *ivpu_gem_prime_import(struct drm_device *dev, struct dma_buf *dma_buf); > +int ivpu_gem_prime_handle_to_fd(struct drm_device *dev, struct drm_file *file_priv, > + u32 handle, u32 flags, int *prime_fd); > +bool ivpu_gem_is_userptr_dma_buf(struct dma_buf *dma_buf); > struct ivpu_bo *ivpu_bo_create(struct ivpu_device *vdev, struct ivpu_mmu_context *ctx, > struct ivpu_addr_range *range, u64 size, u32 flags); > struct ivpu_bo *ivpu_bo_create_runtime(struct ivpu_device *vdev, u64 addr, u64 size, u32 flags); > diff --git a/drivers/accel/ivpu/ivpu_gem_userptr.c b/drivers/accel/ivpu/ivpu_gem_userptr.c > index 7cbf3a4cdc73..45eabea5961e 100644 > --- a/drivers/accel/ivpu/ivpu_gem_userptr.c > +++ b/drivers/accel/ivpu/ivpu_gem_userptr.c > @@ -61,6 +61,11 @@ static const struct dma_buf_ops ivpu_gem_userptr_dmabuf_ops = { > .release = ivpu_gem_userptr_dmabuf_release, > }; > > +bool ivpu_gem_is_userptr_dma_buf(struct dma_buf *dma_buf) > +{ > + return dma_buf->ops == &ivpu_gem_userptr_dmabuf_ops; > +} > + > static struct dma_buf * > ivpu_create_userptr_dmabuf(struct ivpu_device *vdev, void __user *user_ptr, > size_t size, uint32_t flags) > -- > 2.34.1 >

1 day, 14 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig