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'?

[Andrew Morton <akpm@linux-foundation.org>]

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.

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.