When calling __generic_fsdax_supported(), a dax-unsupported device may not have dax_dev as NULL, e.g. the dax related code block is not enabled by Kconfig. Therefore in __generic_fsdax_supported(), to check whether a device supports DAX or not, the following order should be performed, - If dax_dev pointer is NULL, it means the device driver explicitly announce it doesn't support DAX. Then it is OK to directly return false from __generic_fsdax_supported(). - If dax_dev pointer is NOT NULL, it might be because the driver doesn't support DAX and not explicitly initialize related data structure. Then bdev_dax_supported() should be called for further check. IMHO if device driver desn't explicitly set its dax_dev pointer to NULL, this is not a bug. Calling bdev_dax_supported() makes sure they can be recognized as dax-unsupported eventually. This patch does the following change for the above purpose, - if (!dax_dev && !bdev_dax_supported(bdev, blocksize)) { + if (!dax_dev || !bdev_dax_supported(bdev, blocksize)) { Fixes: c2affe920b0e ("dax: do not print error message for non-persistent memory block device") Signed-off-by: Coly Li <colyli(a)suse.de&gt;

On 2020/9/4 00:06, Ira Weiny wrote: > On Thu, Sep 03, 2020 at 07:55:49PM +0800, Coly Li wrote: >> When calling __generic_fsdax_supported(), a dax-unsupported device may >> not have dax_dev as NULL, e.g. the dax related code block is not enabled >> by Kconfig. >> >> Therefore in __generic_fsdax_supported(), to check whether a device >> supports DAX or not, the following order should be performed, >> - If dax_dev pointer is NULL, it means the device driver explicitly >> announce it doesn't support DAX. Then it is OK to directly return >> false from __generic_fsdax_supported(). >> - If dax_dev pointer is NOT NULL, it might be because the driver doesn't >> support DAX and not explicitly initialize related data structure. Then >> bdev_dax_supported() should be called for further check. >> >> IMHO if device driver desn't explicitly set its dax_dev pointer to NULL, >> this is not a bug. Calling bdev_dax_supported() makes sure they can be >> recognized as dax-unsupported eventually. >> >> This patch does the following change for the above purpose, >> - if (!dax_dev && !bdev_dax_supported(bdev, blocksize)) { >> + if (!dax_dev || !bdev_dax_supported(bdev, blocksize)) { >> >> >> Fixes: c2affe920b0e ("dax: do not print error message for non-persistent memory block device") >> Signed-off-by: Coly Li <colyli(a)suse.de&gt; > > I hate to do this because I realize this is a bug which people really need > fixed. > > However, shouldn't we also check (!dax_dev || !bdev_dax_supported()) as the > _first_ check in __generic_fsdax_supported()? > > It seems like the other pr_info's could also be called when DAX is not > supported and we probably don't want them to be? > > Perhaps that should be a follow on patch though. So... I am not author of c2affe920b0e, but I guess it was because bdev_dax_supported() needed blocksize, so blocksize should pass previous checks firstly to make sure bdev_dax_supported() has a correct blocksize to check. > > As a direct fix to c2affe920b0e > > Reviewed-by: Ira Weiny <ira.weiny(a)intel.com&gt; Thanks. Coly Li > >> Cc: Adrian Huang <ahuang12(a)lenovo.com&gt; >> Cc: Ira Weiny <ira.weiny(a)intel.com&gt; >> Cc: Jan Kara <jack(a)suse.com&gt; >> Cc: Mike Snitzer <snitzer(a)redhat.com&gt; >> Cc: Pankaj Gupta <pankaj.gupta.linux(a)gmail.com&gt; >> Cc: Vishal Verma <vishal.l.verma(a)intel.com&gt; >> --- >> drivers/dax/super.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/dax/super.c b/drivers/dax/super.c >> index 32642634c1bb..e5767c83ea23 100644 >> --- a/drivers/dax/super.c >> +++ b/drivers/dax/super.c >> @@ -100,7 +100,7 @@ bool __generic_fsdax_supported(struct dax_device *dax_dev, >> return false; >> } >> >> - if (!dax_dev && !bdev_dax_supported(bdev, blocksize)) { >> + if (!dax_dev || !bdev_dax_supported(bdev, blocksize)) { >> pr_debug("%s: error: dax unsupported by block device\n", >> bdevname(bdev, buf)); >> return false; >> -- >> 2.26.2 >> _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm(a)lists.01.org To unsubscribe send an email to linux-nvdimm-leave(a)lists.01.org