From: Christoph Hellwig <hch@lst.de>
To: Bingbu Cao <bingbu.cao@linux.intel.com>
Cc: Huan Yang <link@vivo.com>,
hch@lst.de, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
lorenzo.stoakes@oracle.com, opensource.kernel@vivo.com,
rppt@kernel.org, ryan.roberts@arm.com, urezki@gmail.com,
ziy@nvidia.com
Subject: Re: [PATCH] mm/vmalloc: fix mischeck pfn valid in vmap_pfns
Date: Mon, 17 Mar 2025 06:53:04 +0100 [thread overview]
Message-ID: <20250317055304.GB26662@lst.de> (raw)
In-Reply-To: <79247edd-761c-82e3-b8d2-acdbe31c8205@linux.intel.com>
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
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
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?
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.
next prev parent reply other threads:[~2025-03-17 5:53 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-12 6:15 Huan Yang
2025-03-12 6:18 ` Christoph Hellwig
2025-03-17 2:12 ` Huan Yang
2025-03-17 5:29 ` Bingbu Cao
2025-03-17 5:53 ` Christoph Hellwig [this message]
2025-03-17 7:42 ` Huan Yang
2025-03-18 6:48 ` Christoph Hellwig
2025-03-18 8:20 ` Huan Yang
2025-03-18 8:33 ` Christoph Hellwig
2025-03-18 8:39 ` Huan Yang
2025-03-18 8:44 ` Christoph Hellwig
2025-03-18 8:50 ` Huan Yang
[not found] ` <20250319050359.3484-1-hdanton@sina.com>
2025-03-19 8:08 ` Christoph Hellwig
[not found] ` <20250319112651.3502-1-hdanton@sina.com>
2025-03-24 2:13 ` Huan Yang
2025-03-25 6:32 ` Kasireddy, Vivek
2025-03-25 6:46 ` Bingbu Cao
2025-03-27 13:40 ` Matthew Wilcox
2025-03-28 6:13 ` Huan Yang
2025-03-19 9:09 ` Gao Xiang
2025-03-20 5:31 ` Christoph Hellwig
2025-03-24 2:22 ` Huan Yang
2025-03-24 2:57 ` Matthew Wilcox
2025-03-17 6:26 ` Huan Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250317055304.GB26662@lst.de \
--to=hch@lst.de \
--cc=akpm@linux-foundation.org \
--cc=bingbu.cao@linux.intel.com \
--cc=link@vivo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=opensource.kernel@vivo.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=urezki@gmail.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox