in_atomic doesn't count local_irq_disable?

in_atomic doesn't count local_irq_disable?

[Srivatsa Vaddagiri]

Hi,
	I am getting messages like:

 "Debug: sleeping function called from invalid context at include/linux/rwsem.h:45"
 "in_atomic: 0, irqs_disabled(): 1"

while running some (CPU Hotplug) tests against (2.6.0-test11-bk6 + the CPU hotplug patch).

This is basically because down_read was called with interrupts disabled ..
__might_sleep was "unable" to dump the stack of callers which 
lead to this problem ..

I put some debug code in down_read (an inline function) and found
that down_read was actually called from do_page_fault.

do_page_fault avoids calling this down_read if we are "in_atomic()"
Isn't in_atomic supposed to count IRQs disabled case? If not
then shouldn't do_page_fault also check for irqs_disabled() 
before calling down_read()?

Please let me know what I am missing here!


-- 


Thanks and Regards,
Srivatsa Vaddagiri,
Linux Technology Center,
IBM Software Labs,
Bangalore, INDIA - 560033

Re: in_atomic doesn't count local_irq_disable?

[Srivatsa Vaddagiri]

FYI, I am running with preemption disabled ..

On Mon, Dec 29, 2003 at 07:03:36PM +0530, Srivatsa Vaddagiri wrote:
> Hi,
> 	I am getting messages like:
> 
>  "Debug: sleeping function called from invalid context at include/linux/rwsem.h:45"
>  "in_atomic: 0, irqs_disabled(): 1"
> 
> while running some (CPU Hotplug) tests against (2.6.0-test11-bk6 + the CPU hotplug patch).
> 
> This is basically because down_read was called with interrupts disabled ..
> __might_sleep was "unable" to dump the stack of callers which 
> lead to this problem ..
> 
> I put some debug code in down_read (an inline function) and found
> that down_read was actually called from do_page_fault.
> 
> do_page_fault avoids calling this down_read if we are "in_atomic()"
> Isn't in_atomic supposed to count IRQs disabled case? If not
> then shouldn't do_page_fault also check for irqs_disabled() 
> before calling down_read()?
> 
> Please let me know what I am missing here!
> 
> 
> -- 
> 
> 
> Thanks and Regards,
> Srivatsa Vaddagiri,
> Linux Technology Center,
> IBM Software Labs,
> Bangalore, INDIA - 560033

-- 


Thanks and Regards,
Srivatsa Vaddagiri,
Linux Technology Center,
IBM Software Labs,
Bangalore, INDIA - 560033

Re: in_atomic doesn't count local_irq_disable?

[Manfred Spraul]

Srivatsa Vaddagiri wrote:

>This is basically because down_read was called with interrupts disabled ..
>__might_sleep was "unable" to dump the stack of callers which 
>lead to this problem ..

What do you mean with unable? Could you post what was printed?

I guess it's a get_user within either spin_lock_irq() or local_irq_disable. Without more info about the context, it's difficult to figure out if the page fault handler or the caller should be updated
--
	Manfred

Re: in_atomic doesn't count local_irq_disable?

[Rusty Russell]

On Mon, 29 Dec 2003 19:03:36 +0530
Srivatsa Vaddagiri <vatsa@in.ibm.com> wrote:

> do_page_fault avoids calling this down_read if we are "in_atomic()"
> Isn't in_atomic supposed to count IRQs disabled case? If not
> then shouldn't do_page_fault also check for irqs_disabled() 
> before calling down_read()?

in_atomic() doesn't actually return true if irqs are disabled.

hence "(in_atomic() || irqs_disabled())" in __might_sleep.

do_page_fault should have the same test...

Thanks,
Rusty.
-- 
   there are those who do and those who hang on and you don't see too
   many doers quoting their contemporaries.  -- Larry McVoy

Re: in_atomic doesn't count local_irq_disable?

[Srivatsa Vaddagiri]

On Mon, Dec 29, 2003 at 04:13:38PM +0100, Manfred Spraul wrote:
> 
> What do you mean with unable? Could you post what was printed?

All I used to get was :

"Debug: sleeping function called from invalid context
at include/linux/rwsem.h:45
in_atomic: 0, irqs_disabled(): 1
Call Trace:"

That's it. Nothing more. Looks like it could not read the
stack at that point and hence couldn't dump the stack traceback.

I now inserted some printk's in do_page_fault
to print regs->eip before calling down_read i.e:

        /*
         * If we're in an interrupt, have no user context or are running in an
         * atomic region then we must not take the fault..
         */
        if (in_atomic() || !mm)
                goto bad_area_nosemaphore;

+       if (irqs_disabled()) {
+               printk("BAD Access at (EIP) %08lx\n", regs->eip);
+               printk("Bad Access at virtual address %08lx\n",address);
+       }

        down_read(&mm->mmap_sem);


This is what I got now when I reran my stress test:


BAD Access at (EIP) c011c1b5
Bad Access at virtual address 05050501
Debug: sleeping function called from invalid context at include/linux/rwsem.h:47
in_atomic():0, irqs_disabled():1
Call Trace:
 [<c011fd66>] __might_sleep+0x86/0x90
 [<c01378f6>] module_unload_free+0x36/0xe0
 [<c011b889>] do_page_fault+0xc9/0x573
 [<c013f1df>] buffered_rmqueue+0x10f/0x120
 [<c013f2ba>] __alloc_pages+0xca/0x360
 [<c0148d64>] do_anonymous_page+0x1c4/0x1d0
 [<c011b7c0>] do_page_fault+0x0/0x573
 [<c01378f6>] module_unload_free+0x36/0xe0
 [<c0109d6d>] error_code+0x2d/0x38
 [<01010101>] 

BAD Access at (EIP) c0139934
Bad Access at virtual address 0101011f


The first EIP (c011c1b5) is inside search_extable!!
The second EIP (c0139934) is inside get_ksymbol() ...

I suspect the second happened when kdb tried decoding the (first) exception
address and hence is secondary here ..

The stack trace that follows the first exception seems to be
totally bogus(?) .. I suspect the first exception 
happened in search_extable when looking up some module exception
tables(?) ..Because search_module_extables() calls search_extable() with 
interrupts disabled ..

I think this points to some module unload (race) issues during hotplug ..

Rusty, any comments?







> 
> I guess it's a get_user within either spin_lock_irq() or local_irq_disable. Without more info about the context, it's difficult to figure out if the page fault handler or the caller should be updated


Given the context above, I feel it would be correct for
do_page_fault() to avoid calling down_read() when IRQs are
disabled and instead just branch to bad_nosemaphore.
(as Rusty seems to concur) .. However, schedule() doesn't
seem to actually trap the case when it is called with interrupts disabled (as using local_irq_disable)?

-- 


Thanks and Regards,
Srivatsa Vaddagiri,
Linux Technology Center,
IBM Software Labs,
Bangalore, INDIA - 560033