Oops in sock_poll

Hi all,

I have a kernel Oops on ppc kernel 2.4.5 with an application listenning to a high throughput of incoming messages on a netlink socket. The application is running select() on the netlink socket file descriptor followed with recvmsg() call (in a forever loop).

The Oops (not saved, and hard to reproduce) showed a crash in the sock_poll function (kernel/net/socket.c); after investigations, crash is due to a NULL pointer in f_dentry member of the file structure. This pointer is set to NULL in the fput (kernel/fs/file_table.c) function. The backtraces show that the calling function is the sys_recvmsg (kernel/net/socket.c).

My understanding of the problem is the following:

- When everything goes right:

A/ When netlink socket is opened, its associated file structure is initialised with f_count to 1, and a dentry;

B/ When select is executed, f_count is increased to 2;

C/ When select ends, f_count is decreased to 1;

D/ When recvmsg is executed, f_count is increased to 2;

E/ When recvmsg ends, f_count is decreased to 1;

F/ Loop forever to B/

- When the problem occurs:

A/ When netlink socket is opened, its associated file structure is initialised with f_count to 1, and a dentry;

B/ When select is executed, f_count is increased to 2;

C/ When select ends, f_count is decreased to 1;

D/ When recvmsg is executed, f_count is increased to 2;

????/ SOMETHING decreases f_count to 1;

E/ When recvmsg ends, f_count is decreased to 0, AND THEREFORE f_dentry member of file is set to NULL (since file is considered as not used) ;

F/ When select is executed, f_count is incremented to 1, but f_dentry is NULL and therefore following code crashes in sock_poll function:
sock = socki_lookup(file->f_dentry->d_inode);

Do you have an idea of the event that could have decreased the f_count member between D/ and E/ ?
Could you give me elements to continue my investigation ?

Thanks a lot for you help,
Fabien

Can you reproduce this with a more recent kernel? Anything

would be sufficient.

And also please provide a full decoded OOPS log as well, thanks.

Hi,

The kernel used is customized in many ways, it is a long work to upgrade
...

here it is:
ksymoops 2.3.7 on i686 2.4.3. Options used
-v vmlinux (specified)
-K (specified)
-L (specified)
-O (specified)
-m System.map (specified)
-t elf_powerpc -a powerpc:common

Oops: kernel access of bad area, sig: 11
NIP: C00A0EB4 XER: 00000000 LR: C0046B20 SP: C1981E60 REGS: c1981db0

TRAP: 0300
MSR: 00009230 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c1980000[148] 'feemond' Last syscall: 142
last math 00000000 last altivec 00000000
GPR00: C0046B20 C1981E60 C1980000 C1AEFBA0 C1981E78 C1981E78 C1BEB780 00000000
GPR08: 00000000 00000000 00000000 C1BEB800 C1BEB780 1001D8B8 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 C1981EE8 00000005 000000B4 00000000
GPR24: C1981E78 00000004 00000145 C1981EC8 00000000 00000000 00000010 C1AEFBA0
Call backtrace:
C0046884 C0046B20 C0046FC4 C0007E1C C000266C 10001888 100016F8 10000B30 0FEF6A6C 00000000
Warning (Oops_read): Code line not seen, dumping what data is available

Trace; c0046884 <poll_freewait+54/70>
Trace; c0046b20 <do_select+e4/208>
Trace; c0046fc4 <sys_select+330/470>
Trace; c0007e1c <ppc_select+a0/b0>
Trace; c000266c <ret_from_syscall_1+0/b4>
Trace; 10001888 Before first symbol
Trace; 100016f8 Before first symbol
Trace; 10000b30 Before first symbol
Trace; 0fef6a6c Before first symbol
Trace; 00000000 Before first symbol

1 warning issued. Results may not be reliable.

From: Fabien Ribes <[email protected]>
Date: Fri, 18 Jan 2002 09:01:32 +0000

The kernel used is customized in many ways, it is a long work to upgrade

Then I can't help you... there have probably been many networking bugs fixed since 2.4.9

Hello!

I do not remember that we _ever_ had problems with leaking f_count. And it is so far of networking... :-)

"customized in many ways" bug sounds as better candidate to be fixed.

Alexey