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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 14 Aug 2023 13:33:19 -0700 Suren Baghdasaryan <surenb@xxxxxxxxxx> 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@xxxxxxxxxxxxxx/)
> 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@xxxxxxxxxxxxx/)
> requires at least one patch from my patchset to work correctly, this
> one: https://lore.kernel.org/all/20230630211957.1341547-4-surenb@xxxxxxxxxx/.
> 
> An additional note,
> https://lore.kernel.org/all/20230812002033.1002367-1-willy@xxxxxxxxxxxxx/
> 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.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux