From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33687) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbC20-0005hj-BZ for qemu-devel@nongnu.org; Mon, 06 Oct 2014 13:25:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XbC1s-0003cl-Ov for qemu-devel@nongnu.org; Mon, 06 Oct 2014 13:25:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62619) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbC1s-0003cX-FI for qemu-devel@nongnu.org; Mon, 06 Oct 2014 13:25:00 -0400 Date: Mon, 6 Oct 2014 19:24:15 +0200 From: Andrea Arcangeli Message-ID: <20141006172415.GC31075@redhat.com> References: <1412356087-16115-1-git-send-email-aarcange@redhat.com> <1412356087-16115-9-git-send-email-aarcange@redhat.com> <20141003231336.GA13528@glandium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141003231336.GA13528@glandium.org> Subject: Re: [Qemu-devel] [PATCH 08/17] mm: madvise MADV_USERFAULT List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mike Hommey Cc: Robert Love , Dave Hansen , Jan Kara , kvm@vger.kernel.org, Neil Brown , Stefan Hajnoczi , qemu-devel@nongnu.org, linux-mm@kvack.org, KOSAKI Motohiro , Michel Lespinasse , Taras Glek , Andrew Jones , Juan Quintela , Hugh Dickins , Isaku Yamahata , Mel Gorman , Sasha Levin , Android Kernel Team , "\\\"Dr. David Alan Gilbert\\\"" , "Huangpeng (Peter)" , Andres Lagar-Cavilla , Christopher Covington , Anthony Liguori , Keith Packard , Wenchao Xia , linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, Andy Lutomirski , Minchan Kim , Dmitry Adamushko , Johannes Weiner , Paolo Bonzini , Andrew Morton , Linus Torvalds , Peter Feiner Hi, On Sat, Oct 04, 2014 at 08:13:36AM +0900, Mike Hommey wrote: > On Fri, Oct 03, 2014 at 07:07:58PM +0200, Andrea Arcangeli wrote: > > MADV_USERFAULT is a new madvise flag that will set VM_USERFAULT in the > > vma flags. Whenever VM_USERFAULT is set in an anonymous vma, if > > userland touches a still unmapped virtual address, a sigbus signal is > > sent instead of allocating a new page. The sigbus signal handler will > > then resolve the page fault in userland by calling the > > remap_anon_pages syscall. > > What does "unmapped virtual address" mean in this context? To clarify this I added this in a second sentence in the commit header: "still unmapped virtual address" of the previous sentence in this context means that the pte/trans_huge_pmd is null. It means it's an hole inside the anonymous vma (the kind of hole that doesn't account for RSS but only virtual size of the process). It is the same state all anonymous virtual memory is, right after mmap. The same state that if you read from it, will map a zeropage into the faulting virtual address. If the page is swapped out, it will not trigger userfaults. If something isn't clear let me know. Thanks, Andrea