From: Roland Dreier <rdreier@cisco.com>
To: Constantine Gavrilov <constantine.gavrilov@gmail.com>
Cc: linux-kernel@vger.kernel.org, general@lists.openfabrics.org,
netdev@vger.kernel.org
Subject: Re: patch: support long (above 14 bytes) HW addresses in arp_ioctl
Date: Mon, 03 Nov 2008 15:53:26 -0800 [thread overview]
Message-ID: <adaod0wv021.fsf@cisco.com> (raw)
In-Reply-To: <490F496C.2010608@gmail.com> (Constantine Gavrilov's message of "Mon, 03 Nov 2008 20:56:44 +0200")
[netdev added to cc list]
> In arp_req_get() in net/arp.c, there is code:
>
> memcpy(r->arp_ha.sa_data, neigh->ha, dev->addr_len);
>
> dev->addr_len can be larger than size of
> r->arp_ha.sa_data. Inititally, I thought it would corrupt kernel
> stack. I was wrong, since r still has enough space not to overflow
> even for the largest HW address (32 bytes). It would corrupt the data
> structure though, and that corrupted reply would be propagated to
> user.
>
> There is a similar situation in arp_req_set(), where a "junk" arp
> entry will be set if dev->addr_len is larger that 14 bytes.
>
> At the very minimum, both arp_req_set() and arp_req_get() should
> return error (-EINVAL), and not return junk or set junk. Truncated
> /proc/net/arp output should also be fixed.
The EINVAL return makes sense; I'm not sure /proc/net/arp is important
enough to fix. I guess it depends on the impact of the fix.
> I was not aware that rtnetlink is capable of doing things like arp
> table or interface manipulation (like netdevice ioctls). My
> applications needs to be able to manipulate arp cache for large macs,
> and I do not mind recompiling by adding a flag. I do not mind fixing
> arp cli to use this either (venerable arp does use arp_ioctl). And
> there are many many legacy solutions that use arp_ioctl() in programs
> and arp utility in scripts. Consider porting those to infiniband.
>
> Will rtnetlink work for any net_device (like netdevice ioctls do) for
> ARP and interface configurations calls or does it require special
> support in net_device itself? Any possible problems with rtnetlink?
rtnetlink is the preferred modern interface between userspace and kernel
for networking information. There is also the "iproute2" package that
provides a good command line interface that is capable of handling IPoIB
addresses. For example:
$ ip addr show dev ib1
5: ib1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast state UP qlen 256
link/infiniband 80:00:00:48:fe:80:00:00:00:00:00:00:00:02:c9:03:00:00:01:65 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
inet 192.168.145.74/24 brd 192.168.145.255 scope global ib1
inet6 fe80::202:c903:0:165/64 scope link
valid_lft forever preferred_lft forever
$ ip neigh
192.168.145.73 dev ib1 lladdr 80:00:00:48:fe:80:00:00:00:00:00:00:00:02:c9:03:00:00:01:30 STALE
172.29.224.1 dev eth0 lladdr 00:00:0c:07:ac:e0 REACHABLE
and so on.
- R.
prev parent reply other threads:[~2008-11-03 23:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-03 11:09 patch: support long (above 14 bytes) HW addresses in arp_ioctl Constantine Gavrilov
2008-11-03 16:34 ` Constantine Gavrilov
2008-11-03 17:39 ` Roland Dreier
2008-11-03 18:56 ` Constantine Gavrilov
2008-11-03 21:58 ` Stephen Hemminger
2008-11-03 23:53 ` Roland Dreier [this message]
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=adaod0wv021.fsf@cisco.com \
--to=rdreier@cisco.com \
--cc=constantine.gavrilov@gmail.com \
--cc=general@lists.openfabrics.org \
--cc=linux-kernel@vger.kernel.org \
--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.