Re: Debug: sleeping function called from invalid context

Randy.Dunlap
2003-08-19T03:39:34Z

> "Randy.Dunlap" <rddunlap@osdl.org> wrote:
>>
>> Debug: sleeping function called with interrupts disabled at
>> include/asm/uaccess.h:473
>
> OK, now my vague understanding of what's going on is that the app has chosen
> to disable local interupts (via iopl()) and has taken a vm86 trap. I guess
> we'd see the same thing if the app performed some sleeping syscall while
> interrupts are disabled.
>
> If that is correct then it really is just a false positive.
>
> It could also point at a bug in the application; it is presumably disabling
> interrupts for some form of locking, atomicity or timing guarantee. But it
> will not lock against other CPUs and the fact that it trapped into the
> kernel indicates tat it may not be getting the atomicity which it desires.

Call Trace:
[<c0120d93>] __might_sleep+0x53/0x74
[<c010d001>] save_v86_state+0x71/0x1f0
[<c010dbd5>] handle_vm86_fault+0xc5/0xa90
[<c019cac8>] ext3_file_write+0x28/0xc0
[<c011cd96>] __change_page_attr+0x26/0x220
[<c010b310>] do_general_protection+0x0/0x90
[<c010a69d>] error_code+0x2d/0x40
[<c0109657>] syscall_call+0x7/0xb

My (more) vague understanding is that X(?) got the kernel to
do_general_protection() somehow, but change_page_attr() does this:
spin_lock_irqsave(&cpa_lock, flags);
in arch/i386/mm/pageattr.c (I'm on a UP box),
so irqs are disabled by the kernel and then we calls put_user()
with a spinlock held.

~Randy [betting I understand it less than Andrew]