From: Andrew Morton on 11 May 2010 19:30 On Wed, 12 May 2010 09:17:09 +1000 Dave Airlie <airlied(a)gmail.com> wrote: > >> >> and > >> >> this codepath is called from non-irq contexts just as much as irq > >> >> contexts. > >> > > >> > That's fine. __As long as we do a local_irq_disable(), KM_IRQ0 can be > >> > used from both irq- and non-irq contexts. __All we need to do is to > >> > ensure that some interrupt cannot come along on this CPU and corrupt > >> > the slot. > >> > >> I don't think we do that in a lot of places, and I'd rather not add > >> that in to fix this problem at this point in the release cycle, as > >> we've no idea what it might break/regress. > > > > What is "that"? __The switch to irq-protected KM_IRQ0? __That won't break > > anything. > > > > disabling local cpu irqs around all these kmap mappings. > Ah. Well if there are other uses of KM_USER0 from interrupt context then yes, we have more problems. CONFIG_DEBUG_HIGHMEM && CONFIG_TRACE_IRQFLAGS_SUPPORT will detect that and as long as Jaswinder has hit all code paths in his testing, we're good. Some manual review for this would be good. -- 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/ |