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;
Date:   Sat, 8 Jul 2023 10:39:36 -0700
From:   Andrew Morton <akpm@linux-foundation.org>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Thorsten Leemhuis <regressions@leemhuis.info>,
        Suren Baghdasaryan <surenb@google.com>,
        Bagas Sanjaya <bagasdotme@gmail.com>,
        Jacob Young <jacobly.alt@gmail.com>,
        Laurent Dufour <ldufour@linux.ibm.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux Memory Management <linux-mm@kvack.org>,
        Linux PowerPC <linuxppc-dev@lists.ozlabs.org>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        Greg KH <gregkh@linuxfoundation.org>,
        Linux regressions mailing list <regressions@lists.linux.dev>
Subject: Re: Fwd: Memory corruption in multithreaded user space program
 while calling fork
Message-Id: <20230708103936.4f6655cd0d8e8a0478509e25@linux-foundation.org>
In-Reply-To: <CAHk-=whKd05V49AbZGF=inYmhU6H_yNvvw1grWyhQfQ=9+5-VQ@mail.gmail.com>
References: <facbfec3-837a-51ed-85fa-31021c17d6ef@gmail.com>
        <5c7455db-4ed8-b54f-e2d5-d2811908123d@leemhuis.info>
        <CAJuCfpH7BOBYGEG=op09bZrh1x3WA8HMcGBXXRhe6M5RJaen5A@mail.gmail.com>
        <CAJuCfpH7t7gCV2FkctzG2eWTUVTFZD7CtD14-WuHqBqOYBo1jA@mail.gmail.com>
        <2023070359-evasive-regroup-f3b8@gregkh>
        <CAJuCfpF=XPpPYqp2Y1Vu-GUL=RBj4fyhXoXzjBY4EKtBnYE_eQ@mail.gmail.com>
        <2023070453-plod-swipe-cfbf@gregkh>
        <20230704091808.aa2ed3c11a5351d9bf217ac9@linux-foundation.org>
        <CAJuCfpE_WjRQoDT1XnvBghCH-kpqk+pfcBJGyDnK7DZLMVG5Mw@mail.gmail.com>
        <2023070509-undertow-pulverize-5adc@gregkh>
        <7668c45a-70b1-dc2f-d0f5-c0e76ec17145@leemhuis.info>
        <20230705084906.22eee41e6e72da588fce5a48@linux-foundation.org>
        <df1d7d39-56f3-699c-0d0f-fcc8774f182e@leemhuis.info>
        <CAHk-=whKd05V49AbZGF=inYmhU6H_yNvvw1grWyhQfQ=9+5-VQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Sat, 8 Jul 2023 10:29:42 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Sat, 8 Jul 2023 at 04:35, Thorsten Leemhuis
> <regressions@leemhuis.info> wrote:
> >
> > The plan since early this week is to mark CONFIG_PER_VMA_LOCK as broken;
> > latest patch that does this is this one afaics:
> 
> Bah.
> 
> Both marking it as broken and the pending fix seems excessive.
> 
> Why isn't the trivial fix just to say "yes, fork() gets the mmap_lock
> for writing for a reason, and that reason is that it acts kind of like
> mprotect()".
> 
> And then just do what those functions do.
> 
> IOW, why isn't the fix just to do
> 
>   --- a/kernel/fork.c
>   +++ b/kernel/fork.c
>   @@ -686,6 +686,7 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
>         for_each_vma(old_vmi, mpnt) {
>                 struct file *file;
> 
>   +             vma_start_write(mpnt);
>                 if (mpnt->vm_flags & VM_DONTCOPY) {
>                         vm_stat_account(mm, mpnt->vm_flags, -vma_pages(mpnt));
>                         continue;
> 
> and be done with this? Yes, we could move it down a bit more, ignoring
> the VM_DONTCOPY vma's, but they are so uncommon as to not matter, so
> who cares?

That was the v1 fix, but after some discussion
(https://lkml.kernel.org/r/20230705063711.2670599-1-surenb@google.com)
it was decided to take the "excessive" approach.

Also, this change needs a couple more updates:
https://lkml.kernel.org/r/20230707043211.3682710-1-surenb@google.com
https://lkml.kernel.org/r/20230707043211.3682710-2-surenb@google.com

So I'm thinking it's best to disable the feature in 6.4.x and reenable
it for 6.5 once all this is sorted out.