On Wed, 12 May 2010 09:17:09 +1000 Dave Airlie <airlied@xxxxxxxxx> 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel