Most recent kernel where this bug did not occur: unknown Distribution: mainline Hardware Environment: irrelevant Software Environment: 2.6.23-rc3 Problem Description: slub memory allocation with GFP_DMA and without __GFP_WAIT can fail even if there is enough memory because of trying to acquire a semaphore only once. Steps to reproduce: try to allocate memory with GFP_DMA and without __GFP_WAIT when some other thread is holding the slub semaphore. Bug 8790's Attachment 12368 [details]'s patch is buggy because function dma_cache_add_func does not disable interrupts before acquiring the spin lock and function dma_kmalloc_cache can spin forever trying to acquire the spin lock if called from interrupt context.
This is restricted only to kmalloc allocations using GFP_ATOMIC and GFP_DMA. It is not a general issue with slabs. And it only can occur the first time a certain size of the dma kmalloc array is used. As already explained in Bug 8790: GFP_ATOMIC/GFP_DMA kmallocsare retried. Holding the slub_lock is restricted to short time periods during slab creation/removal and cpu hotplug events. Its unlikely to occur and there is no report that indicates that is a problem. Andi Kleen is in the process of removing all dma slab users from the kernel. We may remove support for dma kmalloc slabs entirely.
What's the status on this, has it caused any problems to you Matti?
It has not caused any errors to me as far as I know. I found out about the problem through code inspection.
Since the problem is recognized and is being addressed by the redesign that is explained in #1 by Christoph I am changing status to "fix later".