On Thu, May 27, 2010 at 7:02 PM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> 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 <ohad@xxxxxxxxxx>
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
