* [patch] neighbour.c, pneigh_get_next() skips published entry
@ 2006-09-25 23:45 Andrew Morton
2006-09-25 23:47 ` David Miller
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Morton @ 2006-09-25 23:45 UTC (permalink / raw)
To: netdev; +Cc: Jari Takkala
I've been sitting on this patch because afaik the problem which it purports
to fix remains unfixed.
Should I drop it??
Thanks.
From: "Jari Takkala" <Jari.Takkala@Q9.com>
Fix a problem where output from /proc/net/arp skips a record when the full
output does not fit into the users read() buffer.
To reproduce: publish a large number of ARP entries (more than 10 required
on my system). Run 'dd if=/proc/net/arp of=arp-1024.out bs=1024'. View
the output, one entry will be missing.
Signed-off-by: Jari Takkala <jari.takkala@q9.com>
[akpm: submitted before, discussion ended inconclusively, iirc]
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
net/core/neighbour.c | 6 ++++++
1 file changed, 6 insertions(+)
diff -puN net/core/neighbour.c~neighbourc-pneigh_get_next-skips-published-entry net/core/neighbour.c
--- a/net/core/neighbour.c~neighbourc-pneigh_get_next-skips-published-entry
+++ a/net/core/neighbour.c
@@ -2209,6 +2209,12 @@ static struct pneigh_entry *pneigh_get_n
struct neigh_seq_state *state = seq->private;
struct neigh_table *tbl = state->tbl;
+ if (pos != NULL && *pos == 1 &&
+ (pn->next || tbl->phash_buckets[state->bucket])) {
+ --(*pos);
+ return pn;
+ }
+
pn = pn->next;
while (!pn) {
if (++state->bucket > PNEIGH_HASHMASK)
_
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [patch] neighbour.c, pneigh_get_next() skips published entry
2006-09-25 23:45 [patch] neighbour.c, pneigh_get_next() skips published entry Andrew Morton
@ 2006-09-25 23:47 ` David Miller
2006-09-26 0:34 ` Andrew Morton
2006-09-26 5:59 ` Philip Craig
0 siblings, 2 replies; 6+ messages in thread
From: David Miller @ 2006-09-25 23:47 UTC (permalink / raw)
To: akpm; +Cc: netdev, jari.takkala
From: Andrew Morton <akpm@osdl.org>
Date: Mon, 25 Sep 2006 16:45:35 -0700
> I've been sitting on this patch because afaik the problem which it purports
> to fix remains unfixed.
>
> Should I drop it??
>
> Thanks.
Please drop it, the patch submitted didn't give us the feedback
and test results we asked for which is necessary to pinpoint the
true issue here.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch] neighbour.c, pneigh_get_next() skips published entry
2006-09-25 23:47 ` David Miller
@ 2006-09-26 0:34 ` Andrew Morton
2006-09-26 5:59 ` Philip Craig
1 sibling, 0 replies; 6+ messages in thread
From: Andrew Morton @ 2006-09-26 0:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jari.takkala
On Mon, 25 Sep 2006 16:47:31 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Andrew Morton <akpm@osdl.org>
> Date: Mon, 25 Sep 2006 16:45:35 -0700
>
> > I've been sitting on this patch because afaik the problem which it purports
> > to fix remains unfixed.
> >
> > Should I drop it??
> >
> > Thanks.
>
> Please drop it, the patch submitted didn't give us the feedback
> and test results we asked for which is necessary to pinpoint the
> true issue here.
Well that's why I hang onto such patches: so I can bug people about it
every few months. Consider it the world's dumbest bug-tracking system.
But I have a feeling I'll get shouted at if I try it again with this one
(looks at the 18-month-old tulip-fix-for-64-bit-mips.patch), so yeah, I'll drop
it.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch] neighbour.c, pneigh_get_next() skips published entry
2006-09-25 23:47 ` David Miller
2006-09-26 0:34 ` Andrew Morton
@ 2006-09-26 5:59 ` Philip Craig
2006-09-27 11:12 ` Herbert Xu
1 sibling, 1 reply; 6+ messages in thread
From: Philip Craig @ 2006-09-26 5:59 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, jari.takkala
David Miller wrote:
>> I've been sitting on this patch because afaik the problem which it purports
>> to fix remains unfixed.
>>
>> Should I drop it??
>>
>> Thanks.
>
> Please drop it, the patch submitted didn't give us the feedback
> and test results we asked for which is necessary to pinpoint the
> true issue here.
It is faster to reproduce with a smaller block size.
I haven't looked in detail to find the cause, but I did notice that
neigh_seq_start() does a pos_minus_one adjustment, and neigh_seq_next()
does not.
First, with only one entry, both block sizes work:
# dd if=/proc/net/arp bs=1024
IP address HW type Flags HW address Mask Device
10.46.1.1 0x1 0x2 00:04:23:C8:8D:E9 * eth0
0+1 records in
0+1 records out
156 bytes (156 B) copied, 0.000161 seconds, 969 kB/s
# dd if=/proc/net/arp bs=128
IP address HW type Flags HW address Mask Device
10.46.1.1 0x1 0x2 00:04:23:C8:8D:E9 * eth0
1+1 records in
1+1 records out
156 bytes (156 B) copied, 0.000193 seconds, 808 kB/s
But add another entry, and it is lost with bs=128:
# arp -Ds 1.1.1.1 eth1 pub
# dd if=/proc/net/arp bs=1024
IP address HW type Flags HW address Mask Device
10.46.1.1 0x1 0x2 00:04:23:C8:8D:E9 * eth0
1.1.1.1 0x1 0xc 00:00:00:00:00:00 * eth1
0+1 records in
0+1 records out
233 bytes (233 B) copied, 2.6e-05 seconds, 9.0 MB/s
# dd if=/proc/net/arp bs=128
IP address HW type Flags HW address Mask Device
10.46.1.1 0x1 0x2 00:04:23:C8:8D:E9 * eth0
1+1 records in
1+1 records out
156 bytes (156 B) copied, 7.9e-05 seconds, 2.0 MB/s
Add more entries, but still only one is lost:
# arp -Ds 1.1.1.2 eth1 pub
# arp -Ds 1.1.1.3 eth1 pub
# arp -Ds 1.1.1.4 eth1 pub
# arp -Ds 1.1.1.5 eth1 pub
# dd if=/proc/net/arp bs=128
IP address HW type Flags HW address Mask Device
10.46.1.1 0x1 0x2 00:04:23:C8:8D:E9 * eth0
1.1.1.3 0x1 0xc 00:00:00:00:00:00 * eth1
1.1.1.2 0x1 0xc 00:00:00:00:00:00 * eth1
1.1.1.5 0x1 0xc 00:00:00:00:00:00 * eth1
1.1.1.4 0x1 0xc 00:00:00:00:00:00 * eth1
3+1 records in
3+1 records out
464 bytes (464 B) copied, 3.6e-05 seconds, 12.9 MB/s
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] neighbour.c, pneigh_get_next() skips published entry
@ 2006-05-11 16:29 Jari Takkala
0 siblings, 0 replies; 6+ messages in thread
From: Jari Takkala @ 2006-05-11 16:29 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev
The following patch fixes a problem where output from /proc/net/arp
skips a record when the full output does not fit into the users read()
buffer.
To reproduce: publish a large number of ARP entries (more than 10
required on my system). Run 'dd if=/proc/net/arp of=arp-1024.out
bs=1024'. View the output, one entry will be missing.
Please review and commit if acceptable.
Signed-off-by: Jari Takkala <jari.takkala@q9.com>
--- linux-2.6.16.15.orig/net/core/neighbour.c 2006-05-09
15:53:30.000000000 -0400
+++ linux-2.6.16.15/net/core/neighbour.c 2006-05-10
16:06:40.000000000 -0400
@@ -2120,6 +2120,11 @@
struct neigh_seq_state *state = seq->private;
struct neigh_table *tbl = state->tbl;
+ if (pos != NULL && *pos == 1 && (pn->next ||
tbl->phash_buckets[state->bucket])) {
+ --(*pos);
+ return pn;
+ }
+
pn = pn->next;
while (!pn) {
if (++state->bucket > PNEIGH_HASHMASK)
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-09-27 11:13 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-09-25 23:45 [patch] neighbour.c, pneigh_get_next() skips published entry Andrew Morton
2006-09-25 23:47 ` David Miller
2006-09-26 0:34 ` Andrew Morton
2006-09-26 5:59 ` Philip Craig
2006-09-27 11:12 ` Herbert Xu
-- strict thread matches above, loose matches on Subject: below --
2006-05-11 16:29 [PATCH] " Jari Takkala
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).