Hi, As discussed in a previous thread today, the seemingly much saner approach is just to allow signals (including SIGSTOP) for the PF_IO_WORKER IO threads. If we just have the threads call get_signal() for signal_pending(), then everything just falls out naturally with how we receive and handle signals. Patch 1 adds support for checking and calling get_signal() from the regular IO workers, the manager, and the SQPOLL thread. Patch 2 unblocks SIGSTOP from the default IO thread blocked mask, and the rest just revert special cases that were put in place for PF_IO_WORKER threads. With this done, only two special cases remain for PF_IO_WORKER, and they aren't related to signals so not part of this patchset. But both of them can go away as well now that we have "real" threads as IO workers, and then we'll have zero special cases for PF_IO_WORKER. This passes the usual regression testing, my other usual 24h run has been kicked off. But I wanted to send this out early. Thanks to Linus for the suggestion. As with most other good ideas, it's obvious once you hear it. The fact that we end up with _zero_ special cases with this is a clear sign that this is the right way to do it indeed. The fact that this series is 2/3rds revert further drives that point home. Also thanks to Eric for diligent review on the signal side of things for the past changes (and hopefully ditto on this series :-)) -- Jens Axboe
