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@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 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@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? I'll reply to the individual patches soon. Thanks, Naoya Horiguchi
