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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220421054656.GA3602272@hori.linux.bs1.fc.nec.co.jp>
Date:   Thu, 21 Apr 2022 05:47:09 +0000
From:   HORIGUCHI NAOYA(堀口　直也) 
        <naoya.horiguchi@....com>
To:     Dave Chinner <david@...morbit.com>
CC:     Dan Williams <dan.j.williams@...el.com>,
        Shiyang Ruan <ruansy.fnst@...itsu.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-xfs <linux-xfs@...r.kernel.org>,
        Linux NVDIMM <nvdimm@...ts.linux.dev>,
        Linux MM <linux-mm@...ck.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        "Darrick J. Wong" <djwong@...nel.org>,
        Christoph Hellwig <hch@...radead.org>,
        Jane Chu <jane.chu@...cle.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v13 0/7] fsdax: introduce fs query to support reflink

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@...itsu.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