truncated lines in /proc/net/tcp

truncated lines in /proc/net/tcp

[Arnout Engelen]

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

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

(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).

-- 
Arnout Engelen <arnouten@bzzt.net>

  "If it sounds good, it /is/ good."
          -- Duke Ellington

Re: truncated lines in /proc/net/tcp

[Randy.Dunlap]

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