linux-kernel - Re: [PATCH 0/3] Volatile Ranges (v11)

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:	Tue, 18 Mar 2014 11:07:50 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Minchan Kim <minchan@...nel.org>
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>,
	KOSAKI Motohiro <kosaki.motohiro@...il.com>,
	Michel Lespinasse <walken@...gle.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH 0/3] Volatile Ranges (v11)

On Tue, Mar 18, 2014 at 8:11 AM, Minchan Kim <minchan@...nel.org> wrote:
> 1) SIGBUS
>
> It's one of the arguable issue because some user want to get a
> SIGBUS(ex, Firefox) while other want a just zero page(ex, Google
> address sanitizer) without signal so it should be option.
>
>         int vrange(start, len, VRANGE_VOLATILE|VRANGE_ZERO, &purged);
>         int vrange(start, len, VRANGE_VOLATILE|VRANGE_SIGNAL, &purged);

So, the zero-fill on volatile access feels like a *very* special case
to me, since a null page could be valid data in many cases. Since
support/interest for volatile ranges has been middling at best, I want
to start culling the stranger use cases. I'm open in the future to
adding a special flag or something if it really make sense, but at
this point, lets just get the more general volatile range use cases
supported.


> 2) Accouting
>
> The one of problem I have thought is lack of accouting of vrange pages.
> I mean we need some statistics for vrange pages and it should be number
> of pages rather than vma size. Without that, user space couldn't see
> current status and then they couldn't control the system's memory
> consumption. It's alredy known problem for other OS which have support
> similar thing(ex, MADV_FREE).
>
> For accouting, we should account how many of existing pages are the range
> when vrange syscall is called. It could increase syscall overhead
> but user could have accurate statistics information. It's just trade-off.

Agreed. As I've been looking at handling anonymous page aging on
swapless systems, the naive method causes performance issues as we
scan and scan and scan the anonymous list trying to page things out to
nowhere. Providing the number of volatile pages would allow the
scanning to stop at a sensible time.

> 3) Aging
>
> I think vrange pages should be discarded eariler than other hot pages
> so want to move pages to tail of inactive LRU when syscall is called.
> We could do by using deactivate_page with some tweak while we accouts
> pages in syscall context.
>
> But if user want to treat vrange pages with other hot pages equally
> he could ask so that we could skip deactivating.
>
>         vrange(start, len, VRANGE_VOLATILE|VRANGE_ZERO|VRANGE_AGING, &purged)
>         or
>         vrange(start, len, VRANGE_VOLATILE|VRANGE_SIGNAL|VRANGE_AGING, &purged)
>
> It could be convenient for Moz usecase if they want to age vrange
> pages.

Again, I want to keep the scope small for now, so I'd rather not add
more options just yet. I think we should come up with a sensable
default and give that time to be used, and if there need to be more
options later, we can open those up. I think activating on volatile
(so the pages are purged together) is the right default approach, but
I'm open to discuss this further.


> 4) Permanency
>
> Like MCL_FUTURE of mlockall, it would be better to make the range
> have permanent property until called VRANGE_NOVOLATILE.
> I mean pages faulted on the range in future since syscall is called
> should be volatile automatically so that user could avoid frequent
> syscall to make them volatile.

I'm not sure I followed this. Is this with respect to the issue of
unmapped holes in the range?

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/