start_kernel(): bug: interrupts were enabled early
in [Kernel]
|
From: Andrew Morton on 31 Mar 2010 21:30 On Thu, 01 Apr 2010 12:17:11 +1100 Benjamin Herrenschmidt <benh(a)kernel.crashing.org> wrote: > On Wed, 2010-03-31 at 15:49 -0700, Andrew Morton wrote: > > > > But these things are all utterly gross. The bottom line is that > > radix_tree_init() is manifestly unsuited to being called with local > > interrupts disabled. 773e3eb7b81e5ba13b5155dfb3bb75b8ce37f8f9 was > > just a wrong patch. > > Except that powerpc (and now it seems x86) both want to use radix trees > for interrupt handling... At least on powerpc, we trick and use a linear > search until the radix trees are initialized, which we do later during > boot, but that somewhat sucks. > > I believe sherry picking things like not calling radix_tree_init() is > going to fix one case today, until we have another one, and another one, > and etc... > > I suspect we're better off fixing the root of the problem in down/up. > Not by adding overhead to every single down_read()/down_write() just to fix a once-off startup problem - that's taking laziness way too far. We'd be better off hacking a kmem_cache_create() special case to avoid taking the rwsem. Add SLAB_I_SUCK to `flags' perhaps. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 1 Apr 2010 02:40 On 03/31/2010 03:26 PM, Andrew Morton wrote: > > Not by adding overhead to every single down_read()/down_write() just to > fix a once-off startup problem - that's taking laziness way too far. > How much overhead is this on non-x86 architectures (keep in mind x86 doesn't use this?) -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Morton on 1 Apr 2010 02:40 On Wed, 31 Mar 2010 23:26:52 -0700 "H. Peter Anvin" <hpa(a)zytor.com> wrote: > On 03/31/2010 03:26 PM, Andrew Morton wrote: > > > > Not by adding overhead to every single down_read()/down_write() just to > > fix a once-off startup problem - that's taking laziness way too far. > > > > How much overhead is this on non-x86 architectures (keep in mind x86 > doesn't use this?) > Just a few instructions, I guess. But we can do it with zero. And from a design POV, pretending that down_read()/down_write() can be called with interrupts disabled is daft - they cannot! Why muck up the usual code paths with this startup-specific hack? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Benjamin Herrenschmidt on 1 Apr 2010 03:00 On Wed, 2010-03-31 at 23:33 -0400, Andrew Morton wrote: > Just a few instructions, I guess. But we can do it with zero. > > And from a design POV, pretending that down_read()/down_write() can be > called with interrupts disabled is daft - they cannot! Why muck up > the > usual code paths with this startup-specific hack? Because we the problem of when interrupts are enabled for the first time is a nasty one, and having entire layer of things not usable at the right level of init because somewhere something might do an irq enable due to calling generic code that down's a semaphore is a PITA. Seriously, Andrew, I don't see a clean solution... Something -somewhere- will have to be ugly. Allocation is a pretty basic service that a lot of stuff expect especially when booting. We went through that discussion before when we moved the SLAB init earlier during boot, because it makes no sense to have tons of code to have to figure out what allocator to call depending on what phase of the moon it's called from (especially when said code can also be called later during boot, say for hotplug reasons). So we moved sl*b init earlier, thus we ought to be able to also kmem_cache_alloc() earlier. We -fixed- that problem already afaik. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Benjamin Herrenschmidt on 1 Apr 2010 04:00
On Wed, 2010-03-31 at 23:26 -0700, H. Peter Anvin wrote: > On 03/31/2010 03:26 PM, Andrew Morton wrote: > > > > Not by adding overhead to every single down_read()/down_write() just to > > fix a once-off startup problem - that's taking laziness way too far. > > > > How much overhead is this on non-x86 architectures (keep in mind x86 > doesn't use this?) None on powerpc, we use atomic ops and don't disable IRQs. BTW. The same problem used to happen with mutex debug. Was this ever fixed ? Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |