Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
在 2022/6/3 9:07, Shiyang Ruan 写道: 在 2022/6/3 2:56, Andrew Morton 写道: On Sun, 8 May 2022 22:36:06 +0800 Shiyang Ruan wrote: This is a combination of two patchsets: 1.fsdax-rmap: https://lore.kernel.org/linux-xfs/20220419045045.1664996-1-ruansy.f...@fujitsu.com/ 2.fsdax-reflink: https://lore.kernel.org/linux-xfs/20210928062311.4012070-1-ruansy.f...@fujitsu.com/ I'm getting lost in conflicts trying to get this merged up. Mainly memory-failure.c due to patch series "mm, hwpoison: enable 1GB hugepage support". Could you please take a look at what's in the mm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm a few hours from now? Or the next linux-next. OK, let me rebase this patchset on your mm-unstable branch. -- Thanks, Ruan. And I suggest that converting it all into a single 14-patch series would be more straightforward. The patchset in this thread is the 14-patch series. I have solved many conflicts. It's an updated / newest version, and a combination of the 2 urls quoted above. In an other word, instead of using this two: >> This is a combination of two patchsets: >> 1.fsdax-rmap: https://... >> 2.fsdax-reflink: https://... you could take this (the url of the current thread): https://lore.kernel.org/linux-xfs/20220508143620.1775214-1-ruansy.f...@fujitsu.com/ My description misleaded you. Sorry for that. -- Thanks, Ruan. Thanks.
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
在 2022/6/3 2:56, Andrew Morton 写道: On Sun, 8 May 2022 22:36:06 +0800 Shiyang Ruan wrote: This is a combination of two patchsets: 1.fsdax-rmap: https://lore.kernel.org/linux-xfs/20220419045045.1664996-1-ruansy.f...@fujitsu.com/ 2.fsdax-reflink: https://lore.kernel.org/linux-xfs/20210928062311.4012070-1-ruansy.f...@fujitsu.com/ I'm getting lost in conflicts trying to get this merged up. Mainly memory-failure.c due to patch series "mm, hwpoison: enable 1GB hugepage support". Could you please take a look at what's in the mm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm a few hours from now? Or the next linux-next. And I suggest that converting it all into a single 14-patch series would be more straightforward. The patchset in this thread is the 14-patch series. I have solved many conflicts. It's an updated / newest version, and a combination of the 2 urls quoted above. In an other word, instead of using this two: >> This is a combination of two patchsets: >> 1.fsdax-rmap: https://... >> 2.fsdax-reflink: https://... you could take this (the url of the current thread): https://lore.kernel.org/linux-xfs/20220508143620.1775214-1-ruansy.f...@fujitsu.com/ My description misleaded you. Sorry for that. -- Thanks, Ruan. Thanks.
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
On Sun, 8 May 2022 22:36:06 +0800 Shiyang Ruan wrote: > This is a combination of two patchsets: > 1.fsdax-rmap: > https://lore.kernel.org/linux-xfs/20220419045045.1664996-1-ruansy.f...@fujitsu.com/ > 2.fsdax-reflink: > https://lore.kernel.org/linux-xfs/20210928062311.4012070-1-ruansy.f...@fujitsu.com/ I'm getting lost in conflicts trying to get this merged up. Mainly memory-failure.c due to patch series "mm, hwpoison: enable 1GB hugepage support". Could you please take a look at what's in the mm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm a few hours from now? Or the next linux-next. And I suggest that converting it all into a single 14-patch series would be more straightforward. Thanks.
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
On Thu, 2 Jun 2022 10:18:09 -0700 "Darrick J. Wong" wrote: > On Thu, Jun 02, 2022 at 05:42:13PM +0800, Shiyang Ruan wrote: > > Hi, > > > > Is there any other work I should do with these two patchsets? I think they > > are good for now. So... since the 5.19-rc1 is coming, could the > > notify_failure() part be merged as your plan? > > Hmm. I don't see any of the patches 1-5,7-13 in current upstream, so > I'm guessing this means Andrew isn't taking it for 5.19? Sorry, the volume of commentary led me to believe that it wasn't considered finalized. Shall take a look now.
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
On Thu, Jun 02, 2022 at 05:42:13PM +0800, Shiyang Ruan wrote:
> Hi,
>
> Is there any other work I should do with these two patchsets? I think they
> are good for now. So... since the 5.19-rc1 is coming, could the
> notify_failure() part be merged as your plan?
Hmm. I don't see any of the patches 1-5,7-13 in current upstream, so
I'm guessing this means Andrew isn't taking it for 5.19?
--D
>
>
> --
> Thanks,
> Ruan.
>
>
> 在 2022/5/12 20:27, Shiyang Ruan 写道:
> >
> >
> > 在 2022/5/11 23:46, Dan Williams 写道:
> > > On Wed, May 11, 2022 at 8:21 AM Darrick J. Wong
> > > wrote:
> > > >
> > > > Oan Tue, May 10, 2022 at 10:24:28PM -0700, Andrew Morton wrote:
> > > > > On Tue, 10 May 2022 19:43:01 -0700 "Darrick J. Wong"
> > > > > wrote:
> > > > >
> > > > > > On Tue, May 10, 2022 at 07:28:53PM -0700, Andrew Morton wrote:
> > > > > > > On Tue, 10 May 2022 18:55:50 -0700 Dan Williams
> > > > > > > wrote:
> > > > > > >
> > > > > > > > > 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?
> > > > > > >
> > > > > > > What are we referring to here? I think a minimal thing would be
> > > > > > > the
> > > > > > > memremap.h and memory-failure.c changes from
> > > > > > > https://lkml.kernel.org/r/20220508143620.1775214-4-ruansy.f...@fujitsu.com
> > > > > > > ?
> > > > > > >
> > > > > > > Sure, I can scoot that into 5.19-rc1 if you think that's best. It
> > > > > > > would probably be straining things to slip it into 5.19.
> > > > > > >
> > > > > > > The use of EOPNOTSUPP is a bit suspect, btw. It *sounds* like the
> > > > > > > right thing, but it's a networking errno. I suppose
> > > > > > > livable with if it
> > > > > > > never escapes the kernel, but if it can get back to userspace
> > > > > > > then a
> > > > > > > user would be justified in wondering how the heck a filesystem
> > > > > > > operation generated a networking errno?
> > > > > >
> > > > > > most filesystems return EOPNOTSUPP rather
> > > > > > enthusiastically when
> > > > > > they don't know how to do something...
> > > > >
> > > > > Can it propagate back to userspace?
> > > >
> > > > AFAICT, the new code falls back to the current (mf_generic_kill_procs)
> > > > failure code if the filesystem doesn't provide a ->memory_failure
> > > > function or if it returns -EOPNOSUPP. mf_generic_kill_procs can also
> > > > return -EOPNOTSUPP, but all the memory_failure() callers (madvise, etc.)
> > > > convert that to 0 before returning it to userspace.
> > > >
> > > > I suppose the weirder question is going to be what happens when madvise
> > > > starts returning filesystem errors like EIO or EFSCORRUPTED when pmem
> > > > loses half its brains and even the fs can't deal with it.
> > >
> > > Even then that notification is not in a system call context so it
> > > would still result in a SIGBUS notification not a EOPNOTSUPP return
> > > code. The only potential gap I see are what are the possible error
> > > codes that MADV_SOFT_OFFLINE might see? The man page is silent on soft
> > > offline failure codes. Shiyang, that's something to check / update if
> > > necessary.
> >
> > According to the code around MADV_SOFT_OFFLINE, it will return -EIO when
> > the backend is NVDIMM.
> >
> > Here is the logic:
> > madvise_inject_error() {
> > ...
> > if (MADV_SOFT_OFFLINE) {
> > ret = soft_offline_page() {
> > ...
> > /* Only online pages can be soft-offlined (esp., not
> > ZONE_DEVICE). */
> > page = pfn_to_online_page(pfn);
> > if (!page) {
> > put_ref_page(ref_page);
> > return -EIO;
> > }
> > ...
> > }
> > } else {
> > ret = memory_failure()
> > }
> > return ret
> > }
> >
> >
> > --
> > Thanks,
> > Ruan.
> >
> >
>
>
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
Hi,
Is there any other work I should do with these two patchsets? I think
they are good for now. So... since the 5.19-rc1 is coming, could the
notify_failure() part be merged as your plan?
--
Thanks,
Ruan.
在 2022/5/12 20:27, Shiyang Ruan 写道:
在 2022/5/11 23:46, Dan Williams 写道:
On Wed, May 11, 2022 at 8:21 AM Darrick J. Wong
wrote:
Oan Tue, May 10, 2022 at 10:24:28PM -0700, Andrew Morton wrote:
On Tue, 10 May 2022 19:43:01 -0700 "Darrick J. Wong"
wrote:
On Tue, May 10, 2022 at 07:28:53PM -0700, Andrew Morton wrote:
On Tue, 10 May 2022 18:55:50 -0700 Dan Williams
wrote:
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?
What are we referring to here? I think a minimal thing would be the
memremap.h and memory-failure.c changes from
https://lkml.kernel.org/r/20220508143620.1775214-4-ruansy.f...@fujitsu.com
?
Sure, I can scoot that into 5.19-rc1 if you think that's best. It
would probably be straining things to slip it into 5.19.
The use of EOPNOTSUPP is a bit suspect, btw. It *sounds* like the
right thing, but it's a networking errno. I suppose livable with
if it
never escapes the kernel, but if it can get back to userspace then a
user would be justified in wondering how the heck a filesystem
operation generated a networking errno?
most filesystems return EOPNOTSUPP rather enthusiastically
when
they don't know how to do something...
Can it propagate back to userspace?
AFAICT, the new code falls back to the current (mf_generic_kill_procs)
failure code if the filesystem doesn't provide a ->memory_failure
function or if it returns -EOPNOSUPP. mf_generic_kill_procs can also
return -EOPNOTSUPP, but all the memory_failure() callers (madvise, etc.)
convert that to 0 before returning it to userspace.
I suppose the weirder question is going to be what happens when madvise
starts returning filesystem errors like EIO or EFSCORRUPTED when pmem
loses half its brains and even the fs can't deal with it.
Even then that notification is not in a system call context so it
would still result in a SIGBUS notification not a EOPNOTSUPP return
code. The only potential gap I see are what are the possible error
codes that MADV_SOFT_OFFLINE might see? The man page is silent on soft
offline failure codes. Shiyang, that's something to check / update if
necessary.
According to the code around MADV_SOFT_OFFLINE, it will return -EIO when
the backend is NVDIMM.
Here is the logic:
madvise_inject_error() {
...
if (MADV_SOFT_OFFLINE) {
ret = soft_offline_page() {
...
/* Only online pages can be soft-offlined (esp., not
ZONE_DEVICE). */
page = pfn_to_online_page(pfn);
if (!page) {
put_ref_page(ref_page);
return -EIO;
}
...
}
} else {
ret = memory_failure()
}
return ret
}
--
Thanks,
Ruan.
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
在 2022/5/11 23:46, Dan Williams 写道:
On Wed, May 11, 2022 at 8:21 AM Darrick J. Wong wrote:
Oan Tue, May 10, 2022 at 10:24:28PM -0700, Andrew Morton wrote:
On Tue, 10 May 2022 19:43:01 -0700 "Darrick J. Wong" wrote:
On Tue, May 10, 2022 at 07:28:53PM -0700, Andrew Morton wrote:
On Tue, 10 May 2022 18:55:50 -0700 Dan Williams
wrote:
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?
What are we referring to here? I think a minimal thing would be the
memremap.h and memory-failure.c changes from
https://lkml.kernel.org/r/20220508143620.1775214-4-ruansy.f...@fujitsu.com ?
Sure, I can scoot that into 5.19-rc1 if you think that's best. It
would probably be straining things to slip it into 5.19.
The use of EOPNOTSUPP is a bit suspect, btw. It *sounds* like the
right thing, but it's a networking errno. I suppose livable with if it
never escapes the kernel, but if it can get back to userspace then a
user would be justified in wondering how the heck a filesystem
operation generated a networking errno?
most filesystems return EOPNOTSUPP rather enthusiastically when
they don't know how to do something...
Can it propagate back to userspace?
AFAICT, the new code falls back to the current (mf_generic_kill_procs)
failure code if the filesystem doesn't provide a ->memory_failure
function or if it returns -EOPNOSUPP. mf_generic_kill_procs can also
return -EOPNOTSUPP, but all the memory_failure() callers (madvise, etc.)
convert that to 0 before returning it to userspace.
I suppose the weirder question is going to be what happens when madvise
starts returning filesystem errors like EIO or EFSCORRUPTED when pmem
loses half its brains and even the fs can't deal with it.
Even then that notification is not in a system call context so it
would still result in a SIGBUS notification not a EOPNOTSUPP return
code. The only potential gap I see are what are the possible error
codes that MADV_SOFT_OFFLINE might see? The man page is silent on soft
offline failure codes. Shiyang, that's something to check / update if
necessary.
According to the code around MADV_SOFT_OFFLINE, it will return -EIO when
the backend is NVDIMM.
Here is the logic:
madvise_inject_error() {
...
if (MADV_SOFT_OFFLINE) {
ret = soft_offline_page() {
...
/* Only online pages can be soft-offlined (esp., not
ZONE_DEVICE). */
page = pfn_to_online_page(pfn);
if (!page) {
put_ref_page(ref_page);
return -EIO;
}
...
}
} else {
ret = memory_failure()
}
return ret
}
--
Thanks,
Ruan.
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
On Wed, May 11, 2022 at 8:21 AM Darrick J. Wong wrote: > > Oan Tue, May 10, 2022 at 10:24:28PM -0700, Andrew Morton wrote: > > On Tue, 10 May 2022 19:43:01 -0700 "Darrick J. Wong" > > wrote: > > > > > On Tue, May 10, 2022 at 07:28:53PM -0700, Andrew Morton wrote: > > > > On Tue, 10 May 2022 18:55:50 -0700 Dan Williams > > > > wrote: > > > > > > > > > > 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? > > > > > > > > What are we referring to here? I think a minimal thing would be the > > > > memremap.h and memory-failure.c changes from > > > > https://lkml.kernel.org/r/20220508143620.1775214-4-ruansy.f...@fujitsu.com > > > > ? > > > > > > > > Sure, I can scoot that into 5.19-rc1 if you think that's best. It > > > > would probably be straining things to slip it into 5.19. > > > > > > > > The use of EOPNOTSUPP is a bit suspect, btw. It *sounds* like the > > > > right thing, but it's a networking errno. I suppose livable with if it > > > > never escapes the kernel, but if it can get back to userspace then a > > > > user would be justified in wondering how the heck a filesystem > > > > operation generated a networking errno? > > > > > > most filesystems return EOPNOTSUPP rather enthusiastically when > > > they don't know how to do something... > > > > Can it propagate back to userspace? > > AFAICT, the new code falls back to the current (mf_generic_kill_procs) > failure code if the filesystem doesn't provide a ->memory_failure > function or if it returns -EOPNOSUPP. mf_generic_kill_procs can also > return -EOPNOTSUPP, but all the memory_failure() callers (madvise, etc.) > convert that to 0 before returning it to userspace. > > I suppose the weirder question is going to be what happens when madvise > starts returning filesystem errors like EIO or EFSCORRUPTED when pmem > loses half its brains and even the fs can't deal with it. Even then that notification is not in a system call context so it would still result in a SIGBUS notification not a EOPNOTSUPP return code. The only potential gap I see are what are the possible error codes that MADV_SOFT_OFFLINE might see? The man page is silent on soft offline failure codes. Shiyang, that's something to check / update if necessary.
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
Oan Tue, May 10, 2022 at 10:24:28PM -0700, Andrew Morton wrote: > On Tue, 10 May 2022 19:43:01 -0700 "Darrick J. Wong" > wrote: > > > On Tue, May 10, 2022 at 07:28:53PM -0700, Andrew Morton wrote: > > > On Tue, 10 May 2022 18:55:50 -0700 Dan Williams > > > wrote: > > > > > > > > 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? > > > > > > What are we referring to here? I think a minimal thing would be the > > > memremap.h and memory-failure.c changes from > > > https://lkml.kernel.org/r/20220508143620.1775214-4-ruansy.f...@fujitsu.com > > > ? > > > > > > Sure, I can scoot that into 5.19-rc1 if you think that's best. It > > > would probably be straining things to slip it into 5.19. > > > > > > The use of EOPNOTSUPP is a bit suspect, btw. It *sounds* like the > > > right thing, but it's a networking errno. I suppose livable with if it > > > never escapes the kernel, but if it can get back to userspace then a > > > user would be justified in wondering how the heck a filesystem > > > operation generated a networking errno? > > > > most filesystems return EOPNOTSUPP rather enthusiastically when > > they don't know how to do something... > > Can it propagate back to userspace? AFAICT, the new code falls back to the current (mf_generic_kill_procs) failure code if the filesystem doesn't provide a ->memory_failure function or if it returns -EOPNOSUPP. mf_generic_kill_procs can also return -EOPNOTSUPP, but all the memory_failure() callers (madvise, etc.) convert that to 0 before returning it to userspace. I suppose the weirder question is going to be what happens when madvise starts returning filesystem errors like EIO or EFSCORRUPTED when pmem loses half its brains and even the fs can't deal with it. --D
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
On Tue, May 10, 2022 at 10:24:28PM -0700, Andrew Morton wrote: > On Tue, 10 May 2022 19:43:01 -0700 "Darrick J. Wong" > wrote: > > > On Tue, May 10, 2022 at 07:28:53PM -0700, Andrew Morton wrote: > > > On Tue, 10 May 2022 18:55:50 -0700 Dan Williams > > > wrote: > > > > > > > > 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? > > > > > > What are we referring to here? I think a minimal thing would be the > > > memremap.h and memory-failure.c changes from > > > https://lkml.kernel.org/r/20220508143620.1775214-4-ruansy.f...@fujitsu.com > > > ? > > > > > > Sure, I can scoot that into 5.19-rc1 if you think that's best. It > > > would probably be straining things to slip it into 5.19. > > > > > > The use of EOPNOTSUPP is a bit suspect, btw. It *sounds* like the > > > right thing, but it's a networking errno. I suppose livable with if it > > > never escapes the kernel, but if it can get back to userspace then a > > > user would be justified in wondering how the heck a filesystem > > > operation generated a networking errno? > > > > most filesystems return EOPNOTSUPP rather enthusiastically when > > they don't know how to do something... > > Can it propagate back to userspace? Maybe not this one, but the point Darrick is making is that we really don't care if it does because we've been propagating it to userspace in documented filesystem APIs for at least 15 years now. e.g: $ man 2 fallocate . Errors . EOPNOTSUPP The filesystem containing the file referred to by fd does not support this operation; or the mode is not supported by the filesystem containing the file referred to by fd. . Other random examples: pwritev2(RWF_NOWAIT) can return -EOPNOTSUPP on buffered writes. Documented in the man page. FICLONERANGE on an filesystem that doesn't support reflink will return -EOPNOTSUPP. Documented in the man page. mmap(MAP_SYNC) returns -EOPNOTSUPP if the underlying filesystem and/or storage doesn't support DAX. Documented in the man page. I could go on, but I think I've made the point already... Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
On Tue, 10 May 2022 19:43:01 -0700 "Darrick J. Wong" wrote: > On Tue, May 10, 2022 at 07:28:53PM -0700, Andrew Morton wrote: > > On Tue, 10 May 2022 18:55:50 -0700 Dan Williams > > wrote: > > > > > > 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? > > > > What are we referring to here? I think a minimal thing would be the > > memremap.h and memory-failure.c changes from > > https://lkml.kernel.org/r/20220508143620.1775214-4-ruansy.f...@fujitsu.com ? > > > > Sure, I can scoot that into 5.19-rc1 if you think that's best. It > > would probably be straining things to slip it into 5.19. > > > > The use of EOPNOTSUPP is a bit suspect, btw. It *sounds* like the > > right thing, but it's a networking errno. I suppose livable with if it > > never escapes the kernel, but if it can get back to userspace then a > > user would be justified in wondering how the heck a filesystem > > operation generated a networking errno? > > most filesystems return EOPNOTSUPP rather enthusiastically when > they don't know how to do something... Can it propagate back to userspace?
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
On Tue, May 10, 2022 at 09:20:57PM -0700, Dan Williams wrote: > On Tue, May 10, 2022 at 7:29 PM Andrew Morton > wrote: > > > > On Tue, 10 May 2022 18:55:50 -0700 Dan Williams > > wrote: > > > > > > 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? > > > > What are we referring to here? I think a minimal thing would be the > > memremap.h and memory-failure.c changes from > > https://lkml.kernel.org/r/20220508143620.1775214-4-ruansy.f...@fujitsu.com ? > > Latest is here: > https://lore.kernel.org/all/20220508143620.1775214-1-ruansy.f...@fujitsu.com/ > > > Sure, I can scoot that into 5.19-rc1 if you think that's best. It > > would probably be straining things to slip it into 5.19. > > Hmm, if it's straining things and XFS will also target v5.20 I think > the best course for all involved is just wait. Let some of the current > conflicts in -mm land in v5.19 and then I can merge the DAX baseline > and publish a stable branch for XFS and BTRFS to build upon for v5.20. Sounds good to /me... --D > > The use of EOPNOTSUPP is a bit suspect, btw. It *sounds* like the > > right thing, but it's a networking errno. I suppose livable with if it > > never escapes the kernel, but if it can get back to userspace then a > > user would be justified in wondering how the heck a filesystem > > operation generated a networking errno?
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
On Tue, May 10, 2022 at 7:29 PM Andrew Morton wrote: > > On Tue, 10 May 2022 18:55:50 -0700 Dan Williams > wrote: > > > > 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? > > What are we referring to here? I think a minimal thing would be the > memremap.h and memory-failure.c changes from > https://lkml.kernel.org/r/20220508143620.1775214-4-ruansy.f...@fujitsu.com ? Latest is here: https://lore.kernel.org/all/20220508143620.1775214-1-ruansy.f...@fujitsu.com/ > Sure, I can scoot that into 5.19-rc1 if you think that's best. It > would probably be straining things to slip it into 5.19. Hmm, if it's straining things and XFS will also target v5.20 I think the best course for all involved is just wait. Let some of the current conflicts in -mm land in v5.19 and then I can merge the DAX baseline and publish a stable branch for XFS and BTRFS to build upon for v5.20. > The use of EOPNOTSUPP is a bit suspect, btw. It *sounds* like the > right thing, but it's a networking errno. I suppose livable with if it > never escapes the kernel, but if it can get back to userspace then a > user would be justified in wondering how the heck a filesystem > operation generated a networking errno?
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
On Tue, May 10, 2022 at 07:28:53PM -0700, Andrew Morton wrote: > On Tue, 10 May 2022 18:55:50 -0700 Dan Williams > wrote: > > > > 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? > > What are we referring to here? I think a minimal thing would be the > memremap.h and memory-failure.c changes from > https://lkml.kernel.org/r/20220508143620.1775214-4-ruansy.f...@fujitsu.com ? > > Sure, I can scoot that into 5.19-rc1 if you think that's best. It > would probably be straining things to slip it into 5.19. > > The use of EOPNOTSUPP is a bit suspect, btw. It *sounds* like the > right thing, but it's a networking errno. I suppose livable with if it > never escapes the kernel, but if it can get back to userspace then a > user would be justified in wondering how the heck a filesystem > operation generated a networking errno? most filesystems return EOPNOTSUPP rather enthusiastically when they don't know how to do something... --D
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
On Tue, 10 May 2022 18:55:50 -0700 Dan Williams wrote: > > 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? What are we referring to here? I think a minimal thing would be the memremap.h and memory-failure.c changes from https://lkml.kernel.org/r/20220508143620.1775214-4-ruansy.f...@fujitsu.com ? Sure, I can scoot that into 5.19-rc1 if you think that's best. It would probably be straining things to slip it into 5.19. The use of EOPNOTSUPP is a bit suspect, btw. It *sounds* like the right thing, but it's a networking errno. I suppose livable with if it never escapes the kernel, but if it can get back to userspace then a user would be justified in wondering how the heck a filesystem operation generated a networking errno?
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
On Tue, May 10, 2022 at 06:55:50PM -0700, Dan Williams wrote: > [ 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.f...@fujitsu.com/ > > > > 2.fsdax-reflink: > > > > https://lore.kernel.org/linux-xfs/20210928062311.4012070-1-ruansy.f...@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? Sure, if you want to push them that way I'm not going to complain or stop you. :) Anything that makes the eventual XFS feature merge simpler counts as a win in my books. Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
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.f...@fujitsu.com/ > > 2.fsdax-reflink: > > https://lore.kernel.org/linux-xfs/20210928062311.4012070-1-ruansy.f...@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... Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
[ 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.f...@fujitsu.com/ > > > 2.fsdax-reflink: > > > https://lore.kernel.org/linux-xfs/20210928062311.4012070-1-ruansy.f...@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?
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
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.f...@fujitsu.com/ > 2.fsdax-reflink: > https://lore.kernel.org/linux-xfs/20210928062311.4012070-1-ruansy.f...@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? 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. --D > xfs: Implement ->notify_failure() for XFS > fsdax: set a CoW flag when associate reflink mappings > fsdax-reflink: > fsdax: Output address in dax_iomap_pfn() and rename it > fsdax: Introduce dax_iomap_cow_copy() > fsdax: Replace mmap entry in case of CoW > fsdax: Add dax_iomap_cow_copy() for dax zero > fsdax: Dedup file range to use a compare function > xfs: support CoW in fsdax mode > xfs: Add dax dedupe support > > drivers/dax/super.c | 67 +- > drivers/md/dm.c | 2 +- > drivers/nvdimm/pmem.c | 17 ++ > fs/dax.c| 398 ++-- > fs/erofs/super.c| 13 +- > fs/ext2/super.c | 7 +- > fs/ext4/super.c | 9 +- > fs/remap_range.c| 31 ++- > fs/xfs/Makefile | 5 + > fs/xfs/xfs_buf.c| 10 +- > fs/xfs/xfs_file.c | 9 +- > fs/xfs/xfs_fsops.c | 3 + > fs/xfs/xfs_inode.c | 69 ++- > fs/xfs/xfs_inode.h | 1 + > fs/xfs/xfs_iomap.c | 46 - > fs/xfs/xfs_iomap.h | 3 + > fs/xfs/xfs_mount.h | 1 + > fs/xfs/xfs_notify_failure.c | 220 > fs/xfs/xfs_reflink.c| 12 +- > fs/xfs/xfs_super.h | 1 + > include/linux/dax.h | 56 - > include/linux/fs.h | 12 +- > include/linux/memremap.h| 12 ++ > include/linux/mm.h | 2 + > include/linux/page-flags.h | 6 + > mm/memory-failure.c | 257 --- > 26 files changed, 1087 insertions(+), 182 deletions(-) > create mode 100644 fs/xfs/xfs_notify_failure.c > > -- > 2.35.1 > > >
Re: [PATCHSETS] v14 fsdax-rmap + v11 fsdax-reflink
The patch numbering due looks odd due to the combination of the two series. But otherwise this looks good to me modulo the one minor nitpick.
