lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 10 Apr 2014 11:49:47 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	KOSAKI Motohiro <kosaki.motohiro@...il.com>
CC:	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Android Kernel Team <kernel-team@...roid.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Robert Love <rlove@...gle.com>, Mel Gorman <mel@....ul.ie>,
	Hugh Dickins <hughd@...gle.com>, Dave Hansen <dave@...1.net>,
	Rik van Riel <riel@...hat.com>,
	Dmitry Adamushko <dmitry.adamushko@...il.com>,
	Neil Brown <neilb@...e.de>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Mike Hommey <mh@...ndium.org>, Taras Glek <tglek@...illa.com>,
	Jan Kara <jack@...e.cz>, Michel Lespinasse <walken@...gle.com>,
	Minchan Kim <minchan@...nel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH 3/5] vrange: Add page purging logic & SIGBUS trap

Hey Kosaki-san,
  Just a few follow ups on your comments here in preparation for v13.

On 03/23/2014 04:44 PM, KOSAKI Motohiro wrote:
> On Fri, Mar 21, 2014 at 2:17 PM, John Stultz <john.stultz@...aro.org> wrote:
> @@ -683,6 +684,7 @@ enum page_references {
>         PAGEREF_RECLAIM,
>         PAGEREF_RECLAIM_CLEAN,
>         PAGEREF_KEEP,
> +       PAGEREF_DISCARD,
> "discard" is alread used in various place for another meanings.
> another name is better.

Any suggestions here? Is PAGEREF_PURGE better?


>
>>         PAGEREF_ACTIVATE,
>>  };
>>
>> @@ -703,6 +705,13 @@ static enum page_references page_check_references(struct page *page,
>>         if (vm_flags & VM_LOCKED)
>>                 return PAGEREF_RECLAIM;
>>
>> +       /*
>> +        * If volatile page is reached on LRU's tail, we discard the
>> +        * page without considering recycle the page.
>> +        */
>> +       if (vm_flags & VM_VOLATILE)
>> +               return PAGEREF_DISCARD;
>> +
>>         if (referenced_ptes) {
>>                 if (PageSwapBacked(page))
>>                         return PAGEREF_ACTIVATE;
>> @@ -930,6 +939,9 @@ static unsigned long shrink_page_list(struct list_head *page_list,
>>                 switch (references) {
>>                 case PAGEREF_ACTIVATE:
>>                         goto activate_locked;
>> +               case PAGEREF_DISCARD:
>> +                       if (may_enter_fs && !discard_vpage(page))
> Wny may-enter-fs is needed? discard_vpage never enter FS.

I think this is a hold over from the file based/shared volatility.
Thanks for pointing it out, I've dropped the may_enter_fs check.


>> +       /*
>> +        * During interating the loop, some processes could see a page as
>> +        * purged while others could see a page as not-purged because we have
>> +        * no global lock between parent and child for protecting vrange system
>> +        * call during this loop. But it's not a problem because the page is
>> +        * not *SHARED* page but *COW* page so parent and child can see other
>> +        * data anytime. The worst case by this race is a page was purged
>> +        * but couldn't be discarded so it makes unnecessary page fault but
>> +        * it wouldn't be severe.
>> +        */
>> +       anon_vma_interval_tree_foreach(avc, &anon_vma->rb_root, pgoff, pgoff) {
>> +               struct vm_area_struct *vma = avc->vma;
>> +
>> +               if (!(vma->vm_flags & VM_VOLATILE))
>> +                       continue;
> When you find !VM_VOLATILE vma, we have no reason to continue pte zapping.
> Isn't it?

Sounds reasonable. I'll switch to breaking out here and returning an
error if Minchan doesn't object.


>
>> +               try_to_discard_one(page, vma);
>> +       }
>> +       page_unlock_anon_vma_read(anon_vma);
>> +       return 0;
>> +}
>> +
>> +
>> +/**
>> + * discard_vpage - If possible, discard the specified volatile page
>> + *
>> + * Attempts to discard a volatile page, and if needed frees the swap page
>> + *
>> + * Returns 0 on success, -1 on error.
>> + */
>> +int discard_vpage(struct page *page)
>> +{
>> +       VM_BUG_ON(!PageLocked(page));
>> +       VM_BUG_ON(PageLRU(page));
>> +
>> +       /* XXX - for now we only support anonymous volatile pages */
>> +       if (!PageAnon(page))
>> +               return -1;
>> +
>> +       if (!try_to_discard_vpage(page)) {
>> +               if (PageSwapCache(page))
>> +                       try_to_free_swap(page);
> This looks strange. try_to_free_swap can't handle vpurge pseudo entry.

So I may be missing some of the subtleties of the swap code, but the
vpurge pseudo swp entry is on the pte, where as here we're just trying
to make sure that before we drop the page we disconnect any swap-backing
the page may have (if it were swapped out previously before being marked
volatile). Let me know if I'm just not understanding the code or your point.


>> +
>> +               if (page_freeze_refs(page, 1)) {
> Where is page_unfreeze_refs() for the pair of this?

Since we're about to free the page I don't think we need a unfreeze_refs
pair? Or am I just misunderstanding the rules here?

thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists