* [PATCH 2/3] ipv4: Remove route key identity dependencies in ip_rt_get_source().
From: David Miller @ 2011-05-13 21:51 UTC (permalink / raw)
To: netdev
Pass in the sk_buff so that we can fetch the necessary keys from
the packet header when working with input routes.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/net/route.h | 2 +-
net/ipv4/ip_options.c | 12 ++++++------
net/ipv4/route.c | 24 ++++++++++++++----------
3 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/include/net/route.h b/include/net/route.h
index 9f8070b..ba0e084 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -189,7 +189,7 @@ extern unsigned inet_addr_type(struct net *net, __be32 addr);
extern unsigned inet_dev_addr_type(struct net *net, const struct net_device *dev, __be32 addr);
extern void ip_rt_multicast_event(struct in_device *);
extern int ip_rt_ioctl(struct net *, unsigned int cmd, void __user *arg);
-extern void ip_rt_get_source(u8 *src, struct rtable *rt);
+extern void ip_rt_get_source(u8 *src, struct sk_buff *skb, struct rtable *rt);
extern int ip_rt_dump(struct sk_buff *skb, struct netlink_callback *cb);
struct in_ifaddr;
diff --git a/net/ipv4/ip_options.c b/net/ipv4/ip_options.c
index c6474cd..89268ba 100644
--- a/net/ipv4/ip_options.c
+++ b/net/ipv4/ip_options.c
@@ -37,7 +37,7 @@
*/
void ip_options_build(struct sk_buff *skb, struct ip_options *opt,
- __be32 daddr, struct rtable *rt, int is_frag)
+ __be32 daddr, struct rtable *rt, int is_frag)
{
unsigned char *iph = skb_network_header(skb);
@@ -50,9 +50,9 @@ void ip_options_build(struct sk_buff *skb, struct ip_options *opt,
if (!is_frag) {
if (opt->rr_needaddr)
- ip_rt_get_source(iph+opt->rr+iph[opt->rr+2]-5, rt);
+ ip_rt_get_source(iph+opt->rr+iph[opt->rr+2]-5, skb, rt);
if (opt->ts_needaddr)
- ip_rt_get_source(iph+opt->ts+iph[opt->ts+2]-9, rt);
+ ip_rt_get_source(iph+opt->ts+iph[opt->ts+2]-9, skb, rt);
if (opt->ts_needtime) {
struct timespec tv;
__be32 midtime;
@@ -553,7 +553,7 @@ void ip_forward_options(struct sk_buff *skb)
if (opt->rr_needaddr) {
optptr = (unsigned char *)raw + opt->rr;
- ip_rt_get_source(&optptr[optptr[2]-5], rt);
+ ip_rt_get_source(&optptr[optptr[2]-5], skb, rt);
opt->is_changed = 1;
}
if (opt->srr_is_hit) {
@@ -572,13 +572,13 @@ void ip_forward_options(struct sk_buff *skb)
}
if (srrptr + 3 <= srrspace) {
opt->is_changed = 1;
- ip_rt_get_source(&optptr[srrptr-1], rt);
+ ip_rt_get_source(&optptr[srrptr-1], skb, rt);
optptr[2] = srrptr+4;
} else if (net_ratelimit())
printk(KERN_CRIT "ip_forward(): Argh! Destination lost!\n");
if (opt->ts_needaddr) {
optptr = raw + opt->ts;
- ip_rt_get_source(&optptr[optptr[2]-9], rt);
+ ip_rt_get_source(&optptr[optptr[2]-9], skb, rt);
opt->is_changed = 1;
}
}
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 6a83840..ad141d8 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1699,22 +1699,26 @@ static int ip_rt_bug(struct sk_buff *skb)
in IP options!
*/
-void ip_rt_get_source(u8 *addr, struct rtable *rt)
+void ip_rt_get_source(u8 *addr, struct sk_buff *skb, struct rtable *rt)
{
__be32 src;
- struct fib_result res;
if (rt_is_output_route(rt))
src = rt->rt_src;
else {
- struct flowi4 fl4 = {
- .daddr = rt->rt_key_dst,
- .saddr = rt->rt_key_src,
- .flowi4_tos = rt->rt_key_tos,
- .flowi4_oif = rt->rt_oif,
- .flowi4_iif = rt->rt_iif,
- .flowi4_mark = rt->rt_mark,
- };
+ struct fib_result res;
+ struct flowi4 fl4;
+ struct iphdr *iph;
+
+ iph = ip_hdr(skb);
+
+ memset(&fl4, 0, sizeof(fl4));
+ fl4.daddr = iph->daddr;
+ fl4.saddr = iph->saddr;
+ fl4.flowi4_tos = iph->tos;
+ fl4.flowi4_oif = rt->dst.dev->ifindex;
+ fl4.flowi4_iif = skb->dev->ifindex;
+ fl4.flowi4_mark = skb->mark;
rcu_read_lock();
if (fib_lookup(dev_net(rt->dst.dev), &fl4, &res) == 0)
--
1.7.4.4
^ permalink raw reply related
* [PATCH 3/3] ipv4: Remove rt->rt_dst reference from ip_forward_options().
From: David Miller @ 2011-05-13 21:51 UTC (permalink / raw)
To: netdev
At this point iph->daddr equals what rt->rt_dst would hold.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/ip_options.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/ip_options.c b/net/ipv4/ip_options.c
index 89268ba..c3118e1 100644
--- a/net/ipv4/ip_options.c
+++ b/net/ipv4/ip_options.c
@@ -567,7 +567,7 @@ void ip_forward_options(struct sk_buff *skb)
) {
if (srrptr + 3 > srrspace)
break;
- if (memcmp(&rt->rt_dst, &optptr[srrptr-1], 4) == 0)
+ if (memcmp(&ip_hdr(skb)->daddr, &optptr[srrptr-1], 4) == 0)
break;
}
if (srrptr + 3 <= srrspace) {
--
1.7.4.4
^ permalink raw reply related
* [PATCH net-next-2.6] net: ipv4: add ping_group_range documentation
From: Eric Dumazet @ 2011-05-13 22:22 UTC (permalink / raw)
To: Andi Kleen
Cc: Vasiliy Kulikov, David Miller, solar-cxoSlKxDwOJWk0Htik3J/w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
peak-8SWXkBwqxoT9tFMPJ9EooEJFmxxWawaa,
kees.cook-Z7WLFzj8eWMS+FvcfC7Uqw,
dan.j.rosenberg-Re5JQEeQqe8AvxtiuMwx3w,
eugene-H+wXaHxf7aLQT0dZR+AlfA, nelhage-SEpxePOmGhdBDgjK7y7TUQ,
kuznet-v/Mj1YrvjDBInbfyfbPRSQ, pekkas-UjJjq++bwZ7HOG6cAo2yLw,
jmorris-gx6/JNMH7DfYtjvyW6yDsg, yoshfuji-VfPWfsRibaP+Ru+s062T9g,
kaber-dcUjhNyLwpNeoWH0uzbU5w, linux-man-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <m2wrhuxp8c.fsf-Vw/NltI1exuRpAAqCnN02g@public.gmane.org>
Le vendredi 13 mai 2011 à 14:30 -0700, Andi Kleen a écrit :
> Vasiliy Kulikov <segoon-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org> writes:
>
> > This patch adds IPPROTO_ICMP socket kind. It makes it possible to send
> > ICMP_ECHO messages and receive the corresponding ICMP_ECHOREPLY messages
> > without any special privileges. In other words, the patch makes it
> > possible to implement setuid-less and CAP_NET_RAW-less /bin/ping. In
> > order not to increase the kernel's attack surface, the new functionality
> > is disabled by default, but is enabled at bootup by supporting Linux
> > distributions, optionally with restriction to a group or a group range
> > (see below).
>
> You'll need to do a manpage patch too. Otherwise noone will know how to use
> it.
Yes probably...
It would be nice to copy part of changelog in
Documentation/networking/ip-sysctl.txt
socket(2) is restricted to the group range specified in
"/proc/sys/net/ipv4/ping_group_range". It is "1 0" by default, meaning
that nobody (not even root) may create ping sockets. Setting it to "100
100" would grant permissions to the single group (to either make
/sbin/ping g+s and owned by this group or to grant permissions to the
"netadmins" group), "0 4294967295" would enable it for the world, "100
4294967295" would enable it for the users, but not daemons.
Too late here, time for sleep...
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr
From: Stephen Hemminger @ 2011-05-14 0:17 UTC (permalink / raw)
To: netdev
There are some addresses in the assigned vendor block that don't obey
the locally assigned convention. These should be avoided by random_ether_addr
assignment.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
include/linux/etherdevice.h | 17 +----------------
net/ethernet/eth.c | 42 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 43 insertions(+), 16 deletions(-)
--- a/include/linux/etherdevice.h 2011-05-13 12:37:08.199257621 -0700
+++ b/include/linux/etherdevice.h 2011-05-13 16:48:46.722745009 -0700
@@ -45,8 +45,7 @@ extern void eth_header_cache_update(stru
extern int eth_mac_addr(struct net_device *dev, void *p);
extern int eth_change_mtu(struct net_device *dev, int new_mtu);
extern int eth_validate_addr(struct net_device *dev);
-
-
+extern void random_ether_addr(u8 *addr);
extern struct net_device *alloc_etherdev_mqs(int sizeof_priv, unsigned int txqs,
unsigned int rxqs);
@@ -126,20 +125,6 @@ static inline int is_valid_ether_addr(co
}
/**
- * random_ether_addr - Generate software assigned random Ethernet address
- * @addr: Pointer to a six-byte array containing the Ethernet address
- *
- * Generate a random Ethernet address (MAC) that is not multicast
- * and has the local assigned bit set.
- */
-static inline void random_ether_addr(u8 *addr)
-{
- get_random_bytes (addr, ETH_ALEN);
- addr [0] &= 0xfe; /* clear multicast bit */
- addr [0] |= 0x02; /* set local assignment bit (IEEE802) */
-}
-
-/**
* dev_hw_addr_random - Create random MAC and set device flag
* @dev: pointer to net_device structure
* @hwaddr: Pointer to a six-byte array containing the Ethernet address
--- a/net/ethernet/eth.c 2011-05-13 12:37:08.219257985 -0700
+++ b/net/ethernet/eth.c 2011-05-13 17:03:39.412209908 -0700
@@ -392,3 +392,46 @@ ssize_t sysfs_format_mac(char *buf, cons
return (ssize_t)l;
}
EXPORT_SYMBOL(sysfs_format_mac);
+
+/* These vendors are known to violate the local MAC address assignment
+ convention. Avoid using them. */
+static const struct {
+ u8 oui[3];
+} inuse[] = {
+ { .oui = { 0x02, 0x07, 0x01 } }, /* Interlan */
+ { .oui = { 0x02, 0x60, 0x60 } }, /* 3Com */
+ { .oui = { 0x02, 0x60, 0x8c } }, /* 3Com */
+ { .oui = { 0x02, 0xa0, 0xc9 } }, /* Intel */
+ { .oui = { 0x02, 0xaa, 0x3c } }, /* Olivetti */
+ { .oui = { 0x02, 0xcf, 0x1f } }, /* CMC */
+ { .oui = { 0x02, 0xe0, 0x3b } }, /* Prominet */
+ { .oui = { 0x02, 0xe6, 0xd3 } }, /* BTI */
+ { .oui = { 0x52, 0x54, 0x00 } }, /* Realtek */
+ { .oui = { 0x52, 0x54, 0x4c } }, /* Novell 2000 */
+ { .oui = { 0x52, 0x54, 0xab } }, /* Realtec */
+ { .oui = { 0xe2, 0x0c, 0x0f } }, /* Kingston Technologies */
+};
+
+/**
+ * random_ether_addr - Generate software assigned random Ethernet address
+ * @addr: Pointer to a six-byte array containing the Ethernet address
+ *
+ * Generate a random Ethernet address (MAC) that is not multicast
+ * and has the local assigned bit set.
+ */
+
+void random_ether_addr(u8 *addr)
+{
+ int i;
+
+ retry:
+ get_random_bytes (addr, ETH_ALEN);
+
+ addr [0] &= 0xfe; /* clear multicast bit */
+ addr [0] |= 0x02; /* set local assignment bit (IEEE802) */
+
+ for (i = 0; i < ARRAY_SIZE(inuse); i++)
+ if (memcmp(inuse[i].oui, addr, 3) == 0)
+ goto retry;
+}
+EXPORT_SYMBOL(random_ether_addr);
^ permalink raw reply
* Re: [RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr
From: Rick Jones @ 2011-05-14 0:28 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20110513171729.247b126e@nehalam>
On Fri, 2011-05-13 at 17:17 -0700, Stephen Hemminger wrote:
> There are some addresses in the assigned vendor block that don't obey
> the locally assigned convention. These should be avoided by random_ether_addr
> assignment.
How "recent" are these violations? Is there really a non-trivial chance
of colliding? Much more than two or more stations in the same broadcast
domain randomly picking the same random MAC anyway?
At one level, avoiding using those OUIs seems to be a tacit approval of
the violations.
rick jones
^ permalink raw reply
* Re: [RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr
From: Stephen Hemminger @ 2011-05-14 0:32 UTC (permalink / raw)
To: rick.jones2; +Cc: netdev
In-Reply-To: <1305332905.8149.705.camel@tardy>
On Fri, 13 May 2011 17:28:25 -0700
Rick Jones <rick.jones2@hp.com> wrote:
> On Fri, 2011-05-13 at 17:17 -0700, Stephen Hemminger wrote:
> > There are some addresses in the assigned vendor block that don't obey
> > the locally assigned convention. These should be avoided by random_ether_addr
> > assignment.
>
> How "recent" are these violations? Is there really a non-trivial chance
> of colliding? Much more than two or more stations in the same broadcast
> domain randomly picking the same random MAC anyway?
>
> At one level, avoiding using those OUIs seems to be a tacit approval of
> the violations.
These were assigned long ago in the early days of Ethernet.
It makes sense to me to avoid them as just good policy.
--
^ permalink raw reply
* Re: [RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr
From: Rick Jones @ 2011-05-14 0:44 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20110513173213.491c74a1@nehalam>
On Fri, 2011-05-13 at 17:32 -0700, Stephen Hemminger wrote:
> On Fri, 13 May 2011 17:28:25 -0700
> Rick Jones <rick.jones2@hp.com> wrote:
>
> > On Fri, 2011-05-13 at 17:17 -0700, Stephen Hemminger wrote:
> > > There are some addresses in the assigned vendor block that don't obey
> > > the locally assigned convention. These should be avoided by random_ether_addr
> > > assignment.
> >
> > How "recent" are these violations? Is there really a non-trivial chance
> > of colliding? Much more than two or more stations in the same broadcast
> > domain randomly picking the same random MAC anyway?
> >
> > At one level, avoiding using those OUIs seems to be a tacit approval of
> > the violations.
>
> These were assigned long ago in the early days of Ethernet.
> It makes sense to me to avoid them as just good policy.
Well, then by a quick glance at
http://standards.ieee.org/develop/regauth/oui/oui.txt it looks like
there are more to add... (some overlap with your list, I've not checked
the entire thing, how the name conflicts should be resolved I've no
idea)
raj@tardy:~$ grep ^02- oui.txt
02-07-01 (hex) RACAL-DATACOM
02-1C-7C (hex) PERQ SYSTEMS CORPORATION
02-60-86 (hex) LOGIC REPLACEMENT TECH. LTD.
02-60-8C (hex) 3COM CORPORATION
02-70-01 (hex) RACAL-DATACOM
02-70-B0 (hex) M/A-COM INC. COMPANIES
02-70-B3 (hex) DATA RECALL LTD
02-9D-8E (hex) CARDIAC RECORDERS INC.
02-AA-3C (hex) OLIVETTI TELECOMM SPA (OLTECO)
02-BB-01 (hex) OCTOTHORPE CORP.
02-C0-8C (hex) 3COM CORPORATION
02-CF-1C (hex) COMMUNICATION MACHINERY CORP.
02-E6-D3 (hex) NIXDORF COMPUTER CORPORATION
The ieee's list doesn't have any 52's though.
rick
^ permalink raw reply
* Re: [PATCH 1/1] IPVS: seq_release_net should be used.
From: Simon Horman @ 2011-05-14 0:50 UTC (permalink / raw)
To: Hans Schillstrom; +Cc: ja, lvs-devel, netdev, netfilter-devel, hans
In-Reply-To: <1305266600-21507-1-git-send-email-hans.schillstrom@ericsson.com>
On Fri, May 13, 2011 at 08:03:20AM +0200, Hans Schillstrom wrote:
> Without this patch every access to ip_vs in procfs will increase
> the netns count i.e. an unbalanced get_net()/put_net().
> (ipvsadm commands also use procfs.)
> The result is you can't exit a netns if reading ip_vs_* procfs entries.
Hi Hans,
we should try and get this into 2.6.39, right?
>
> Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
> ---
> net/netfilter/ipvs/ip_vs_app.c | 2 +-
> net/netfilter/ipvs/ip_vs_conn.c | 4 ++--
> net/netfilter/ipvs/ip_vs_ctl.c | 6 +++---
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_app.c b/net/netfilter/ipvs/ip_vs_app.c
> index 51f3af7..059af31 100644
> --- a/net/netfilter/ipvs/ip_vs_app.c
> +++ b/net/netfilter/ipvs/ip_vs_app.c
> @@ -572,7 +572,7 @@ static const struct file_operations ip_vs_app_fops = {
> .open = ip_vs_app_open,
> .read = seq_read,
> .llseek = seq_lseek,
> - .release = seq_release,
> + .release = seq_release_net,
> };
> #endif
>
> diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
> index d3fd91b..bf28ac2 100644
> --- a/net/netfilter/ipvs/ip_vs_conn.c
> +++ b/net/netfilter/ipvs/ip_vs_conn.c
> @@ -1046,7 +1046,7 @@ static const struct file_operations ip_vs_conn_fops = {
> .open = ip_vs_conn_open,
> .read = seq_read,
> .llseek = seq_lseek,
> - .release = seq_release,
> + .release = seq_release_net,
> };
>
> static const char *ip_vs_origin_name(unsigned flags)
> @@ -1114,7 +1114,7 @@ static const struct file_operations ip_vs_conn_sync_fops = {
> .open = ip_vs_conn_sync_open,
> .read = seq_read,
> .llseek = seq_lseek,
> - .release = seq_release,
> + .release = seq_release_net,
> };
>
> #endif
> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> index 89842f0..699c79a 100644
> --- a/net/netfilter/ipvs/ip_vs_ctl.c
> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> @@ -2066,7 +2066,7 @@ static const struct file_operations ip_vs_info_fops = {
> .open = ip_vs_info_open,
> .read = seq_read,
> .llseek = seq_lseek,
> - .release = seq_release_private,
> + .release = seq_release_net,
> };
>
> static int ip_vs_stats_show(struct seq_file *seq, void *v)
> @@ -2106,7 +2106,7 @@ static const struct file_operations ip_vs_stats_fops = {
> .open = ip_vs_stats_seq_open,
> .read = seq_read,
> .llseek = seq_lseek,
> - .release = single_release,
> + .release = single_release_net,
> };
>
> static int ip_vs_stats_percpu_show(struct seq_file *seq, void *v)
> @@ -2175,7 +2175,7 @@ static const struct file_operations ip_vs_stats_percpu_fops = {
> .open = ip_vs_stats_percpu_seq_open,
> .read = seq_read,
> .llseek = seq_lseek,
> - .release = single_release,
> + .release = single_release_net,
> };
> #endif
>
> --
> 1.7.2.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] net: netlink: don't try unicast when dst_pid is zero for NETLINK_USERSOCK
From: Changli Gao @ 2011-05-14 0:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110513.164816.691741982303119913.davem@davemloft.net>
On Sat, May 14, 2011 at 4:48 AM, David Miller <davem@davemloft.net> wrote:
> From: Changli Gao <xiaosuo@gmail.com>
> Date: Fri, 13 May 2011 14:24:54 +0800
>
>> For NETLINK_USERSOCK, no one listens on PID 0, so sending a message only to
>> to a multicast group should not return -ECONNREFUSED.
>>
>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>
> I don't think this is a great idea, creating different semantics for
> NETLINK_USERSOCK vs. other types.
>
> You have to set the pid to something which will receive the unicast
> message, and then you can also (on top of that) send it to a multicast
> group as well.
>
> But the base operation is always the unicast send, and that is what
> determines success/failure of the operation.
>
Yes, I have seen that the return value of netlink_broadcast() isn't
returned to the caller, so the caller can't know whether the message
broadcasted is sent successfully or not. It isn't a big problem, as
netlink isn't a reliable datagram protocol. Without this patch
applied, we can also send a message to a multicast group only, but
ignore the -ECONNREFUSED error.
Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr
From: Rick Jones @ 2011-05-14 1:00 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <1305333898.8149.715.camel@tardy>
> Well, then by a quick glance at
> http://standards.ieee.org/develop/regauth/oui/oui.txt it looks like
> there are more to add... (some overlap with your list, I've not checked
> the entire thing, how the name conflicts should be resolved I've no
> idea)
>
> raj@tardy:~$ grep ^02- oui.txt
> 02-07-01 (hex) RACAL-DATACOM
> 02-1C-7C (hex) PERQ SYSTEMS CORPORATION
> 02-60-86 (hex) LOGIC REPLACEMENT TECH. LTD.
> 02-60-8C (hex) 3COM CORPORATION
> 02-70-01 (hex) RACAL-DATACOM
> 02-70-B0 (hex) M/A-COM INC. COMPANIES
> 02-70-B3 (hex) DATA RECALL LTD
> 02-9D-8E (hex) CARDIAC RECORDERS INC.
> 02-AA-3C (hex) OLIVETTI TELECOMM SPA (OLTECO)
> 02-BB-01 (hex) OCTOTHORPE CORP.
> 02-C0-8C (hex) 3COM CORPORATION
> 02-CF-1C (hex) COMMUNICATION MACHINERY CORP.
> 02-E6-D3 (hex) NIXDORF COMPUTER CORPORATION
>
> The ieee's list doesn't have any 52's though.
It does have some A's though:
~$ grep ^.[26AE]- oui.txt
[the aforementioned 02's]
AA-00-00 (hex) DIGITAL EQUIPMENT CORPORATION
AA-00-01 (hex) DIGITAL EQUIPMENT CORPORATION
AA-00-02 (hex) DIGITAL EQUIPMENT CORPORATION
AA-00-03 (hex) DIGITAL EQUIPMENT CORPORATION
AA-00-04 (hex) DIGITAL EQUIPMENT CORPORATION
which if I've not botched my bits has the locally administered bit set.
rick
^ permalink raw reply
* [PATCH net-2.6] ethtool: Remove fallback to old ethtool operations for ETHTOOL_SFEATURES
From: Ben Hutchings @ 2011-05-14 1:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Michał Mirosław
ethtool_set_feature_compat() squashes the feature mask into a boolean,
which is not correct for ethtool_ops::set_flags.
We could fix this, but the fallback code for ETHTOOL_SFEATURES actually
makes things more complicated for the ethtool utility and any other
application using the ethtool API. They will still need to fall back to
the old offload control commands in order to support older kernel
versions. The fallback code in the kernel adds a third possibility for
them to handle. So make ETHTOOL_SFEATURES fail when the driver
implements the old offload control operations, and let userland do the
fallback.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
include/linux/ethtool.h | 5 ----
net/core/ethtool.c | 55 ++++++-----------------------------------------
2 files changed, 7 insertions(+), 53 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index dc80d82..5fb916c 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -625,9 +625,6 @@ struct ethtool_sfeatures {
* Probably there are other device-specific constraints on some features
* in the set. When %ETHTOOL_F_UNSUPPORTED is set, .valid is considered
* here as though ignored bits were cleared.
- * %ETHTOOL_F_COMPAT - some or all changes requested were made by calling
- * compatibility functions. Requested offload state cannot be properly
- * managed by kernel.
*
* Meaning of bits in the masks are obtained by %ETHTOOL_GSSET_INFO (number of
* bits in the arrays - always multiple of 32) and %ETHTOOL_GSTRINGS commands
@@ -637,12 +634,10 @@ struct ethtool_sfeatures {
enum ethtool_sfeatures_retval_bits {
ETHTOOL_F_UNSUPPORTED__BIT,
ETHTOOL_F_WISH__BIT,
- ETHTOOL_F_COMPAT__BIT,
};
#define ETHTOOL_F_UNSUPPORTED (1 << ETHTOOL_F_UNSUPPORTED__BIT)
#define ETHTOOL_F_WISH (1 << ETHTOOL_F_WISH__BIT)
-#define ETHTOOL_F_COMPAT (1 << ETHTOOL_F_COMPAT__BIT)
#ifdef __KERNEL__
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 74ead9e..5f58f1f 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -207,52 +207,6 @@ static void ethtool_get_features_compat(struct net_device *dev,
features[0].available |= flags_dup_features;
}
-static int ethtool_set_feature_compat(struct net_device *dev,
- int (*legacy_set)(struct net_device *, u32),
- struct ethtool_set_features_block *features, u32 mask)
-{
- u32 do_set;
-
- if (!legacy_set)
- return 0;
-
- if (!(features[0].valid & mask))
- return 0;
-
- features[0].valid &= ~mask;
-
- do_set = !!(features[0].requested & mask);
-
- if (legacy_set(dev, do_set) < 0)
- netdev_info(dev,
- "Legacy feature change (%s) failed for 0x%08x\n",
- do_set ? "set" : "clear", mask);
-
- return 1;
-}
-
-static int ethtool_set_features_compat(struct net_device *dev,
- struct ethtool_set_features_block *features)
-{
- int compat;
-
- if (!dev->ethtool_ops)
- return 0;
-
- compat = ethtool_set_feature_compat(dev, dev->ethtool_ops->set_sg,
- features, NETIF_F_SG);
- compat |= ethtool_set_feature_compat(dev, dev->ethtool_ops->set_tx_csum,
- features, NETIF_F_ALL_CSUM);
- compat |= ethtool_set_feature_compat(dev, dev->ethtool_ops->set_tso,
- features, NETIF_F_ALL_TSO);
- compat |= ethtool_set_feature_compat(dev, dev->ethtool_ops->set_rx_csum,
- features, NETIF_F_RXCSUM);
- compat |= ethtool_set_feature_compat(dev, dev->ethtool_ops->set_flags,
- features, flags_dup_features);
-
- return compat;
-}
-
static int ethtool_get_features(struct net_device *dev, void __user *useraddr)
{
struct ethtool_gfeatures cmd = {
@@ -307,8 +261,13 @@ static int ethtool_set_features(struct net_device *dev, void __user *useraddr)
if (features[0].valid & ~NETIF_F_ETHTOOL_BITS)
return -EINVAL;
- if (ethtool_set_features_compat(dev, features))
- ret |= ETHTOOL_F_COMPAT;
+ /* If the driver implements any of the old operations, don't
+ * update features directly.
+ */
+ if (dev->ethtool_ops->set_sg || dev->ethtool_ops->set_tx_csum ||
+ dev->ethtool_ops->set_tso || dev->ethtool_ops->set_rx_csum ||
+ dev->ethtool_ops->set_flags)
+ return -EOPNOTSUPP;
if (features[0].valid & ~dev->hw_features) {
features[0].valid &= dev->hw_features;
--
1.7.4
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* [PATCHv1 (Repost)] bnx2x: Allow ethtool to enable/disable loopback.
From: Mahesh Bandewar @ 2011-05-14 1:08 UTC (permalink / raw)
To: Eilon Greenstein, David Miller; +Cc: netdev, Tom Herbert, Mahesh Bandewar
In-Reply-To: <1304472033-510-1-git-send-email-maheshb@google.com>
This patch updates the bnx2x_set_features() to handle loopback mode.
When enabled; it sets internal-MAC loopback.
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
drivers/net/bnx2x/bnx2x_cmn.c | 16 ++++++++++++++++
drivers/net/bnx2x/bnx2x_main.c | 3 +++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_cmn.c b/drivers/net/bnx2x/bnx2x_cmn.c
index 8729061..e944d2a 100644
--- a/drivers/net/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/bnx2x/bnx2x_cmn.c
@@ -2506,15 +2506,31 @@ int bnx2x_set_features(struct net_device *dev, u32 features)
{
struct bnx2x *bp = netdev_priv(dev);
u32 flags = bp->flags;
+ bool bnx2x_reload = false;
if (features & NETIF_F_LRO)
flags |= TPA_ENABLE_FLAG;
else
flags &= ~TPA_ENABLE_FLAG;
+ if (features & NETIF_F_LOOPBACK) {
+ if (bp->link_params.loopback_mode != LOOPBACK_BMAC) {
+ bp->link_params.loopback_mode = LOOPBACK_BMAC;
+ bnx2x_reload = true;
+ }
+ } else {
+ if (bp->link_params.loopback_mode != LOOPBACK_NONE) {
+ bp->link_params.loopback_mode = LOOPBACK_NONE;
+ bnx2x_reload = true;
+ }
+ }
+
if (flags ^ bp->flags) {
bp->flags = flags;
+ bnx2x_reload = true;
+ }
+ if (bnx2x_reload) {
if (bp->recovery_state == BNX2X_RECOVERY_DONE)
return bnx2x_reload_if_running(dev);
/* else: bnx2x_nic_load() will be called at end of recovery */
diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
index bfd7ac9..2c6b5e2 100644
--- a/drivers/net/bnx2x/bnx2x_main.c
+++ b/drivers/net/bnx2x/bnx2x_main.c
@@ -9435,6 +9435,9 @@ static int __devinit bnx2x_init_dev(struct pci_dev *pdev,
if (bp->flags & USING_DAC_FLAG)
dev->features |= NETIF_F_HIGHDMA;
+ /* Add Loopback capability to the device */
+ dev->hw_features |= NETIF_F_LOOPBACK;
+
#ifdef BCM_DCBNL
dev->dcbnl_ops = &bnx2x_dcbnl_ops;
#endif
--
1.7.3.1
^ permalink raw reply related
* Re: [RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr
From: Bill Fink @ 2011-05-14 6:28 UTC (permalink / raw)
To: rick.jones2; +Cc: Stephen Hemminger, netdev
In-Reply-To: <1305334848.8149.729.camel@tardy>
On Fri, 13 May 2011, Rick Jones wrote:
> > Well, then by a quick glance at
> > http://standards.ieee.org/develop/regauth/oui/oui.txt it looks like
> > there are more to add... (some overlap with your list, I've not checked
> > the entire thing, how the name conflicts should be resolved I've no
> > idea)
> >
> > raj@tardy:~$ grep ^02- oui.txt
> > 02-07-01 (hex) RACAL-DATACOM
> > 02-1C-7C (hex) PERQ SYSTEMS CORPORATION
> > 02-60-86 (hex) LOGIC REPLACEMENT TECH. LTD.
> > 02-60-8C (hex) 3COM CORPORATION
> > 02-70-01 (hex) RACAL-DATACOM
> > 02-70-B0 (hex) M/A-COM INC. COMPANIES
> > 02-70-B3 (hex) DATA RECALL LTD
> > 02-9D-8E (hex) CARDIAC RECORDERS INC.
> > 02-AA-3C (hex) OLIVETTI TELECOMM SPA (OLTECO)
> > 02-BB-01 (hex) OCTOTHORPE CORP.
> > 02-C0-8C (hex) 3COM CORPORATION
> > 02-CF-1C (hex) COMMUNICATION MACHINERY CORP.
> > 02-E6-D3 (hex) NIXDORF COMPUTER CORPORATION
> >
> > The ieee's list doesn't have any 52's though.
>
> It does have some A's though:
> ~$ grep ^.[26AE]- oui.txt
> [the aforementioned 02's]
> AA-00-00 (hex) DIGITAL EQUIPMENT CORPORATION
> AA-00-01 (hex) DIGITAL EQUIPMENT CORPORATION
> AA-00-02 (hex) DIGITAL EQUIPMENT CORPORATION
> AA-00-03 (hex) DIGITAL EQUIPMENT CORPORATION
> AA-00-04 (hex) DIGITAL EQUIPMENT CORPORATION
>
> which if I've not botched my bits has the locally administered bit set.
The AA addresses are used by DECNET and related protocols.
-Bill
^ permalink raw reply
* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Shan Wei @ 2011-05-14 6:54 UTC (permalink / raw)
To: Michał Mirosław
Cc: Michael S. Tsirkin, netdev, Ben Hutchings, herbert
In-Reply-To: <20110505152644.GA8459@rere.qmqm.pl>
Michał Mirosław wrote, at 05/05/2011 11:26 PM:
> On Wed, May 04, 2011 at 09:18:14PM +0300, Michael S. Tsirkin wrote:
>> BTW, I just noticed that net-next spits out
>> many of the following when I run any VMs:
> [...]
>> tap0: Features changed: 0x40004040 -> 0x401b4849
>
> Before this message, userspace called ioctl(TIOCSETOFFLOAD)
> turning offloads on.
>
>> tap0: Dropping NETIF_F_SG since no checksum feature.
>> tap0: Dropping NETIF_F_GSO since no SG feature.
>> tap0: Features changed: 0x401b4849 -> 0x40004040
>
> And then it probably called ioctl(TIOCSETOFFLOAD) again, disabling them.
[263958.167861] tap1: Dropping NETIF_F_SG since no checksum feature.
[263958.167866] tap1: Dropping NETIF_F_GSO since no SG feature.
[263958.167871] tap1: Features changed: 0x401b4849 -> 0x40004040
See same warning message using tunctl to create a tap device on net-next tree.
But on RHEL6, no warning message.
strace shows no TUNSETOFFLOAD to be used.
Seems that checksum feature is not set when creating tap0 interface.
#strace tunctl -u root -t tap1
open("/dev/net/tun", O_RDWR) = 3
ioctl(3, TUNSETIFF, 0x7fff789ada10) = 0
ioctl(3, TUNSETOWNER, 0) = 0
ioctl(3, TUNSETPERSIST, 0x1) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f66aeed9000
write(1, "Set 'tap1' persistent and owned "..., 41Set 'tap1' persistent and owned by uid 0
) = 41
exit_group(0) = ?
--
Best Regards
-----
Shan Wei
^ permalink raw reply
* [PATCH net-next] net: drivers: kill two unused macro definitions
From: Shan Wei @ 2011-05-14 7:08 UTC (permalink / raw)
To: fubar, andy, David Miller, jpirko, Michał Mirosław
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
---
drivers/net/bonding/bonding.h | 10 ----------
drivers/net/veth.c | 1 -
2 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index d08362e..ea1d005 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -39,16 +39,6 @@
netif_carrier_ok(dev))
/*
- * Checks whether bond is ready for transmit.
- *
- * Caller must hold bond->lock
- */
-#define BOND_IS_OK(bond) \
- (((bond)->dev->flags & IFF_UP) && \
- netif_running((bond)->dev) && \
- ((bond)->slave_cnt > 0))
-
-/*
* Checks whether slave is ready for transmit.
*/
#define SLAVE_IS_OK(slave) \
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 3b0151a..8461576 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -22,7 +22,6 @@
#define MIN_MTU 68 /* Min L3 MTU */
#define MAX_MTU 65535 /* Max L3 MTU (arbitrary) */
-#define MTU_PAD (ETH_HLEN + 4) /* Max difference between L2 and L3 size MTU */
struct veth_net_stats {
unsigned long rx_packets;
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH net-next] net: drivers: kill two unused macro definitions
From: Jiri Pirko @ 2011-05-14 7:53 UTC (permalink / raw)
To: Shan Wei
Cc: fubar, andy, David Miller, Michał Mirosław,
Eric Dumazet, ebiederm, netdev
In-Reply-To: <4DCE2A7F.1040000@cn.fujitsu.com>
Sat, May 14, 2011 at 09:08:47AM CEST, shanwei@cn.fujitsu.com wrote:
>
>
>Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
>---
> drivers/net/bonding/bonding.h | 10 ----------
> drivers/net/veth.c | 1 -
> 2 files changed, 0 insertions(+), 11 deletions(-)
>
>diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
>index d08362e..ea1d005 100644
>--- a/drivers/net/bonding/bonding.h
>+++ b/drivers/net/bonding/bonding.h
>@@ -39,16 +39,6 @@
> netif_carrier_ok(dev))
>
> /*
>- * Checks whether bond is ready for transmit.
>- *
>- * Caller must hold bond->lock
>- */
>-#define BOND_IS_OK(bond) \
>- (((bond)->dev->flags & IFF_UP) && \
>- netif_running((bond)->dev) && \
>- ((bond)->slave_cnt > 0))
>-
>-/*
> * Checks whether slave is ready for transmit.
> */
> #define SLAVE_IS_OK(slave) \
>diff --git a/drivers/net/veth.c b/drivers/net/veth.c
>index 3b0151a..8461576 100644
>--- a/drivers/net/veth.c
>+++ b/drivers/net/veth.c
>@@ -22,7 +22,6 @@
>
> #define MIN_MTU 68 /* Min L3 MTU */
> #define MAX_MTU 65535 /* Max L3 MTU (arbitrary) */
>-#define MTU_PAD (ETH_HLEN + 4) /* Max difference between L2 and L3 size MTU */
>
> struct veth_net_stats {
> unsigned long rx_packets;
>--
>1.7.4.1
Reviewed-by: Jiri Pirko <jpirko@redhat.com>
^ permalink raw reply
* [PATCH net-next-2.6] net: ping: small changes
From: Eric Dumazet @ 2011-05-14 8:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Vasiliy Kulikov
ping_table is not __read_mostly, since it contains one rwlock,
and is static to ping.c
ping_port_rover & ping_v4_lookup are static
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Vasiliy Kulikov <segoon@openwall.com>
---
net/ipv4/ping.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index a77e2d7..7041d09 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -49,9 +49,9 @@
#include <net/checksum.h>
-struct ping_table ping_table __read_mostly;
+static struct ping_table ping_table;
-u16 ping_port_rover;
+static u16 ping_port_rover;
static inline int ping_hashfn(struct net *net, unsigned num, unsigned mask)
{
@@ -150,8 +150,8 @@ static void ping_v4_unhash(struct sock *sk)
}
}
-struct sock *ping_v4_lookup(struct net *net, u32 saddr, u32 daddr,
- u16 ident, int dif)
+static struct sock *ping_v4_lookup(struct net *net, u32 saddr, u32 daddr,
+ u16 ident, int dif)
{
struct hlist_nulls_head *hslot = ping_hashslot(&ping_table, net, ident);
struct sock *sk = NULL;
^ permalink raw reply related
* Re: question about UFO behavior for bridge device
From: Shan Wei @ 2011-05-14 9:54 UTC (permalink / raw)
To: Herbert Xu, Ben Hutchings; +Cc: netdev
In-Reply-To: <20110513143627.GA29054@gondor.apana.org.au>
Herbert Xu wrote, at 05/13/2011 10:36 PM:
> On Fri, May 13, 2011 at 02:06:52PM +0100, Ben Hutchings wrote:
>>
>>> But, actually, i saw original big skb in eth0's tcpdump file, but not segmented skbs.
>>> The behavior is right or what we want?
>>> Is there anything missed about my analysis?
>>
>> I assume that packet capturing is handled earlier in the transmit path.
>
> Yes it is. It's the same with TSO.
Be cheated by tcpdump. :-(
dev_queue_xmit_nit(skb, dev) which dumps packet to user is called before handling GSO segments.
Thanks very much.
--
Best Regards
-----
Shan Wei
^ permalink raw reply
* Re: [PATCH net-2.6] ethtool: Remove fallback to old ethtool operations for ETHTOOL_SFEATURES
From: Michał Mirosław @ 2011-05-14 9:54 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev
In-Reply-To: <1305335142.2851.70.camel@bwh-desktop>
On Sat, May 14, 2011 at 02:05:42AM +0100, Ben Hutchings wrote:
> ethtool_set_feature_compat() squashes the feature mask into a boolean,
> which is not correct for ethtool_ops::set_flags.
>
> We could fix this, but the fallback code for ETHTOOL_SFEATURES actually
> makes things more complicated for the ethtool utility and any other
> application using the ethtool API. They will still need to fall back to
> the old offload control commands in order to support older kernel
> versions. The fallback code in the kernel adds a third possibility for
> them to handle. So make ETHTOOL_SFEATURES fail when the driver
> implements the old offload control operations, and let userland do the
> fallback.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
This will disable SFEATURES for drivers which implement changing newer
features that have no old ethtool ops (e.g. NETIF_F_LOOPBACK), but are
not converted, yet. This might matter when bisecting.
It's easy to fix this. The code is going away for 2.6.40, though.
Do you want to get rid of ETHTOOL_F_COMPAT bit before 2.6.39?
BTW, what are the complications for userspace?
This change misses ethtool_get_features_compat() setting available bits.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: future developments of usbnet
From: Oliver Neukum @ 2011-05-14 10:01 UTC (permalink / raw)
To: Alan Stern; +Cc: David Miller, shemminger, tom.leiming, netdev, linux-usb
In-Reply-To: <Pine.LNX.4.44L0.1105121025360.1917-100000@iolanthe.rowland.org>
Am Donnerstag, 12. Mai 2011, 16:37:28 schrieb Alan Stern:
> Therefore usbnet's poll routine should take the "weight" argument as an
> indication of how many outstanding rx URBs are allowed. Each time the
> poll routine is called, it should check to see if any rx URBs have
> completed since the previous poll. If not then there is no network
> traffic, so usbnet can take itself out of the poll loop. Otherwise,
> the number of outstanding URBs should be adjusted (by unlinking some or
> submitting more -- subject to some fixed maximum limit) to match the
> new "weight".
>
> Does that make sense?
What does happen if we reach the weight 0 ?
Regards
Oliver
^ permalink raw reply
* Re: [PATCH 1/1] IPVS: seq_release_net should be used.
From: Hans Schillstrom @ 2011-05-14 10:05 UTC (permalink / raw)
To: Simon Horman; +Cc: Hans Schillstrom, ja, lvs-devel, netdev, netfilter-devel
In-Reply-To: <20110514005025.GD4862@verge.net.au>
On Saturday, May 14, 2011 02:50:26 Simon Horman wrote:
> On Fri, May 13, 2011 at 08:03:20AM +0200, Hans Schillstrom wrote:
> > Without this patch every access to ip_vs in procfs will increase
> > the netns count i.e. an unbalanced get_net()/put_net().
> > (ipvsadm commands also use procfs.)
> > The result is you can't exit a netns if reading ip_vs_* procfs entries.
>
> Hi Hans,
>
> we should try and get this into 2.6.39, right?
Yes, this is a trivial bug fix
>
> >
> > Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
> > ---
> > net/netfilter/ipvs/ip_vs_app.c | 2 +-
> > net/netfilter/ipvs/ip_vs_conn.c | 4 ++--
> > net/netfilter/ipvs/ip_vs_ctl.c | 6 +++---
> > 3 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/net/netfilter/ipvs/ip_vs_app.c b/net/netfilter/ipvs/ip_vs_app.c
> > index 51f3af7..059af31 100644
> > --- a/net/netfilter/ipvs/ip_vs_app.c
> > +++ b/net/netfilter/ipvs/ip_vs_app.c
> > @@ -572,7 +572,7 @@ static const struct file_operations ip_vs_app_fops = {
> > .open = ip_vs_app_open,
> > .read = seq_read,
> > .llseek = seq_lseek,
> > - .release = seq_release,
> > + .release = seq_release_net,
> > };
> > #endif
> >
> > diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
> > index d3fd91b..bf28ac2 100644
> > --- a/net/netfilter/ipvs/ip_vs_conn.c
> > +++ b/net/netfilter/ipvs/ip_vs_conn.c
> > @@ -1046,7 +1046,7 @@ static const struct file_operations ip_vs_conn_fops = {
> > .open = ip_vs_conn_open,
> > .read = seq_read,
> > .llseek = seq_lseek,
> > - .release = seq_release,
> > + .release = seq_release_net,
> > };
> >
> > static const char *ip_vs_origin_name(unsigned flags)
> > @@ -1114,7 +1114,7 @@ static const struct file_operations ip_vs_conn_sync_fops = {
> > .open = ip_vs_conn_sync_open,
> > .read = seq_read,
> > .llseek = seq_lseek,
> > - .release = seq_release,
> > + .release = seq_release_net,
> > };
> >
> > #endif
> > diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> > index 89842f0..699c79a 100644
> > --- a/net/netfilter/ipvs/ip_vs_ctl.c
> > +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> > @@ -2066,7 +2066,7 @@ static const struct file_operations ip_vs_info_fops = {
> > .open = ip_vs_info_open,
> > .read = seq_read,
> > .llseek = seq_lseek,
> > - .release = seq_release_private,
> > + .release = seq_release_net,
> > };
> >
> > static int ip_vs_stats_show(struct seq_file *seq, void *v)
> > @@ -2106,7 +2106,7 @@ static const struct file_operations ip_vs_stats_fops = {
> > .open = ip_vs_stats_seq_open,
> > .read = seq_read,
> > .llseek = seq_lseek,
> > - .release = single_release,
> > + .release = single_release_net,
> > };
> >
> > static int ip_vs_stats_percpu_show(struct seq_file *seq, void *v)
> > @@ -2175,7 +2175,7 @@ static const struct file_operations ip_vs_stats_percpu_fops = {
> > .open = ip_vs_stats_percpu_seq_open,
> > .read = seq_read,
> > .llseek = seq_lseek,
> > - .release = single_release,
> > + .release = single_release_net,
> > };
> > #endif
> >
>
^ permalink raw reply
* [PATCH] net: fix ETHTOOL_SFEATURES compatibility with old ethtool_ops.set_flags
From: Michał Mirosław @ 2011-05-14 10:31 UTC (permalink / raw)
To: netdev; +Cc: Ben Hutchings, David Miller
In-Reply-To: <20110514095457.GA31970@rere.qmqm.pl>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
Against net-next, but this should also go to net.
net/core/ethtool.c | 25 ++++++++++++++++++++++++-
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index b8c2bcf..7bb3276 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -233,6 +233,29 @@ static int ethtool_set_feature_compat(struct net_device *dev,
return 1;
}
+static int ethtool_set_flags_compat(struct net_device *dev,
+ int (*legacy_set)(struct net_device *, u32),
+ struct ethtool_set_features_block *features, u32 mask)
+{
+ u32 value;
+
+ if (!legacy_set)
+ return 0;
+
+ if (!(features[0].valid & mask))
+ return 0;
+
+ features[0].valid &= ~mask;
+
+ value = dev->features & ~features[0].valid;
+ value |= features[0].requested;
+
+ if (legacy_set(dev, value & mask) < 0)
+ netdev_info(dev, "Legacy flags change failed\n");
+
+ return 1;
+}
+
static int ethtool_set_features_compat(struct net_device *dev,
struct ethtool_set_features_block *features)
{
@@ -249,7 +272,7 @@ static int ethtool_set_features_compat(struct net_device *dev,
features, NETIF_F_ALL_TSO);
compat |= ethtool_set_feature_compat(dev, dev->ethtool_ops->set_rx_csum,
features, NETIF_F_RXCSUM);
- compat |= ethtool_set_feature_compat(dev, dev->ethtool_ops->set_flags,
+ compat |= ethtool_set_flags_compat(dev, dev->ethtool_ops->set_flags,
features, flags_dup_features);
return compat;
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH net-2.6] ethtool: Remove fallback to old ethtool operations for ETHTOOL_SFEATURES
From: Michał Mirosław @ 2011-05-14 10:35 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev
In-Reply-To: <1305335142.2851.70.camel@bwh-desktop>
On Sat, May 14, 2011 at 02:05:42AM +0100, Ben Hutchings wrote:
> ethtool_set_feature_compat() squashes the feature mask into a boolean,
> which is not correct for ethtool_ops::set_flags.
>
> We could fix this, but the fallback code for ETHTOOL_SFEATURES actually
> makes things more complicated for the ethtool utility and any other
> application using the ethtool API. They will still need to fall back to
> the old offload control commands in order to support older kernel
> versions. The fallback code in the kernel adds a third possibility for
> them to handle. So make ETHTOOL_SFEATURES fail when the driver
> implements the old offload control operations, and let userland do the
> fallback.
BTW, the idea behind the compat code is that if ETHTOOL_[GS]FEATURES is
available, then there should be no need to fallback to old ops. For
a userspace tool that targets only kernels >= 2.6.39 there's no need
to care about old ops at all.
Best Regards,
Michał Mirosław
^ permalink raw reply
* [PATCH v2] net: fix ETHTOOL_SFEATURES compatibility with old ethtool_ops.set_flags
From: Michał Mirosław @ 2011-05-14 10:41 UTC (permalink / raw)
To: netdev; +Cc: Ben Hutchings, David Miller
In-Reply-To: <20110514103111.3FD5913A6A@rere.qmqm.pl>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
v2: fix 'valid' bits clearing before use
net/core/ethtool.c | 25 ++++++++++++++++++++++++-
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index b8c2bcf..d1c8b64 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -233,6 +233,29 @@ static int ethtool_set_feature_compat(struct net_device *dev,
return 1;
}
+static int ethtool_set_flags_compat(struct net_device *dev,
+ int (*legacy_set)(struct net_device *, u32),
+ struct ethtool_set_features_block *features, u32 mask)
+{
+ u32 value;
+
+ if (!legacy_set)
+ return 0;
+
+ if (!(features[0].valid & mask))
+ return 0;
+
+ value = dev->features & ~features[0].valid;
+ value |= features[0].requested;
+
+ features[0].valid &= ~mask;
+
+ if (legacy_set(dev, value & mask) < 0)
+ netdev_info(dev, "Legacy flags change failed\n");
+
+ return 1;
+}
+
static int ethtool_set_features_compat(struct net_device *dev,
struct ethtool_set_features_block *features)
{
@@ -249,7 +272,7 @@ static int ethtool_set_features_compat(struct net_device *dev,
features, NETIF_F_ALL_TSO);
compat |= ethtool_set_feature_compat(dev, dev->ethtool_ops->set_rx_csum,
features, NETIF_F_RXCSUM);
- compat |= ethtool_set_feature_compat(dev, dev->ethtool_ops->set_flags,
+ compat |= ethtool_set_flags_compat(dev, dev->ethtool_ops->set_flags,
features, flags_dup_features);
return compat;
--
1.7.2.5
^ permalink raw reply related
* Re: future developments of usbnet
From: Michał Mirosław @ 2011-05-14 10:46 UTC (permalink / raw)
To: Oliver Neukum
Cc: Alan Stern, David Miller, shemminger-ZtmgI6mnKB3QT0dZR+AlfA,
tom.leiming-Re5JQEeQqe8AvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <201105141201.40265.oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
2011/5/14 Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>:
> Am Donnerstag, 12. Mai 2011, 16:37:28 schrieb Alan Stern:
>> Therefore usbnet's poll routine should take the "weight" argument as an
>> indication of how many outstanding rx URBs are allowed. Each time the
>> poll routine is called, it should check to see if any rx URBs have
>> completed since the previous poll. If not then there is no network
>> traffic, so usbnet can take itself out of the poll loop. Otherwise,
>> the number of outstanding URBs should be adjusted (by unlinking some or
>> submitting more -- subject to some fixed maximum limit) to match the
>> new "weight".
> What does happen if we reach the weight 0 ?
Poll callback won't be called with weight 0. If there are more RX
packets after processing 'weight' of them, then the callback will be
called again later.
Best Regards,
Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox