Spinlocks and interrupts

[Dave Hylands]

Hi Kai,

On Thu, Nov 10, 2011 at 10:14 AM, Kai Meyer <kai at gnukai.com> 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