On 2020/8/19 23:42, Adrian Huang wrote: > From: Adrian Huang <[email protected]> > > From: Adrian Huang <[email protected]> > > 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. > > Fixes: 231609785cbf ("dax: print error message by pr_info() in > __generic_fsdax_supported()") > Cc: Coly Li <[email protected]> > Cc: Dan Williams <[email protected]> > Cc: Alasdair Kergon <[email protected]> > Cc: Mike Snitzer <[email protected]> > Signed-off-by: Adrian Huang <[email protected]>
It makes sense to me. Thanks for the fix up. Acked-by: Coly Li <[email protected]> Coly Li > --- > drivers/dax/super.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > 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); > _______________________________________________ Linux-nvdimm mailing list -- [email protected] To unsubscribe send an email to [email protected]
