Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp871090rwr; Thu, 4 May 2023 10:37:50 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7DBmSB5CHE95EnUFQt5pltff6P11+MoxsOXHPw4nnbDpNcxM0rS+Vzi6qLoH/6cAN0O+Z+ X-Received: by 2002:a05:6a00:170e:b0:63d:254a:3909 with SMTP id h14-20020a056a00170e00b0063d254a3909mr3517470pfc.32.1683221870543; Thu, 04 May 2023 10:37:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683221870; cv=none; d=google.com; s=arc-20160816; b=WNJc1QyE6/sg0aR6azMiuklTUMO9+/6ike8yTgbsALfLWYOlhgkJZ207C1/9OGtO+Y 0JgGHB4Yc77mjRjfyMK2sCQUxhy0WwQgZB1FleqHu+hTWWaSiFf6A82+2dFWVGdq5LQ0 fNHEl3MdRAgU42T9Oh8HqE/D+U+p3ePRxoCPbAVOU2xhRhezZ6Zo+kNpyqSBpNjuXoX6 KvUR53wxNBT9e0BxotoS7jHmSOS9gwWwIuJ3d5zvQLbPR+1T13sPWnGKLHG7FXTeCr0P bUjsSNJlpXNGHoFVQlhmuBrVYtFzhXP+fOFbJ7uKTlh7P/LLgaoeR3SQrx6RbbGREiMt NHrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=U2WuUou8YNL9Xp5WPJi0n6sPZ6G3kepjeD9YD/gQ+RQ=; b=bCHwqyl8mXOiPEqMf+bifNFm+7ca/QmDSEpu3RyVPXvkUa2WvzY7GLvmo7pe0bI7qg iFQZIZUuf9+BUIkLJ5f5zz82sMdxDShA0rucUhKPToh8FIZW4o7gzQy306L1wS90tZ75 kpLe/AjkxOj5Ww0CQ+1PfhZBPp5PBNjwntA9JNlD23+loPoLTtA23a5MOpmMxB3Pix07 L62fOyvq5TdgQKkNcvXPthWODkMu4mji6Sy+R2fqhg3v9H5o8leERki3Kij8KJL9oAeQ +3RiX2h3TrRWP9LQJpV+xdKzOodS+TD9A4pHTqn9Nm6tcDo/2IC4LEifVJjWIKrikNde AWJA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=I4tkKjcK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i26-20020a056a00005a00b0063b1421d10fsi37575720pfk.222.2023.05.04.10.37.35; Thu, 04 May 2023 10:37:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=I4tkKjcK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229980AbjEDRRV (ORCPT + 99 others); Thu, 4 May 2023 13:17:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229697AbjEDRRT (ORCPT ); Thu, 4 May 2023 13:17:19 -0400 Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CE1E74225; Thu, 4 May 2023 10:17:17 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-50bcb00a4c2so1255348a12.1; Thu, 04 May 2023 10:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683220636; x=1685812636; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=U2WuUou8YNL9Xp5WPJi0n6sPZ6G3kepjeD9YD/gQ+RQ=; b=I4tkKjcK+DCRLRIlqzczRjordUh+ogvbdiMmZfqh502Thdtfi/q7aT76ekiU4iHRdZ t1qVdUm0eYnur4o4d/BlTW8GiV9O6MJmiZigOqKlA4IT1Za7YOCjgc4lEvyyPPFNfT0S y3+SV7UjlabcX1EAKJhbDB4QrxqS2f20o6yFKxlVBQcgEJUTmzcxrxkS3sZ3WvseR/Pe Zl5fslr3SlxUnjd/Zup3Mijs3tlwakD0ubIfURE5AVo+V3qtwfWJ0oM1rXhjsOHZ3i+0 dtWfq17zIiCZFJtalZQp1oNrmh0p2DvSzGHyV4WLoKaBR2DtUfDBLLbjghuLSbrFuwms xz7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683220636; x=1685812636; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=U2WuUou8YNL9Xp5WPJi0n6sPZ6G3kepjeD9YD/gQ+RQ=; b=cHFOCKJZFp7t8FjXrvmSdYac39m+0I0WFCADNAlOAj/SbMsYV7Cl2crF/lqHze6Mco QkP/dhfor5tJRIoU3oibAFyNgmOH/TnmaN9ij4z8Xjj9fYem4EtbnqIcZ/FS8V+3/7GN 9a3inFReZB/EcsFwWXmdn8rmOCb+bDqi2pQn3UE/mCODxR8OxEcseXzm5BIgWTWHMEUo WgUgk74mD2YZKeVAn3529u9mNWFTqyNo3Do5rbd29njFIJC3u2BBUZLgHII+IUf53Wre Nnls9IE3kSymJ8UDZqJmtPm35rfTzsC4iXtlRPyZ09YPkexdAL7Ftm07HqlzZ/J/oPPY MDTg== X-Gm-Message-State: AC+VfDx80R5bAZzwaQnzWIgYdMxBoXl08HEnTAdF8anRiUZ+3s+fe+ri oqUiIkQ8+xDxiHpZF9gporA= X-Received: by 2002:a17:907:a426:b0:94a:9c9e:6885 with SMTP id sg38-20020a170907a42600b0094a9c9e6885mr7729969ejc.58.1683220635964; Thu, 04 May 2023 10:17:15 -0700 (PDT) Received: from localhost ([2a00:23ee:19a0:5577:d26d:e6d:b920:1ba2]) by smtp.gmail.com with ESMTPSA id fx21-20020a170906b75500b009531d9efcc4sm18900677ejb.133.2023.05.04.10.17.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 May 2023 10:17:14 -0700 (PDT) Date: Thu, 4 May 2023 18:17:13 +0100 From: Lorenzo Stoakes To: David Hildenbrand Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Jason Gunthorpe , Jens Axboe , Matthew Wilcox , Dennis Dalessandro , Leon Romanovsky , Christian Benvenuti , Nelson Escobar , Bernard Metzler , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Ian Rogers , Adrian Hunter , Bjorn Topel , Magnus Karlsson , Maciej Fijalkowski , Jonathan Lemon , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Christian Brauner , Richard Cochran , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , linux-fsdevel@vger.kernel.org, linux-perf-users@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, Oleg Nesterov , Jason Gunthorpe , John Hubbard , Jan Kara , "Kirill A . Shutemov" , Pavel Begunkov , Mika Penttila , Dave Chinner , Theodore Ts'o , Peter Xu , Matthew Rosato , "Paul E . McKenney" , Christian Borntraeger Subject: Re: [PATCH v8 1/3] mm/mmap: separate writenotify and dirty tracking logic Message-ID: References: <7ac8bb557517bcdc9225b4e4893a2ca7f603fcc4.1683067198.git.lstoakes@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 03, 2023 at 04:31:36PM +0200, David Hildenbrand wrote: > On 03.05.23 00:51, Lorenzo Stoakes wrote: > > vma_wants_writenotify() is specifically intended for setting PTE page table > > flags, accounting for existing page table flag state and whether the > > filesystem performs dirty tracking. > > > > Separate out the notions of dirty tracking and PTE write notify checking in > > order that we can invoke the dirty tracking check from elsewhere. > > > > Note that this change introduces a very small duplicate check of the > > separated out vm_ops_needs_writenotify() and vma_is_shared_writable() > > functions. This is necessary to avoid making vma_needs_dirty_tracking() > > needlessly complicated (e.g. passing flags or having it assume checks were > > already performed). This is small enough that it doesn't seem too > > egregious. > > > > We check to ensure the mapping is shared writable, as any GUP caller will > > be safe - MAP_PRIVATE mappings will be CoW'd and read-only file-backed > > shared mappings are not permitted access, even with FOLL_FORCE. > > > > Signed-off-by: Lorenzo Stoakes > > Reviewed-by: John Hubbard > > Reviewed-by: Mika Penttil? > > Reviewed-by: Jan Kara > > Reviewed-by: Jason Gunthorpe > > --- > > include/linux/mm.h | 1 + > > mm/mmap.c | 53 ++++++++++++++++++++++++++++++++++------------ > > 2 files changed, 41 insertions(+), 13 deletions(-) > > > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > index 27ce77080c79..7b1d4e7393ef 100644 > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -2422,6 +2422,7 @@ extern unsigned long move_page_tables(struct vm_area_struct *vma, > > #define MM_CP_UFFD_WP_ALL (MM_CP_UFFD_WP | \ > > MM_CP_UFFD_WP_RESOLVE) > > +bool vma_needs_dirty_tracking(struct vm_area_struct *vma); > > int vma_wants_writenotify(struct vm_area_struct *vma, pgprot_t vm_page_prot); > > static inline bool vma_wants_manual_pte_write_upgrade(struct vm_area_struct *vma) > > { > > diff --git a/mm/mmap.c b/mm/mmap.c > > index 5522130ae606..fa7442e44cc2 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -1475,6 +1475,42 @@ SYSCALL_DEFINE1(old_mmap, struct mmap_arg_struct __user *, arg) > > } > > #endif /* __ARCH_WANT_SYS_OLD_MMAP */ > > +/* Do VMA operations imply write notify is required? */ > > Nit: comment is superfluous, this is already self-documenting code. > > > +static bool vm_ops_needs_writenotify(const struct vm_operations_struct *vm_ops) > > +{ > > + return vm_ops && (vm_ops->page_mkwrite || vm_ops->pfn_mkwrite); > > +} > > + > > +/* Is this VMA shared and writable? */ > > Nit: dito > > > +static bool vma_is_shared_writable(struct vm_area_struct *vma) > > +{ > > + return (vma->vm_flags & (VM_WRITE | VM_SHARED)) == > > + (VM_WRITE | VM_SHARED); > > +} > > + > > +/* > > + * Does this VMA require the underlying folios to have their dirty state > > + * tracked? > > + */ > > Nit: dito > Ack, was just trying to follow the pattern of comments on these helpers but you're right, these aren't adding anything will strip. > > +bool vma_needs_dirty_tracking(struct vm_area_struct *vma) > > +{ > > + /* Only shared, writable VMAs require dirty tracking. */ > > + if (!vma_is_shared_writable(vma)) > > + return false; > > + > > + /* Does the filesystem need to be notified? */ > > + if (vm_ops_needs_writenotify(vma->vm_ops)) > > + return true; > > + > > + /* Specialty mapping? */ > > + if (vma->vm_flags & VM_PFNMAP) > > + return false; > > + > > + /* Can the mapping track the dirty pages? */ > > + return vma->vm_file && vma->vm_file->f_mapping && > > + mapping_can_writeback(vma->vm_file->f_mapping); > > +} > > + > > /* > > * Some shared mappings will want the pages marked read-only > > * to track write events. If so, we'll downgrade vm_page_prot > > @@ -1483,21 +1519,18 @@ SYSCALL_DEFINE1(old_mmap, struct mmap_arg_struct __user *, arg) > > */ > > int vma_wants_writenotify(struct vm_area_struct *vma, pgprot_t vm_page_prot) > > { > > - vm_flags_t vm_flags = vma->vm_flags; > > - const struct vm_operations_struct *vm_ops = vma->vm_ops; > > - > > /* If it was private or non-writable, the write bit is already clear */ > > - if ((vm_flags & (VM_WRITE|VM_SHARED)) != ((VM_WRITE|VM_SHARED))) > > + if (!vma_is_shared_writable(vma)) > > return 0; > > /* The backer wishes to know when pages are first written to? */ > > - if (vm_ops && (vm_ops->page_mkwrite || vm_ops->pfn_mkwrite)) > > + if (vm_ops_needs_writenotify(vma->vm_ops)) > > return 1; > > /* The open routine did something to the protections that pgprot_modify > > * won't preserve? */ > > if (pgprot_val(vm_page_prot) != > > - pgprot_val(vm_pgprot_modify(vm_page_prot, vm_flags))) > > + pgprot_val(vm_pgprot_modify(vm_page_prot, vma->vm_flags))) > > return 0; > > /* > > @@ -1511,13 +1544,7 @@ int vma_wants_writenotify(struct vm_area_struct *vma, pgprot_t vm_page_prot) > > if (userfaultfd_wp(vma)) > > return 1; > > - /* Specialty mapping? */ > > - if (vm_flags & VM_PFNMAP) > > - return 0; > > - > > - /* Can the mapping track the dirty pages? */ > > - return vma->vm_file && vma->vm_file->f_mapping && > > - mapping_can_writeback(vma->vm_file->f_mapping); > > + return vma_needs_dirty_tracking(vma); > > } > > /* > > We now have duplicate vma_is_shared_writable() and > vm_ops_needs_writenotify() checks ... > Yes, this is noted in the commit message. > > Maybe move the VM_PFNMAP and "/* Can the mapping track the dirty pages? */" > checks into a separate helper and call that from both, > vma_wants_writenotify() and vma_needs_dirty_tracking() ? I'll try to juggle it a bit more, the whole reason I'm doing these very annoying duplications is because of the ordering and precedence of the checks in both and wanting to avoid some hideious passing of flags or splitting into too many bits or returning a non-bool value etc. Will try to improve it in respin. > > > In any case > > Acked-by: David Hildenbrand > Thanks! > -- > Thanks, > > David / dhildenb >