All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Huang <adrianhuang0701@gmail.com>
To: linux-nvdimm@lists.01.org
Cc: Adrian Huang <ahuang12@lenovo.com>, Coly Li <colyli@suse.de>,
	Alasdair Kergon <agk@redhat.com>,
	Mike Snitzer <snitzer@redhat.com>
Subject: [PATCH 1/1] dax: do not print error message for non-persistent memory block device
Date: Wed, 19 Aug 2020 23:42:36 +0800	[thread overview]
Message-ID: <20200819154236.24191-1-adrianhuang0701@gmail.com> (raw)

From: Adrian Huang <ahuang12@lenovo.com>

From: Adrian Huang <ahuang12@lenovo.com>

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 <colyli@suse.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Alasdair Kergon <agk@redhat.com>
Cc: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Adrian Huang <ahuang12@lenovo.com>
---
 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);
-- 
2.17.1
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

             reply	other threads:[~2020-08-19 15:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-19 15:42 Adrian Huang [this message]
2020-08-19 15:54 ` [PATCH 1/1] dax: do not print error message for non-persistent memory block device Coly Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200819154236.24191-1-adrianhuang0701@gmail.com \
    --to=adrianhuang0701@gmail.com \
    --cc=agk@redhat.com \
    --cc=ahuang12@lenovo.com \
    --cc=colyli@suse.de \
    --cc=linux-nvdimm@lists.01.org \
    --cc=snitzer@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.