illegal instructions / irqs disabled warning

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 1832 bytes --]

So I run across this warning: 
[ 2724.595549] Debug: sleeping function called from invalid context at arch/ppc/kernel/traps.c:528
[ 2724.595563] in_atomic():0, irqs_disabled():1
[ 2724.595568] Call trace:
[ 2724.595573]  [c001fe54] __might_sleep+0xd4/0xf0
[ 2724.595592]  [c0005ad8] program_check_exception+0xb8/0x520
[ 2724.595606]  [c0004f04] ret_from_except_full+0x0/0x4c

when I wrote a program calling illegal instructions. I then checked out
why this happened and the cause is the might_sleep() here:

#define __get_user_check(x, ptr, size)                                  \
({                                                                      \
        long __gu_err = -EFAULT;                                        \
        unsigned long  __gu_val = 0;                                    \
        const __typeof__(*(ptr)) __user *__gu_addr = (ptr);             \
        might_sleep();                                                  \
...

I then figured I could use __copy_from_user_inatomic to access the
instruction word to fix this (as far as I can tell only the warning is
annoying, because the instruction already failed at that point so it
must be in memory, right?)

But here's the actual question:
static inline unsigned long __copy_from_user(void *to,
                const void __user *from, unsigned long size)
{
        might_sleep();
        return __copy_from_user_inatomic(to, from, size);
}

Does that mean __copy_from_user_inatomic isn't actually valid to call in
atomic context? Or is this only so that kernel developers that use
powerpc see the bugs their code would have on other platforms? The magic
in get_user_asm thoroughly confuses me.

[Somehow I got sidetracked. I only wanted to look at implementing
backtrace support for oprofile...]

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]