On Fri, Sep 29, 2023 at 11:28:02AM -0700, Dan Williams wrote: > Eric Sandeen wrote: > > On 9/29/23 9:17 AM, Chandan Babu R wrote: > > > On Thu, Sep 28, 2023 at 09:20:52 AM -0700, Andrew Morton wrote: > > >> On Thu, 28 Sep 2023 16:44:00 +0800 Shiyang Ruan <ruansy.fnst@xxxxxxxxxxx> wrote: > > >> > > >>> But please pick the following patch[1] as well, which fixes failures of > > >>> xfs55[0-2] cases. > > >>> > > >>> [1] > > >>> https://lore.kernel.org/linux-xfs/20230913102942.601271-1-ruansy.fnst@xxxxxxxxxxx > > >> > > >> I guess I can take that xfs patch, as it fixes a DAX patch. I hope the xfs team > > >> are watching. > > >> > > >> But > > >> > > >> a) I'm not subscribed to linux-xfs and > > >> > > >> b) the changelog fails to describe the userspace-visible effects of > > >> the bug, so I (and others) are unable to determine which kernel > > >> versions should be patched. > > >> > > >> Please update that changelog and resend? > > > > > > I will apply "xfs: correct calculation for agend and blockcount" patch to > > > xfs-linux Git tree and include it for the next v6.6 pull request to Linus. > > > > > > At the outset, It looks like I can pick "mm, pmem, xfs: Introduce > > > MF_MEM_PRE_REMOVE for unbind" > > > (i.e. https://lore.kernel.org/linux-xfs/20230928103227.250550-1-ruansy.fnst@xxxxxxxxxxx/T/#u) > > > patch for v6.7 as well. But that will require your Ack. Please let me know > > > your opinion. > > > > > > Also, I will pick "xfs: drop experimental warning for FSDAX" patch for v6.7. > > > > While I hate to drag it out even longer, it seems slightly optimistic to > > drop experimental at the same time as the "last" fix, in case it's not > > really the last fix. > > > > But I don't have super strong feelings about it, and I would be happy to > > finally see experimental go away. So if those who are more tuned into > > the details are comfortable with that 6.7 plan, I'll defer to them on > > the question. > > The main blockage of "experimental" was the inability to specify > dax+reflink, and the concern that resolving that conflict would end up > breaking MAP_SYNC semantics or some other regression. > > The dax_notify_failure() work has resolved that conflict without > regressing semantics. > > Ultimately this is an XFS filesystem maintainer decision, but my > perspective is that v6.7-rc1 starts the clock on experimental going away > and if the bug reports stay quiet that state can persist into > v6.7-final. If new reports crop up, revert the experimental removal and > try again for v6.8. I'm ok with this. Let's merge the PRE_REMOVE patch (and the arithematic fix) for 6.7-rc1. If nobody screams during 6.7, send a patch to Linus removing EXPERIMENTAL after (say) 6.7-rc8. DAX will no longer be experimental for the 2024 LTS. --D
