[ add Andrew ] On Tue, May 10, 2022 at 6:49 PM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > On Tue, May 10, 2022 at 05:03:52PM -0700, Darrick J. Wong wrote: > > On Sun, May 08, 2022 at 10:36:06PM +0800, Shiyang Ruan wrote: > > > This is a combination of two patchsets: > > > 1.fsdax-rmap: https://lore.kernel.org/linux-xfs/20220419045045.1664996-1-ruansy.fnst@xxxxxxxxxxx/ > > > 2.fsdax-reflink: https://lore.kernel.org/linux-xfs/20210928062311.4012070-1-ruansy.fnst@xxxxxxxxxxx/ > > > > > > Changes since v13 of fsdax-rmap: > > > 1. Fixed mistakes during rebasing code to latest next- > > > 2. Rebased to next-20220504 > > > > > > Changes since v10 of fsdax-reflink: > > > 1. Rebased to next-20220504 and fsdax-rmap > > > 2. Dropped a needless cleanup patch: 'fsdax: Convert dax_iomap_zero to > > > iter model' > > > 3. Fixed many conflicts during rebasing > > > 4. Fixed a dedupe bug in Patch 05: the actuall length to compare could be > > > shorter than smap->length or dmap->length. > > > PS: There are many changes during rebasing. I think it's better to > > > review again. > > > > > > == > > > Shiyang Ruan (14): > > > fsdax-rmap: > > > dax: Introduce holder for dax_device > > > mm: factor helpers for memory_failure_dev_pagemap > > > pagemap,pmem: Introduce ->memory_failure() > > > fsdax: Introduce dax_lock_mapping_entry() > > > mm: Introduce mf_dax_kill_procs() for fsdax case > > > > Hmm. This patchset touches at least the dax, pagecache, and xfs > > subsystems. Assuming it's too late for 5.19, how should we stage this > > for 5.20? > > Yeah, it's past my "last date for this merge cycle" which was > -rc6. I expected stuff might slip a little - as it has with the LARP > code - but I don't have the time and bandwidth to start working > on merging another feature from scratch before the merge window > comes around. > > Getting the dax+reflink stuff in this cycle was always an optimistic > stretch, but I wanted to try so that there was no doubt it would be > ready for merge in the next cycle... > > > I could just add the entire series to iomap-5.20-merge and base the > > xfs-5.20-merge off of that? But I'm not sure what else might be landing > > in the other subsystems, so I'm open to input. > > It'll need to be a stable branch somewhere, but I don't think it > really matters where al long as it's merged into the xfs for-next > tree so it gets filesystem test coverage... So how about let the notify_failure() bits go through -mm this cycle, if Andrew will have it, and then the reflnk work has a clean v5.19-rc1 baseline to build from?
