Comment 8 for bug 1354114

So probably to last commits touching libmultipath/waiter.c (and fixing this issue) would be:

1)

commit e1fcc5933ac44683cdee1a02304e1115abec3ff5
Author: Benjamin Marzinski <email address hidden>
Date: Sat May 19 01:37:03 2012 -0500

    multipath: clean up code for stopping the waiter threads

    The way multipathd currently stops the waiter threads needs some work.
    Right now they are stopped by being sent the SIGUSR1 signal. However their
    cleanup code assumes that they are being cancelled, just like all the other
    threads are. There's no reason for them to be so unnecessarily
    complicated and different from the other threads

    This patch does a couple of things. First, it removes the mutex from
    the event_thread. This wasn't doing anything. It was designed to protect
    the wp->mapname variable, which the waiter threads were checking to see
    if they should quit. However, the mutex was only ever being used by the
    thread itself, and it clearly didn't need to serialize with itself. Also,
    the function to clear the mapname, signal_waiter(), was set with
    pthread_cleanup_push(), which never got called early, since the threads
    weren't being cancelled. Thus, the mapname never got cleared
    until the pthreads were about to shut down.

    The patch also rips out all the signal stopping code, and just uses
    pthread_cancel. There already are cancellation points in the waiter
    thread code. Between the cancellation points, both explicit and implicit,
    and the fact that the waiter threads will never be killed except when the
    killer is holding the vecs lock, there shouldn't be any place where the
    waiter thread can access freed data.

    To make sure the waiter thread cleans itself up properly, the dmt
    has been moved into the event_thread structure, and is destroyed in
    free_waiter() if necessary.

    Signed-off-by: Benjamin Marzinski <email address hidden>