Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751942AbaJCIXt (ORCPT ); Fri, 3 Oct 2014 04:23:49 -0400 Received: from mail-yk0-f182.google.com ([209.85.160.182]:35718 "EHLO mail-yk0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751343AbaJCIXp (ORCPT ); Fri, 3 Oct 2014 04:23:45 -0400 MIME-Version: 1.0 X-Originating-IP: [84.208.172.182] In-Reply-To: <20141002200612.GQ14081@wotan.suse.de> References: <1411768637-6809-1-git-send-email-mcgrof@do-not-panic.com> <1411768637-6809-6-git-send-email-mcgrof@do-not-panic.com> <20140930022751.GA14081@wotan.suse.de> <20140930152419.GF14081@wotan.suse.de> <20141002200612.GQ14081@wotan.suse.de> From: Tom Gundersen Date: Fri, 3 Oct 2014 10:23:24 +0200 Message-ID: Subject: Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support To: "Luis R. Rodriguez" Cc: systemd Mailing List , "Luis R. Rodriguez" , Michal Hocko , Greg KH , Dmitry Torokhov , Takashi Iwai , Tejun Heo , Arjan van de Ven , Robert Milasan , werner@suse.com, Oleg Nesterov , hare , Benjamin Poirier , Santosh Rastapur , pmladek@suse.cz, dbueso@suse.com, LKML , Tetsuo Handa , Joseph Salisbury , Kay Sievers , One Thousand Gnomes , Tim Gardner , Pierre Fersing , Andrew Morton , Nagalakshmi Nandigama , Praveen Krishnamoorthy , Sreekanth Reddy , Abhijit Mahajan , Casey Leedom , Hariprasad S , "mpt-fusionlinux.pdl" , Linux SCSI List , netdev Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 2, 2014 at 10:06 PM, Luis R. Rodriguez 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/