From: John Stultz <john.stultz@linaro.org> To: Minchan Kim <minchan@kernel.org> Cc: LKML <linux-kernel@vger.kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Android Kernel Team <kernel-team@android.com>, Johannes Weiner <hannes@cmpxchg.org>, Robert Love <rlove@google.com>, Mel Gorman <mel@csn.ul.ie>, Hugh Dickins <hughd@google.com>, Dave Hansen <dave@sr71.net>, Rik van Riel <riel@redhat.com>, Dmitry Adamushko <dmitry.adamushko@gmail.com>, Neil Brown <neilb@suse.de>, Andrea Arcangeli <aarcange@redhat.com>, Mike Hommey <mh@glandium.org>, Taras Glek <tglek@mozilla.com>, Jan Kara <jack@suse.cz>, KOSAKI Motohiro <kosaki.motohiro@gmail.com>, Michel Lespinasse <walken@google.com>, Keith Packard <keithp@keithp.com>, "linux-mm@kvack.org" <linux-mm@kvack.org> Subject: Re: [PATCH 2/4] MADV_VOLATILE: Add MADV_VOLATILE/NONVOLATILE hooks and handle marking vmas Date: Thu, 08 May 2014 09:38:40 -0700 [thread overview] Message-ID: <536BB310.1050105@linaro.org> (raw) In-Reply-To: <20140508012142.GA5282@bbox> On 05/07/2014 06:21 PM, Minchan Kim wrote: > Hey John, > > On Tue, Apr 29, 2014 at 02:21:21PM -0700, John Stultz wrote: >> This patch introduces MADV_VOLATILE/NONVOLATILE flags to madvise(), >> which allows for specifying ranges of memory as volatile, and able >> to be discarded by the system. >> >> This initial patch simply adds flag handling to madvise, and the >> vma handling, splitting and merging the vmas as needed, and marking >> them with VM_VOLATILE. >> >> No purging or discarding of volatile ranges is done at this point. >> >> This a simplified implementation which reuses some of the logic >> from Minchan's earlier efforts. So credit to Minchan for his work. > Remove purged argument is really good thing but I'm not sure merging > the feature into madvise syscall is good idea. > My concern is how we support user who don't want SIGBUS. > I believe we should support them because someuser(ex, sanitizer) really > want to avoid MADV_NONVOLATILE call right before overwriting their cache > (ex, If there was purged page for cyclic cache, user should call NONVOLATILE > right before overwriting to avoid SIGBUS). So... Why not use MADV_FREE then for this case? Just to be clear, by moving back to madvise, I'm not trying to replace MADV_FREE. I think you're work there is still useful and splitting the semantics between the two is cleaner. > Moreover, this changes made unmarking cost O(N) so I'd like to avoid > NOVOLATILE syscall if possible. Well, I think that was made in v13, but yes. NONVOLATILE is currently an expensive operation in order to keep the semantics simpler, as requested by Johannes and Kosaki-san. > For me, SIGBUS is more special usecase for code pages but I believe > both are reasonable for each usecase so my preference is MADV_VOLATILE > is just zero-filled page and MADV_VOLATILE_SIGBUS, another new advise > if you really want to merge volatile range feature with madvise. This I disagree with. Even for non-code page cases, SIGBUS on volatile page access is important for normal users who might accidentally touch volatile data, so they know they are corrupting their data. I know Johannes suggested this is simply a use-after-free issue, but I really feel it results in having very strange semantics. And for those cases where there is a benefit to zero-fill, MADV_FREE seems more appropriate. thanks -john
WARNING: multiple messages have this Message-ID (diff)
From: John Stultz <john.stultz@linaro.org> To: Minchan Kim <minchan@kernel.org> Cc: LKML <linux-kernel@vger.kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Android Kernel Team <kernel-team@android.com>, Johannes Weiner <hannes@cmpxchg.org>, Robert Love <rlove@google.com>, Mel Gorman <mel@csn.ul.ie>, Hugh Dickins <hughd@google.com>, Dave Hansen <dave@sr71.net>, Rik van Riel <riel@redhat.com>, Dmitry Adamushko <dmitry.adamushko@gmail.com>, Neil Brown <neilb@suse.de>, Andrea Arcangeli <aarcange@redhat.com>, Mike Hommey <mh@glandium.org>, Taras Glek <tglek@mozilla.com>, Jan Kara <jack@suse.cz>, KOSAKI Motohiro <kosaki.motohiro@gmail.com>, Michel Lespinasse <walken@google.com>, Keith Packard <keithp@keithp.com>, "linux-mm@kvack.org" <linux-mm@kvack.org> Subject: Re: [PATCH 2/4] MADV_VOLATILE: Add MADV_VOLATILE/NONVOLATILE hooks and handle marking vmas Date: Thu, 08 May 2014 09:38:40 -0700 [thread overview] Message-ID: <536BB310.1050105@linaro.org> (raw) In-Reply-To: <20140508012142.GA5282@bbox> On 05/07/2014 06:21 PM, Minchan Kim wrote: > Hey John, > > On Tue, Apr 29, 2014 at 02:21:21PM -0700, John Stultz wrote: >> This patch introduces MADV_VOLATILE/NONVOLATILE flags to madvise(), >> which allows for specifying ranges of memory as volatile, and able >> to be discarded by the system. >> >> This initial patch simply adds flag handling to madvise, and the >> vma handling, splitting and merging the vmas as needed, and marking >> them with VM_VOLATILE. >> >> No purging or discarding of volatile ranges is done at this point. >> >> This a simplified implementation which reuses some of the logic >> from Minchan's earlier efforts. So credit to Minchan for his work. > Remove purged argument is really good thing but I'm not sure merging > the feature into madvise syscall is good idea. > My concern is how we support user who don't want SIGBUS. > I believe we should support them because someuser(ex, sanitizer) really > want to avoid MADV_NONVOLATILE call right before overwriting their cache > (ex, If there was purged page for cyclic cache, user should call NONVOLATILE > right before overwriting to avoid SIGBUS). So... Why not use MADV_FREE then for this case? Just to be clear, by moving back to madvise, I'm not trying to replace MADV_FREE. I think you're work there is still useful and splitting the semantics between the two is cleaner. > Moreover, this changes made unmarking cost O(N) so I'd like to avoid > NOVOLATILE syscall if possible. Well, I think that was made in v13, but yes. NONVOLATILE is currently an expensive operation in order to keep the semantics simpler, as requested by Johannes and Kosaki-san. > For me, SIGBUS is more special usecase for code pages but I believe > both are reasonable for each usecase so my preference is MADV_VOLATILE > is just zero-filled page and MADV_VOLATILE_SIGBUS, another new advise > if you really want to merge volatile range feature with madvise. This I disagree with. Even for non-code page cases, SIGBUS on volatile page access is important for normal users who might accidentally touch volatile data, so they know they are corrupting their data. I know Johannes suggested this is simply a use-after-free issue, but I really feel it results in having very strange semantics. And for those cases where there is a benefit to zero-fill, MADV_FREE seems more appropriate. thanks -john -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-05-08 16:38 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-04-29 21:21 [PATCH 0/4] Volatile Ranges (v14 - madvise reborn edition!) John Stultz 2014-04-29 21:21 ` John Stultz 2014-04-29 21:21 ` [PATCH 1/4] swap: Cleanup how special swap file numbers are defined John Stultz 2014-04-29 21:21 ` John Stultz 2014-04-29 21:21 ` [PATCH 2/4] MADV_VOLATILE: Add MADV_VOLATILE/NONVOLATILE hooks and handle marking vmas John Stultz 2014-04-29 21:21 ` John Stultz 2014-05-08 1:21 ` Minchan Kim 2014-05-08 1:21 ` Minchan Kim 2014-05-08 16:38 ` John Stultz [this message] 2014-05-08 16:38 ` John Stultz 2014-05-08 23:12 ` Minchan Kim 2014-05-08 23:12 ` Minchan Kim 2014-05-08 23:43 ` John Stultz 2014-05-08 23:43 ` John Stultz 2014-05-09 0:07 ` Minchan Kim 2014-05-09 0:07 ` Minchan Kim 2014-05-09 0:24 ` John Stultz 2014-05-09 0:24 ` John Stultz 2014-05-09 0:41 ` Minchan Kim 2014-05-09 0:41 ` Minchan Kim 2014-04-29 21:21 ` [PATCH 3/4] MADV_VOLATILE: Add purged page detection on setting memory non-volatile John Stultz 2014-04-29 21:21 ` John Stultz 2014-05-08 1:51 ` Minchan Kim 2014-05-08 1:51 ` Minchan Kim 2014-05-08 21:45 ` John Stultz 2014-05-08 21:45 ` John Stultz 2014-05-08 23:45 ` Minchan Kim 2014-05-08 23:45 ` Minchan Kim 2014-04-29 21:21 ` [PATCH 4/4] MADV_VOLATILE: Add page purging logic & SIGBUS trap John Stultz 2014-04-29 21:21 ` John Stultz 2014-05-08 5:16 ` Minchan Kim 2014-05-08 5:16 ` Minchan Kim 2014-05-08 16:39 ` John Stultz 2014-05-08 16:39 ` John Stultz 2014-05-08 5:58 ` [PATCH 0/4] Volatile Ranges (v14 - madvise reborn edition!) Minchan Kim 2014-05-08 5:58 ` Minchan Kim 2014-05-08 17:04 ` John Stultz 2014-05-08 17:04 ` John Stultz 2014-05-08 23:29 ` Minchan Kim 2014-05-08 23:29 ` Minchan Kim 2014-05-08 17:12 ` John Stultz 2014-05-08 17:12 ` John Stultz 2014-06-03 14:57 ` Johannes Weiner 2014-06-03 14:57 ` Johannes Weiner 2014-06-16 20:12 ` John Stultz 2014-06-16 20:12 ` John Stultz 2014-06-16 22:24 ` Andrea Arcangeli 2014-06-16 22:24 ` Andrea Arcangeli
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=536BB310.1050105@linaro.org \ --to=john.stultz@linaro.org \ --cc=aarcange@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=dave@sr71.net \ --cc=dmitry.adamushko@gmail.com \ --cc=hannes@cmpxchg.org \ --cc=hughd@google.com \ --cc=jack@suse.cz \ --cc=keithp@keithp.com \ --cc=kernel-team@android.com \ --cc=kosaki.motohiro@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mel@csn.ul.ie \ --cc=mh@glandium.org \ --cc=minchan@kernel.org \ --cc=neilb@suse.de \ --cc=riel@redhat.com \ --cc=rlove@google.com \ --cc=tglek@mozilla.com \ --cc=walken@google.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.