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@xxxxxxxxxxx> 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 > > > > 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@xxxxxxxxxxxxx/ > > 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? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
