From: "Isaac J. Manjarres" <isaacm@codeaurora.org>
To: hch@lst.de, m.szyprowski@samsung.com, robin.murphy@arm.com
Cc: "Isaac J. Manjarres" <isaacm@codeaurora.org>,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
pratikp@codeaurora.org, lmark@codeaurora.org,
stable@vger.kernel.org
Subject: [PATCH] dma-mapping: Use unsigned types for size checks
Date: Mon, 12 Aug 2019 12:03:02 -0700 [thread overview]
Message-ID: <1565636582-9802-1-git-send-email-isaacm@codeaurora.org> (raw)
Both the size parameter in the dma_alloc_from_[dev/global]_coherent()
functions and the size field in the dma_coherent_mem structure
are represented by a signed quantity, which makes it so that any
comparisons between these two quantities is a signed comparison.
When a reserved memory region is larger than or equal to 2GB in
size, this will cause the most significant bit to be set to 1,
thus, treating the size as a negative number in signed
comparisons.
This can result in allocation failures when an amount of
memory that is strictly less than 2 GB is requested from
this region. The allocation fails because the signed comparison
to prevent from allocating more memory than what is in the
region in __dma_alloc_from_coherent() evaluates to true since
the size of the region is treated as a negative number, but the
size of the request is treated as a positive number.
Thus, change the type of the size parameter in the allocation
functions to an unsigned type, and change the type of the
size field in the dma_coherent_mem structure to an unsigned type
as well, as it does not make sense for sizes to be represented
by signed quantities.
Fixes: ee7e5516be4f ("generic: per-device coherent dma allocator")
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Cc: stable@vger.kernel.org
---
include/linux/dma-mapping.h | 6 +++---
kernel/dma/coherent.c | 8 ++++----
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f7d1eea..06d446d 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -159,14 +159,14 @@ static inline int is_device_dma_capable(struct device *dev)
* These three functions are only for dma allocator.
* Don't use them in device drivers.
*/
-int dma_alloc_from_dev_coherent(struct device *dev, ssize_t size,
+int dma_alloc_from_dev_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, void **ret);
int dma_release_from_dev_coherent(struct device *dev, int order, void *vaddr);
int dma_mmap_from_dev_coherent(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, size_t size, int *ret);
-void *dma_alloc_from_global_coherent(ssize_t size, dma_addr_t *dma_handle);
+void *dma_alloc_from_global_coherent(size_t size, dma_addr_t *dma_handle);
int dma_release_from_global_coherent(int order, void *vaddr);
int dma_mmap_from_global_coherent(struct vm_area_struct *vma, void *cpu_addr,
size_t size, int *ret);
@@ -176,7 +176,7 @@ int dma_mmap_from_global_coherent(struct vm_area_struct *vma, void *cpu_addr,
#define dma_release_from_dev_coherent(dev, order, vaddr) (0)
#define dma_mmap_from_dev_coherent(dev, vma, vaddr, order, ret) (0)
-static inline void *dma_alloc_from_global_coherent(ssize_t size,
+static inline void *dma_alloc_from_global_coherent(size_t size,
dma_addr_t *dma_handle)
{
return NULL;
diff --git a/kernel/dma/coherent.c b/kernel/dma/coherent.c
index 29fd659..c671d5c 100644
--- a/kernel/dma/coherent.c
+++ b/kernel/dma/coherent.c
@@ -13,7 +13,7 @@ struct dma_coherent_mem {
void *virt_base;
dma_addr_t device_base;
unsigned long pfn_base;
- int size;
+ unsigned long size;
unsigned long *bitmap;
spinlock_t spinlock;
bool use_dev_dma_pfn_offset;
@@ -136,7 +136,7 @@ void dma_release_declared_memory(struct device *dev)
EXPORT_SYMBOL(dma_release_declared_memory);
static void *__dma_alloc_from_coherent(struct dma_coherent_mem *mem,
- ssize_t size, dma_addr_t *dma_handle)
+ size_t size, dma_addr_t *dma_handle)
{
int order = get_order(size);
unsigned long flags;
@@ -179,7 +179,7 @@ static void *__dma_alloc_from_coherent(struct dma_coherent_mem *mem,
* Returns 0 if dma_alloc_coherent should continue with allocating from
* generic memory areas, or !0 if dma_alloc_coherent should return @ret.
*/
-int dma_alloc_from_dev_coherent(struct device *dev, ssize_t size,
+int dma_alloc_from_dev_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, void **ret)
{
struct dma_coherent_mem *mem = dev_get_coherent_memory(dev);
@@ -191,7 +191,7 @@ int dma_alloc_from_dev_coherent(struct device *dev, ssize_t size,
return 1;
}
-void *dma_alloc_from_global_coherent(ssize_t size, dma_addr_t *dma_handle)
+void *dma_alloc_from_global_coherent(size_t size, dma_addr_t *dma_handle)
{
if (!dma_coherent_default_memory)
return NULL;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
next reply other threads:[~2019-08-12 19:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-12 19:03 Isaac J. Manjarres [this message]
[not found] ` <20190813124814.A17F320578@mail.kernel.org>
2019-08-13 16:36 ` [PATCH] dma-mapping: Use unsigned types for size checks isaacm
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=1565636582-9802-1-git-send-email-isaacm@codeaurora.org \
--to=isaacm@codeaurora.org \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lmark@codeaurora.org \
--cc=m.szyprowski@samsung.com \
--cc=pratikp@codeaurora.org \
--cc=robin.murphy@arm.com \
--cc=stable@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).