asklet_action is called for handling tasklets that have already been scheduled. So for these tasklets t->state should have TASKLET_STATE_SCHED bit set.
In line 404, test_and_clear_bit clears TASKLET_STATE_SCHED bit and returns the old value of that bit. If it returns 0, that means a bug, so it calls BUG() handler. Otherwise it skips line 405 and calls tasklet handler. - Meraj ----- Original Message ---- From: Tony Mouawad <[EMAIL PROTECTED]> To: kernelnewbies <[email protected]> Sent: Monday, October 22, 2007 5:19:05 PM Subject: tasklet_action() failure Hello, I'm trying to get a handle on a problem that is occuring inside of a call to tasklet_action(). Can someone explain a bit about what line 404 is doing ( and the function itself ) in the following code? It seems that the OS is intermittently resulting in a false result on line 404 and then executing line 405 which ultimately halts the kernel. Regards, Tony 388 static void tasklet_action(struct softirq_action *a) 389 { 390 struct tasklet_struct *list; 391 392 local_irq_disable(); 393 list = __get_cpu_var(tasklet_vec).list; 394 __get_cpu_var(tasklet_vec).list = NULL; 395 local_irq_enable(); 396 397 while (list) { 398 struct tasklet_struct *t = list; 399 400 list = list->next; 401 402 if (tasklet_trylock(t)) { 403 if (!atomic_read(&t->count)) { 404 if (!test_and_clear_bit(TASKLET_STATE_SCHED, &t->state)) 405 BUG(); 406 t->func(t->data); 407 tasklet_unlock(t); 408 continue; 409 } 410 tasklet_unlock(t); 411 } 412 413 local_irq_disable(); 414 t->next = __get_cpu_var(tasklet_vec).list; 415 __get_cpu_var(tasklet_vec).list = t; 416 __raise_softirq_irqoff(TASKLET_SOFTIRQ); 417 local_irq_enable(); 418 } 419 } -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to [EMAIL PROTECTED] Please read the FAQ at http://kernelnewbies.org/FAQ __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
