On 12/27/18 9:42 AM, yangerkun wrote:
Hi,
While we are testing fs with xfstests, generic/108 will fail at some
times with the reson that rmmod find the refcnt of scsi_debug module
isn't 0 by checking /proc/modules. And this your patch is really
describe the same thing. But, i am confusing about the scene as you said:
cleanup() {
if [ -d "$MNT_DIR" ] ; then
umount -f $MNT_DIR 2>/dev/null
rmdir $MNT_DIR 2>/dev/null
fi
rm -f $LOCAL_FILE 2> /dev/null
- udevadm settle >/dev/null 2>&1
- rmmod scsi_debug 2> /dev/null
+ scsi_debug_teardown "$DEV" || exit 100
}
After the settle, all the event has been finish, so who will trigger the
scan, and how to scan? Can you help to explain this? Thanks a lot!
Well, almost true. But by our experience udev settle command behaviour
is not strictly defined (and also discouraged from using even by udev
maintainers themselves IIRC). For example it will not synchronize you
against events coming after you trigger the settle command. And you have
zero control over when the event is added. So the long-term goal is to
get rid of it from all tests in cryptsetup (not being on top of our todo
list as you can clearly see if you grep scripts across tests
subdirectory :)).
Due to many existing udev versions among many distributions we found out
there's no more reliable way than trying to remove scsi_debug in retry
loop. And that loop also handles some weird versions (legacy versions
but we do sometimes test even old distros) where udev fails to remove
device nodes from /dev from time to time.
Regards
O.
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
https://www.saout.de/mailman/listinfo/dm-crypt
