I am a system engineer in a Chinese = software=20 development company, and currently I am implementing IPSec on Linux = version=20 2.2.16. Generally speaking, what I am doing is adding internet key = exchange and=20 IPsec processing functions into the Linux ip_queue_xmit, ip_build_xmit = and=20 ip_local_deliver procedures. After I have built up a new sk_buff = variable, I=20 send it off using my own function send_skbuff(), this is where the = problem=20 occurs. Following is the complete copy of the culprit:

iph =3D = skb->nh.iph;
=20 if(ip_route_output(&rt, iph->daddr,=20 iph->saddr,
IPTOS_LOWDELAY, 0))
    goto=20 drop;
skb->dst =3D dst_clone(&rt->u.dst);
=20 skb->priority =3D TC_PRIO_FILLER;
if=20 (skb_cloned(skb))
    skb =3D skb_copy(skb,=20 GFP_ATOMIC);
else
    skb =3D skb_clone(skb, = GFP_ATOMIC);
if (skb->len >=20 rt->u.dst.pmtu)
    goto fragment;
=20 skb->dst->output(skb);
return;
fragment:
=20 ip_fragment(skb, skb->dst->output);
= return;
drop:
=20 kfree_skb(skb);
}

All functions within the above = procedure are=20 kernel supplied and irrelevant to the problem, so I will skip its=20 explanation.
I use the kgdb to debug my codes. Everything worked fine = until I=20 had crossed the skb->dst->output(skb) statement and hit upon = return. Then,=20 when I typed “next” on host machine, the system crashed with = “Scheduling in interrupt!” appearing on target machine and = the=20 following message on my host machine:

Leery of some low level codes within = the=20 “skb->dst->output(skb)” provoked the crash, I step = into that=20 statement which points to function ip_output. Alas, the system crashed = with the=20 same reason upon the first statement of procedure ip_output, and that = statement=20 does simple book keeping!
The problem is patent: scheduling while = within the=20 interrupt processing, the myth is how could it ever be scheduling within = interrupt since I am not doing anything within the interrupt context!? = It is a=20 well known fact that within Linux there are three places to evoke = scheduling,=20 either it is educed explicitly by the procedure itself, which = won’t be=20 within interrupt context as long as the caller is not within it; or it = can be=20 elicited when the current process’s time quantum is exhausted or = when a=20 newly awakened process has a higher priority than the current one, = during these=20 two situations, the system will mark the need_resched flag, and the = actual=20 scheduling is performed when the system returns from a interrupt, again = within=20 the context of the process that is to be scheduled away. Therefore = normally=20 there is no chance to be scheduling in interrupt. Where is the hole? The = problem=20 must be caused by my codes, shouldn’t it?
By the way, I = implemented the=20 send_skbuff months ago, and together with other codes they had been = working=20 fine. This scheduling in interrupt problem only recently popped up when = I was=20 debugging error processing for IPsec and the place it occurred is = irrelevant to=20 the error processing.
Any comments will be greatly = appreciated.