On 06/17/2018 12:53 PM, Dan Williams wrote: > [..] >> diff --git a/mm/rmap.c b/mm/rmap.c >> index 6db729dc4c50..37576f0a4645 100644 >> --- a/mm/rmap.c >> +++ b/mm/rmap.c >> @@ -1360,6 +1360,8 @@ static bool try_to_unmap_one(struct page *page, struct >> vm_area_struct *vma, >> flags & TTU_SPLIT_FREEZE, page); >> } >> >> + if (PageDmaPinned(page)) >> + return false; >> /* >> * We have to assume the worse case ie pmd for invalidation. Note >> that >> * the page can not be free in this function as call of >> try_to_unmap() > > We have a similiar problem with DAX and the conclusion we came to is > that it is not acceptable for userspace to arbitrarily block kernel > actions. The conclusion there was: 'wait' if the DMA is transient, and > 'revoke' if the DMA is long lived, or otherwise 'block' long-lived DMA > if a revocation mechanism is not available. >
Dan, thanks...can you please say a few words (or point to the code) about the "revoke" part of this design? And whether you think it could be applied here (instead of the unconditional appproach I have above)?
