On Thu, May 27, 2010 at 7:02 PM, Ohad Ben-Cohen <[email protected]> wrote:
> Eliminate the call to follow_page. Instead, use the page
> information that was kept during the proc_map call.
> This also has the advantage that users can now only
> specify memory areas that were previously mapped.
>
> Signed-off-by: Ohad Ben-Cohen <[email protected]>
I found another issue with this patch:
> - if (memory_sync_vma((u32) pmpu_addr, ul_size, FlushMemType)) {
> + /* 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;
> + }
> + if (memory_sync_page(map_obj, (u32) pmpu_addr, ul_size, ul_flags)) {
> pr_err("%s: InValid address parameters %p %x\n",
> - __func__, pmpu_addr, ul_size);
> + __func__, pmpu_addr, ul_size);
> status = -EFAULT;
> }
find_containing_mapping() is taking the lock for dmm_map_list,
however, nothing prevents the map_obj to be destroyed after that,
specially if kcalloc sleeps, and then an unmap happens. While doing
some stress testing I found there's a race condition that makes
exactly that happen.
I'm sending some patches to fix that.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
