On 03/31/2010 11:48 PM, Benjamin Herrenschmidt wrote: > 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. I would like to point out that initialization is a particular subcase of a more general rule: - It is safe to call a semaphore/rwlock down with IRQ disabled *if and only if* the caller can guarantee non-contention. Initialization is an obvious subcase, but there might be others. -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-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html