On 07/03/2018 10:08 AM, Christopher Lameter wrote: > On Mon, 2 Jul 2018, John Hubbard wrote: > >>> If you establish a reference to a page then increase the page count. If >>> the reference is a dma pin action also then increase the pinned count. >>> >>> That way you know how many of the references to the page are dma >>> pins and you can correctly manage the state of the page if the dma pins go >>> away. >>> >> >> I think this sounds like what this patch already does, right? See: >> __put_page_for_pinned_dma(), __get_page_for_pinned_dma(), and >> pin_page_for_dma(). The locking seems correct to me, but I suspect it's >> too heavyweight for such a hot path. But without adding a new put_user_page() >> call, that was the best I could come up with. > > When I saw the patch it looked like you were avoiding to increment the > page->count field. Looking at it again, this patch is definitely susceptible to Jan's "page gets dma-unpinnned too soon" problem. That leaves a window in which the original problem can occur. The page->_refcount field is used normally, in addition to the dma_pinned_count. But the problem is that, unless the caller knows what kind of page it is, the page->dma_pinned_count cannot be looked at, because it is unioned with page->lru.prev. page->dma_pinned_flags, at least starting at bit 1, are safe to look at due to pointer alignment, but now you cannot atomically count... So this seems unsolvable without having the caller specify that it knows the page type, and that it is therefore safe to decrement page->dma_pinned_count. I was hoping I'd found a way, but clearly I haven't. :) thanks, -- John Hubbard NVIDIA -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
