Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1319550 > unrolled thread

[PATCH] mm: do not let vdso pages into LRU rotation

Back to article view | Back to linux.kernel

Contents

  [PATCH] mm: do not let vdso pages into LRU rotation Johannes Weiner <hannes@cmpxchg.org> - 2016-01-27 20:50 +0100
    Re: [PATCH] mm: do not let vdso pages into LRU rotation Andy Lutomirski <luto@amacapital.net> - 2016-01-27 21:40 +0100
      Re: [PATCH] mm: do not let vdso pages into LRU rotation Johannes Weiner <hannes@cmpxchg.org> - 2016-01-28 22:40 +0100
        Re: [PATCH] mm: do not let vdso pages into LRU rotation Andy Lutomirski <luto@amacapital.net> - 2016-01-29 23:30 +0100

#1319550 — [PATCH] mm: do not let vdso pages into LRU rotation

Hi,

I noticed that vdso pages are faulted and unmapped as if they were
regular file pages. And I'm guessing this is so that the vdso mappings
are able to use the generic COW code in memory.c.

However, it's a little unsettling that zap_pte_range() makes decisions
based on PageAnon() and the page even reaches mark_page_accessed(), as
that function makes several assumptions about the page being a regular
LRU user page. It seems this isn't crashing today by sheer luck, but I
am working on code that does when page_is_file_cache() returns garbage.

I'm using this hack to work around it:

diff --git a/mm/memory.c b/mm/memory.c
index c387430f06c3..f0537c500150 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1121,7 +1121,8 @@ again:
 					set_page_dirty(page);
 				}
 				if (pte_young(ptent) &&
-				    likely(!(vma->vm_flags & VM_SEQ_READ)))
+				    likely(!(vma->vm_flags & VM_SEQ_READ)) &&
+				    !PageReserved(page))
 					mark_page_accessed(page);
 				rss[MM_FILEPAGES]--;
 			}

but I think we need a cleaner (and more robust) solution there to make
it clearer that these pages are not regularly managed pages.

Could the VDSO be a VM_MIXEDMAP to keep the initial unmanaged pages
out of the VM while allowing COW into regular anonymous pages?

Are there other requirements of the VDSO that I might be missing?

Any feedback would be greatly appreciated.

Thanks!
Johannes

[toc] | [next] | [standalone]

#1319705

On Wed, Jan 27, 2016 at 11:39 AM, Johannes Weiner <hannes@cmpxchg.org> wrote:
> Hi,
>
> I noticed that vdso pages are faulted and unmapped as if they were
> regular file pages. And I'm guessing this is so that the vdso mappings
> are able to use the generic COW code in memory.c.
>
> However, it's a little unsettling that zap_pte_range() makes decisions
> based on PageAnon() and the page even reaches mark_page_accessed(), as
> that function makes several assumptions about the page being a regular
> LRU user page. It seems this isn't crashing today by sheer luck, but I
> am working on code that does when page_is_file_cache() returns garbage.
>
> I'm using this hack to work around it:
>
> diff --git a/mm/memory.c b/mm/memory.c
> index c387430f06c3..f0537c500150 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1121,7 +1121,8 @@ again:
>                                         set_page_dirty(page);
>                                 }
>                                 if (pte_young(ptent) &&
> -                                   likely(!(vma->vm_flags & VM_SEQ_READ)))
> +                                   likely(!(vma->vm_flags & VM_SEQ_READ)) &&
> +                                   !PageReserved(page))
>                                         mark_page_accessed(page);
>                                 rss[MM_FILEPAGES]--;
>                         }
>
> but I think we need a cleaner (and more robust) solution there to make
> it clearer that these pages are not regularly managed pages.
>
> Could the VDSO be a VM_MIXEDMAP to keep the initial unmanaged pages
> out of the VM while allowing COW into regular anonymous pages?

Probably.  What are its limitations?  We want ptrace to work on it,
and mprotect needs to work and allow COW.  access_process_vm should
probably work, too.

>
> Are there other requirements of the VDSO that I might be missing?

There's vvar, too, on x86_64, and that mapping is really strange.
It's different in -tip than in any released kernel, too.  VM_MIXEDMAP
seems to work.

If you want to improve this, take a look at -tip -- it's cleaned up a lot.

--Andy

[toc] | [prev] | [next] | [standalone]

#1321077

On Wed, Jan 27, 2016 at 12:32:16PM -0800, Andy Lutomirski wrote:
> On Wed, Jan 27, 2016 at 11:39 AM, Johannes Weiner <hannes@cmpxchg.org> wrote:
> > Could the VDSO be a VM_MIXEDMAP to keep the initial unmanaged pages
> > out of the VM while allowing COW into regular anonymous pages?
> 
> Probably.  What are its limitations?  We want ptrace to work on it,
> and mprotect needs to work and allow COW.  access_process_vm should
> probably work, too.

Thanks, that's good to know.

However, after looking at this a little longer, it appears this would
need work in do_wp_page() to support non-page COW copying, then adding
vm_ops->access and complicating ->fault in all VDSO implementations.

And it looks like - at least theoretically - drivers can inject non-VM
pages into the page tables as well (comment above insert_page())

Given that this behavior has been around for a long time (the comment
at the bottom of vm_normal_page is ancient), I'll probably go with a
more conservative approach; add a comment to mark_page_accessed() and
filter out non-VM pages in the function I'm going to call from it.

Thanks!

[toc] | [prev] | [next] | [standalone]

#1322129

On Thu, Jan 28, 2016 at 1:33 PM, Johannes Weiner <hannes@cmpxchg.org> wrote:
> On Wed, Jan 27, 2016 at 12:32:16PM -0800, Andy Lutomirski wrote:
>> On Wed, Jan 27, 2016 at 11:39 AM, Johannes Weiner <hannes@cmpxchg.org> wrote:
>> > Could the VDSO be a VM_MIXEDMAP to keep the initial unmanaged pages
>> > out of the VM while allowing COW into regular anonymous pages?
>>
>> Probably.  What are its limitations?  We want ptrace to work on it,
>> and mprotect needs to work and allow COW.  access_process_vm should
>> probably work, too.
>
> Thanks, that's good to know.
>
> However, after looking at this a little longer, it appears this would
> need work in do_wp_page() to support non-page COW copying, then adding
> vm_ops->access and complicating ->fault in all VDSO implementations.
>
> And it looks like - at least theoretically - drivers can inject non-VM
> pages into the page tables as well (comment above insert_page())
>
> Given that this behavior has been around for a long time (the comment
> at the bottom of vm_normal_page is ancient), I'll probably go with a
> more conservative approach; add a comment to mark_page_accessed() and
> filter out non-VM pages in the function I'm going to call from it.

I just checked: in -tip, I'm creating a VM_PFNMAP (not VM_MIXEDMAP)
vma and faulting a RAM page (with struct page and all) in using
vm_insert_pfn.  Is that okay, or so I need to use VM_MIXEDMAP instead?

--Andy

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web