Re: [PATCH 0/4] Some more lock_page work..

["Kirill A. Shutemov" <kirill@shutemov.name>]

On Wed, Oct 14, 2020 at 09:53:35AM -0700, Linus Torvalds wrote:
> In particular, what I _think_ we could do is:
> 
>  - lock the page tables
> 
>  - check that the page isn't locked
> 
>  - increment the page mapcount (atomic and ordered)
> 
>  - check that the page still isn't locked
> 
>  - insert pte
> 
> without taking the page lock. And the reason that's safe is that *if*
> we're racing with something that is about the remove the page mapping,
> then *that* code will
> 
>  (a) hold the page lock
> 
>  (b) before it removes the mapping, it has to remove it from any
> existing mappings, which involves checking the mapcount and going off
> and getting the page table locks to remove any ptes.
> 
> but my patch did *not* do that, because you have to re-organize things a bit.

Okay, I see what you propose.

But I don't think it addresses race with try_to_unmap():

	CPU0				CPU1
filemap_map_pages()
  take ptl
  PageLocked() == false
 				lock_page()
				try_to_unmap()
				  rwc->done()
				    page_mapcount_is_zero() == true
				  rwc->done() == true, skip full rmap walk
				  never take ptl taken by CPU0
				try_to_unmap() == true
				...
				unlock_page()
  increment mapcount
  PageLocked() == false
  insert PTE

Are we willing to give up rwc->done() optimization?
Or do I miss some other serialization point?

-- 
 Kirill A. Shutemov