Tang Rui wrote: > Hi, > > Could anyone help me to analyse the following issue? I just > understand that during atomic operation my driver might call some > methods that can cause scheduling. > > I don't know where the problem is. Could anyone help me to figure it > out? > It's not allowd to call schedule when in this case. When you grabbed a spinlock, preemption is disabled. Then you call schedule, now another process may grab that same spinlock, resulting in deadlock. So you can release the lock, and then call schedule, and then grab the lock again. > > > BUG: scheduling while atomic: ird.out/0x00000001/734 > > > > Call trace: > > [<8468e4b0>] __switch_to_end+0x526/0x556 > > [<84437000>] hrtimer_cancel+0x0/0x20 > > [<8468faa4>] do_nanosleep+0x84/0xc0 > > [<844376da>] ktime_get_ts+0x1a/0x60 > > [<84437066>] enqueue_hrtimer+0x46/0x80 > > [<844372ae>] hrtimer_start+0x4e/0x120 > > [<8468faa4>] do_nanosleep+0x84/0xc0 > > [<84437260>] hrtimer_start+0x0/0x120 > > [<8468dc40>] schedule+0x0/0x314 > > [<84437000>] hrtimer_cancel+0x0/0x20 > > [<8443742c>] hrtimer_nanosleep+0x2c/0x140 > > [<84436ec0>] hrtimer_wakeup+0x0/0x20 > > [<844375ac>] sys_nanosleep+0x6c/0x80 > > [<8440519c>] syscall_call+0xc/0x10 > > [<84437540>] sys_nanosleep+0x0/0x80 > > -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
