Re: linux-next: manual merge of the akpm-current tree with the folio tree

Re: linux-next: manual merge of the akpm-current tree with the folio tree

[Matthew Wilcox]

On Thu, Feb 17, 2022 at 05:38:10PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> On Wed, 16 Feb 2022 21:51:24 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Thu, 17 Feb 2022 16:30:26 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > 
> > > On Wed, 16 Feb 2022 20:41:35 +0000 Matthew Wilcox <willy@infradead.org> wrote:  
> > > >
> > > > So where do we go from here?  I can see ways of resolving this if
> > > > Andrew switches to git, but he won't, so that's out.  Perhaps I can
> > > > publish a git tree of Hugh's mlock patches and Christoph's series,
> > > > and you can pull that before Andrew's tree so git resolves the conflicts
> > > > early before trying to resolve conflicts against my tree?  
> > > 
> > > My response for any other subsystem would be that you need to go
> > > through the maintainer's tree.  In this case that means feeding a patch
> > > series to Andrew and updating that patch series.
> > > 
> > > Alternatively, you need to find someone (with Andrew's agreement) who
> > > can maintain a git tree that includes all Andrew's MM patches and any
> > > other topic branches and deals with all the conflicts and can feed it
> > > all to Linus.  Linux-next would also include that tree/branch.
> > > 
> > > Andrew, do you have any comments?  
> > 
> > Let's try Matthew's idea - I'll get Hugh's and Christoph's series via
> > linux-next and shall figure out the rest.
> 
> OK, but I am on vacation from tomorrow until Feb 28th, so I will assume
> you will have it all ready for me by then.

I assume you mean that you'll do one last pull and release a
next-20220218, rather than saying that the next release will be
next-20220229?

I have pushed out f82e2137bc1e to infradead/for-next.  xfstests currently
running.  It includes:

Alex Sierra (10):
      mm: add zone device coherent type memory support
      mm: add device coherent vma selection for memory migration
      mm/gup: fail get_user_pages for LONGTERM dev coherent type
      drm/amdkfd: add SPM support for SVM
      drm/amdkfd: coherent type as sys mem on migration to ram
      lib: test_hmm add ioctl to get zone device type
      lib: test_hmm add module param for zone device type
      lib: add support for device coherent type in test_hmm
      tools: update hmm-test to support device coherent type
      tools: update test_hmm script to support SP config

Alistair Popple (2):
      mm: remove the vma check in migrate_vma_setup()
      mm/gup: migrate device coherent pages when pinning instead of failing

Christoph Hellwig (14):
      mm: remove a pointless CONFIG_ZONE_DEVICE check in memremap_pages
      mm: remove the __KERNEL__ guard from <linux/mm.h>
      mm: remove pointless includes from <linux/hmm.h>
      mm: move free_devmap_managed_page to memremap.c
      mm: simplify freeing of devmap managed pages
      mm: don't include <linux/memremap.h> in <linux/mm.h>
      mm: remove the extra ZONE_DEVICE struct page refcount
      fsdax: depend on ZONE_DEVICE || FS_DAX_LIMITED
      mm: generalize the pgmap based page_free infrastructure
      mm: refactor check_and_migrate_movable_pages
      mm: refactor the ZONE_DEVICE handling in migrate_vma_insert_page
      mm: refactor the ZONE_DEVICE handling in migrate_vma_pages
      mm: move the migrate_vma_* device migration code into its own file
      mm: build migrate_vma_* for all configs with ZONE_DEVICE support

Hugh Dickins (13):
      mm/munlock: delete page_mlock() and all its works
      mm/munlock: delete FOLL_MLOCK and FOLL_POPULATE
      mm/munlock: delete munlock_vma_pages_all(), allow oomreap
      mm/munlock: rmap call mlock_vma_page() munlock_vma_page()
      mm/munlock: replace clear_page_mlock() by final clearance
      mm/munlock: maintain page->mlock_count while unevictable
      mm/munlock: mlock_pte_range() when mlocking or munlocking
      mm/migrate: __unmap_and_move() push good newpage to LRU
      mm/munlock: delete smp_mb() from __pagevec_lru_add_fn()
      mm/munlock: mlock_page() munlock_page() batch by pagevec
      mm/munlock: page migration needs mlock pagevec drained
      mm/thp: collapse_file() do try_to_unmap(TTU_BATCH_FLUSH)
      mm/thp: shrink_page_list() avoid splitting VM_LOCKED THP

Matthew Wilcox (Oracle) (83):
[skipped]

Mike Rapoport (1):
      arch: Add pmd_pfn() where it is missing

William Kucharski (1):
      mm/readahead: Align file mappings for non-DAX


I squashed in the various -fix patches that were in the akpm or next
trees.  I hope I didn't miss anything important.

https://git.infradead.org/users/willy/pagecache.git/shortlog/refs/heads/for-next
if anyone wants to browse and tell me if I messed something up.

Re: linux-next: manual merge of the akpm-current tree with the folio tree

[Christoph Hellwig]

On Thu, Feb 17, 2022 at 09:19:43PM +0000, Matthew Wilcox wrote:
> > > Let's try Matthew's idea - I'll get Hugh's and Christoph's series via
> > > linux-next and shall figure out the rest.
> > 
> > OK, but I am on vacation from tomorrow until Feb 28th, so I will assume
> > you will have it all ready for me by then.
> 
> I assume you mean that you'll do one last pull and release a
> next-20220218, rather than saying that the next release will be
> next-20220229?
> 
> I have pushed out f82e2137bc1e to infradead/for-next.  xfstests currently
> running.  It includes:

Not sure where this mail started, but I already suggested a git tree
in the cover letter of the ZONE_DEVICE series, so the overall approach
sounds fine to me.

Re: linux-next: manual merge of the akpm-current tree with the folio tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

Hi Matthew,

On Thu, 17 Feb 2022 21:19:43 +0000 Matthew Wilcox <willy@infradead.org> wrote:
>
> I assume you mean that you'll do one last pull and release a
> next-20220218, rather than saying that the next release will be
> next-20220229?

Suprise! No :-) I started vacation on Friday morning (18-27the Feb *inclusive*).

> I have pushed out f82e2137bc1e to infradead/for-next.  xfstests currently
> running.  It includes:

I have refetched your tree into the stuff I will leave for Mark.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]