[lkml]   [2003]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Debug: sleeping function called from invalid context
    > "Randy.Dunlap" <> 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]

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:47    [W:0.021 / U:33.868 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site