From owner-freebsd-hackers@FreeBSD.ORG  Fri Mar  1 13:50:31 2013
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@FreeBSD.org
Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115])
 by hub.freebsd.org (Postfix) with ESMTP id 2E657D7A
 for <freebsd-hackers@FreeBSD.org>; Fri,  1 Mar 2013 13:50:31 +0000 (UTC)
 (envelope-from avg@FreeBSD.org)
Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140])
 by mx1.freebsd.org (Postfix) with ESMTP id 75CC0E62
 for <freebsd-hackers@FreeBSD.org>; Fri,  1 Mar 2013 13:50:30 +0000 (UTC)
Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua
 [212.40.38.101])
 by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA09155
 for <freebsd-hackers@freebsd.org>; Fri, 01 Mar 2013 15:50:28 +0200 (EET)
 (envelope-from avg@FreeBSD.org)
Message-ID: <5130B224.8000600@FreeBSD.org>
Date: Fri, 01 Mar 2013 15:50:28 +0200
From: Andriy Gapon <avg@FreeBSD.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
 rv:17.0) Gecko/20130220 Thunderbird/17.0.3
MIME-Version: 1.0
To: freebsd-hackers <freebsd-hackers@FreeBSD.org>
Subject: memory allocation in spinlock context
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Mar 2013 13:50:31 -0000


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.

-- 
Andriy Gapon