memory allocation in spinlock context

[Alfred Perlstein]

On 3/1/13 5:50 AM, Andriy Gapon wrote:
> I am trying to understand if it is possible to allow memory allocations (M_NOWAIT,
> of course) in a spinlock context.
> I do not see any obvious architectural obstacles.
> But the fact that all of the uma locks, system map lock, object locks, page queue
> locks and so on are regular mutexes makes it impossible to allocate memory without
> violating the fundamental lock ordering rules.
>
> Could all of the above mentioned locks potentially be converted to spin mutexes?
> (And that seems to be a large nasty change)
> Are there any alternative possibilities?
>
> BTW, currently we have at least one place where a memory allocation of this kind
> is done stealthily (and thus dangerously?).  ACPI resume code must execute
> AcpiLeaveSleepStatePrep with interrupts disabled and ACPICA code performs memory
> allocations in that code path.  Since the interrupts are disabled by means of
> intr_disable(), witness(9) and similar are completely oblivious of the fact.
>
Typically the need for such a facility means that the locks are being 
held for too long.

I think someone has suggested using a private allocator carving out of a 
pre-allocated space.

Depending on the subsystem you are allocating for this may work for you.

I am looking to do this for the kernel gzip routines so that we can do 
compressed kernel dumps as soon as I verify the bounds of the gzip 
allocations.

-Alfred