This is a note to let you know that I've just added the patch titled
staging: tidspbridge: protect dmm_map properly
to my staging git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6.git
in the staging-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also will be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From ab42abf33a3efdf754710a0a513c00c40854cd61 Mon Sep 17 00:00:00 2001
From: Felipe Contreras <[email protected]>
Date: Fri, 11 Mar 2011 18:29:06 -0600
Subject: staging: tidspbridge: protect dmm_map properly
We need to protect not only the dmm_map list, but the individual
map_obj's, otherwise, we might be building the scatter-gather list with
garbage. So, use the existing proc_lock for that.
I observed race conditions which caused kernel panics while running
stress tests, also, Tuomas Kulve found it happening quite often in
Gumstix Over. This patch fixes those.
Cc: Tuomas Kulve <[email protected]>
Signed-off-by: Felipe Contreras <[email protected]>
Signed-off-by: Omar Ramirez Luna <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/tidspbridge/rmgr/proc.c | 19 ++++++++++++++-----
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/tidspbridge/rmgr/proc.c
b/drivers/staging/tidspbridge/rmgr/proc.c
index 54f6133..c4e5c4e 100644
--- a/drivers/staging/tidspbridge/rmgr/proc.c
+++ b/drivers/staging/tidspbridge/rmgr/proc.c
@@ -779,12 +779,14 @@ int proc_begin_dma(void *hprocessor, void *pmpu_addr, u32
ul_size,
(u32)pmpu_addr,
ul_size, dir);
+ mutex_lock(&proc_lock);
+
/* find requested memory are in cached mapping information */
map_obj = find_containing_mapping(pr_ctxt, (u32) pmpu_addr, ul_size);
if (!map_obj) {
pr_err("%s: find_containing_mapping failed\n", __func__);
status = -EFAULT;
- goto err_out;
+ goto no_map;
}
if (memory_give_ownership(map_obj, (u32) pmpu_addr, ul_size, dir)) {
@@ -793,6 +795,8 @@ int proc_begin_dma(void *hprocessor, void *pmpu_addr, u32
ul_size,
status = -EFAULT;
}
+no_map:
+ mutex_unlock(&proc_lock);
err_out:
return status;
@@ -817,21 +821,24 @@ int proc_end_dma(void *hprocessor, void *pmpu_addr, u32
ul_size,
(u32)pmpu_addr,
ul_size, dir);
+ mutex_lock(&proc_lock);
+
/* find requested memory are in cached mapping information */
map_obj = find_containing_mapping(pr_ctxt, (u32) pmpu_addr, ul_size);
if (!map_obj) {
pr_err("%s: find_containing_mapping failed\n", __func__);
status = -EFAULT;
- goto err_out;
+ goto no_map;
}
if (memory_regain_ownership(map_obj, (u32) pmpu_addr, ul_size, dir)) {
pr_err("%s: InValid address parameters %p %x\n",
__func__, pmpu_addr, ul_size);
status = -EFAULT;
- goto err_out;
}
+no_map:
+ mutex_unlock(&proc_lock);
err_out:
return status;
}
@@ -1724,9 +1731,8 @@ int proc_un_map(void *hprocessor, void *map_addr,
(p_proc_object->bridge_context, va_align, size_align);
}
- mutex_unlock(&proc_lock);
if (status)
- goto func_end;
+ goto unmap_failed;
/*
* A successful unmap should be followed by removal of map_obj
@@ -1735,6 +1741,9 @@ int proc_un_map(void *hprocessor, void *map_addr,
*/
remove_mapping_information(pr_ctxt, (u32) map_addr, size_align);
+unmap_failed:
+ mutex_unlock(&proc_lock);
+
func_end:
dev_dbg(bridge, "%s: hprocessor: 0x%p map_addr: 0x%p status: 0x%x\n",
__func__, hprocessor, map_addr, status);
--
1.7.3.4
_______________________________________________
stable mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/stable
