Date: Sat, 7 Jan 2006 15:20:05 GMT From: Mark Tinguely <tinguely@casselton.net> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/78179: bus_dmamem_alloc() with BUS_DMA_NOWAIT can block Message-ID: <200601071520.k07FK58e092093@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/78179; it has been noted by GNATS. From: Mark Tinguely <tinguely@casselton.net> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200601071520.k07FK58e092093>