On Fri, Mar 02, 2018 at 08:19:39PM +0100, Martin Wilck wrote: > On Wed, 2018-02-28 at 23:13 -0600, Benjamin Marzinski wrote: > > > > effects multipathd is its use of SIGALRM. Now assuming signal > > processing > > worked correctly in multipathd (it doesn't. commit 534ec4c broke it. > > I'm > > planning on fixing that shortly) > > Details about this breakage, and your idea how to fix it, would be > highly appreciated. I plan on fixing the issue using exactly the method that commit 534ec4c says it is using. :) I cleaned up the signal handling years ago with commit 5ee9f71, which blocked all the then-used signals for all threads except uxlsnr, which is who calls handle_signals. Other threads unblocked signals only as necessary. I'm not sure what issue caused Bart to write 534ec4c. Perhaps an earlier commit actually broke the signal handling, and this was just the commit that git blame pointed to. But in any case, after commit 534ec4c, we are only blocking SIGUSR2 on all threads, which is the only signal we don't need to block. This means that, for instance, we have no idea which thread a SIGALRM is going to, because any of them could receive it. It is safe to unblock SIGUSR2 on multiple threads at once, since (I hope) the only things that send it are stop_io_err_stat_thread() and stop_waiter_thread(), and both of those send it via pthread_kill, which will make sure it goes to the proper thread. -Ben > > Martin > > -- > Dr. Martin Wilck <mwilck@xxxxxxxx>, 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 dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
