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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 5E1A4C64E7B for ; Tue, 1 Dec 2020 12:59:36 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BCCCA207FF for ; Tue, 1 Dec 2020 12:59:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="cKgT78pH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BCCCA207FF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C56688D0002; Tue, 1 Dec 2020 07:59:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BB6678D0001; Tue, 1 Dec 2020 07:59:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A57EF8D0002; Tue, 1 Dec 2020 07:59:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0225.hostedemail.com [216.40.44.225]) by kanga.kvack.org (Postfix) with ESMTP id 8E1B28D0001 for ; Tue, 1 Dec 2020 07:59:34 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 4E1312481 for ; Tue, 1 Dec 2020 12:59:34 +0000 (UTC) X-FDA: 77544719868.13.maid41_0715885273aa Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id 21DB018140B69 for ; Tue, 1 Dec 2020 12:59:34 +0000 (UTC) X-HE-Tag: maid41_0715885273aa X-Filterd-Recvd-Size: 3870 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Tue, 1 Dec 2020 12:59:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=A/weu5pnukRhVU7q8jWcuRe0AHdNtgBdrJmzM8pOUaI=; b=cKgT78pHn6uvtONlR4vcFaVwdR Hf39+E3MvAJ68bTfkwNKPj3aL1fG7L3wFOviVqulK4jg0FKvT17Uch3XUoFhVRcZZ1eDUU3fPIEic 2biLL0Vs9O5/F1JK2YF9LSHK8LcTYSIjt69OIqKZiFhAAZA3OUO4eNi0aV0Zb/6Lu1x5Yn4PDj4kG aSu5ZMfXdBKD0boQp5dNkB8g0Iz36cmdUjPKC3EbqiN4Sl8V5if5msDtm5J0rGPEk6HDOQE2iVhvm OoJoxQaiCsHlnfH/57jilzyS4AWy6xxstVL1WBIpr5UzOOKBO/75/LJN2Qt9ZE496Sr2Z60LaLUfZ hiwv88og==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kk5Ff-0006aN-P1; Tue, 01 Dec 2020 12:59:27 +0000 Date: Tue, 1 Dec 2020 12:59:27 +0000 From: Matthew Wilcox To: Peter Xu Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Hugh Dickins , Andrea Arcangeli , Mike Rapoport Subject: Re: [PATCH v2] mm: Don't fault around userfaultfd-registered regions on reads Message-ID: <20201201125927.GB11935@casper.infradead.org> References: <20201130230603.46187-1-peterx@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201130230603.46187-1-peterx@redhat.com> 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: On Mon, Nov 30, 2020 at 06:06:03PM -0500, Peter Xu wrote: > Faulting around for reads are in most cases helpful for the performance so that > continuous memory accesses may avoid another trip of page fault. However it > may not always work as expected. > > For example, userfaultfd registered regions may not be the best candidate for > pre-faults around the reads. > > For missing mode uffds, fault around does not help because if the page cache > existed, then the page should be there already. If the page cache is not > there, nothing else we can do, either. If the fault-around code is destined to > be helpless for userfault-missing vmas, then ideally we can skip it. This sounds like you're thinking of a file which has exactly one user. If there are multiple processes mapping the same file, then no, there's no reason to expect a page to be already present in the page table, just because it's present in the page cache. > 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. This still doesn't make sense. If the page is Uptodate in the page cache, then userspace gets to access it. If you don't want the page to be accessible, ClearPageUptodate(). read() can also access it if it's marked Uptodate. A write fault on a page will call the filesystem's page_mkwrite() and you can block it there.