Description of problem:
After upgrading from xfsdump-3.1.8-2.el8.x86_64 to xfsdump-3.1.8-4.el8.x86_64, attempting to xfsdump the root filesystem, via a path through the device mapper, on a host with the BIND chroot runtime enabled, fails.

Version-Release number of selected component (if applicable):
xfsdump-3.1.8-4.el8.x86_64

How reproducible:
Always?

Steps to Reproduce:
1. With named-chroot.service active, run
/sbin/xfsdump -F -J -l 0 - /dev/dm-0 > /dev/null
where /dev/dm-0 is the device for the root filesystem; or, equivalently,
/sbin/xfsdump -F -J -l 0 - /dev/mapper/cl_hostname-root > /dev/null
where /dev/mapper/cl_hostname-root is the device name as per /etc/fstab.

Actual results:
xfsdump fails with a message of the form:

/sbin/xfsdump: version 3.1.8 (dump format 3.0)
/sbin/xfsdump: level 0 dump of hostname:/var/named/chroot/var/named
/sbin/xfsdump: dump date: Fri Jun 3 10:05:08 2022
/sbin/xfsdump: session id: 29d5cf9e-951d-4077-966c-3db918668768
/sbin/xfsdump: session label: ""
/sbin/xfsdump: ERROR: /var/named/chroot/var/named is not the root of the filesystem (bind mount?) - use primary mountpoint
/sbin/xfsdump: Dump Status: ERROR

(Note that xfsdump is attempting to dump the wrong pathname, i.e., /var/named/chroot/var/named instead of /.)

Expected results:
Dump should proceed, although note that in previous releases (e.g., 3.1.8-2.el8):

• xfsdump still reported "dump of hostname:/var/named/chroot/var/named", although it appears that the backup contained the full root filesystem), and
• a warning of the form "NOTE: root ino 128 differs from mount dir ino 134955734, bind mount?" would be emitted.

Additional info:

In my testing, the problem did not occur using
/sbin/xfsdump -F -J -l 0 - / > /dev/null
but rather only when using a path to the device through /dev/mapper/. However, there's no obvious way to use this to workaround when dumping with Amanda, which appears to map the filesystem to the device according to /etc/fstab .

The issue is almost certainly not specific to bind-chroot, and likely occurs in other instances where bind mounts are present, but bind-chroot is likely to be a common reason for bind mounts to be present.