Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
MIME-Version: 1.0
References: <CAG48ez12VN1JAOtTNMY+Y2YnsU45yL5giS-Qn=ejtiHpgJAbdQ@mail.gmail.com>
 <20230816161758.avedpxvqpwngzmut@revolver> <CAG48ez3mcH-ms0piv7iMcB_ap+WDgkE_ex6VHSZw_Aw30-Ox8g@mail.gmail.com>
 <20230816191851.wo2xhthmfq7uzoc3@revolver> <20230922161919.6ct5c7tj35r4ex7m@revolver>
 <20230922175232.gneuhwhzs4moql5u@revolver>
In-Reply-To: <20230922175232.gneuhwhzs4moql5u@revolver>
From:   Jann Horn <jannh@google.com>
Date:   Fri, 22 Sep 2023 20:02:57 +0200
Message-ID: <CAG48ez3iDwFPR=Ed1BfrNuyUJPMK_=StjxhUsCkL6po1s7bONg@mail.gmail.com>
Subject: Re: maple tree change made it possible for VMA iteration to see same
 VMA twice due to late vma_merge() failure
To:     "Liam R. Howlett" <Liam.Howlett@oracle.com>,
        Jann Horn <jannh@google.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        kernel list <linux-kernel@vger.kernel.org>,
        Linux-MM <linux-mm@kvack.org>,
        Lorenzo Stoakes <lstoakes@gmail.com>,
        Vlastimil Babka <vbabka@suse.cz>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Sep 22, 2023 at 7:52=E2=80=AFPM Liam R. Howlett <Liam.Howlett@oracl=
e.com> wrote:
>
> ...
> >
> > Looking at this, I think it's best to make a label and undo the
> > vma_prev() with a vma_next() - at least for now.
> >
> > I'm also reading this for the error path on dup_anon_vma() failure, and
> > it appears to also have an issue which I'd like to point out here befor=
e
> > I send the fix for the first issue.
> >
> > -----------
> >                 vma_start_write(next);
> >                 remove =3D next;                          /* case 1 */
> >                 vma_end =3D next->vm_end;
> >                 err =3D dup_anon_vma(prev, next);
> >                 if (curr) {                             /* case 6 */
> >                         vma_start_write(curr);
> >                         remove =3D curr;
> >                         remove2 =3D next;
> >                         if (!next->anon_vma)
> >                                 err =3D dup_anon_vma(prev, curr);
> > -----------
> >
> > Since dup_anon_vma() can fail, I think here in case 6 we could overwrit=
e
> > the failure.
> >
> > That is, we will fail to clone the anon vma and mask the failure if we
> > are running case 6 with an anon in next.  Once the first dup_anon_vma()
> > returns error, the next call to clone curr vma may return 0 if there is
> > no anon vma (this, I think _must_ be the case). Then we are in a
> > situation where we will be removing next and expanding prev over curr
> > and next, but have not dup'ed the anon vma from next.
> >
>
> I think I am incorrect in the error being overwritten because we won't
> call dup_anon_vma(prev, curr) if the source of the previous call (next)
> has an anon vma.

Hm, yeah. It looks pretty dodgy and I guess it could use a comment,
but as you said, it seems to actually not be a problem...

We could do "err |=3D dup_anon_vma(...)" there for clarity instead, as
long as the only thing we care about is whether we have a nonzero
error...