From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-17.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 21A96C3E8C5 for ; Sat, 28 Nov 2020 00:33:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 76A872223F for ; Sat, 28 Nov 2020 00:33:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="YsXt0CXw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 76A872223F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 78DAE6B005C; Fri, 27 Nov 2020 19:33:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 717B76B005D; Fri, 27 Nov 2020 19:33:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5DFF46B0068; Fri, 27 Nov 2020 19:33:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0159.hostedemail.com [216.40.44.159]) by kanga.kvack.org (Postfix) with ESMTP id 41B566B005C for ; Fri, 27 Nov 2020 19:33:48 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 0189E180AD822 for ; Sat, 28 Nov 2020 00:33:48 +0000 (UTC) X-FDA: 77531954136.09.mom39_460d0452738c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin09.hostedemail.com (Postfix) with ESMTP id DEFD3180AD81F for ; Sat, 28 Nov 2020 00:33:47 +0000 (UTC) X-HE-Tag: mom39_460d0452738c X-Filterd-Recvd-Size: 7116 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Sat, 28 Nov 2020 00:33:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1606523626; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=KFfdlT9oNUwho2w5XQHB2zyqSSAHo4d/LdFWl9C4gCA=; b=YsXt0CXwQ1CHO72X73KBCShx4OYl15OWyrrKkt0JbcXIgUBnrXF+3njlsvWhG5z1JhJ9d1 a051cdOZM9Ir9lHjDZvCw7Ty3npyS9bje6zCDCSBdxDcOnqtjtPci3+WjKgULVH+y4kOYA nSyN5ChLTSxPIGbmzxnmYfEexW7J6Tw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-489-Kqd8r88RMNacv7rPCQ94aA-1; Fri, 27 Nov 2020 19:33:45 -0500 X-MC-Unique: Kqd8r88RMNacv7rPCQ94aA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7607F10059A2; Sat, 28 Nov 2020 00:33:43 +0000 (UTC) Received: from mail (ovpn-112-118.rdu2.redhat.com [10.10.112.118]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3D5A96085D; Sat, 28 Nov 2020 00:33:40 +0000 (UTC) Date: Fri, 27 Nov 2020 19:33:39 -0500 From: Andrea Arcangeli To: Matthew Wilcox Cc: Peter Xu , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Hugh Dickins , Mike Rapoport Subject: Re: [PATCH] mm: Don't fault around userfaultfd-registered regions on reads Message-ID: References: <20201126222359.8120-1-peterx@redhat.com> <20201127122224.GX4327@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201127122224.GX4327@casper.infradead.org> User-Agent: Mutt/2.0.2 (2020-11-20) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hello, On Fri, Nov 27, 2020 at 12:22:24PM +0000, Matthew Wilcox wrote: > On Thu, Nov 26, 2020 at 05:23:59PM -0500, Peter Xu wrote: > > For wr-protected mode uffds, errornously fault in those pages around could lead > > to threads accessing the pages without uffd server's awareness. For example, > > when punching holes on uffd-wp registered shmem regions, we'll first try to > > unmap all the pages before evicting the page cache but without locking the > > page (please refer to shmem_fallocate(), where unmap_mapping_range() is called > > before shmem_truncate_range()). When fault-around happens near a hole being > > punched, we might errornously fault in the "holes" right before it will be > > punched. Then there's a small window before the page cache was finally > > dropped, and after the page will be writable again (NOTE: the uffd-wp protect > > information is totally lost due to the pre-unmap in shmem_fallocate(), so the > > page can be writable within the small window). That's severe data loss. > > Sounds like you have a missing page_mkwrite implementation. If the real fault happened through the pagetable (which got dropped by the hole punching), a "missing type" userfault would be delivered to userland (because the pte would be none). Userland would invoke UFFDIO_COPY with the UFFDIO_COPY_MODE_WP flag. Such flag would then map the filled shmem page (not necessarily all zero and not necessarily the old content before the hole punch) with _PAGE_RW not set and _PAGE_UFFD_WP set, so the next write would also trigger a wrprotect userfault (this is what the uffd-wp app expects). filemap_map_pages doesn't notify userland when it fills a pte and it will map again the page read-write. However filemap_map_pages isn't capable to fill a hole and to undo the hole punch, all it can do are minor faults to re-fill the ptes from a not-yet-truncated inode page. Now it would be ok if filemap_map_pages re-filled the ptes, after they were zapped the first time by fallocate, and then the fallocate would zap them again before truncating the page, but I don't see a second pte zap... there's just the below single call of unmap_mapping_range: if ((u64)unmap_end > (u64)unmap_start) unmap_mapping_range(mapping, unmap_start, 1 + unmap_end - unmap_start, 0); shmem_truncate_range(inode, offset, offset + len - 1); So looking at filemap_map_pages in shmem, I'm really wondering if the non-uffd case is correct or not. Do we end up with ptes pointing to non pagecache, so then the virtual mapping is out of sync also with read/write syscalls that will then allocate another shmem page out of sync of the ptes? If a real page fault happened instead of filemap_map_pages, the shmem_fault() would block during fallocate punch hole by checking inode->i_private, as the comment says: * So refrain from * faulting pages into the hole while it's being punched. It's not immediately clear where filemap_map_pages refrains from faulting pages into the hole while it's being punched... given it's ignoring inode->i_private. So I'm not exactly sure how shmem can safely faulted in through filemap_map_pages, without going through shmem_fault... I suppose shmem simply is unsafe to use filemap_map_pages and it'd require a specific shmem_map_pages? If only filemap_map_pages was refraining re-faulting ptes of a shmem page that is about to be truncated (whose original ptes had _PAGE_RW unset and _PAGE_UFFD_WP set) there would be no problem with the uffd interaction. So a proper shmem_map_pages could co-exist with uffd, the userfaultfd_armed check would be only an optimization but it wouldn't be required to avoid userland memory corruption? >From 8c6fb1b7dde309f0c8b5666a8e13557ae46369b4 Mon Sep 17 00:00:00 2001 From: Andrea Arcangeli Date: Fri, 27 Nov 2020 19:12:44 -0500 Subject: [PATCH 1/1] shmem: stop faulting in pages without checking inode->i_private Per shmem_fault comment shmem need to "refrain from faulting pages into the hole while it's being punched" and to do so it must check inode->i_private, which filemap_map_pages won't so it's unsafe to use in shmem because it can leave ptes pointing to non-pagecache pages in shmem backed vmas. Signed-off-by: Andrea Arcangeli --- mm/shmem.c | 1 - 1 file changed, 1 deletion(-) diff --git a/mm/shmem.c b/mm/shmem.c index 8e2b35ba93ad..f6f29b3e67c6 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -3942,7 +3942,6 @@ static const struct super_operations shmem_ops = { static const struct vm_operations_struct shmem_vm_ops = { .fault = shmem_fault, - .map_pages = filemap_map_pages, #ifdef CONFIG_NUMA .set_policy = shmem_set_policy, .get_policy = shmem_get_policy, Thanks, Andrea