At 14:49 on Tue 18/03/03, [EMAIL PROTECTED] masquerading as 'Herbert Poetzl' wrote: > okay, I should rephrase: > > - it is obvious that (as the BUG message states) > schedule() is called from an (soft)irq, which > in turn bails out (correct behaviour ;) > > - I can follow your deduction that (if the crash > is only ctx related, what seems very likely) > the schedule() got triggered by some semaphore > acquiring, which failed (for whatever reason) > > - what I was unable to trace so far is the path, > on which sys_assign_ip_info (for example) > gets called from a softirq ... > > tcp_create_openreq_child -> sys_assign_ip_info > tcp_v4/6_syn_recv_sock -> tcp_create_openreq_child > tcp_check_req -> syn_recv_sock() > tcp_v4/6_hnd_req -> tcp_check_req > tcp_v4/6_do_rcv -> tcp_v4/6_hnd_req > tcp_v4/6_rcv -> tcp_v4/6_do_rcv > > ip_mr_input -> ip_local_deliver (multicast) > > process_backlog -> netif_receive_skb
The argument in a nutshell is:
*) do_softirq() occurs in the backtrace
*) semaphores, which are not allowed at IRQ level, are spotted near
the oops
*) assuming that the backtrace is continuous
=) this indicates that semaphores are being used illegally
=>) replace semaphores with spinlocks or redesign
I want to say 'dammit, it works and it's "obvious"', but you're quite
correct, this is not rigorous enough!
Another decoded oops (from the email I sent to the list and cc'd you on
last Thursday) replete with tortuous ascii code path:
//----------------------------------------------------------------------
X rwsem_down_write_failed
? .text.lock.sys
^ tcp_create_openreq_child <== bingo
^ tcp_v4_syn_recv_sock
\ tcp_check_req -<-<-<-<-_ <== only called by tcp_v4_hnd_req
\
__alloc_pages |
do_no_page ^
__kfree_skb |
ipt_do_table ^
ipt_do_table |
ip_local_deliver_finish ^
ipt_do_table |
netif_rx ^
|
/ tcp_v4_hnd_req -->->->-/
^ tcp_v4_do_rcv
\ tcp_v4_rcv -<-<-<-<-<-_ <== Setup as static struct inet_protocol
\ tcp_protocol:handler in protocol.c
\
ip_local_deliver_finish \
ip_local_deliver_finish |
nf_hook_slow |
|
/ ip_local_deliver_finish -/ <== Calls struct inet_protocol*ipprot->
^ handler()
\ ip_local_deliver -<-_ <== route.c in various places sets
\ struct rtable * rth->u.dst.input =
\ ip_local_deliver;
\
ip_local_deliver_finish |
ip_rcv_finish |
nf_iterate /
nf_hook_slow /
/
/ ip_rcv_finish ->->->-/ <= calls ip_route_input() which links rth
^ above to skb, then calls skb->dst->
| input(skb);
^
\ ip_rcv -<-<-<-<-<-<-_ <= ip_rcv() set as struct packet_type
\ ip_packet_type->func in ip_output.c
^
ip_rcv_finish |
^
|
/ netif_receive_skb --/ <= calls struct packet_type * pt_prev->func()
^ process_backlog
^ net_rx_action
\ do_softirq <== dev.c's net_dev_init() calls:
open_softirq(NET_RX_SOFTIRQ,
net_rx_action, NULL);
.text.lock.af_inet
inet_stream_connect
sys_connect
sock_map_fd
sys_socket
sys_socketcall
sys_write
do_page_fault
//----------------------------------------------------------------------
Enough?
The answer had better be 'yes' 'cos that's your lot for now :)
Regards,
Jonathan
--
Jonathan Sambrook
Software Developer
Designer Servers
pgp00000.pgp
Description: PGP signature
