On Fri, 14 Sep 2007 11:02:40 -0500 Eric Van Hensbergen <ericvh@xxxxxxxxx> wrote:
> + list_for_each_entry_reverse(tmp_page, page_list, lru) {
> + BUG_ON(count > num_pages);
> + if (add_to_page_cache(tmp_page, mapping,
> + tmp_page->index, GFP_KERNEL)) {
> + page_cache_release(tmp_page);
> + continue;
> + }
> +
> + kv[count].iov_base = kmap(tmp_page);
> + kv[count].iov_len = PAGE_CACHE_SIZE;
> + count++;
> + }
> +
> + read_size = count * PAGE_CACHE_SIZE;
> + if (!read_size)
> + goto cleanup;
> +
> + retval = p9_client_readv(fid, kv, offset, count);
> +
> +cleanup:
> + list_for_each_safe(p, n, page_list) {
> + tmp_page = list_entry(p, struct page, lru);
> + list_del(&tmp_page->lru);
> + if (!pagevec_add(&lru_pvec, tmp_page))
> + __pagevec_lru_add(&lru_pvec);
> + kunmap(tmp_page);
> + flush_dcache_page(tmp_page);
> + SetPageUptodate(tmp_page);
> + unlock_page(tmp_page);
> + }
eww, kmap. Large amounts of them, apparently.
Be aware that kmap is a) slow and b) deadlockable. The latter happens when
multiple tasks want to take more than one kmap simultaneously: they all
wait for someone else to release one. Your code here seems especially
vulnerable to this.
Nick had a kmap-speedup patchset a while back which addressed a) but I
don't know if it addressed the deadlock. But that patch seemed to die.
Strongly recommend that the code be reworked to use kmap_atomic()
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
