ERROR: scheduling while atomic in kernel module - Linux

This is a discussion on ERROR: scheduling while atomic in kernel module - Linux ; Hi All, I am getting an error "Scheduling while atomic" very infrequently on Linux 2.6.14 kernel on MIPS architecture with this piece of my kernel module (Mymodule.ko) . My kernel module codes look like : //This function is called from ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: ERROR: scheduling while atomic in kernel module

  1. ERROR: scheduling while atomic in kernel module

    Hi All,

    I am getting an error "Scheduling while atomic" very infrequently on
    Linux 2.6.14 kernel on MIPS architecture with this piece of my kernel
    module (Mymodule.ko) . My kernel module codes look like :

    //This function is called from the process context
    fn_in_process_context ()
    {
    //some code here
    in_use = 1;
    wait_event (queue, in_use==0);
    //some more code
    }

    //This function is called from the interrupt context.....in bottom half
    callback_fn_in_interrupt_context()
    {
    //some code here
    in_use = 0;
    wake_up (queue);
    //some more code
    }

    and the call stack looks like :

    scheduling while atomic: mymodule/0xffffff00/564

    Call Trace:

    [<803fc3c0>] schedule+0x74/0x980
    [<8011cbec>] __wake_up+0x34/0x64
    [<803fc34c>] schedule+0x0/0x980
    [<80138548>] prepare_to_wait+0x0/0x7c
    [] fn_in_process_context+0x32c/0x578 [mymodule]
    [<80126510>] irq_exit+0x40/0x4c
    [<80126348>] __do_softirq+0x68/0xec
    [<801386a8>] autoremove_wake_function+0x0/0x44
    [<802be1e4>] __copy_user+0x0/0x1c
    [<801386a8>] autoremove_wake_function+0x0/0x44
    [<801386a8>] autoremove_wake_function+0x0/0x44

    Is the wake_up() function somehow calls the schedule() ?? Is it safe to
    call wake_up from interrupt context?
    Or there is something else that is responsible for this error ??


  2. Re: ERROR: scheduling while atomic in kernel module


    grv.aggarwal@gmail.com wrote:

    > Hi All,
    >
    > I am getting an error "Scheduling while atomic" very infrequently on
    > Linux 2.6.14 kernel on MIPS architecture with this piece of my kernel
    > module (Mymodule.ko) . My kernel module codes look like :
    >
    > //This function is called from the process context
    > fn_in_process_context ()
    > {
    > //some code here
    > in_use = 1;
    > wait_event (queue, in_use==0);
    > //some more code
    > }
    >
    > //This function is called from the interrupt context.....in bottom half
    > callback_fn_in_interrupt_context()
    > {
    > //some code here
    > in_use = 0;
    > wake_up (queue);
    > //some more code
    > }
    >
    > and the call stack looks like :
    >
    > scheduling while atomic: mymodule/0xffffff00/564
    >
    > Call Trace:
    >
    > [<803fc3c0>] schedule+0x74/0x980
    > [<8011cbec>] __wake_up+0x34/0x64
    > [<803fc34c>] schedule+0x0/0x980
    > [<80138548>] prepare_to_wait+0x0/0x7c
    > [] fn_in_process_context+0x32c/0x578 [mymodule]
    > [<80126510>] irq_exit+0x40/0x4c
    > [<80126348>] __do_softirq+0x68/0xec
    > [<801386a8>] autoremove_wake_function+0x0/0x44
    > [<802be1e4>] __copy_user+0x0/0x1c
    > [<801386a8>] autoremove_wake_function+0x0/0x44
    > [<801386a8>] autoremove_wake_function+0x0/0x44
    >
    > Is the wake_up() function somehow calls the schedule() ?? Is it safe to
    > call wake_up from interrupt context?


    wake_up(): When any process is finished using a resource for which
    there is a wait_queue, it should wake up and processes that might be
    sleeping on that wait_queue ny wake_up()

    Further, interrupt handlers are not schedulable so they too are atomic.
    In other words, not willing to be scheduled.

    > Or there is something else that is responsible for this error ??

    I think you are scheduling in interrupt context whichi is causing
    error.

    see this.
    http://www.linuxjournal.com/article/8144
    http://kerneltrap.org/node/435


  3. Re: ERROR: scheduling while atomic in kernel module


    grv.aggarwal@gmail.com wrote:

    > Hi All,
    >
    > I am getting an error "Scheduling while atomic" very infrequently on
    > Linux 2.6.14 kernel on MIPS architecture with this piece of my kernel
    > module (Mymodule.ko) . My kernel module codes look like :
    >
    > //This function is called from the process context
    > fn_in_process_context ()
    > {
    > //some code here
    > in_use = 1;
    > wait_event (queue, in_use==0);
    > //some more code
    > }
    >
    > //This function is called from the interrupt context.....in bottom half
    > callback_fn_in_interrupt_context()
    > {
    > //some code here
    > in_use = 0;
    > wake_up (queue);
    > //some more code
    > }
    >
    > and the call stack looks like :
    >
    > scheduling while atomic: mymodule/0xffffff00/564
    >
    > Call Trace:
    >
    > [<803fc3c0>] schedule+0x74/0x980

    see here. schedule is being called from wake_up()
    > [<8011cbec>] __wake_up+0x34/0x64
    > [<803fc34c>] schedule+0x0/0x980
    > [<80138548>] prepare_to_wait+0x0/0x7c
    > [] fn_in_process_context+0x32c/0x578 [mymodule]
    > [<80126510>] irq_exit+0x40/0x4c
    > [<80126348>] __do_softirq+0x68/0xec
    > [<801386a8>] autoremove_wake_function+0x0/0x44
    > [<802be1e4>] __copy_user+0x0/0x1c
    > [<801386a8>] autoremove_wake_function+0x0/0x44
    > [<801386a8>] autoremove_wake_function+0x0/0x44
    >
    > Is the wake_up() function somehow calls the schedule() ??

    Is it safe to
    > call wake_up from interrupt context?
    > Or there is something else that is responsible for this error ??



  4. Re: ERROR: scheduling while atomic in kernel module

    grv.aggarwal@gmail.com wrote:
    > I am getting an error "Scheduling while atomic" very infrequently on
    > Linux 2.6.14 kernel on MIPS architecture with this piece of my kernel
    > module (Mymodule.ko) . My kernel module codes look like :
    >
    > //This function is called from the process context
    > fn_in_process_context ()
    > {
    > //some code here
    > in_use = 1;
    > wait_event (queue, in_use==0);
    > //some more code
    > }
    >
    > //This function is called from the interrupt context.....in bottom half
    > callback_fn_in_interrupt_context()
    > {
    > //some code here
    > in_use = 0;
    > wake_up (queue);
    > //some more code
    > }

    [snip]
    > Is the wake_up() function somehow calls the schedule() ?? Is it safe to
    > call wake_up from interrupt context?
    > Or there is something else that is responsible for this error ??


    Yes it's safe to call wake_up from interrupt context, and it does not
    call schedule.

    Given your code, it seems likely that something else if going on here.
    Bear in mind that (especially with optimized code) you don't
    necessarily see a coherent call stack trace. The stack trace function
    in the kernel basically just scans the kernel stack area looking for
    any value that appears to be a valid kernel text address. You can't
    really rely on it for more than a general idea as to which functions
    have been called lately (except for the top-most entry which is pretty
    reliable).

    For example, there may well have been a previous interrupt or previous
    process context call hierarchy that may have left a number of kernel
    return addresses sitting in stack memory. If those stack locations are
    subsequently re-used for local variables that may not be initialized in
    some code paths, those addresses will still be sitting in memory and
    will show up in the stack "trace".

    I would look at the "Some code here" and "Some more code" places in
    your bottom-half function to see if there's some other path that might
    be calling schedule.

    GH


  5. Re: ERROR: scheduling while atomic in kernel module


    gil_hamilton@hotmail.com wrote:
    > grv.aggarwal@gmail.com wrote:
    > > I am getting an error "Scheduling while atomic" very infrequently on
    > > Linux 2.6.14 kernel on MIPS architecture with this piece of my kernel
    > > module (Mymodule.ko) . My kernel module codes look like :
    > >
    > > //This function is called from the process context
    > > fn_in_process_context ()
    > > {
    > > //some code here
    > > in_use = 1;
    > > wait_event (queue, in_use==0);
    > > //some more code
    > > }
    > >
    > > //This function is called from the interrupt context.....in bottom half
    > > callback_fn_in_interrupt_context()
    > > {
    > > //some code here
    > > in_use = 0;
    > > wake_up (queue);
    > > //some more code
    > > }

    > [snip]
    > > Is the wake_up() function somehow calls the schedule() ?? Is it safe to
    > > call wake_up from interrupt context?
    > > Or there is something else that is responsible for this error ??

    >
    > Yes it's safe to call wake_up from interrupt context, and it does not
    > call schedule.
    >
    > Given your code, it seems likely that something else if going on here.
    > Bear in mind that (especially with optimized code) you don't
    > necessarily see a coherent call stack trace. The stack trace function
    > in the kernel basically just scans the kernel stack area looking for
    > any value that appears to be a valid kernel text address. You can't
    > really rely on it for more than a general idea as to which functions
    > have been called lately (except for the top-most entry which is pretty
    > reliable).
    >
    > For example, there may well have been a previous interrupt or previous
    > process context call hierarchy that may have left a number of kernel
    > return addresses sitting in stack memory. If those stack locations are
    > subsequently re-used for local variables that may not be initialized in
    > some code paths, those addresses will still be sitting in memory and
    > will show up in the stack "trace".
    >
    > I would look at the "Some code here" and "Some more code" places in
    > your bottom-half function to see if there's some other path that might
    > be calling schedule.
    >
    > GH


    The commented out code "Some code here" and "Some more code" is just
    lots of assignment to local variable. I must mention here that I got
    this error very infrequently (say 1 in 25 times) and only in MIPS
    architecture. I didn't see this error in x86 platform till this time.


+ Reply to Thread