Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754116AbYLGEb2 (ORCPT ); Sat, 6 Dec 2008 23:31:28 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753583AbYLGEbT (ORCPT ); Sat, 6 Dec 2008 23:31:19 -0500 Received: from netgear.net.ru ([195.178.208.66]:58318 "EHLO tservice.net.ru" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1753544AbYLGEbT (ORCPT ); Sat, 6 Dec 2008 23:31:19 -0500 Date: Sun, 7 Dec 2008 07:31:16 +0300 From: Evgeniy Polyakov To: Kay Sievers Cc: Alan Cox , linux-kernel@vger.kernel.org Subject: Re: Runaway loop with the current git. Message-ID: <20081207043116.GA12161@ioremap.net> References: <20081205212428.GB8075@ioremap.net> <20081206160927.GA498@ioremap.net> <20081206165634.GA2516@ioremap.net> <1228591926.3808.6.camel@nga> <20081206202620.GA9470@ioremap.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1521 Lines: 36 On Sun, Dec 07, 2008 at 04:56:04AM +0100, Kay Sievers (kay.sievers@vrfy.org) wrote: > I was able to reproduce it with the .config you attached, and running it in kvm. > > It is caused by: > "modprobe cryptomgr" called from swapper[1] > > This modprobe process does try to log an error, accesses /dev/console, > which is not initialized in the kernel at that time, and the kernel > module loader tries the load a module to support dev_t 5:1, which > again runs modprobe, and ... > > Setting CONFIG_CRYPTO_MANAGER=y makes it disapper. The patch I sent > seems to fix it. Great to know it works. I will test it when get access to the machine after the weekend. > The bug is handled here: http://bugzilla.kernel.org/show_bug.cgi?id=12153 There is a good point in the thread, that hotplug should not call recursion, but while this may be very valid requirement, it is _very_ subtle, and something more solid should be done. Just an opinion. Initialization reordering is likely also not what we want, but simple dumb console (or just dummy device which will accept data and will be replaced later) sounds like a way to go, and your patch seems to allow that dumb class registration first. I actually used to believe that it works that way already... -- Evgeniy Polyakov -- 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/