lkml.org 
[lkml]   [2004]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: truncated lines in /proc/net/tcp
On Fri, 10 Sep 2004 18:30:03 +0200 Arnout Engelen wrote:

Note: netdev@oss.sgi.com would be more appropriate for this.


| Hi,
|
| I noticed lines in the output of /proc/net/tcp sometimes appear 'truncated', like
| this:
|
| 52: 010310AC:9D95 030310AC:1770 06 00000000:00000000 03:0000146C
| 00000000 0 0 0 2 c4e3f0c0
|
| (also notice that the inode is '0' instead of some large integer)
|
| This is print by the code at:
|
| http://lxr.linux.no/source/net/ipv4/tcp_ipv4.c?v=2.6.8.1#L2504

That line is used/printed if socket state is case TCP_SEQ_STATE_ESTABLISHED:
or case TCP_SEQ_STATE_LISTENING:
(line 2559). However, if socket state is case TCP_SEQ_STATE_OPENREQ:,
get_openreq4() is called to print the info, and if socket state is
case TCP_SEQ_STATE_TIME_WAIT:, get_timewait4_sock() is called to
print the info. The first case includes 5 fields after the %p (pointer),
while the 2nd and 3rd cases do not. Is that the truncation that you
are referring to?

| Maybe the value of 'tp' gets invalidated at some point during the
| gathering of the data to be printed there?

That doesn't quite explain it.

| (note that I'm not myself a kernel developer. I ran into this when
| writing a userspace application and decided I wanted to know why this
| happened. I saw this behaviour on a 2.4.26 kernel, but the code
| doesn't appear to be significantly different in 2.6. I'm not subscribed
| to the LKML, so if you want to ask me something please CC me personally).

Expect different output formats depending on socket state.

--
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.031 / U:1.984 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site