A question on "Scheduling in interrupt". (fwd)

[Ingo Molnar]

looks like that besides Ulrich Windl i got the very same email body as
well, as a private email. Lee, how many kernel hackers have you mailed
with the same email body, i hope it's not "everyone in the CREDITS and
MAINTAINERS file" ?  Why didnt you ask this on [e-mail]
or [e-mail]?

	Ingo

---------- Forwarded message ----------
Date: Sat, 15 Jun 2002 12:55:30 +0800
From: "[gb2312] ÎÀÇå" <[e-mail]>
To: [e-mail]
Subject: A question on "Scheduling in interrupt".

Dear Ingo Molnar,

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

void send_skbuff(struct sk_buff *skb)
{
  struct rtable *rt;
  struct iphdr *iph;

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

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

Program received signal SIGSEGV, Segmentation fault.
Schedule () at sched.c: 875
875 *(int *)0 = 0

Leery of some low level codes within the ¡°skb->dst->output(skb)¡± provoked the crash, I step into that statement which points to function ip_output. Alas, the system crashed with the same reason upon the first statement of procedure ip_output, and that statement does simple book keeping!
The problem is patent: scheduling while within the interrupt processing context, the myth is how could it ever be scheduling within interrupt since I am not doing anything within the interrupt context!?
By the way, I implemented the send_skbuff months ago, and together with other codes had been working fine. This scheduling in interrupt problem only recently popped up when I was debugging error processing for IPsec and the place it occurred is irrelevant to the error processing.
Any comments will be greatly appreciated.

Regards,

Lee Tong