Re: [PATCH v11 7/8] xfs: Implement ->notify_failure() for XFS

2022-04-08 Thread Dan Williams
On Thu, Apr 7, 2022 at 11:05 PM Shiyang Ruan  wrote:
>
>
>
> 在 2022/3/30 14:00, Christoph Hellwig 写道:
> >> @@ -1892,6 +1893,8 @@ xfs_free_buftarg(
> >>  list_lru_destroy(>bt_lru);
> >>
> >>  blkdev_issue_flush(btp->bt_bdev);
> >> +if (btp->bt_daxdev)
> >> +dax_unregister_holder(btp->bt_daxdev, btp->bt_mount);
> >>  fs_put_dax(btp->bt_daxdev);
> >>
> >>  kmem_free(btp);
> >> @@ -1939,6 +1942,7 @@ xfs_alloc_buftarg(
> >>  struct block_device *bdev)
> >>   {
> >>  xfs_buftarg_t   *btp;
> >> +int error;
> >>
> >>  btp = kmem_zalloc(sizeof(*btp), KM_NOFS);
> >>
> >> @@ -1946,6 +1950,14 @@ xfs_alloc_buftarg(
> >>  btp->bt_dev =  bdev->bd_dev;
> >>  btp->bt_bdev = bdev;
> >>  btp->bt_daxdev = fs_dax_get_by_bdev(bdev, >bt_dax_part_off);
> >> +if (btp->bt_daxdev) {
> >> +error = dax_register_holder(btp->bt_daxdev, mp,
> >> +_dax_holder_operations);
> >> +if (error) {
> >> +xfs_err(mp, "DAX device already in use?!");
> >> +goto error_free;
> >> +}
> >> +}
> >
> > It seems to me that just passing the holder and holder ops to
> > fs_dax_get_by_bdev and the holder to dax_unregister_holder would
> > significantly simply the interface here.
> >
> > Dan, what do you think?
>
> Hi Dan,
>
> Could you give some advise on this API?  Is it needed to move
> dax_register_holder's job into fs_dax_get_by_bdev()?


Yes, works for me to just add them as optional arguments.



Re: [PATCH v11 7/8] xfs: Implement ->notify_failure() for XFS

2022-04-08 Thread Dan Williams
On Tue, Mar 29, 2022 at 11:01 PM Christoph Hellwig  wrote:
>
> > @@ -1892,6 +1893,8 @@ xfs_free_buftarg(
> >   list_lru_destroy(>bt_lru);
> >
> >   blkdev_issue_flush(btp->bt_bdev);
> > + if (btp->bt_daxdev)
> > + dax_unregister_holder(btp->bt_daxdev, btp->bt_mount);
> >   fs_put_dax(btp->bt_daxdev);
> >
> >   kmem_free(btp);
> > @@ -1939,6 +1942,7 @@ xfs_alloc_buftarg(
> >   struct block_device *bdev)
> >  {
> >   xfs_buftarg_t   *btp;
> > + int error;
> >
> >   btp = kmem_zalloc(sizeof(*btp), KM_NOFS);
> >
> > @@ -1946,6 +1950,14 @@ xfs_alloc_buftarg(
> >   btp->bt_dev =  bdev->bd_dev;
> >   btp->bt_bdev = bdev;
> >   btp->bt_daxdev = fs_dax_get_by_bdev(bdev, >bt_dax_part_off);
> > + if (btp->bt_daxdev) {
> > + error = dax_register_holder(btp->bt_daxdev, mp,
> > + _dax_holder_operations);
> > + if (error) {
> > + xfs_err(mp, "DAX device already in use?!");
> > + goto error_free;
> > + }
> > + }
>
> It seems to me that just passing the holder and holder ops to
> fs_dax_get_by_bdev and the holder to dax_unregister_holder would
> significantly simply the interface here.
>
> Dan, what do you think?

Yes, makes sense, just like the optional holder arguments to blkdev_get_by_*().

>
> > +#if IS_ENABLED(CONFIG_MEMORY_FAILURE) && IS_ENABLED(CONFIG_FS_DAX)
>
> No real need for the IS_ENABLED.  Also any reason to even build this
> file if the options are not set?  It seems like
> xfs_dax_holder_operations should just be defined to NULL and the
> whole file not supported if we can't support the functionality.
>
> Dan: not for this series, but is there any reason not to require
> MEMORY_FAILURE for DAX to start with?

Given that DAX ties some storage semantics to memory and storage
supports EIO I can see an argument to require memory_failure() for
DAX, and especially for DAX on CXL where hotplug is supported it will
be necessary. Linux currently has no facility to consult PCI drivers
about removal actions, so the only recourse for a force removed CXL
device is mass memory_failure().

>
> > +
> > + ddev_start = mp->m_ddev_targp->bt_dax_part_off;
> > + ddev_end = ddev_start +
> > + (mp->m_ddev_targp->bt_bdev->bd_nr_sectors << SECTOR_SHIFT) - 
> > 1;
>
> This should use bdev_nr_bytes.
>
> But didn't we say we don't want to support notifications on partitioned
> devices and thus don't actually need all this?

Right.



Re: [PATCH v11 7/8] xfs: Implement ->notify_failure() for XFS

2022-04-08 Thread Shiyang Ruan




在 2022/3/30 14:00, Christoph Hellwig 写道:

@@ -1892,6 +1893,8 @@ xfs_free_buftarg(
list_lru_destroy(>bt_lru);
  
  	blkdev_issue_flush(btp->bt_bdev);

+   if (btp->bt_daxdev)
+   dax_unregister_holder(btp->bt_daxdev, btp->bt_mount);
fs_put_dax(btp->bt_daxdev);
  
  	kmem_free(btp);

@@ -1939,6 +1942,7 @@ xfs_alloc_buftarg(
struct block_device *bdev)
  {
xfs_buftarg_t   *btp;
+   int error;
  
  	btp = kmem_zalloc(sizeof(*btp), KM_NOFS);
  
@@ -1946,6 +1950,14 @@ xfs_alloc_buftarg(

btp->bt_dev =  bdev->bd_dev;
btp->bt_bdev = bdev;
btp->bt_daxdev = fs_dax_get_by_bdev(bdev, >bt_dax_part_off);
+   if (btp->bt_daxdev) {
+   error = dax_register_holder(btp->bt_daxdev, mp,
+   _dax_holder_operations);
+   if (error) {
+   xfs_err(mp, "DAX device already in use?!");
+   goto error_free;
+   }
+   }


It seems to me that just passing the holder and holder ops to
fs_dax_get_by_bdev and the holder to dax_unregister_holder would
significantly simply the interface here.

Dan, what do you think?


Hi Dan,

Could you give some advise on this API?  Is it needed to move 
dax_register_holder's job into fs_dax_get_by_bdev()?



--
Thanks,
Ruan




+#if IS_ENABLED(CONFIG_MEMORY_FAILURE) && IS_ENABLED(CONFIG_FS_DAX)


No real need for the IS_ENABLED.  Also any reason to even build this
file if the options are not set?  It seems like
xfs_dax_holder_operations should just be defined to NULL and the
whole file not supported if we can't support the functionality.

Dan: not for this series, but is there any reason not to require
MEMORY_FAILURE for DAX to start with?


+
+   ddev_start = mp->m_ddev_targp->bt_dax_part_off;
+   ddev_end = ddev_start +
+   (mp->m_ddev_targp->bt_bdev->bd_nr_sectors << SECTOR_SHIFT) - 1;


This should use bdev_nr_bytes.

But didn't we say we don't want to support notifications on partitioned
devices and thus don't actually need all this?


+
+   /* Ignore the range out of filesystem area */
+   if ((offset + len) < ddev_start)


No need for the inner braces.


+   if ((offset + len) > ddev_end)


No need for the braces either.


diff --git a/fs/xfs/xfs_notify_failure.h b/fs/xfs/xfs_notify_failure.h
new file mode 100644
index ..76187b9620f9
--- /dev/null
+++ b/fs/xfs/xfs_notify_failure.h
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2022 Fujitsu.  All Rights Reserved.
+ */
+#ifndef __XFS_NOTIFY_FAILURE_H__
+#define __XFS_NOTIFY_FAILURE_H__
+
+extern const struct dax_holder_operations xfs_dax_holder_operations;
+
+#endif  /* __XFS_NOTIFY_FAILURE_H__ */


Dowe really need a new header for this vs just sequeezing it into
xfs_super.h or something like that?


diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
index e8f37bdc8354..b8de6ed2c888 100644
--- a/fs/xfs/xfs_super.c
+++ b/fs/xfs/xfs_super.c
@@ -353,6 +353,12 @@ xfs_setup_dax_always(
return -EINVAL;
}
  
+	if (xfs_has_reflink(mp) && !xfs_has_rmapbt(mp)) {

+   xfs_alert(mp,
+   "need rmapbt when both DAX and reflink enabled.");
+   return -EINVAL;
+   }


Right now we can't even enable reflink with DAX yet, so adding this
here seems premature - it should go into the patch allowing DAX+reflink.







Re: [PATCH v11 7/8] xfs: Implement ->notify_failure() for XFS

2022-03-30 Thread Christoph Hellwig
On Wed, Mar 30, 2022 at 11:16:10PM +0800, Shiyang Ruan wrote:
> > > +#if IS_ENABLED(CONFIG_MEMORY_FAILURE) && IS_ENABLED(CONFIG_FS_DAX)
> > 
> > No real need for the IS_ENABLED.  Also any reason to even build this
> > file if the options are not set?  It seems like
> > xfs_dax_holder_operations should just be defined to NULL and the
> > whole file not supported if we can't support the functionality.
> 
> Got it.  These two CONFIG seem not related for now.  So, I think I should
> wrap these code with #ifdef CONFIG_MEMORY_FAILURE here, and add
> `xfs-$(CONFIG_FS_DAX) += xfs_notify_failure.o` in the makefile.

I'd do

ifeq ($(CONFIG_MEMORY_FAILURE),y)
xfs-$(CONFIG_FS_DAX) += xfs_notify_failure.o
endif

in the makefile and keep it out of the actual source file entirely.

> > > +
> > > + /* Ignore the range out of filesystem area */
> > > + if ((offset + len) < ddev_start)
> > 
> > No need for the inner braces.
> > 
> > > + if ((offset + len) > ddev_end)
> > 
> > No need for the braces either.
> 
> Really no need?  It is to make sure the range to be handled won't out of the
> filesystem area.  And make sure the @offset and @len are valid and correct
> after subtract the bbdev_start.

Yes, but there is no need for the braces per the precedence rules in
C.  So these could be:

if (offset + len < ddev_start)

and

if (offset + len > ddev_end)



Re: [PATCH v11 7/8] xfs: Implement ->notify_failure() for XFS

2022-03-30 Thread Shiyang Ruan




在 2022/3/30 14:00, Christoph Hellwig 写道:

@@ -1892,6 +1893,8 @@ xfs_free_buftarg(
list_lru_destroy(>bt_lru);
  
  	blkdev_issue_flush(btp->bt_bdev);

+   if (btp->bt_daxdev)
+   dax_unregister_holder(btp->bt_daxdev, btp->bt_mount);
fs_put_dax(btp->bt_daxdev);
  
  	kmem_free(btp);

@@ -1939,6 +1942,7 @@ xfs_alloc_buftarg(
struct block_device *bdev)
  {
xfs_buftarg_t   *btp;
+   int error;
  
  	btp = kmem_zalloc(sizeof(*btp), KM_NOFS);
  
@@ -1946,6 +1950,14 @@ xfs_alloc_buftarg(

btp->bt_dev =  bdev->bd_dev;
btp->bt_bdev = bdev;
btp->bt_daxdev = fs_dax_get_by_bdev(bdev, >bt_dax_part_off);
+   if (btp->bt_daxdev) {
+   error = dax_register_holder(btp->bt_daxdev, mp,
+   _dax_holder_operations);
+   if (error) {
+   xfs_err(mp, "DAX device already in use?!");
+   goto error_free;
+   }
+   }


It seems to me that just passing the holder and holder ops to
fs_dax_get_by_bdev and the holder to dax_unregister_holder would
significantly simply the interface here.

Dan, what do you think?


+#if IS_ENABLED(CONFIG_MEMORY_FAILURE) && IS_ENABLED(CONFIG_FS_DAX)


No real need for the IS_ENABLED.  Also any reason to even build this
file if the options are not set?  It seems like
xfs_dax_holder_operations should just be defined to NULL and the
whole file not supported if we can't support the functionality.


Got it.  These two CONFIG seem not related for now.  So, I think I 
should wrap these code with #ifdef CONFIG_MEMORY_FAILURE here, and add 
`xfs-$(CONFIG_FS_DAX) += xfs_notify_failure.o` in the makefile.




Dan: not for this series, but is there any reason not to require
MEMORY_FAILURE for DAX to start with?


+
+   ddev_start = mp->m_ddev_targp->bt_dax_part_off;
+   ddev_end = ddev_start +
+   (mp->m_ddev_targp->bt_bdev->bd_nr_sectors << SECTOR_SHIFT) - 1;


This should use bdev_nr_bytes.


OK.



But didn't we say we don't want to support notifications on partitioned
devices and thus don't actually need all this?


+
+   /* Ignore the range out of filesystem area */
+   if ((offset + len) < ddev_start)


No need for the inner braces.


+   if ((offset + len) > ddev_end)


No need for the braces either.


Really no need?  It is to make sure the range to be handled won't out of 
the filesystem area.  And make sure the @offset and @len are valid and 
correct after subtract the bbdev_start.





diff --git a/fs/xfs/xfs_notify_failure.h b/fs/xfs/xfs_notify_failure.h
new file mode 100644
index ..76187b9620f9
--- /dev/null
+++ b/fs/xfs/xfs_notify_failure.h
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2022 Fujitsu.  All Rights Reserved.
+ */
+#ifndef __XFS_NOTIFY_FAILURE_H__
+#define __XFS_NOTIFY_FAILURE_H__
+
+extern const struct dax_holder_operations xfs_dax_holder_operations;
+
+#endif  /* __XFS_NOTIFY_FAILURE_H__ */


Dowe really need a new header for this vs just sequeezing it into
xfs_super.h or something like that?


Yes, I'll move it into xfs_super.h.  The xfs_notify_failure.c was 
splitted from xfs_super.c in the old patch.  There is no need to create 
a header file for only single line of code.





diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
index e8f37bdc8354..b8de6ed2c888 100644
--- a/fs/xfs/xfs_super.c
+++ b/fs/xfs/xfs_super.c
@@ -353,6 +353,12 @@ xfs_setup_dax_always(
return -EINVAL;
}
  
+	if (xfs_has_reflink(mp) && !xfs_has_rmapbt(mp)) {

+   xfs_alert(mp,
+   "need rmapbt when both DAX and reflink enabled.");
+   return -EINVAL;
+   }


Right now we can't even enable reflink with DAX yet, so adding this
here seems premature - it should go into the patch allowing DAX+reflink.



Yes.  I'll remove it for now.


--
Thanks,
Ruan.





Re: [PATCH v11 7/8] xfs: Implement ->notify_failure() for XFS

2022-03-30 Thread Christoph Hellwig
> @@ -1892,6 +1893,8 @@ xfs_free_buftarg(
>   list_lru_destroy(>bt_lru);
>  
>   blkdev_issue_flush(btp->bt_bdev);
> + if (btp->bt_daxdev)
> + dax_unregister_holder(btp->bt_daxdev, btp->bt_mount);
>   fs_put_dax(btp->bt_daxdev);
>  
>   kmem_free(btp);
> @@ -1939,6 +1942,7 @@ xfs_alloc_buftarg(
>   struct block_device *bdev)
>  {
>   xfs_buftarg_t   *btp;
> + int error;
>  
>   btp = kmem_zalloc(sizeof(*btp), KM_NOFS);
>  
> @@ -1946,6 +1950,14 @@ xfs_alloc_buftarg(
>   btp->bt_dev =  bdev->bd_dev;
>   btp->bt_bdev = bdev;
>   btp->bt_daxdev = fs_dax_get_by_bdev(bdev, >bt_dax_part_off);
> + if (btp->bt_daxdev) {
> + error = dax_register_holder(btp->bt_daxdev, mp,
> + _dax_holder_operations);
> + if (error) {
> + xfs_err(mp, "DAX device already in use?!");
> + goto error_free;
> + }
> + }

It seems to me that just passing the holder and holder ops to
fs_dax_get_by_bdev and the holder to dax_unregister_holder would
significantly simply the interface here.

Dan, what do you think?

> +#if IS_ENABLED(CONFIG_MEMORY_FAILURE) && IS_ENABLED(CONFIG_FS_DAX)

No real need for the IS_ENABLED.  Also any reason to even build this
file if the options are not set?  It seems like
xfs_dax_holder_operations should just be defined to NULL and the
whole file not supported if we can't support the functionality.

Dan: not for this series, but is there any reason not to require
MEMORY_FAILURE for DAX to start with?

> +
> + ddev_start = mp->m_ddev_targp->bt_dax_part_off;
> + ddev_end = ddev_start +
> + (mp->m_ddev_targp->bt_bdev->bd_nr_sectors << SECTOR_SHIFT) - 1;

This should use bdev_nr_bytes.

But didn't we say we don't want to support notifications on partitioned
devices and thus don't actually need all this?

> +
> + /* Ignore the range out of filesystem area */
> + if ((offset + len) < ddev_start)

No need for the inner braces.

> + if ((offset + len) > ddev_end)

No need for the braces either.

> diff --git a/fs/xfs/xfs_notify_failure.h b/fs/xfs/xfs_notify_failure.h
> new file mode 100644
> index ..76187b9620f9
> --- /dev/null
> +++ b/fs/xfs/xfs_notify_failure.h
> @@ -0,0 +1,10 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2022 Fujitsu.  All Rights Reserved.
> + */
> +#ifndef __XFS_NOTIFY_FAILURE_H__
> +#define __XFS_NOTIFY_FAILURE_H__
> +
> +extern const struct dax_holder_operations xfs_dax_holder_operations;
> +
> +#endif  /* __XFS_NOTIFY_FAILURE_H__ */

Dowe really need a new header for this vs just sequeezing it into
xfs_super.h or something like that?

> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
> index e8f37bdc8354..b8de6ed2c888 100644
> --- a/fs/xfs/xfs_super.c
> +++ b/fs/xfs/xfs_super.c
> @@ -353,6 +353,12 @@ xfs_setup_dax_always(
>   return -EINVAL;
>   }
>  
> + if (xfs_has_reflink(mp) && !xfs_has_rmapbt(mp)) {
> + xfs_alert(mp,
> + "need rmapbt when both DAX and reflink enabled.");
> + return -EINVAL;
> + }

Right now we can't even enable reflink with DAX yet, so adding this
here seems premature - it should go into the patch allowing DAX+reflink.




Re: [PATCH v11 7/8] xfs: Implement ->notify_failure() for XFS

2022-02-27 Thread kernel test robot
Hi Shiyang,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on xfs-linux/for-next]
[also build test ERROR on linux/master]
[cannot apply to hnaz-mm/master linus/master v5.17-rc5 next-20220225]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Shiyang-Ruan/fsdax-introduce-fs-query-to-support-reflink/20220227-200849
base:   https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git for-next
config: riscv-randconfig-p001-20220227 
(https://download.01.org/0day-ci/archive/20220227/202202272331.sp0o3f9l-...@intel.com/config)
compiler: riscv64-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/9f4bfbd2bae60e9f172e0b7332b2af32aa5baa87
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Shiyang-Ruan/fsdax-introduce-fs-query-to-support-reflink/20220227-200849
git checkout 9f4bfbd2bae60e9f172e0b7332b2af32aa5baa87
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross 
O=build_dir ARCH=riscv SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   riscv64-linux-ld: fs/xfs/xfs_buf.o: in function `.L828':
>> xfs_buf.c:(.text+0x3f7c): undefined reference to `dax_unregister_holder'
   riscv64-linux-ld: fs/xfs/xfs_notify_failure.o: in function 
`xfs_dax_notify_failure':
>> xfs_notify_failure.c:(.text+0x2b0): undefined reference to `dax_holder'

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org



Re: [PATCH v11 7/8] xfs: Implement ->notify_failure() for XFS

2022-02-27 Thread kernel test robot
Hi Shiyang,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on xfs-linux/for-next]
[also build test ERROR on linux/master]
[cannot apply to hnaz-mm/master linus/master v5.17-rc5 next-20220225]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Shiyang-Ruan/fsdax-introduce-fs-query-to-support-reflink/20220227-200849
base:   https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git for-next
config: hexagon-buildonly-randconfig-r005-20220227 
(https://download.01.org/0day-ci/archive/20220227/202202272333.bhlvmuhf-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 
d271fc04d5b97b12e6b797c6067d3c96a8d7470e)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/9f4bfbd2bae60e9f172e0b7332b2af32aa5baa87
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Shiyang-Ruan/fsdax-introduce-fs-query-to-support-reflink/20220227-200849
git checkout 9f4bfbd2bae60e9f172e0b7332b2af32aa5baa87
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=hexagon SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

>> ld.lld: error: undefined symbol: dax_unregister_holder
   >>> referenced by xfs_buf.c
   >>> xfs/xfs_buf.o:(xfs_free_buftarg) in archive fs/built-in.a
   >>> referenced by xfs_buf.c
   >>> xfs/xfs_buf.o:(xfs_free_buftarg) in archive fs/built-in.a
--
>> ld.lld: error: undefined symbol: dax_holder
   >>> referenced by xfs_notify_failure.c
   >>> xfs/xfs_notify_failure.o:(xfs_dax_notify_failure) in archive 
fs/built-in.a
   >>> referenced by xfs_notify_failure.c
   >>> xfs/xfs_notify_failure.o:(xfs_dax_notify_failure) in archive 
fs/built-in.a

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org



Re: [PATCH v11 7/8] xfs: Implement ->notify_failure() for XFS

2022-02-27 Thread kernel test robot
Hi Shiyang,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on xfs-linux/for-next]
[also build test ERROR on linux/master]
[cannot apply to hnaz-mm/master linus/master v5.17-rc5 next-20220225]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Shiyang-Ruan/fsdax-introduce-fs-query-to-support-reflink/20220227-200849
base:   https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git for-next
config: i386-randconfig-a003 
(https://download.01.org/0day-ci/archive/20220227/202202272203.u7vlqy3b-...@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/9f4bfbd2bae60e9f172e0b7332b2af32aa5baa87
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Shiyang-Ruan/fsdax-introduce-fs-query-to-support-reflink/20220227-200849
git checkout 9f4bfbd2bae60e9f172e0b7332b2af32aa5baa87
# save the config file to linux build tree
mkdir build_dir
make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   ld: fs/xfs/xfs_buf.o: in function `xfs_free_buftarg':
>> fs/xfs/xfs_buf.c:1897: undefined reference to `dax_unregister_holder'
   ld: fs/xfs/xfs_notify_failure.o: in function `xfs_dax_notify_failure':
>> fs/xfs/xfs_notify_failure.c:187: undefined reference to `dax_holder'


vim +1897 fs/xfs/xfs_buf.c

  1885  
  1886  void
  1887  xfs_free_buftarg(
  1888  struct xfs_buftarg  *btp)
  1889  {
  1890  unregister_shrinker(>bt_shrinker);
  1891  ASSERT(percpu_counter_sum(>bt_io_count) == 0);
  1892  percpu_counter_destroy(>bt_io_count);
  1893  list_lru_destroy(>bt_lru);
  1894  
  1895  blkdev_issue_flush(btp->bt_bdev);
  1896  if (btp->bt_daxdev)
> 1897  dax_unregister_holder(btp->bt_daxdev, btp->bt_mount);
  1898  fs_put_dax(btp->bt_daxdev);
  1899  
  1900  kmem_free(btp);
  1901  }
  1902  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org