lkml.org 
[lkml]   [2002]   [Feb]   [18]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Subject[bug+patch] negative inode number in /proc/net/udp
FromArnaud Giersch <>
Date18 Feb 2002 16:16:58 +0100
Hi,

I was playing this morning with the netstat command and had a segfault
when doing `netstat -ulp'. My kernel version is 2.4.17 on an i686.

I first searched for a bug in netstat and I discovered that it was a
negative inode number in /proc/net/udp that confused netstat:

$ cat /proc/net/udp
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode                               
[...]
  80: 00000000:02D0 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 -2127935727 2 ca5dd060              
[...]

(Before continuing, I want to tell you that it is the first time I
look so precisely in the kernel source so please tell me if I'm
wrong or I missed something.)


If I understand the kernel source, an inode number is an unsigned
value ("typedef unsigned long __kernel_ino_t;" in
linux/include/asm-i386/posix_types.h) so it shouldn't be negative.

I tried to find where /proc/net/udp is created and I found the
function get_udp_sock in linux/net/ipv4/udp.c responsible of
generating the lines.

There, the sprintf call uses %ld instead of %lu to print the inode
number. I propose the following patch:

diff -Naur linux.orig/net/ipv4/udp.c linux/net/ipv4/udp.c
--- linux.orig/net/ipv4/udp.c	Wed Oct 17 23:16:39 2001
+++ linux/net/ipv4/udp.c	Mon Feb 18 15:49:49 2002
@@ -957,7 +957,7 @@
 	destp = ntohs(sp->dport);
 	srcp  = ntohs(sp->sport);
 	sprintf(tmpbuf, "%4d: %08X:%04X %08X:%04X"
-		" %02X %08X:%08X %02X:%08lX %08X %5d %8d %ld %d %p",
+		" %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %p",
 		i, src, srcp, dest, destp, sp->state, 
 		atomic_read(&sp->wmem_alloc), atomic_read(&sp->rmem_alloc),
 		0, 0L, 0,
I don't know how to generate this kind of information in /proc, so I
didn't test it.

I also looked the 2.4.18-rc1 and 2.5.5-pre1 kernels and the bug still
exist.

-- 
Arnaud
\
 
 \ /
  Last update: 2005-03-22 12:18    [W:0.168 / U:0.380 seconds]
©2003-2008 Jasper Spaans