Re: bus_dmamap_destroy no longer callable from interrupt context?

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Matt Thomas <matt%3am-software.com@localhost> wrote:
> 
> On Nov 15, 2013, at 10:56 AM, Lars Heidieker <lars%heidieker.de@localhost> 
> wrote:
> 
> > Matt, you mean allocating and freeing memory from softint context should
> > be ok? That's something that went through my mind as well and I think
> > it's the right way.
> 
> I do.  softint routines can wait for mutexes so allocation in them should
> be safe.  Adding the complexity of needing a "real" thread context to do
> safe allocations seems more prone to problems.

Software interrupts can already allocate memory either using kmem_intr_*(9)
or pool_cache(9) (the current diagnostic check ensures that it has the IPL
specified i.e. is not IPL_NONE).

Are you talking about KM_SLEEP/PR_WAITOK?  The implications of that are
very different.  Yes, the software interrupts can block on adaptive locks,
but *only* on them, based on the assumption that the locks will generally
not be very contended (if you have significant contention, especially with
locks involved in the interrupt processing, it is already preferable to
fix them).  Any longer blocking would have a negative impact on the system,
which can be be very significant.  This is quite fundamental.

-- 
Mindaugas