On Thu, Jun 13, 2019 at 7:49 AM Ira Weiny <ira.weiny@xxxxxxxxx> wrote: > > On Wed, Jun 12, 2019 at 09:54:58PM +0800, Pingfan Liu wrote: > > On Tue, Jun 11, 2019 at 04:29:11PM +0000, Weiny, Ira wrote: > > > > Pingfan Liu <kernelfans@xxxxxxxxx> writes: > > > > > > > > > As for FOLL_LONGTERM, it is checked in the slow path > > > > > __gup_longterm_unlocked(). But it is not checked in the fast path, > > > > > which means a possible leak of CMA page to longterm pinned requirement > > > > > through this crack. > > > > > > > > Shouldn't we disallow FOLL_LONGTERM with get_user_pages fastpath? W.r.t > > > > dax check we need vma to ensure whether a long term pin is allowed or not. > > > > If FOLL_LONGTERM is specified we should fallback to slow path. > > > > > > Yes, the fastpath bails to the slowpath if FOLL_LONGTERM _and_ DAX. But it does this while walking the page tables. I missed the CMA case and Pingfan's patch fixes this. We could check for CMA pages while walking the page tables but most agreed that it was not worth it. For DAX we already had checks for *_devmap() so it was easier to put the FOLL_LONGTERM checks there. > > > > > Then for CMA pages, are you suggesting something like: > > I'm not suggesting this. OK, then I send out v4. > > Sorry I wrote this prior to seeing the numbers in your other email. Given > the numbers it looks like performing the check whilst walking the tables is > worth the extra complexity. I was just trying to summarize the thread. I > don't think we should disallow FOLL_LONGTERM because it only affects CMA and > DAX. Other pages will be fine with FOLL_LONGTERM. Why penalize every call if > we don't have to. Also in the case of DAX the use of vma will be going > away...[1] Eventually... ;-) A good feature. Trying to catch up. Thanks, Pingfan
