[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5a12454c-16a1-4400-a764-f49293d8dece@vivo.com>
Date: Mon, 17 Mar 2025 15:42:15 +0800
From: Huan Yang <link@...o.com>
To: hch@....de
Cc: akpm@...ux-foundation.org, bingbu.cao@...ux.intel.com, link@...o.com,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
lorenzo.stoakes@...cle.com, opensource.kernel@...o.com, rppt@...nel.org,
ryan.roberts@....com, urezki@...il.com, ziy@...dia.com
Subject: Re: [PATCH] mm/vmalloc: fix mischeck pfn valid in vmap_pfns
HI Christoph
> On Mon, Mar 17, 2025 at 01:29:05PM +0800, Bingbu Cao wrote:
>> Why not update udmabuf to make it work with both vmap_pfns() and >> vmap()? As only the udmabuf knows it is actually working on? >> >>
I don't think it's a good idea to hack the common API, the WARN_ON() >>
is really a mandatory check, and current case is a good example.
> What non-page backed memory does udmabuf try to work on, and more
It's HUGETLB which enabled VMEMMAP_OPTIMIZE, all tail page's struct will
ref to head page struct, and then release tailed page struct.
> importantly how does it actually work on them given that the normal
> DMA APIs require page backed memory. Or is this just made it up
udmabuf's sg_table ref only folio+offset, no any page struct ref.
So, any DMA APIs just use folio based.
It pin each folio given by memfd&offset.(memfd can be shmem or hugetlb).
So, shmem memfd can get page struct, hugetlb's may can't.
> and it doesn't work at all given that it also tries to dma map
> to the fake miscdevice struct device which can't work for most
> cases?
This implement map_dma_buf&mmap&vmap&begin/end_cpu_access.
It's simple implement.
>
> Mapping non-page memory is difficult and without having coherent theory
> of what non-page memory you are mapping and being very careful you
> are extremely unlikely to get it right.
Powered by blists - more mailing lists