Message ID | 20230728091849.7f32259d@canb.auug.org.au |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:918b:0:b0:3e4:2afc:c1 with SMTP id s11csp107224vqg; Thu, 27 Jul 2023 17:54:30 -0700 (PDT) X-Google-Smtp-Source: APBJJlHUU05U1357ZWuQhdyavO9+GM0eTUDtsHtvyaU5X+PTcPpR/sMpQQ0APoQWZV9qMDhFg7vs X-Received: by 2002:aa7:c409:0:b0:51e:eaf:4fea with SMTP id j9-20020aa7c409000000b0051e0eaf4feamr378073edq.35.1690505669817; Thu, 27 Jul 2023 17:54:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690505669; cv=none; d=google.com; s=arc-20160816; b=omoa2bUzPjVtYi2mm21fkOcexTSPK0JQIgSEyeYFpq5m5uS0GwBmldULsWrb5gv72/ dhlUM9CdXMvfhv5H94qxZCLVSVWgoHsiLVtxC8nSxdknDqCLSVeOJbx2qbjD9ovc4u0u 67olILqhl757YaD8ObiHBCD+u7XtnwpUoMvKIpdcvZvukQyozYKCyvTylbLny6eLlYl3 IIKPU+5r6X88mpLqx/Gz9XbkShh/KYA1g4QjJ8Fg/LKhil5GU3wHVs4O1wqzJcFlGCOF 2fRCIua3UBixJqM2NLR/0BS4OG0iaViRcVDcixcFgfMRPmXcFA0uaKWwKxV5P6eSh1fP pXzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:subject:cc:to:from:date :dkim-signature; bh=jU5JsLHZmKBu77K0XMsV1r5yt36hT5CLa9hx2frbJj0=; fh=PSo3nDQPfHVPX9XiEdA7e7Lza8c+u0cuN6E6LPt7lPE=; b=zDqojcvpWpXoQa6cnz5zqzbxPsnffenSnAe7Vl7aQxkrDo/0WE+T8NvZAanvA3Ypbf xXZb8JQRDTI+JaLjzT12xQpP4ofJ1kD82moN/qREWmgZtSiaRNpnR7fNbS/L+iwB6eA6 X3vtLLMRuzXvxVzfjz7b8ykaqsz9sxCBPAfqCHnODEqPXZ4OiV4pGVv/6cWzkNdPn3Tr LS2ua9CCoHpwmuAsvbFTQhJB03iiqB3xo9MUkKI0i7D5eRhY1pbvssi/Dlna1RU9HEO0 KwJ5+DaYv45jgST5iFAU9jovmwiu1/5yubKm8FxoYvHX45IwMbXrpbkBgOcSVA3qwxoj JT5Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@canb.auug.org.au header.s=201702 header.b="fmJ3/vlJ"; 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=NONE dis=NONE) header.from=canb.auug.org.au Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bc4-20020a056402204400b005223c3425a5si1642638edb.147.2023.07.27.17.54.05; Thu, 27 Jul 2023 17:54:29 -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=@canb.auug.org.au header.s=201702 header.b="fmJ3/vlJ"; 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=NONE dis=NONE) header.from=canb.auug.org.au Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231314AbjG0XTL (ORCPT <rfc822;kloczko.tomasz@gmail.com> + 99 others); Thu, 27 Jul 2023 19:19:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37218 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229731AbjG0XTK (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 27 Jul 2023 19:19:10 -0400 Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D0D5A30D3; Thu, 27 Jul 2023 16:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canb.auug.org.au; s=201702; t=1690499943; bh=jU5JsLHZmKBu77K0XMsV1r5yt36hT5CLa9hx2frbJj0=; h=Date:From:To:Cc:Subject:From; b=fmJ3/vlJ9IpmHCnOw5NJJj8Kuw75rkoQEUTCiMuqKNepao9NfuUX5UYMtop3wt03p gH8eHIO6nDKSLd67jkOPNm03jEFDpcRHd0OP9Dl2JpJQQQQdOyx5sG9o8k84j/wmow 8oA7E9sNXPXH1UwPg3Z5dFlpFDXnw+MHPkBSOuDF1mT51iEJ2/6WObkngBHKjU6Z6j yLMgLlU8itd2t1Vra8OyVlEvesQ+sLiKTaSG9GYPUyxfQfGb8gjZ+Bv2/EClK4GShO ISqJ9Fzh2PJsgo58z7Q96Q5+XMe7D/VwKYFO7UvMsccdR5+UFfkqKT0MPf5hbtM04G 3vjCOaCHBT5MA== Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4RBmtG70tnz4wZw; Fri, 28 Jul 2023 09:19:02 +1000 (AEST) Date: Fri, 28 Jul 2023 09:18:49 +1000 From: Stephen Rothwell <sfr@canb.auug.org.au> To: Andrew Morton <akpm@linux-foundation.org> Cc: Jann Horn <jannh@google.com>, Linus Torvalds <torvalds@linux-foundation.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux Next Mailing List <linux-next@vger.kernel.org>, "Matthew Wilcox (Oracle)" <willy@infradead.org>, Suren Baghdasaryan <surenb@google.com> Subject: linux-next: manual merge of the mm tree with Linus' tree Message-ID: <20230728091849.7f32259d@canb.auug.org.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/TtX60qia5O1Es19qg7bXjYk"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1772620368069097959 X-GMAIL-MSGID: 1772623673414384321 |
Series |
linux-next: manual merge of the mm tree with Linus' tree
|
|
Commit Message
Stephen Rothwell
July 27, 2023, 11:18 p.m. UTC
Hi all, Today's linux-next merge of the mm tree got a conflict in: mm/memory.c between commit: 657b5146955e ("mm: lock_vma_under_rcu() must check vma->anon_vma under vma lock") from Linus' tree and commits: 69f6bbd1317f ("mm: handle userfaults under VMA lock") a3bdf38e85aa ("mm: allow per-VMA locks on file-backed VMAs") from the mm tree. I fixed it up (I think, please check - see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts.
Comments
Hi Matthew, On Fri, 28 Jul 2023 00:49:50 +0100 Matthew Wilcox <willy@infradead.org> wrote: > > On Fri, Jul 28, 2023 at 09:18:49AM +1000, Stephen Rothwell wrote: > > diff --cc mm/memory.c > > index ca632b58f792,271982fab2b8..000000000000 > > --- a/mm/memory.c > > +++ b/mm/memory.c > > @@@ -5392,32 -5597,18 +5597,21 @@@ retry > > if (!vma) > > goto inval; > > > > - /* Only anonymous and tcp vmas are supported for now */ > > - if (!vma_is_anonymous(vma) && !vma_is_tcp(vma)) > > - /* find_mergeable_anon_vma uses adjacent vmas which are not locked */ > > - if (vma_is_anonymous(vma) && !vma->anon_vma) > > -- goto inval; > > -- > > if (!vma_start_read(vma)) > > goto inval; > > > > + /* > > + * find_mergeable_anon_vma uses adjacent vmas which are not locked. > > + * This check must happen after vma_start_read(); otherwise, a > > + * concurrent mremap() with MREMAP_DONTUNMAP could dissociate the VMA > > + * from its anon_vma. > > + */ > > - if (unlikely(!vma->anon_vma && !vma_is_tcp(vma))) > > - goto inval_end_read; > > - > > - /* > > - * Due to the possibility of userfault handler dropping mmap_lock, avoid > > - * it for now and fall back to page fault handling under mmap_lock. > > - */ > > - if (userfaultfd_armed(vma)) > > ++ if (unlikely(vma_is_anonymous(vma) && !vma_is_tcp(vma))) > > + goto inval_end_read; > > + > > No, this isn't right. It should be: > > if (unlikely(vma_is_anonymous(vma) && !vma->anon_vma)) > goto inval_end_read; Yeah, see my second attempt. > I'm not sure about the userfaultfd_armed() clause. My patch wasn't > intended to affect that. That was removed by commit 69f6bbd1317f ("mm: handle userfaults under VMA lock") in the mm branch.
On Thu, Jul 27, 2023 at 5:21 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi Matthew, > > On Fri, 28 Jul 2023 00:49:50 +0100 Matthew Wilcox <willy@infradead.org> wrote: > > > > On Fri, Jul 28, 2023 at 09:18:49AM +1000, Stephen Rothwell wrote: > > > diff --cc mm/memory.c > > > index ca632b58f792,271982fab2b8..000000000000 > > > --- a/mm/memory.c > > > +++ b/mm/memory.c > > > @@@ -5392,32 -5597,18 +5597,21 @@@ retry > > > if (!vma) > > > goto inval; > > > > > > - /* Only anonymous and tcp vmas are supported for now */ > > > - if (!vma_is_anonymous(vma) && !vma_is_tcp(vma)) > > > - /* find_mergeable_anon_vma uses adjacent vmas which are not locked */ > > > - if (vma_is_anonymous(vma) && !vma->anon_vma) > > > -- goto inval; > > > -- > > > if (!vma_start_read(vma)) > > > goto inval; > > > > > > + /* > > > + * find_mergeable_anon_vma uses adjacent vmas which are not locked. > > > + * This check must happen after vma_start_read(); otherwise, a > > > + * concurrent mremap() with MREMAP_DONTUNMAP could dissociate the VMA > > > + * from its anon_vma. > > > + */ > > > - if (unlikely(!vma->anon_vma && !vma_is_tcp(vma))) > > > - goto inval_end_read; > > > - > > > - /* > > > - * Due to the possibility of userfault handler dropping mmap_lock, avoid > > > - * it for now and fall back to page fault handling under mmap_lock. > > > - */ > > > - if (userfaultfd_armed(vma)) > > > ++ if (unlikely(vma_is_anonymous(vma) && !vma_is_tcp(vma))) > > > + goto inval_end_read; > > > + > > > > No, this isn't right. It should be: > > > > if (unlikely(vma_is_anonymous(vma) && !vma->anon_vma)) > > goto inval_end_read; > > Yeah, see my second attempt. > > > I'm not sure about the userfaultfd_armed() clause. My patch wasn't > > intended to affect that. > > That was removed by commit > > 69f6bbd1317f ("mm: handle userfaults under VMA lock") > > in the mm branch. Hmm. 657b5146955e ("mm: lock_vma_under_rcu() must check vma->anon_vma under vma lock") should be adding a "inval_end_read" label. At least I see it in https://lore.kernel.org/all/20230726214103.3261108-3-jannh@google.com/ and will check Linus' tree in a min. I don't see that label in your patch... I also misspoke in my previous message. The patches in mm tree remove some code from that function, so it's easier to apply them first and then the one from Linus' tree. > > -- > Cheers, > Stephen Rothwell
Hi Suren, On Thu, 27 Jul 2023 17:23:45 -0700 Suren Baghdasaryan <surenb@google.com> wrote: > Hmm. 657b5146955e ("mm: lock_vma_under_rcu() must check vma->anon_vma > under vma lock") should be adding a "inval_end_read" label. At least I > see it in https://lore.kernel.org/all/20230726214103.3261108-3-jannh@google.com/ > and will check Linus' tree in a min. I don't see that label in your > patch... It's there in the file, but did not conflict with anything. What I published is not a "patch" as such, but a diff showing the conflict resolution.
On Thu, Jul 27, 2023 at 5:29 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi Suren, > > On Thu, 27 Jul 2023 17:23:45 -0700 Suren Baghdasaryan <surenb@google.com> wrote: > > > Hmm. 657b5146955e ("mm: lock_vma_under_rcu() must check vma->anon_vma > > under vma lock") should be adding a "inval_end_read" label. At least I > > see it in https://lore.kernel.org/all/20230726214103.3261108-3-jannh@google.com/ > > and will check Linus' tree in a min. I don't see that label in your > > patch... > > It's there in the file, but did not conflict with anything. What I > published is not a "patch" as such, but a diff showing the conflict > resolution. Ah, sorry for the noise then. > > -- > Cheers, > Stephen Rothwell
On Fri, Jul 28, 2023 at 10:00:47AM +1000, Stephen Rothwell wrote: > I have gone with below. Again, please check. LGTM > diff --cc mm/memory.c > index ca632b58f792,271982fab2b8..000000000000 > --- a/mm/memory.c > +++ b/mm/memory.c > @@@ -5392,32 -5597,18 +5597,21 @@@ retry > if (!vma) > goto inval; > > - /* Only anonymous and tcp vmas are supported for now */ > - if (!vma_is_anonymous(vma) && !vma_is_tcp(vma)) > - /* find_mergeable_anon_vma uses adjacent vmas which are not locked */ > - if (vma_is_anonymous(vma) && !vma->anon_vma) > -- goto inval; > -- > if (!vma_start_read(vma)) > goto inval; > > + /* > + * find_mergeable_anon_vma uses adjacent vmas which are not locked. > + * This check must happen after vma_start_read(); otherwise, a > + * concurrent mremap() with MREMAP_DONTUNMAP could dissociate the VMA > + * from its anon_vma. > + */ > - if (unlikely(!vma->anon_vma && !vma_is_tcp(vma))) > - goto inval_end_read; > - > - /* > - * Due to the possibility of userfault handler dropping mmap_lock, avoid > - * it for now and fall back to page fault handling under mmap_lock. > - */ > - if (userfaultfd_armed(vma)) > ++ if (unlikely(vma_is_anonymous(vma) && !vma->anon_vma)) > + goto inval_end_read; > + > /* Check since vm_start/vm_end might change before we lock the VMA */ > - if (unlikely(address < vma->vm_start || address >= vma->vm_end)) { > - vma_end_read(vma); > - goto inval; > - } > + if (unlikely(address < vma->vm_start || address >= vma->vm_end)) > + goto inval_end_read; > > /* Check if the VMA got isolated after we found it */ > if (vma->detached) { If Andrew wants to rebase on Linus' tree, I'll be happy to respin on top of that.
diff --cc mm/memory.c index ca632b58f792,271982fab2b8..000000000000 --- a/mm/memory.c