Hi Kai, On Thu, Nov 10, 2011 at 10:14 AM, Kai Meyer <kai@xxxxxxxxxx> wrote: > I think I get it. I'm hitting the scheduling while atomic because I'm > calling my function from a struct bio's endio function, which is > probably running with a lock held somewhere else, and then my mutex > sleeps, while the spin_lock functions do not sleep. Actually, just holding a lock doesn't create an atomic context. Disabling interrupts, and maybe disabling preemption will create atomic contexts. An atomic context is basically a context where you're not allowed to call blocking functions. Use of spinlocks is pretty much your only option in this scenario (unless of course you can somehow do what you want outside of the atomic context). > Perhaps I need to learn more about the context in which my endio > function is being called. I think so. I haven't written any block drivers, so I'm not familiar with all the gory details. What the errors you're getting tell me is that you function is sometimes called from an atomic context. This means that you shouldn't be calling kmalloc, unless you use the GFP_ATOMIC option, and you need to be prepared to deal with getting a NULL pointer back (which doesn't necessarily mean that you've run out of memory, just that you would have to block in order to allocate the memory). Generally speaking, at least with character drivers, I try to all of my allocations while I'm in thread context (like during an open or ioctl call). -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
