On Fri, Sep 22, 2023 at 7:52 PM Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> 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 before
> > I send the fix for the first issue.
> >
> > -----------
> > vma_start_write(next);
> > remove = next; /* case 1 */
> > vma_end = next->vm_end;
> > err = dup_anon_vma(prev, next);
> > if (curr) { /* case 6 */
> > vma_start_write(curr);
> > remove = curr;
> > remove2 = next;
> > if (!next->anon_vma)
> > err = dup_anon_vma(prev, curr);
> > -----------
> >
> > Since dup_anon_vma() can fail, I think here in case 6 we could overwrite
> > 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 |= dup_anon_vma(...)" there for clarity instead, as
long as the only thing we care about is whether we have a nonzero
error...
