Re: Question about "Add scsi_debug_teardown loop in blockwise tests."

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
[email protected]
https://www.saout.de/mailman/listinfo/dm-crypt