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 <[email protected]>
"If it sounds good, it /is/ good."
-- Duke Ellington
On Fri, 10 Sep 2004 18:30:03 +0200 Arnout Engelen wrote:
Note: [email protected] 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