On Thu, Oct 2, 2014 at 10:06 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote: > On Thu, Oct 02, 2014 at 08:12:37AM +0200, Tom Gundersen wrote: >> Making kmod a special case is of course possible. However, as long as >> there is no fundamental reason why kmod should get this special >> treatment, this just looks like a work-around to me. > > I've mentioned a series of five reasons why its a bad idea right now to > sigkill modules [0], we're reviewed them each and still at least > items 2-4 remain particularly valid fundamental reasons to avoid it So items 2-4 basically say "there currently are drivers that cannot deal with sigkill after a three minute timeout". In the short-term we already have the solution: increase the timeout. In the long-term, we have two choices, either permanently add some heuristic to udev to deal with drivers taking a very long time to be inserted, or fix the drivers not to take such a long time. A priori, it makes no sense to me that drivers spend unbounded amounts of time to get inserted, so fixing the drivers seems like the most reasonable approach to me. That said, I'm of course open to be proven wrong if there are some drivers that fundamentally _must_ take a long time to insert (but we should then discuss why that is and how we can best deal with the situation, rather than adding some hack up-front when we don't even know if it is needed). Your patch series should go a long way towards fixing the drivers (and I imagine there being a lot of low-hanging fruit that can easily be fixed once your series has landed), and the fact that we have now increased the udev timeout from 30 to 180 seconds should also greatly reduce the problem. Cheers, Tom -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
