Re: [akpm-mm:mm-stable 219/240] mm/memory.c:5410:41: error: implicit declaration of function 'vma_is_tcp'; did you mean 'vma_is_dax'?

[Suren Baghdasaryan <surenb@google.com>]

On Mon, Aug 14, 2023 at 1:41 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Mon, 14 Aug 2023 13:33:19 -0700 Suren Baghdasaryan <surenb@google.com> wrote:
>
> > Andrew, is "mm: handle userfaults under VMA lock" merged into
> > mm-stable? I could not find it and in fact the whole "Per-VMA lock
> > support for swap and userfaults" patchset
> > (https://lore.kernel.org/all/CAJuCfpHSFikZ=h34yS980BmUP5M=+j6rB4_b-q7MCc10Xs24+w@mail.gmail.com/)
> > seems to be missing in mm-stable. That's problematic because Matthew's
> > "Handle most file-backed faults under the VMA lock" patchset
> > (https://lore.kernel.org/all/20230724185410.1124082-1-willy@infradead.org/)
> > requires at least one patch from my patchset to work correctly, this
> > one: https://lore.kernel.org/all/20230630211957.1341547-4-surenb@google.com/.
> >
> > An additional note,
> > https://lore.kernel.org/all/20230812002033.1002367-1-willy@infradead.org/
> > is fixing a known issue in "Handle most file-backed faults under the
> > VMA lock" patchset and it's missing from mm-stable too. As Matthew
> > mentioned in that patch, ideally it should be placed before "mm:
> > handle faults that merely update the accessed bit under the VMA lock"
> >
>
> I was unaware of these dependencies.

I didn't notice the reordering in mm-unstable but now I see them
reordered there as well. Should have warned you earlier :(

>
> All the above-mentioned patches are in mm-unstable, so we have
> bisection holes.
>
> If I get sent a replacement patch series, I'll move it to
> back-of-queue, because I'll assume all previous testing is invalidated.
> I assume this is how this misordering came about.  If I get sent
> little -fix patches, I don't do this reordering.

Possibly the recent riscv fixup for my patch series reordered things...

Reordering my patchset before Matthew's would fix that bisection hole
but up to you. I was just worried that if one patchset is merged
without the other, this hole would produce multiple issues.