From: Philip Craig <philipc@snapgear.com>
To: David Miller <davem@davemloft.net>
Cc: akpm@osdl.org, netdev@vger.kernel.org, jari.takkala@q9.com
Subject: Re: [patch] neighbour.c, pneigh_get_next() skips published entry
Date: Tue, 26 Sep 2006 15:59:31 +1000 [thread overview]
Message-ID: <4518C1C3.10004@snapgear.com> (raw)
In-Reply-To: <20060925.164731.71091985.davem@davemloft.net>
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
next prev parent reply other threads:[~2006-09-26 5:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2006-09-27 11:12 ` Herbert Xu
-- strict thread matches above, loose matches on Subject: below --
2006-05-11 16:29 [PATCH] " Jari Takkala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4518C1C3.10004@snapgear.com \
--to=philipc@snapgear.com \
--cc=akpm@osdl.org \
--cc=davem@davemloft.net \
--cc=jari.takkala@q9.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.