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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 58254C433EF for ; Thu, 2 Dec 2021 19:59:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8B16E6B0072; Thu, 2 Dec 2021 14:59:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 861636B0074; Thu, 2 Dec 2021 14:59:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7293B6B0075; Thu, 2 Dec 2021 14:59:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0162.hostedemail.com [216.40.44.162]) by kanga.kvack.org (Postfix) with ESMTP id 607AE6B0072 for ; Thu, 2 Dec 2021 14:59:28 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 0E4D0180FF4D3 for ; Thu, 2 Dec 2021 19:59:18 +0000 (UTC) X-FDA: 78873918396.24.E04E153 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf04.hostedemail.com (Postfix) with ESMTP id 5DE5C40004 for ; Thu, 2 Dec 2021 19:59:17 +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=2lzsGjuMasyWxC1shMbRa1P/BpgSesmupx2ZuN5KYd4=; b=hfOX1TOh+hRMgtHkK3eV8Vw3QZ mYCZx6muJCR7xnp3kqqRXn2U8/CK+TB26hJ/rpk20d6z6vIaXV0d98rjaGMISxVv1jN7A4LBND5QI ZU9pHum9EPwQ5IluUu6N1vvOSGbvuefbfVCAfiFZxzfqUf4cyujmqzpcKSa/KxaRmHc3qxzV5NQJF AZ+hr4UlbUQc2ltRyYhNGZy/3uMQ7Vcxkvn17F9+KoEXnWoYDShNiOQhomW8T9Y3eIDElFbT2bM6i XLC3Wd3vZg1n15Pha2t3ON3ZtYA/ZT4F0HjKlHfzcdgoYPCZf/7hkNV2LWmVr/OOO9/rDBCLurNnr YEWKKRng==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mssEU-005PGQ-3m; Thu, 02 Dec 2021 19:59:06 +0000 Date: Thu, 2 Dec 2021 19:59:06 +0000 From: Matthew Wilcox To: Linus Torvalds Cc: Jann Horn , Jan Kara , Kirill Shutemov , Oleg Nesterov , Christoph Hellwig , Linux-MM , Linux Kernel Mailing List , Mike Kravetz Subject: Re: [5.4 PATCH] mm/gup: Do not force a COW break on file-backed memory Message-ID: References: <20211201231757.332199-1-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 5DE5C40004 X-Stat-Signature: akpn8ixojiup87195riu596zmnc3bx8a Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=hfOX1TOh; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-HE-Tag: 1638475157-706841 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 Thu, Dec 02, 2021 at 10:54:48AM -0800, Linus Torvalds wrote: > On Wed, Dec 1, 2021 at 8:11 PM Matthew Wilcox wrote: > > > > The other patch we've been kicking around (and works) is: > > > > static inline bool should_force_cow_break(struct vm_area_struct *vma, unsigned > > int flags) > > { > > - return is_cow_mapping(vma->vm_flags) && (flags & FOLL_GET); > > + return is_cow_mapping(vma->vm_flags) && > > + (!(vma->vm_flags & VM_DENYWRITE)) && (flags & FOLL_GET); > > } > > That patch makes no sense to me. > > It may "work", but it doesn't actually do anything sensible or really > fix the problem that I can tell. Oh absolutely, it's semantically nonsense. The only reason it fixes the problem is that VM_DENYWRITE VMAs are the only ones considered for the RO_THP merging, so they're the only ones which we've seen causing a problem. > I suspect a real fix would be bigger and more invasive. Darn. I was hoping you were going to say something like "The real problem is follow_trans_huge_pmd() is complete garbage and it should just do X, Y and Z". Or "When we force on FOLL_WRITE, we should also force on FOLL_SPLIT_PMD". > If the answer is not to backport all the other changes (and they were > _really_ invasive), I think one answer may be to simply move the > "should_force_cow_break()" down to below the point where you've looked > up the page. > > Then you can actually look at "is this a file mapped page", and say > "if so, that's ok, we can return it as-is". > > Otherwise, you do something like > > foll_flags |= FOLL_WRITE; > free_page(page); > goto repeat; > > to repeat the loop (now with FOLL_WRITE). > > So the patch is bigger and more involved, because you would have done > the page lookup (for reading) and now notice "Oh, I need it for > writing instead" so you need to undo and re-do). > > But at least - unlike backporting everything else - it would be > limited to that one __get_user_pages() function. > > Hmm? > > (And you'd need to handle that follow_hugetlb_page() case too), not > just the follow_page_mask() one) Thanks, I'll take a look.