From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DD43DC433EF for ; Wed, 11 May 2022 01:56:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 610AC6B0072; Tue, 10 May 2022 21:56:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C1768D0002; Tue, 10 May 2022 21:56:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 412BF8D0001; Tue, 10 May 2022 21:56:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3049E6B0072 for ; Tue, 10 May 2022 21:56:04 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0A03E21E21 for ; Wed, 11 May 2022 01:56:04 +0000 (UTC) X-FDA: 79451796648.25.F12AAFF Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) by imf28.hostedemail.com (Postfix) with ESMTP id A7202C0093 for ; Wed, 11 May 2022 01:55:43 +0000 (UTC) Received: by mail-pg1-f177.google.com with SMTP id 137so513564pgb.5 for ; Tue, 10 May 2022 18:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TkVkCo+AEqF0i40htkHNCtoH0Rbet/ikc5+1DL9KmSo=; b=Hi5aqq1+m/Ej+vEenvxjgpdjskjWHa8HcLWWVrtyiqSRIgdPRYcdyTMaLzlDyQMAKz hlTV9+BhNIFpEMn3zSVZWxWdrXpT2fH5AFkxhKaw3lHtgS3Vux29n80lupydfOUZD67S xaDCcCpZYZmO17Upd/ga/rOBpLackfaJj+oiKTcWZ53uEetfaIi+btgGotGImVV69IqN lnv4N0Kx2TQayXO2t/IA1LNXLRMllhs2tpW1+kEDqvGIhc7+Tv6Qybg1MjvOZV1bQFuR L/6GLMXKGmf8Cn5kzsJLn2NNPN3ugYfuVN51A5bMRmdo5/VQf2sfe9fivmRpGFtiIjB2 po6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TkVkCo+AEqF0i40htkHNCtoH0Rbet/ikc5+1DL9KmSo=; b=HLHfjsnGNR3ll4TU3+Njoncx5jtOwaI8zgom6v+IkSRwqxi//mOoP1zKqhgsvx1jNZ ZKswsdG3ozYEjcezIFyNoVHbZuaUFn8YBJIYWAc2zTSGQWs+3hl3tQKV9+UYlXCqNzRg 2J0vRP4Fa6OY4g7U/hpMdRmtw1n+EPM0agHFuBxUZ5ls9CR0XKV15dq0TmL6OOBG6BxS tzaGy19u/qwNPOLW1AhqADmW2tg0p2OsG01xWB2ILVWok2wiD+lBf+cf7RL/fkj6J+C9 D+X4QsjL1dABDG8+/LhykfYjGpHn54jZLMBSdDftKzYcA3J4NRraiYXHFvIaTownhNmK ELyQ== X-Gm-Message-State: AOAM531+6apjiSta00lVD5qFLh85aLF3Tt/mV2UUbvR/c+LHPDhHmgRs rf8YpsKXxzrnrn07I2foVqSuFjjw6EKW7l5kFXUgiw== X-Google-Smtp-Source: ABdhPJxTwIrZK3os2Y5Gy2M9XbVTxVNnvEv6gF+cVyLYFsVX8OyNesDt7qGu7dcx91JA1iqzYWRqknggbdHvQFq8KGg= X-Received: by 2002:a05:6a00:22d4:b0:510:6d75:e3da with SMTP id f20-20020a056a0022d400b005106d75e3damr23281842pfj.3.1652234161869; Tue, 10 May 2022 18:56:01 -0700 (PDT) MIME-Version: 1.0 References: <20220508143620.1775214-1-ruansy.fnst@fujitsu.com> <20220511000352.GY27195@magnolia> <20220511014818.GE1098723@dread.disaster.area> In-Reply-To: <20220511014818.GE1098723@dread.disaster.area> From: Dan Williams Date: Tue, 10 May 2022 18:55:50 -0700 Message-ID: Subject: Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink To: Dave Chinner Cc: "Darrick J. Wong" , Shiyang Ruan , Linux Kernel Mailing List , linux-xfs , Linux NVDIMM , Linux MM , linux-fsdevel , Christoph Hellwig , Jane Chu , Goldwyn Rodrigues , Al Viro , Matthew Wilcox , Naoya Horiguchi , linmiaohe@huawei.com, Andrew Morton Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: A7202C0093 X-Stat-Signature: ogiu6wkuktew4tqms95at8kypcd7wh8q Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=intel-com.20210112.gappssmtp.com header.s=20210112 header.b=Hi5aqq1+; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=intel.com (policy=none); spf=none (imf28.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.215.177) smtp.mailfrom=dan.j.williams@intel.com X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1652234143-220354 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: [ add Andrew ] On Tue, May 10, 2022 at 6:49 PM Dave Chinner 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@fujitsu.com/ > > > 2.fsdax-reflink: https://lore.kernel.org/linux-xfs/20210928062311.4012070-1-ruansy.fnst@fujitsu.com/ > > > > > > 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?