From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by kanga.kvack.org (Postfix) with ESMTP id E71096B00DE for ; Wed, 2 Apr 2014 15:01:02 -0400 (EDT) Received: by mail-qa0-f46.google.com with SMTP id i13so597565qae.33 for ; Wed, 02 Apr 2014 12:01:02 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) by mx.google.com with ESMTPS id s6si1185656qaj.131.2014.04.02.12.01.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Apr 2014 12:01:00 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id 63so641131qgz.5 for ; Wed, 02 Apr 2014 12:01:00 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20140402175852.GS14688@cmpxchg.org> References: <1395436655-21670-1-git-send-email-john.stultz@linaro.org> <20140401212102.GM4407@cmpxchg.org> <533B313E.5000403@zytor.com> <533B4555.3000608@sr71.net> <533B8E3C.3090606@linaro.org> <20140402163638.GQ14688@cmpxchg.org> <20140402175852.GS14688@cmpxchg.org> Date: Wed, 2 Apr 2014 12:01:00 -0700 Message-ID: Subject: Re: [PATCH 0/5] Volatile Ranges (v12) & LSF-MM discussion fodder From: John Stultz Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Johannes Weiner Cc: Dave Hansen , "H. Peter Anvin" , LKML , Andrew Morton , Android Kernel Team , Robert Love , Mel Gorman , Hugh Dickins , Rik van Riel , Dmitry Adamushko , Neil Brown , Andrea Arcangeli , Mike Hommey , Taras Glek , Jan Kara , KOSAKI Motohiro , Michel Lespinasse , Minchan Kim , "linux-mm@kvack.org" On Wed, Apr 2, 2014 at 10:58 AM, Johannes Weiner wrote: > On Wed, Apr 02, 2014 at 10:40:16AM -0700, John Stultz wrote: >> That point beside, I think the other problem with the page-cleaning >> volatility approach is that there are other awkward side effects. For >> example: Say an application marks a range as volatile. One page in the >> range is then purged. The application, due to a bug or otherwise, >> reads the volatile range. This causes the page to be zero-filled in, >> and the application silently uses the corrupted data (which isn't >> great). More problematic though, is that by faulting the page in, >> they've in effect lost the purge state for that page. When the >> application then goes to mark the range as non-volatile, all pages are >> present, so we'd return that no pages were purged. From an >> application perspective this is pretty ugly. >> >> Johannes: Any thoughts on this potential issue with your proposal? Am >> I missing something else? > > No, this is accurate. However, I don't really see how this is > different than any other use-after-free bug. If you access malloc > memory after free(), you might receive a SIGSEGV, you might see random > data, you might corrupt somebody else's data. This certainly isn't > nice, but it's not exactly new behavior, is it? The part that troubles me is that I see the purged state as kernel data being corrupted by userland in this case. The kernel will tell userspace that no pages were purged, even though they were. Only because userspace made an errant read of a page, and got garbage data back. 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: email@kvack.org