Re: 2.5.39, SMP, pre-empt: snd_ctl_iotcl 'sleeping function called from

Andrew Morton (akpm@digeo.com)
Sat, 28 Sep 2002 22:05:11 -0700


Jurriaan wrote:
>
> Sleeping function called from illegal context at slab.c:1374
> f6b6fbfc c0118554 c02df2e0 c02e3d90 0000055e f7b32390 c0135dd3 c02e3d90
> 0000055e 0000004c f7bafe08 f6b6fcec f7b32390 00000002 c1b0f3f0 c0254345
> 0000004c 000001d0 f7b32360 f6b6fcec c0255903 0000004c 000001d0 bffff628
> Call Trace:
> [<c0118554>]__might_sleep+0x54/0x58
> [<c0135dd3>]kmalloc+0x5b/0x1d4
> [<c0254345>]snd_kcalloc+0x11/0x38
> [<c0255903>]snd_ctl_notify+0xf3/0x1c0
> [<c02567f2>]snd_ctl_elem_write+0x17a/0x230
> [<c0256ce1>]snd_ctl_ioctl+0x175/0x310
> [<c01544e9>]sys_ioctl+0x28d/0x2dc
> [<c0107c5d>]error_code+0x2d/0x38
> [<c01071fb>]syscall_call+0x7/0xb
>
> This is with an EMU10K1 card, and the ALSA drivers in the kernel.
>

snd_ctl_elem_write() calls snd_ctl_notify() under
read_lock(&card->control_rwlock);

But snd_ctl_notify() does a GFP_KERNEL allocation.

Also, snd_ctl_notify() does read_lock_irqsave(&card->control_rwlock, flags);
even though the caller has already taken a read_lock on that lock.
It is not legal to take a read_lock twice in this manner. Because
if another CPU comes in and asks for a write_lock in that window,
deadlock. (I think - there's been some talk about changing the
rwlock implementation so that nested read_locks are safe).

Also, snd_ctl_notify() is performing a GFP_KERNEL allocation
inside spin_lock(&ctl->read_lock);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/