BUG: scheduling while atomic

[Dave Hylands]

Hi Arun,

On Wed, Apr 18, 2012 at 1:08 AM, Arun KS <getarunks at gmail.com> wrote:
> Hi Dave,
>
> Thanks for your reply.
>
> On Wed, Apr 18, 2012 at 1:01 PM, Dave Hylands <dhylands at gmail.com> wrote:
>>
>> Hi Arun,
>>
>> On Tue, Apr 17, 2012 at 11:44 PM, Arun KS <getarunks at gmail.com> wrote:
>> >
>> > Hello Guys,
>> >
>> > System is working normal after this BUG.
>> > PC is at 0x400b4614, probably a mmaped address.
>> >
>> > Just wondering how can this BUG happen when a process is running in user
>> > space.
>> >
>> > Can it be something like this
>> > 1) enter to kernel from userspace through some system call.
>> > 2) kernel disables the interrupt and return to user space.
>>
>> Don't do that
>
>
> I don't do that. This scenario mentioned is a just a wild guess.
>>
>>
>> > 3) and now it can happen in user space?
>>
>> Because something in userspace made a blocking call which would cause
>> a context switch to occur and your driver erroneously left interrupts
>> disabled.
>
> In that case, my system should have been unstable afterwards if interrupts
> are left disabled. But that is not happening.
>
> If we return to user space with interrupts disabled, can we switch back
> again to kernel using a system cal(because interrupts are already disabled)?

As long as you don't do anything which would need to block.

A buggy driver could also interrupt user-code (hardware interrupt) and
disable interrupts and not re-enable them.

-- 
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com