summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAdrian Huang <ahuang12@lenovo.com>2020-08-19 23:42:36 +0800
committerVishal Verma <vishal.l.verma@intel.com>2020-08-20 11:43:18 -0600
commitc2affe920b0e0669650943ac086215cf6519be34 (patch)
treef54629b2dab7a4bf86660b9ea9a4989ec0671636
parent62c789270c0b1ed5598c6b87c53b6908cd3c6eb5 (diff)
dax: do not print error message for non-persistent memory block device
Commit 231609785cbf ("dax: print error message by pr_info() in __generic_fsdax_supported()") happens to print the following error message during booting when the non-persistent memory block devices are configured by device mapper. Those error messages are caused by the variable 'dax_dev' is NULL. Users might be confused with those error messages since they do not use the persistent memory device. Moreover, users might scare about "what's wrong with my disks" because they see the 'error' and 'failed' keywords. # dmesg | grep fail sdk3: error: dax access failed (-95) sdk3: error: dax access failed (-95) sdk3: error: dax access failed (-95) sdk3: error: dax access failed (-95) sdk3: error: dax access failed (-95) sdk3: error: dax access failed (-95) sdk3: error: dax access failed (-95) sdk3: error: dax access failed (-95) sdk3: error: dax access failed (-95) sdb3: error: dax access failed (-95) sdb3: error: dax access failed (-95) sdb3: error: dax access failed (-95) sdb3: error: dax access failed (-95) sdb3: error: dax access failed (-95) sdb3: error: dax access failed (-95) sdb3: error: dax access failed (-95) sdb3: error: dax access failed (-95) sdb3: error: dax access failed (-95) # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1.1T 0 disk ├─sda1 8:1 0 156M 0 part ├─sda2 8:2 0 40G 0 part └─sda3 8:3 0 1.1T 0 part sdb 8:16 0 1.1T 0 disk ├─sdb1 8:17 0 600M 0 part ├─sdb2 8:18 0 1G 0 part └─sdb3 8:19 0 1.1T 0 part ├─rhel00-swap 254:3 0 4G 0 lvm ├─rhel00-home 254:4 0 1T 0 lvm └─rhel00-root 254:5 0 50G 0 lvm sdc 8:32 0 1.1T 0 disk sdd 8:48 0 1.1T 0 disk sde 8:64 0 1.1T 0 disk sdf 8:80 0 1.1T 0 disk sdg 8:96 0 1.1T 0 disk sdh 8:112 0 3.3T 0 disk ├─sdh1 8:113 0 500M 0 part /boot/efi ├─sdh2 8:114 0 40G 0 part / ├─sdh3 8:115 0 2.9T 0 part /home └─sdh4 8:116 0 314.6G 0 part [SWAP] sdi 8:128 0 1.1T 0 disk sdj 8:144 0 3.3T 0 disk ├─sdj1 8:145 0 512M 0 part └─sdj2 8:146 0 3.3T 0 part sdk 8:160 0 119.2G 0 disk ├─sdk1 8:161 0 200M 0 part ├─sdk2 8:162 0 1G 0 part └─sdk3 8:163 0 118G 0 part ├─rhel-swap 254:0 0 4G 0 lvm ├─rhel-home 254:1 0 64G 0 lvm └─rhel-root 254:2 0 50G 0 lvm sdl 8:176 0 119.2G 0 disk The call path is shown as follows: dm_table_determine_type dm_table_supports_dax device_supports_dax generic_fsdax_supported __generic_fsdax_supported With the disk configuration listing from the command 'lsblk', the member 'dev->dax_dev' of the block devices 'sdb3' and 'sdk3' (configured by device mapper) is NULL in function generic_fsdax_supported() because the member is configured in function open_table_device(). To prevent the confusing error messages in this scenario (this is normal behavior), just print those error messages by pr_debug() by checking if dax_dev is NULL and the block device does not support DAX. Link: https://lore.kernel.org/r/20200819154236.24191-1-adrianhuang0701@gmail.com Fixes: 231609785cbf ("dax: print error message by pr_info() in __generic_fsdax_supported()") Cc: Coly Li <colyli@suse.de> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Alasdair Kergon <agk@redhat.com> Cc: Mike Snitzer <snitzer@redhat.com> Acked-by: Coly Li <colyli@suse.de> Signed-off-by: Adrian Huang <ahuang12@lenovo.com> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
-rw-r--r--drivers/dax/super.c6
1 files changed, 6 insertions, 0 deletions
diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index c82cbcb64202..32642634c1bb 100644
--- a/drivers/dax/super.c
+++ b/drivers/dax/super.c
@@ -100,6 +100,12 @@ bool __generic_fsdax_supported(struct dax_device *dax_dev,
return false;
}
+ if (!dax_dev && !bdev_dax_supported(bdev, blocksize)) {
+ pr_debug("%s: error: dax unsupported by block device\n",
+ bdevname(bdev, buf));
+ return false;
+ }
+
id = dax_read_lock();
len = dax_direct_access(dax_dev, pgoff, 1, &kaddr, &pfn);
len2 = dax_direct_access(dax_dev, pgoff_end, 1, &end_kaddr, &end_pfn);