From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040301 Description of problem: The kernel will oops in selinux_socket_sock after a few hours of load. I'll attach a stack trace in a minue. I've also reproced this under 2.6.3-1.110smp (took over 24hrs). The hardware is a dual Xeon. Multiple (identical) boxes act the same way. Version-Release number of selected component (if applicable): 2.6.5-1.315smp How reproducible: Always Steps to Reproduce: 1. Boot system 2. Run lots of mail through sendmail (with a milter filter) 3. Wait for the oops (2-30hours) Additional info: [support@proofpoint support]$ /sbin/lsmod Module Size Used by ipv6 224128 14 tg3 71044 0 ipt_REJECT 8704 1 ipt_state 5376 1 ip_conntrack 29612 1 ipt_state iptable_filter 6016 1 ip_tables 18176 3 ipt_REJECT,ipt_state,iptable_filter p4_clockmod 8068 0 microcode 10528 0 button 8472 0 battery 10892 0 asus_acpi 12440 0 ac 7436 0 ext3 95912 3 jbd 58008 1 ext3 megaraid 37576 4 sd_mod 20224 5 scsi_mod 99912 2 megaraid,sd_mod
Created attachment 99697 [details] text of stack trace (from serial console) I've reproduced this multiple times under 2.6.3. The stack traces are very similar.
Created attachment 99702 [details] Stack trace from oops in 2.6.3
Created attachment 99707 [details] Another oops (same top level, but different call trace)
Created attachment 99717 [details] Another stack trace
Created attachment 99718 [details] yet another stack trace I'll stop posting stack traces unless someone asks for one. It certainly seems to be repeatable (given a few hours).
Could you please post a trace using kernel-smp-2.6.5-1.327.i686.rpm ?
Looks similar to the problem reported earlier by akpm. Unless I misread the code, it looks like isec is null at the point of the dereferencing of isec->sclass after the self_netif_lookup, which implies that the socket inode was freed in the midst of sock_rcv_skb. Suggestions: - Add an explicit null test for isec and return with a warning. - Take the sk_callback_lock around the use of the socket inode? - Eliminate the need for accessing the socket inode by applying the patch I sent a while back to allow use of sk security field for INET sockets.
I have yet to see an oops on 326 or 327. All of them have the vdso=0 boot argument. I have 4 machines running them now. I can take days for this to show, I'll post an oops when I get one.
Created attachment 99760 [details] Call trace from 3.6.5-1.327smp
Thanks for that, it confirms that the oops is happening at the first dereference of the inode security field. isec = inode->i_security; <--- here switch (isec->sclass) { case SECCLASS_UDP_SOCKET: netif_perm = NETIF__UDP_RECV;
A fix has been included in the latest Fedora kernel. Please let us know if this works.
6 months with no comment - closing.