From owner-freebsd-bugs@FreeBSD.ORG Sat Jan 7 15:20:06 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D0EE16A41F for ; Sat, 7 Jan 2006 15:20:06 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01B4343D46 for ; Sat, 7 Jan 2006 15:20:05 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k07FK5t6092094 for ; Sat, 7 Jan 2006 15:20:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k07FK58e092093; Sat, 7 Jan 2006 15:20:05 GMT (envelope-from gnats) Date: Sat, 7 Jan 2006 15:20:05 GMT Message-Id: <200601071520.k07FK58e092093@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Mark Tinguely Cc: Subject: Re: kern/78179: bus_dmamem_alloc() with BUS_DMA_NOWAIT can block X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Tinguely List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2006 15:20:06 -0000 The following reply was made to PR kern/78179; it has been noted by GNATS. From: Mark Tinguely To: PeterJeremy@optushome.com.au, tinguely@casselton.net Cc: bug-followup@freebsd.org Subject: Re: kern/78179: bus_dmamem_alloc() with BUS_DMA_NOWAIT can block Date: Sat, 7 Jan 2006 09:15:08 -0600 (CST) Strange that the following added test in vm_contig_launder_page() did not trigger in the kernel_object case: if (m->dirty) { + /* Both paths use vm_pageout_flush() which forces + * a syncronous putpage for the kernel_object. + */ + if (flags & M_NOWAIT && object == kernel_object) { ... Anyway, I think it was concluded that when contigmalloc() is called from an interrupt handler, we cannot launder the pages at all. It simplifies the patch considerably. A couple things to consider: 1) it is wise for a driver to be requesting more than a page at interrupt time? It is a recipe for failure on busy machines. wouldn't it be better that the driver use some kind of UMA? This really a side issue and does not fix the error. 2) as mentioned before, many other callers to contigmalloc() that set NOWAIT, really expect laundering and waiting a brief amount of time. Many of these callers do not check for the allocation failure case. Most are allocating memory on device initialization and are not in their interrupt handlers. These issue have to be fixed or else we will actually be increasing the number of panics. --Mark Tinguely.