Created attachment 1671208 [details]
strace log

Sorry for not looking at this sooner. If you could re-set up a reproducer, that would be helpful. I can't see this on the RHEL8 machines I've tried on.

So what's happening is that in RHEL8, the multipath command doesn't always do the reload command itself, if multipathd is running, multipath delegates the reload to multipathd, to guarantee that the daemon state is updated. The issue is that on your machines, it is taking too long for the checker to return when multipathd is reconfiguring the device. Since multipathd is reconfiguring, it doesn't trust the old device state.  It waits 100 ms for the path checkers to return something, but that doesn't happen. In this case, multipathd doesn't reload the device, because it doesn't see any known usable paths.  This is the way multipathd has always done things, but device-mapper has allowed reloads with failed paths (or even no paths) for years, so there's no point in this check anymore. Also, if you look at your logs, multipathd drops briefly into recovery mode until the checkers finally return. Actually this message is misleading. The paths are always active for the kernel.

However, this is only an issue here because you are relying on reloading the multipath device to trigger a kpartx update as a side effect.  If you run

kpartx -u /dev/mapper/<device>

Which updates the kpartx partitions, they will get updated correctly. Multipath has never automatically updated its kpartx partition devices, if the paths have their partitions directly changed, because it doesn't get any notification of it. Instead, it has always updated the devices when there was a (non-path state change) uevent for the multipath device itself (which happens when you reload the multipath device).

I'm going to create patches to both allow reloads when all the paths are down (or at least when some of the paths are pending,
which is a state that only really happens when a device first appears or multipathd is reconfigured, so it has no prior state to
go by) and to make multipathd could pending paths as up when checking if it needs to start recovery mode. But until then, you can just run "kpartx -u" if you want to update the kpartx devices (This is, in fact, what you should run, if you just want to update kpartx devices).  That's what's getting run when a multipath device is reloaded, just by udev.

multipath and multipathd should now reload devices correctly, even when there are no active paths.  Also, make kpartx run on a device when the first path appears, even if it otherwise wouldn't be.

kpartx now uses directio to read the devices, to avoid the issue of a stale cache (due to the partitions being updated on another machine).

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (device-mapper-multipath bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:4540