On Thu, Apr 07, 2016 at 07:12:28AM +0100, fdmanana@xxxxxxxxxx wrote: > From: Filipe Manana <fdmanana@xxxxxxxx> > > When running multiple tests using dm's flakey target, often (very rarely) > I was getting an error when a test tried to setup a dm flakey target, > resulting in the following messages in the test's .out.bad file: > > device-mapper: reload ioctl on flakey-test failed: Device or resource busy > Command failed > failed to create flakey device > > Upon further investigation it turns out that it was because the previous > test that ran had failed to remove the flakey device because the device > was being used at the time but this has not made that previous test fail > because we simply redirect the stderr (and stdout) to /dev/null and don't > fail if the dmsetup remove command exits with a non-zero status. > The device was in use, when the test attempted to remove it, by an udev > rule (btrfs udev rule). And that's why we have $UDEV_SETTLE_PROG calls before removing the dm device, which it appears _dmerror_init() does not have. If there are things other than udev holding the device open, then we ned to find what they are first rather than trying to ignore them... > Fix this by passing the option --retry to dmsetup remove, which serves to > deal with such cases. From dmsetup's man page: > > "If an attempt to remove a device fails, perhaps because a process run > from a quick udev rule temporarily opened the device, the --retry > option will cause the operation to be retried for a few seconds before > failing." It also talks about udev, so running $UDEV_SETTLE_PROG before remove should prevent this from happening. If it is not sufficient, then we need to understand why it is not sufficient, not blindly hack around it. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
