RE: [RFC v1 1/3] mm/mmu_notifier: Add a new notifier for mapping updates (new pages)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Jason,

> 
> On Tue, Jul 25, 2023 at 10:44:09PM +0000, Kasireddy, Vivek wrote:
> > > If you still need the memory mapped then you re-call hmm_range_fault
> > > and re-obtain it. hmm_range_fault will resolve all the races and you
> > > get new pages.
> 
> > IIUC, for my udmabuf use-case, it looks like calling hmm_range_fault
> > immediately after an invalidate (range notification) would preemptively
> fault in
> > new pages before a write. The problem with that is if a read occurs on
> those
> > new pages, then the data is incorrect as a write may not have
> > happened yet.
> 
> It cannot be, if you use hmm_range_fault correctly you cannot get
> corruption no matter what is done to the mmap'd memfd. If there is
> otherwise it is a hmm_range_fault bug plain and simple.
> 
> > Ideally, what I am looking for is for getting new pages at the time of or after
> > a write; until then, it is ok to use the old pages given my use-case.
> 
> It is wrong, if you are synchronizing the vma then you must use the
> latest copy. If your use case can tolerate it then keep a 'not
> present' indication for the missing pages until you actually need
> them, but dmabuf doesn't really provide an API for that.
> 
> > I think the difference comes down to whether we (udmabuf driver) want to
> > grab the new pages after getting notified about a PTE update because
> > of a fault
> 
> Why? You still haven't explained why you want this.
Ok, let me explain using one of the udmabuf selftests (added in patch #3)
to describe the problem (sorry, I'd have to use the terms memfd, hole, etc)
I am trying to solve:
        size = MEMFD_SIZE * page_size;
        memfd = create_memfd_with_seals(size, false);
        addr1 = mmap_fd(memfd, size);
        write_to_memfd(addr1, size, 'a');
        buf = create_udmabuf_list(devfd, memfd, size);
        addr2 = mmap_fd(buf, NUM_PAGES * NUM_ENTRIES * getpagesize());
        punch_hole(memfd, MEMFD_SIZE / 2);
   -> At this point, if I were to read addr1, it'd still have "a" in relevant areas
        because a new write hasn't happened yet. And, since this results in an
        invalidation (notification) of the associated VMA range, I could register
        a callback in udmabuf driver and get notified but I am not sure how or
        why that would be useful.

        write_to_memfd(addr1, size, 'b');
   -> Here, the hole gets refilled as a result of the above writes which trigger
        faults and the PTEs are updated to point to new pages. When this happens,
        the udmabuf driver needs to be made aware of the new pages that were
        faulted in because of the new writes. Since there does not appear to be
        a way to get notified when the hole is written to, the solution I came up
        with is to either add a new notifier or add calls to change_pte() when the
        PTEs do get updated. However, considering your suggestion to use
        hmm_range_fault(), it is not clear to me how it would help while the hole
        is being written to as the writes occur outside of the udmabuf driver. And,
        there is no way to get notified or track them either, AFAICS from inside the
        udmabuf driver.

Thanks,
Vivek

> 
> If you are writing to the pages then you have to do this
> 
> If you are reading from the pages then hmm_range_fault should return
> the zero page for a hole until it is written too
> 
> Jason





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux