Skip to contentSkip to conversation

calling schedule() from interupt context

DISCUSSION dan carpenter 2 participants 2 messages Nov 22, 2002

lore
Share & tools
lore

dan carpenter

author
#0 lore raw

From: Robert Love <[email protected]>

Quoted 5 lines · dan carpenter

(Next time trim your CC list: none of those poor guys needed this email..)

trimmed.

Quoted 11 lines
Quoted 7 lines

In drivers/net/tokenring/3c359.c xl_interrupt() calls schedule(). The path from xl_interupt to schedule is:
xl_rx ==> netif_rx ==>
kfree_skb ==> __kfree_skb ==>
secpath_put ==> __secpath_destroy ==>
xfrm_state_put ==> __xfrm_state_destroy ==> xfrm_put_type ==> module_put ==> put_cpu ==> preempt_schedule ==> schedule

Are you actually seeing this code path or is this just what your script is showing you?

ok. I'm an idiot.

The script only checks things at compile time not at runtime. So you are right, of course, that this couldn't happen in real life because of the preemp_count.

Thanks for the explanation...

regards,
dan carpenter

Signature · 6 lines
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

One click access to the Top Search Engines
http://www.exactsearchbar.com/mailcom
#1 lore raw
Quoted 5 lines · dan carpenter

ok. I'm an idiot.

The script only checks things at compile time not at runtime. So you are right, of course, that this couldn't happen in real life because of the preemp_count.

Still, neat scripts.

Statically searching code has a lot of applications that run-time checking does not have. For example, there _are_ a lot of things you do not want to call from interrupts: down(), kmalloc() without GFP_ATOMIC, etc. etc.

And could you get it to check for code paths that could possibly double-acquire the same lock?

etc. etc... be creative.

Quoted 1 line

Thanks for the explanation...

No problem.

Robert Love