Re: [PATCH v3 3/4] mm: don't expose non-hugetlb page to fast gup prematurely
From: Michal Hocko <mhocko@kernel.org>
Date: 2019-09-27 12:33:08
Also in:
lkml
From: Michal Hocko <mhocko@kernel.org>
Date: 2019-09-27 12:33:08
Also in:
lkml
On Thu 26-09-19 20:26:46, John Hubbard wrote:
On 9/26/19 3:20 AM, Kirill A. Shutemov wrote:quoted
BTW, have you looked at other levels of page table hierarchy. Do we have the same issue for PMD/PUD/... pages?Along the lines of "what other memory barriers might be missing for get_user_pages_fast(), I'm also concerned that the synchronization between get_user_pages_fast() and freeing the page tables might be technically broken, due to missing memory barriers on the get_user_pages_fast() side. Details: gup_fast() disables interrupts, but I think it also needs some sort of memory barrier(s), in order to prevent reads of the page table (gup_pgd_range, etc) from speculatively happening before the interrupts are disabled.
Could you be more specific about the race scenario please? I thought that the unmap path will be serialized by the pte lock. -- Michal Hocko SUSE Labs