linux-kernel - Re: [PATCH 05/14] vrange: Add new vrange(2) system call

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]

Message-ID: <5253404D.2030503@linaro.org>
Date:	Mon, 07 Oct 2013 16:14:21 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	LKML <linux-kernel@...r.kernel.org>,
	Minchan Kim <minchan@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Android Kernel Team <kernel-team@...roid.com>,
	Robert Love <rlove@...gle.com>, Mel Gorman <mel@....ul.ie>,
	Hugh Dickins <hughd@...gle.com>,
	Dave Hansen <dave.hansen@...el.com>,
	Rik van Riel <riel@...hat.com>,
	Dmitry Adamushko <dmitry.adamushko@...il.com>,
	Dave Chinner <david@...morbit.com>, Neil Brown <neilb@...e.de>,
	Andrea Righi <andrea@...terlinux.com>,
	Andrea Arcangeli <aarcange@...hat.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	Mike Hommey <mh@...ndium.org>, Taras Glek <tglek@...illa.com>,
	Dhaval Giani <dhaval.giani@...il.com>, Jan Kara <jack@...e.cz>,
	KOSAKI Motohiro <kosaki.motohiro@...il.com>,
	Michel Lespinasse <walken@...gle.com>,
	Rob Clark <robdclark@...il.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH 05/14] vrange: Add new vrange(2) system call

On 10/07/2013 03:56 PM, H. Peter Anvin wrote:
> On 10/02/2013 05:51 PM, John Stultz wrote:
>> From: Minchan Kim <minchan@...nel.org>
>>
>> This patch adds new system call sys_vrange.
>>
>> NAME
>> 	vrange - Mark or unmark range of memory as volatile
>>
> vrange() is about as nondescriptive as one can get -- there is exactly
> one letter that has any connection with that this does.


Hrm. Any suggestions? Would volatile_range() be better?


>
>> SYNOPSIS
>> 	int vrange(unsigned_long start, size_t length, int mode,
>> 			 int *purged);
>>
>> DESCRIPTION
>> 	Applications can use vrange(2) to advise the kernel how it should
>> 	handle paging I/O in this VM area.  The idea is to help the kernel
>> 	discard pages of vrange instead of reclaiming when memory pressure
>> 	happens. It means kernel doesn't discard any pages of vrange if
>> 	there is no memory pressure.
>>
>> 	mode:
>> 	VRANGE_VOLATILE
>> 		hint to kernel so VM can discard in vrange pages when
>> 		memory pressure happens.
>> 	VRANGE_NONVOLATILE
>> 		hint to kernel so VM doesn't discard vrange pages
>> 		any more.
>>
>> 	If user try to access purged memory without VRANGE_NOVOLATILE call,
>> 	he can encounter SIGBUS if the page was discarded by kernel.
>>
>> 	purged: Pointer to an integer which will return 1 if
>> 	mode == VRANGE_NONVOLATILE and any page in the affected range
>> 	was purged. If purged returns zero during a mode ==
>> 	VRANGE_NONVOLATILE call, it means all of the pages in the range
>> 	are intact.
> I'm a bit confused about the "purged"
>
> From an earlier version of the patch:
>
>> - What's different with madvise(DONTNEED)?
>>
>>   System call semantic
>>
>>   DONTNEED makes sure user always can see zero-fill pages after
>>   he calls madvise while vrange can see data or encounter SIGBUS.
> This difference doesn't seem to be a huge one.  The other one seems to
> be the blocking status of MADV_DONTNEED, which perhaps may be better
> handled by adding an option (MADV_LAZY) perhaps?
>
> That way we would have lazy vs. immediate, and zero versus SIGBUS.

And some sort of lazy-cancling call as well.


>
> I see from the change history of the patch that this was an madvise() at
> some point, but was changed into a separate system call at some point,
> does anyone remember why that was?  A quick look through my LKML
> archives doesn't really make it clear.

The reason we can't use madvise, is that to properly handle error cases
and report the pruge state, we need an extra argument.

In much earlier versions, we just returned an error when setting
NONVOLATILE if the data was purged. However, since we have to possibly
do allocations when marking a range as non-volatile, we needed a way to
properly handle that allocation failing. We can't just return ENOMEM, as
we may have already marked purged memory as non-volatile.

Thus, that's why with vrange, we return the number of bytes modified,
along with the purge state. That way, if an error does occur we can
return the purge state of the bytes successfully modified, and only
return an error if nothing was changed, much like when a write fails.

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/