On Thu, 2017-12-07 at 12:49 -0600, Benjamin Marzinski wrote: > There are a couple of issues I noticed with the marginal paths code. > > In hit_io_err_recheck_time() there are some problems with the initial > checks. We should always recover the path if there are no other > usable > paths to the device, so this check should be first. Also, we just > checked that io_err_disable_reinstate isn't zero before calling this > function, so we don't need to check again here (and it doesn't make > any > sense to continue disabling the path if io_err_disable_reinstate is > set > to zero). Finally, the only kind of errors we can get while calling > clock_gettime() are going to happen on every call. So, if we can't > get > the time, assume that the timeout has passed. > > The multipath.conf.5 description of marginal_path_err_sample_time, > states that sampling is stopped for marginal_path_err_rate_threshold > seconds, when it should be marginal_path_err_recheck_gap_time > seconds. > > Lastly, there is a race that can cause multipathd to access freed > memory > on shutdown. io_err_stat_thr is started as a detached thread. This > means > that stop_io_err_stat_thread() can't know when it has actually > stopped, > after pthread_cancel() and pthread_kill() are called. To be safe, it > should not start the thread in a deteched state, and call join to > verify > that it has stopped before freeing the memory it uses. But more > importantly, stop_io_err_stat_thread() was being called before the > checker and uevent threads were being canceled. Both of these threads > access data that is freed in stop_io_err_stat_thread(). To avoid the > chance of these threads accessing freed memory, child() should wait > until these threads are stopped before calling > stop_io_err_stat_thread(). > > Cc: Guan Junxiong <[email protected]> > Signed-off-by: Benjamin Marzinski <[email protected]> > ---
Reviewed-by: Martin Wilck <[email protected]> -- Dr. Martin Wilck <[email protected]>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- dm-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/dm-devel
