From: Ruihan Li <lrh2000@pku.edu.cn>
To: linux-mm@kvack.org
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
Pasha Tatashin <pasha.tatashin@soleen.com>,
David Hildenbrand <david@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Hellwig <hch@infradead.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Ruihan Li <lrh2000@pku.edu.cn>,
stable@vger.kernel.org
Subject: [PATCH 2/4] usb: usbfs: Use consistent mmap functions
Date: Wed, 10 May 2023 16:55:25 +0800 [thread overview]
Message-ID: <20230510085527.57953-3-lrh2000@pku.edu.cn> (raw)
In-Reply-To: <20230510085527.57953-1-lrh2000@pku.edu.cn>
When hcd->localmem_pool is non-null, it is used to allocate DMA memory.
In this case, the dma address will be properly returned (in dma_handle),
and dma_mmap_coherent should be used to map this memory into the user
space. However, the current implementation uses pfn_remap_range, which
is supposed to map normal pages (instead of DMA pages).
Instead of repeating the logic in the memory allocation function, this
patch introduces a more robust solution. To address the previous issue,
this patch checks the type of allocated memory by testing whether
dma_handle is properly set. If dma_handle is properly returned, it means
some DMA pages are allocated and dma_mmap_coherent should be used to map
them. Otherwise, normal pages are allocated and pfn_remap_range should
be called. This ensures that the correct mmap functions are used
consistently, independently with logic details that determine which type
of memory gets allocated.
Fixes: a0e710a7def4 ("USB: usbfs: fix mmap dma mismatch")
Cc: stable@vger.kernel.org
Signed-off-by: Ruihan Li <lrh2000@pku.edu.cn>
---
drivers/usb/core/devio.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index b4cf9e860..5067030b7 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -235,7 +235,7 @@ static int usbdev_mmap(struct file *file, struct vm_area_struct *vma)
size_t size = vma->vm_end - vma->vm_start;
void *mem;
unsigned long flags;
- dma_addr_t dma_handle;
+ dma_addr_t dma_handle = DMA_MAPPING_ERROR;
int ret;
ret = usbfs_increase_memory_usage(size + sizeof(struct usb_memory));
@@ -265,7 +265,13 @@ static int usbdev_mmap(struct file *file, struct vm_area_struct *vma)
usbm->vma_use_count = 1;
INIT_LIST_HEAD(&usbm->memlist);
- if (hcd->localmem_pool || !hcd_uses_dma(hcd)) {
+ /* In DMA-unavailable cases, hcd_buffer_alloc_pages allocates
+ * normal pages and assigns DMA_MAPPING_ERROR to dma_handle. Check
+ * whether we are in such cases, and then use remap_pfn_range (or
+ * dma_mmap_coherent) to map normal (or DMA) pages into the user
+ * space, respectively.
+ */
+ if (dma_handle == DMA_MAPPING_ERROR) {
if (remap_pfn_range(vma, vma->vm_start,
virt_to_phys(usbm->mem) >> PAGE_SHIFT,
size, vma->vm_page_prot) < 0) {
--
2.40.1
next prev parent reply other threads:[~2023-05-10 8:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-10 8:55 [PATCH 0/4] Fix type confusion in page_table_check Ruihan Li
2023-05-10 8:55 ` [PATCH 1/4] usb: usbfs: Enforce page requirements for mmap Ruihan Li
2023-05-10 14:37 ` Alan Stern
2023-05-10 15:38 ` Ruihan Li
2023-05-10 8:55 ` Ruihan Li [this message]
2023-05-10 14:38 ` [PATCH 2/4] usb: usbfs: Use consistent mmap functions Alan Stern
2023-05-10 15:41 ` Ruihan Li
2023-05-10 16:34 ` David Hildenbrand
2023-05-10 8:55 ` [PATCH 3/4] mm: page_table_check: Make it dependent on !DEVMEM Ruihan Li
2023-05-10 16:40 ` David Hildenbrand
2023-05-11 16:07 ` Ruihan Li
2023-05-10 8:55 ` [PATCH 4/4] mm: page_table_check: Ensure user pages are not slab pages Ruihan Li
2023-05-10 22:51 ` [PATCH 0/4] Fix type confusion in page_table_check Greg Kroah-Hartman
2023-05-11 13:44 ` Ruihan Li
2023-05-11 15:32 ` Christoph Hellwig
[not found] ` <zwixiok55avpjvfiknp7tzm7e4aragjj43a46abna4qqegdvdx@suat6sk34lgb>
2023-05-13 9:37 ` Greg Kroah-Hartman
2023-05-14 15:08 ` Ruihan Li
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=20230510085527.57953-3-lrh2000@pku.edu.cn \
--to=lrh2000@pku.edu.cn \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-usb@vger.kernel.org \
--cc=pasha.tatashin@soleen.com \
--cc=stable@vger.kernel.org \
--cc=willy@infradead.org \
/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