Is it safe to call wake_up() from interrupt context? - Embedded

This is a discussion on Is it safe to call wake_up() from interrupt context? - Embedded ; Hi All, Is it safe to call wake_up function from interrupt context in bottom half ? Actually I am trying to do something like this : //This function is called from the process context fn_in_process_context () { //some code here ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Is it safe to call wake_up() from interrupt context?

  1. Is it safe to call wake_up() from interrupt context?

    Hi All,

    Is it safe to call wake_up function from interrupt context in bottom
    half ?
    Actually I am trying to do something like this :

    //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
    }


    Is this piece of code looks OK or is it possible that wake_up() will
    somehow call the schedule in some cases?


  2. Re: Is it safe to call wake_up() from interrupt context?

    grv.aggarwal@gmail.com wrote:
    > Is it safe to call wake_up function from interrupt context in bottom
    > half ?


    Yes. This is one of the main usage patterns pf wake_up().

    regards

    Wolfgang


  3. Re: Is it safe to call wake_up() from interrupt context?

    Wolfgang Mes wrote:
    > grv.aggarwal@gmail.com wrote:
    > > Is it safe to call wake_up function from interrupt context in bottom
    > > half ?

    >
    > Yes. This is one of the main usage patterns pf wake_up().
    >
    > regards
    >
    > Wolfgang


    I am using this in my sample driver but sometimes it gives me an error
    "Scheduling while atomic" . Below is the call trace that I was getting
    at my end:

    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

    I am running my driver on 2.6.14 kernel on MIPS architecture. Then what
    is the possible reason of this error if wake_up() is not the culprit
    here?


  4. Re: Is it safe to call wake_up() from interrupt context?

    > wait_event (queue, in_use==0);

    "Linux Device drivers" says "wait_event_interruptible() is preferred
    over wait_event()".

    -Michael

  5. Re: Is it safe to call wake_up() from interrupt context?


    Michael Schnell wrote:
    > > wait_event (queue, in_use==0);

    >
    > "Linux Device drivers" says "wait_event_interruptible() is preferred
    > over wait_event()".
    >
    > -Michael


    But I don't think that this is creating the problem here as this is
    called from the process context. I used the wait_event() function so
    that spurious signals will not wake up my process.


  6. Re: Is it safe to call wake_up() from interrupt context?

    Hi,

    You got the message "schedule while atomic". That means you may use
    some
    functions to involve the schedule call in your interrupt context. For
    example,
    sleep_on, etc. Copy_to_user, etc. You need check your code again and
    make no
    such functions existing in the interrupt contxt. You know, the schedule
    function will be called after the end of interrupt.

    Take care

    Gaurav wrote:
    > Michael Schnell wrote:
    > > > wait_event (queue, in_use==0);

    > >
    > > "Linux Device drivers" says "wait_event_interruptible() is preferred
    > > over wait_event()".
    > >
    > > -Michael

    >
    > But I don't think that this is creating the problem here as this is
    > called from the process context. I used the wait_event() function so
    > that spurious signals will not wake up my process.



+ Reply to Thread