* [PATCH] fix numbering of lines in /proc/net/tcp (linux-2.6.0-test7)
@ 2003-10-14 16:19 Tim Shepard
2003-10-14 16:38 ` YOSHIFUJI Hideaki / 吉藤英明
0 siblings, 1 reply; 4+ messages in thread
From: Tim Shepard @ 2003-10-14 16:19 UTC (permalink / raw)
To: davem, kuznet, pekkas, jmorris, yoshfuji, netdev; +Cc: torvalds, linux-kernel
While debugging another problem, I noticed that the first number on
each line read from /proc/net/tcp (and from /proc/net/tcp6) was
meaningless. The netstat program ignores this number, and I know of
no other readers of /proc/net/tcp{,6}. So perhaps this is only a
cosmetic bug. Nevertheless, in debugging another problem with the
lines produced by /proc/net/tcp, these meaningless numbers caused
confusion.
On a linux-2.6.0-test7 system, it looks like this:
$ cat /proc/net/tcp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
1: 0100007F:2260 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1000 0 2253 1 cdb27440 3000 0 0 2 -1
1: 00000000:1F40 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 1862 1 cf1e5060 3000 0 0 2 -1
1: 0100007F:0A43 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1000 0 2259 1 cc949460 3000 0 0 2 -1
1: 00000000:0203 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 1256 1 cf1e53e0 3000 0 0 2 -1
1: 0100007F:2266 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1000 0 2255 1 cc949b60 3000 0 0 2 -1
1: 0100007F:2B48 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1000 0 2257 1 cc9497e0 3000 0 0 2 -1
2: 0100007F:16E9 00000000:0000 0A 00000000:00000000 00:00000000 00000000 103 0 1250 1 cf1e5760 3000 0 0 2 -1
2: 0100007F:2B6F 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1000 0 2261 1 cc9490e0 3000 0 0 2 -1
2: 0100007F:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 1141 1 c13443c0 3000 0 0 2 -1
2: 0100007F:0C38 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1000 0 2265 1 cc927800 3000 0 0 2 -1
2: 0100007F:09DD 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1000 0 2263 1 cc927b80 3000 0 0 2 -1
2: B8425C42:8001 0C00000A:0016 01 00000000:00000000 02:006B7C78 00000000 1000 0 2273 2 cc927100 205 40 0 3 -1
2: B8425C42:8000 52001A12:0016 01 00000000:00000000 02:006B4970 00000000 1000 0 2249 2 cdb270c0 262 40 0 3 -1
On a linux-2.4.21 system, this first number just counts up like this:
$ cat /proc/net/tcp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
0: 00000000:1F40 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 580 1 c702f820 300 0 0 2 -1
1: 00000000:16E9 00000000:0000 0A 00000000:00000000 00:00000000 00000000 101 0 297102 1 c718dba0 300 0 0 2 -1
2: 00000000:006F 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 145 1 c77e5420 300 0 0 2 -1
3: 00000000:1770 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 840 1 c6cf94c0 300 0 0 2 -1
4: 0C00000A:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 2627 1 c5fd2b60 300 0 0 2 -1
5: 92425C42:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 2625 1 c5fd2080 300 0 0 2 -1
6: 0100007F:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 332 1 c718d0c0 300 0 0 2 -1
7: 00000000:0016 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 76922 1 c2eac880 300 0 0 2 -1
8: 00000000:0019 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 403 1 c718d800 300 0 0 2 -1
9: 0100007F:177A 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1000 0 314391 1 c2eacc20 300 0 0 2 -1
However, on a linux-2.4.21 system with ipv6 listeners, the numbers are
shared between ipv4 and ipv6:
$ cat /proc/net/tcp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
0: 00000000:1F40 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 580 1 c702f820 300 0 0 2 -1
1: 00000000:16E9 00000000:0000 0A 00000000:00000000 00:00000000 00000000 101 0 297102 1 c718dba0 300 0 0 2 -1
2: 00000000:006F 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 145 1 c77e5420 300 0 0 2 -1
4: 00000000:1770 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 840 1 c6cf94c0 300 0 0 2 -1
5: 0C00000A:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 2627 1 c5fd2b60 300 0 0 2 -1
6: 92425C42:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 2625 1 c5fd2080 300 0 0 2 -1
7: 0100007F:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 332 1 c718d0c0 300 0 0 2 -1
8: 00000000:0016 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 76922 1 c2eac880 300 0 0 2 -1
9: 00000000:0019 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 403 1 c718d800 300 0 0 2 -1
10: 0100007F:177A 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1000 0 314391 1 c2eacc20 300 0 0 2 -1
$ cat /proc/net/tcp6
sl local_address remote_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
3: 00000000000000000000000000000000:0050 00000000000000000000000000000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 6630 1 c702fbc0 300 0 0 2 -1
I am not sure what the behavior is supposed to be. Is there a spec
anywhere for the interface with /proc/net/tcp?
The patch below changes it to always count up from zero, without
sharing the numbers between ipv4 and ipv6. This is an improvement
over linux-2.6.0-test7 behavior, but without a spec I cannot be sure
what the correct behavior would be.
This patch can be applied before, after, alone, or with the other patch I
submitted earlier today. This patch is the less important of the two.
I welcome comments.
-Tim Shepard
shep@alum.mit.edu
--- ../pristine/linux-2.6.0-test7/net/ipv4/tcp_ipv4.c 2003-10-08 15:24:03.000000000 -0400
+++ net/ipv4/tcp_ipv4.c 2003-10-13 22:33:10.000000000 -0400
@@ -2145,7 +2145,6 @@
if (!sk)
continue;
- ++st->num;
if (sk->sk_family == st->family) {
rc = sk;
goto out;
@@ -2159,7 +2158,7 @@
for (st->sbucket = 0; st->sbucket < TCP_SYNQ_HSIZE;
++st->sbucket) {
for (req = tp->listen_opt->syn_table[st->sbucket];
- req; req = req->dl_next, ++st->num) {
+ req; req = req->dl_next) {
if (req->class->family != st->family)
continue;
rc = req;
@@ -2181,6 +2180,8 @@
struct sock *sk = cur;
struct tcp_iter_state* st = seq->private;
+ ++st->num;
+
if (st->state == TCP_SEQ_STATE_OPENREQ) {
struct open_request *req = cur;
@@ -2188,7 +2189,6 @@
req = req->dl_next;
while (1) {
while (req) {
- ++st->num;
if (req->class->family == st->family) {
cur = req;
goto out;
@@ -2254,7 +2254,6 @@
read_lock(&tcp_ehash[st->bucket].lock);
sk_for_each(sk, node, &tcp_ehash[st->bucket].chain) {
if (sk->sk_family != st->family) {
- ++st->num;
continue;
}
rc = sk;
@@ -2264,7 +2263,6 @@
tw_for_each(tw, node,
&tcp_ehash[st->bucket + tcp_ehash_size].chain) {
if (tw->tw_family != st->family) {
- ++st->num;
continue;
}
rc = tw;
@@ -2284,12 +2282,13 @@
struct hlist_node *node;
struct tcp_iter_state* st = seq->private;
+ ++st->num;
+
if (st->state == TCP_SEQ_STATE_TIME_WAIT) {
tw = cur;
tw = tw_next(tw);
get_tw:
while (tw && tw->tw_family != st->family) {
- ++st->num;
tw = tw_next(tw);
}
if (tw) {
@@ -2311,7 +2310,6 @@
sk_for_each_from(sk, node) {
if (sk->sk_family == st->family)
goto found;
- ++st->num;
}
st->state = TCP_SEQ_STATE_TIME_WAIT;
@@ -2354,6 +2352,8 @@
static void *tcp_seq_start(struct seq_file *seq, loff_t *pos)
{
+ struct tcp_iter_state* st = seq->private;
+ st->num = 0;
return *pos ? tcp_get_idx(seq, *pos - 1) : SEQ_START_TOKEN;
}
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] fix numbering of lines in /proc/net/tcp (linux-2.6.0-test7)
2003-10-14 16:19 [PATCH] fix numbering of lines in /proc/net/tcp (linux-2.6.0-test7) Tim Shepard
@ 2003-10-14 16:38 ` YOSHIFUJI Hideaki / 吉藤英明
2003-10-14 17:45 ` David S. Miller
0 siblings, 1 reply; 4+ messages in thread
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2003-10-14 16:38 UTC (permalink / raw)
To: shep
Cc: davem, kuznet, pekkas, jmorris, netdev, torvalds, linux-kernel,
yoshfuji
In article <200310141619.h9EGJWWB013461@ginger.lcs.mit.edu> (at Tue, 14 Oct 2003 12:19:32 -0400), Tim Shepard <shep@alum.mit.edu> says:
> However, on a linux-2.4.21 system with ipv6 listeners, the numbers are
> shared between ipv4 and ipv6:
>
> $ cat /proc/net/tcp
> sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
> 0: 00000000:1F40 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 580 1 c702f820 300 0 0 2 -1
> 1: 00000000:16E9 00000000:0000 0A 00000000:00000000 00:00000000 00000000 101 0 297102 1 c718dba0 300 0 0 2 -1
> 2: 00000000:006F 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 145 1 c77e5420 300 0 0 2 -1
> 4: 00000000:1770 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 840 1 c6cf94c0 300 0 0 2 -1
:
> $ cat /proc/net/tcp6
> sl local_address remote_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
> 3: 00000000000000000000000000000000:0050 00000000000000000000000000000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 6630 1 c702fbc0 300 0 0 2 -1
>
>
>
> I am not sure what the behavior is supposed to be. Is there a spec
> anywhere for the interface with /proc/net/tcp?
Yes, I think the original is okay because the bucket is shared between
tcp6 and tcp4, and I don't want to change this behavior in 2.6 from 2.4.x.
(so, we need to fix 2.6.x.)
--yoshfuji
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] fix numbering of lines in /proc/net/tcp (linux-2.6.0-test7)
2003-10-14 16:38 ` YOSHIFUJI Hideaki / 吉藤英明
@ 2003-10-14 17:45 ` David S. Miller
2003-10-14 18:14 ` Tim Shepard
0 siblings, 1 reply; 4+ messages in thread
From: David S. Miller @ 2003-10-14 17:45 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / _$B5HF#1QL@
Cc: shep, kuznet, pekkas, jmorris, netdev, torvalds, linux-kernel,
yoshfuji
On Wed, 15 Oct 2003 01:38:48 +0900 (JST)
YOSHIFUJI Hideaki / _$B5HF#1QL@ <yoshfuji@linux-ipv6.org> wrote:
> In article <200310141619.h9EGJWWB013461@ginger.lcs.mit.edu> (at Tue, 14 Oct 2003 12:19:32 -0400), Tim Shepard <shep@alum.mit.edu> says:
>
> > I am not sure what the behavior is supposed to be. Is there a spec
> > anywhere for the interface with /proc/net/tcp?
>
> Yes, I think the original is okay because the bucket is shared between
> tcp6 and tcp4, and I don't want to change this behavior in 2.6 from 2.4.x.
> (so, we need to fix 2.6.x.)
In the meantime I've applied Tim's patch because it is definitely
a step in the right direction and the current 2.6.x behavior makes
no sense at all :-)
We can add a fix on top to make 2.6.x behave more closely to 2.4.x
(by sharing numbers between v4 and v6). If that proves to be very
difficult to do, it's not absolutely critical to preserve this behavior
I think.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] fix numbering of lines in /proc/net/tcp (linux-2.6.0-test7)
2003-10-14 17:45 ` David S. Miller
@ 2003-10-14 18:14 ` Tim Shepard
0 siblings, 0 replies; 4+ messages in thread
From: Tim Shepard @ 2003-10-14 18:14 UTC (permalink / raw)
To: David S. Miller
Cc: YOSHIFUJI Hideaki / _$B5HF#1QL@, kuznet, pekkas, jmorris, netdev,
torvalds, linux-kernel
> > > I am not sure what the behavior is supposed to be. Is there a spec
> > > anywhere for the interface with /proc/net/tcp?
> >
> > Yes, I think the original is okay because the bucket is shared between
> > tcp6 and tcp4, and I don't want to change this behavior in 2.6 from 2.4.x.
> > (so, we need to fix 2.6.x.)
>
> In the meantime I've applied Tim's patch because it is definitely
> a step in the right direction and the current 2.6.x behavior makes
> no sense at all :-)
Ok, that makes good sense to me.
> We can add a fix on top to make 2.6.x behave more closely to 2.4.x
> (by sharing numbers between v4 and v6). If that proves to be very
> difficult to do, it's not absolutely critical to preserve this behavior
> I think.
Whoever dives in and fixes this (i.e. makes the linux-2.6 behavior
exactly match linux-2.4 behavior) may want to start with a copy of
net/ipv4/tcp_ipv4.c from 2.6.0-test7 without that patch applied
because that patch rips out bits of code that was trying to increment
st->num whenever sk->sk_family does not match st->family. Some of
those bits of code will need to reappear to make linux-2.6 match
linux-2.4 behavior. (Note, the patch below might contain some clues.)
When testing this stuff, you need to make sure that there is no
dependence upon the buffer size that the user mode program is using to
read from /proc/net/tcp and /proc/net/tcp6. (Use dd with different
bs= arguments.)
I just quickly tried to make the linux-2.6 numbering behave
identically to linux-2.4 (see patch below) but it did not work
properly, and I have not figured out yet where I goofed.
Note: THIS PATCH IS WRONG. Do not apply this patch unless you want
to help figure out why it does not work correctly. I was trying to
make linux-2.6 number the lines the same way linux-2.4 did, but the
numbers come out wrong.
This patch is against linux-2.6.0-test7 without my previous
patch to fix the numbering.
-Tim Shepard
shep@alum.mit.edu
--- ../pristine/linux-2.6.0-test7/net/ipv4/tcp_ipv4.c 2003-10-08 15:24:03.000000000 -0400
+++ net/ipv4/tcp_ipv4.c 2003-10-14 13:23:58.000000000 -0400
@@ -2136,29 +2136,29 @@
static void *listening_get_first(struct seq_file *seq)
{
struct tcp_iter_state* st = seq->private;
void *rc = NULL;
for (st->bucket = 0; st->bucket < TCP_LHTABLE_SIZE; ++st->bucket) {
struct open_request *req;
struct tcp_opt *tp;
struct sock *sk = sk_head(&tcp_listening_hash[st->bucket]);
if (!sk)
continue;
- ++st->num;
if (sk->sk_family == st->family) {
rc = sk;
goto out;
}
+ ++st->num;
tp = tcp_sk(sk);
read_lock_bh(&tp->syn_wait_lock);
if (tp->listen_opt && tp->listen_opt->qlen) {
st->uid = sock_i_uid(sk);
st->syn_wait_sk = sk;
st->state = TCP_SEQ_STATE_OPENREQ;
for (st->sbucket = 0; st->sbucket < TCP_SYNQ_HSIZE;
++st->sbucket) {
for (req = tp->listen_opt->syn_table[st->sbucket];
req; req = req->dl_next, ++st->num) {
if (req->class->family != st->family)
continue;
@@ -2172,54 +2172,57 @@
}
out:
return rc;
}
static void *listening_get_next(struct seq_file *seq, void *cur)
{
struct tcp_opt *tp;
struct hlist_node *node;
struct sock *sk = cur;
struct tcp_iter_state* st = seq->private;
+ ++st->num;
+
if (st->state == TCP_SEQ_STATE_OPENREQ) {
struct open_request *req = cur;
tp = tcp_sk(st->syn_wait_sk);
req = req->dl_next;
while (1) {
while (req) {
- ++st->num;
if (req->class->family == st->family) {
cur = req;
goto out;
}
+ ++st->num;
req = req->dl_next;
}
if (++st->sbucket >= TCP_SYNQ_HSIZE)
break;
get_req:
req = tp->listen_opt->syn_table[st->sbucket];
}
sk = sk_next(st->syn_wait_sk);
st->state = TCP_SEQ_STATE_LISTENING;
read_unlock_bh(&tp->syn_wait_lock);
} else
sk = sk_next(sk);
get_sk:
sk_for_each_from(sk, node) {
if (sk->sk_family == st->family) {
cur = sk;
goto out;
}
+ ++st->num;
tp = tcp_sk(sk);
read_lock_bh(&tp->syn_wait_lock);
if (tp->listen_opt && tp->listen_opt->qlen) {
st->uid = sock_i_uid(sk);
st->syn_wait_sk = sk;
st->state = TCP_SEQ_STATE_OPENREQ;
st->sbucket = 0;
goto get_req;
}
read_unlock_bh(&tp->syn_wait_lock);
}
if (++st->bucket < TCP_LHTABLE_SIZE) {
@@ -2275,24 +2278,26 @@
}
out:
return rc;
}
static void *established_get_next(struct seq_file *seq, void *cur)
{
struct sock *sk = cur;
struct tcp_tw_bucket *tw;
struct hlist_node *node;
struct tcp_iter_state* st = seq->private;
+ ++st->num;
+
if (st->state == TCP_SEQ_STATE_TIME_WAIT) {
tw = cur;
tw = tw_next(tw);
get_tw:
while (tw && tw->tw_family != st->family) {
++st->num;
tw = tw_next(tw);
}
if (tw) {
cur = tw;
goto out;
}
@@ -2345,24 +2350,26 @@
if (!rc) {
tcp_listen_unlock();
local_bh_disable();
st->state = TCP_SEQ_STATE_ESTABLISHED;
rc = established_get_idx(seq, pos);
}
return rc;
}
static void *tcp_seq_start(struct seq_file *seq, loff_t *pos)
{
+ struct tcp_iter_state* st = seq->private;
+ st->num = 0;
return *pos ? tcp_get_idx(seq, *pos - 1) : SEQ_START_TOKEN;
}
static void *tcp_seq_next(struct seq_file *seq, void *v, loff_t *pos)
{
void *rc = NULL;
struct tcp_iter_state* st;
if (v == SEQ_START_TOKEN) {
rc = tcp_get_idx(seq, 0);
goto out;
}
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-10-14 18:14 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-10-14 16:19 [PATCH] fix numbering of lines in /proc/net/tcp (linux-2.6.0-test7) Tim Shepard
2003-10-14 16:38 ` YOSHIFUJI Hideaki / 吉藤英明
2003-10-14 17:45 ` David S. Miller
2003-10-14 18:14 ` Tim Shepard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).