From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by kanga.kvack.org (Postfix) with ESMTP id B97156B003D for ; Fri, 11 Apr 2014 15:32:31 -0400 (EDT) Received: by mail-pd0-f175.google.com with SMTP id x10so5617463pdj.6 for ; Fri, 11 Apr 2014 12:32:31 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by mx.google.com with ESMTPS id iw3si4794056pac.178.2014.04.11.12.32.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Apr 2014 12:32:30 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id bj1so5830213pad.3 for ; Fri, 11 Apr 2014 12:32:30 -0700 (PDT) Message-ID: <53484349.1000806@linaro.org> Date: Fri, 11 Apr 2014 12:32:25 -0700 From: John Stultz MIME-Version: 1.0 Subject: Re: [PATCH 0/5] Volatile Ranges (v12) & LSF-MM discussion fodder 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> <20140402194708.GV14688@cmpxchg.org> <533C6F6E.4080601@linaro.org> In-Reply-To: <533C6F6E.4080601@linaro.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 04/02/2014 01:13 PM, John Stultz wrote: > On 04/02/2014 12:47 PM, Johannes Weiner wrote: > >> It's really nothing but a use-after-free bug that has consequences for >> no-one but the faulty application. The thing that IS new is that even >> a read is enough to corrupt your data in this case. >> >> MADV_REVIVE could return 0 if all pages in the specified range were >> present, -Esomething if otherwise. That would be semantically sound >> even if userspace messes up. > So its semantically more of just a combined mincore+dirty operation.. > and nothing more? > > What are other folks thinking about this? Although I don't particularly > like it, I probably could go along with Johannes' approach, forgoing > SIGBUS for zero-fill and adapting the semantics that are in my mind a > bit stranger. This would allow for ashmem-like style behavior w/ the > additional write-clears-volatile-state and read-clears-purged-state > constraints (which I don't think would be problematic for Android, but > am not totally sure). > > But I do worry that these semantics are easier for kernel-mm-developers > to grasp, but are much much harder for application developers to > understand. So I don't feel like we've gotten enough feedback for consensus here. Thus, to at least address other issues pointed out at LSF-MM, I'm going to shortly send out a v13 of the patchset which keeps with the previous approach instead of adopting Johannes' suggested approach here. If folks do prefer Johannes' approach, please speak up as I'm willing to give it a whirl, despite my concerns about the subtle semantics. 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