Re: [PATCH v13 0/7] fsdax: introduce fs query to support reflink

["HORIGUCHI NAOYA(堀口 直也)" <naoya.horiguchi@nec.com>]

Hi everyone,

On Thu, Apr 21, 2022 at 02:35:02PM +1000, Dave Chinner wrote:
> On Wed, Apr 20, 2022 at 07:20:07PM -0700, Dan Williams wrote:
> > [ add Andrew and Naoya ]
> > 
> > On Wed, Apr 20, 2022 at 6:48 PM Shiyang Ruan <ruansy.fnst@fujitsu.com> wrote:
> > >
> > > Hi Dave,
> > >
> > > 在 2022/4/21 9:20, Dave Chinner 写道:
> > > > Hi Ruan,
> > > >
> > > > On Tue, Apr 19, 2022 at 12:50:38PM +0800, Shiyang Ruan wrote:
> > > >> This patchset is aimed to support shared pages tracking for fsdax.
> > > >
> > > > Now that this is largely reviewed, it's time to work out the
> > > > logistics of merging it.
> > >
> > > Thanks!
> > >
> > > >
> > > >> Changes since V12:
> > > >>    - Rebased onto next-20220414
> > > >
> > > > What does this depend on that is in the linux-next kernel?
> > > >
> > > > i.e. can this be applied successfully to a v5.18-rc2 kernel without
> > > > needing to drag in any other patchsets/commits/trees?
> > >
> > > Firstly, I tried to apply to v5.18-rc2 but it failed.
> > >
> > > There are some changes in memory-failure.c, which besides my Patch-02
> > >    "mm/hwpoison: fix race between hugetlb free/demotion and
> > > memory_failure_hugetlb()"
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=423228ce93c6a283132be38d442120c8e4cdb061

This commit should not logically conflict with patch 2/7 (just mismatch in context)
and the conflict can be trivially resolved, i.e. simply defining 2 new functions
(unmap_and_kill() and mf_generic_kill_procs()) just below try_to_split_thp_page()
(or somewhere else before memory_failure_dev_pagemap()) is a correct resolution.

> > >
> > > Then, why it is on linux-next is: I was told[1] there is a better fix
> > > about "pgoff_address()" in linux-next:
> > >    "mm: rmap: introduce pfn_mkclean_range() to cleans PTEs"
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=65c9605009f8317bb3983519874d755a0b2ca746
> > > so I rebased my patches to it and dropped one of mine.
> > >
> > > [1] https://lore.kernel.org/linux-xfs/YkPuooGD139Wpg1v@infradead.org/
> > 
> > From my perspective, once something has -mm dependencies it needs to
> > go through Andrew's tree, and if it's going through Andrew's tree I
> > think that means the reflink side of this needs to wait a cycle as
> > there is no stable point that the XFS tree could merge to build on top
> > of.
> 
> Ngggh. Still? Really?
> 
> Sure, I'm not a maintainer and just the stand-in patch shepherd for
> a single release. However, being unable to cleanly merge code we
> need integrated into our local subsystem tree for integration
> testing because a patch dependency with another subsystem won't gain
> a stable commit ID until the next merge window is .... distinctly
> suboptimal.
> 
> We know how to do this cleanly, quickly and efficiently - we've been
> doing cross-subsystem shared git branch co-ordination for
> VFS/fs/block stuff when needed for many, many years. It's pretty
> easy to do, just requires clear communication to decide where the
> source branch will be kept. It doesn't even matter what order Linus
> then merges the trees - they are self contained and git sorts out
> the duplicated commits without an issue.
> 
> I mean, we've been using git for *17 years* now - this stuff should
> be second nature to maintainers by now. So how is it still
> considered acceptible for a core kernel subsystem not to have the
> ability to provide other subsystems with stable commits/branches
> so we can cleanly develop cross-subsystem functionality quickly and
> efficiently?
> 
> > The last reviewed-by this wants before going through there is Naoya's
> > on the memory-failure.c changes.
> 
> Naoya? 

I'll reply to the individual patches soon.

Thanks,
Naoya Horiguchi