* Re: fec: add support for PHY interface platform data
From: David Miller @ 2010-05-24 6:32 UTC (permalink / raw)
To: baruch; +Cc: netdev
This patch not longer applied cleanly at all.
Pretty much in every portion of the FEC driver your patch touches, the
code looks totally different in the current tree.
You'll need to respin this against Linus's current tree if you still
want me to apply it.
Thanks.
^ permalink raw reply
* Re: [PATCH 0/2] fixes to arp_notify for virtual machine migration use case
From: David Miller @ 2010-05-24 6:37 UTC (permalink / raw)
To: Ian.Campbell; +Cc: netdev, shemminger, jeremy.fitzhardinge, stable
In-Reply-To: <1273671554.7572.11190.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 12 May 2010 14:39:14 +0100
> Ian Campbell (2):
> arp_notify: generate broadcast ARP reply not request.
> arp_notify: generate arp_notify event on NETDEV_CHANGE too
I don't agree with these changes.
For the first one, I think the documentation is just wrong and the
code is what expresses the intent. The idea is not to spam the
world with a broadcast, only interested parties.
Patch #2 I have major issues with, carriers flapping occaisionally is
very common. I have several interfaces which do this even on lightly
loaded networks. Iff we decide to do something like this (big "if")
it would need to be rate limited so that it doesn't trigger due to
normal flapping.
If you want your VM networking devices to trigger this event maybe
the best thing to do is to create a special notification which
allows us to prevent from doing this ARP notify for spurious physical
network device carrier flaps.
^ permalink raw reply
* Re: [PATCH net-2.6 1/6] caif: Bugfix - wait_ev*_timeout returns long.
From: David Miller @ 2010-05-24 6:40 UTC (permalink / raw)
To: sjur.brandeland; +Cc: netdev, sjurbr, linus.walleij, marcel
In-Reply-To: <1274444172-31969-1-git-send-email-sjur.brandeland@stericsson.com>
From: sjur.brandeland@stericsson.com
Date: Fri, 21 May 2010 14:16:07 +0200
> From: Sjur Braendeland <sjur.brandeland@stericsson.com>
>
> Discovered bug when testing on 64bit architecture.
> Fixed by using long to store result from wait_event_interruptible_timeout.
>
> Signed-off-by: Sjur Braendeland <sjur.brandeland@stericsson.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6 2/6] caif: Bugfix - use standard Linux lists
From: David Miller @ 2010-05-24 6:40 UTC (permalink / raw)
To: sjur.brandeland; +Cc: netdev, sjurbr, linus.walleij, marcel
In-Reply-To: <1274444172-31969-2-git-send-email-sjur.brandeland@stericsson.com>
From: sjur.brandeland@stericsson.com
Date: Fri, 21 May 2010 14:16:08 +0200
> From: Sjur Braendeland <sjur.brandeland@stericsson.com>
>
> Discovered bug when running high number of parallel connect requests.
> Replace buggy home brewed list with linux/list.h.
>
> Signed-off-by: Sjur Braendeland <sjur.brandeland@stericsson.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6 3/6] caif: Bugfix - handle mem-allocation failures
From: David Miller @ 2010-05-24 6:40 UTC (permalink / raw)
To: sjur.brandeland; +Cc: netdev, sjurbr, linus.walleij, marcel
In-Reply-To: <1274444172-31969-3-git-send-email-sjur.brandeland@stericsson.com>
From: sjur.brandeland@stericsson.com
Date: Fri, 21 May 2010 14:16:09 +0200
> From: Sjur Braendeland <sjur.brandeland@stericsson.com>
>
> Discovered bugs when injecting slab allocation failures.
> Add checks on all memory allocation.
>
> Signed-off-by: Sjur Braendeland <sjur.brandeland@stericsson.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6 4/6] caif: Bugfix - Poll can't return POLLHUP while connecting.
From: David Miller @ 2010-05-24 6:40 UTC (permalink / raw)
To: sjur.brandeland; +Cc: netdev, sjurbr, linus.walleij, marcel
In-Reply-To: <1274444172-31969-4-git-send-email-sjur.brandeland@stericsson.com>
From: sjur.brandeland@stericsson.com
Date: Fri, 21 May 2010 14:16:10 +0200
> From: Sjur Braendeland <sjur.brandeland@stericsson.com>
>
> Discovered bug when testing async connect.
> While connecting poll should not return POLLHUP,
> but POLLOUT when connected.
> Also fixed the sysfs flow-control-counters.
>
> Signed-off-by: Sjur Braendeland <sjur.brandeland@stericsson.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6 5/6] caif: Bugfix - missing spin_unlock
From: David Miller @ 2010-05-24 6:40 UTC (permalink / raw)
To: sjur.brandeland; +Cc: netdev, sjurbr, linus.walleij, marcel
In-Reply-To: <1274444172-31969-5-git-send-email-sjur.brandeland@stericsson.com>
From: sjur.brandeland@stericsson.com
Date: Fri, 21 May 2010 14:16:11 +0200
> From: Sjur Braendeland <sjur.brandeland@stericsson.com>
>
> Splint found missing spin_unlock.
> Corrected this an some other trivial split warnings.
>
> Signed-off-by: Sjur Braendeland <sjur.brandeland@stericsson.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6 6/6] caif: Bugfix - use MSG_TRUNC in receive
From: David Miller @ 2010-05-24 6:40 UTC (permalink / raw)
To: sjur.brandeland; +Cc: netdev, sjurbr, linus.walleij, marcel
In-Reply-To: <1274444172-31969-6-git-send-email-sjur.brandeland@stericsson.com>
From: sjur.brandeland@stericsson.com
Date: Fri, 21 May 2010 14:16:12 +0200
> From: Sjur Braendeland <sjur.brandeland@stericsson.com>
>
> Fixed handling when skb don't fit in user buffer,
> instead of returning -EMSGSIZE, the buffer is truncated (just
> as unix seqpakcet does).
>
> Signed-off-by: Sjur Braendeland <sjur.brandeland@stericsson.com>
Applied.
^ permalink raw reply
* Re: tun: Use netif_receive_skb instead of netif_rx
From: David Miller @ 2010-05-24 6:44 UTC (permalink / raw)
To: herbert; +Cc: eric.dumazet, bmb, tgraf, nhorman, nhorman, netdev
In-Reply-To: <20100520065242.GA8719@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 20 May 2010 16:52:42 +1000
> cls_cgroup: Store classid in struct sock
...
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied.
^ permalink raw reply
* Re: tun: Use netif_receive_skb instead of netif_rx
From: David Miller @ 2010-05-24 6:44 UTC (permalink / raw)
To: herbert; +Cc: nhorman, eric.dumazet, bmb, tgraf, nhorman, netdev
In-Reply-To: <20100521011632.GA23849@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 21 May 2010 11:16:32 +1000
> tun: Update classid on packet injection
>
> This patch makes tun update its socket classid every time we
> inject a packet into the network stack. This is so that any
> updates made by the admin to the process writing packets to
> tun is effected.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied.
^ permalink raw reply
* Re: cls_cgroup: Store classid in struct sock
From: David Miller @ 2010-05-24 6:44 UTC (permalink / raw)
To: herbert; +Cc: nhorman, eric.dumazet, bmb, tgraf, nhorman, netdev
In-Reply-To: <20100522014957.GA8779@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 22 May 2010 11:49:57 +1000
> On Fri, May 21, 2010 at 12:40:54PM -0400, Neil Horman wrote:
>>
>> There may also be an issue with the setting of the classid (possible use of the
>> wrong subsys id value when grabbing our cgroup_subsys_state), but I'm checking
>> on that now.
>
> Actually, I think it's because my patch mistook CONFIG_CGROUP
> for CONFIG_CGROUPS.
>
> Here is a fixed version (also includes a build fix on sk->classid).
>
> cls_cgroup: Store classid in struct sock
BTW I made sure to apply this version.
^ permalink raw reply
* Re: [patch] pppoe: uninitialized variable in pppoe_flush_dev()
From: David Miller @ 2010-05-24 6:50 UTC (permalink / raw)
To: error27; +Cc: mostrows, eric.dumazet, jpirko, denys, netdev, kernel-janitors
In-Reply-To: <20100522202534.GO22515@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Sat, 22 May 2010 22:27:48 +0200
> This assignment got deleted along with the checks by mistake. This
> comes from: 8753d29fd "pppoe: remove unnecessary checks in
> pppoe_flush_dev"
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied, thanks Dan.
^ permalink raw reply
* Re: [PATCH 0/2] ISDN fixes for 2.6.35
From: David Miller @ 2010-05-24 6:52 UTC (permalink / raw)
To: isdn; +Cc: tilman, hjlipp, i4ldeveloper, netdev, linux-kernel, keil
In-Reply-To: <201005231301.50967.isdn@linux-pingi.de>
From: Karsten Keil <isdn@linux-pingi.de>
Date: Sun, 23 May 2010 13:01:50 +0200
> On Sonntag, 23. Mai 2010 03:14:43 Tilman Schmidt wrote:
>> Karsten, David,
>>
>> following are two patches to the CAPI subsystem and the Gigaset
>> driver I'd like to see included in kernel release 2.6.35.
>> Together they fix a reported hang of the userspace command
>> "capiinit stop".
>
> Acked-by: Karsten Keil <isdn@linux-pingi.de>
All applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] net/irda: bfin_sir: IRDA is not affected by anomaly 05000230
From: David Miller @ 2010-05-24 6:54 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel, graf.yang
In-Reply-To: <1274601610-882-1-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Sun, 23 May 2010 04:00:10 -0400
> From: Graf Yang <graf.yang@analog.com>
>
> Anomaly 05000230 (over sampling of the UART STOP bit) applies only when
> the peripheral is operating in UART mode. So drop the anomaly handling
> in the IRDA code.
>
> Signed-off-by: Graf Yang <graf.yang@analog.com>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied, thanks.
^ permalink raw reply
* Re: cls_cgroup: Store classid in struct sock
From: David Miller @ 2010-05-24 6:55 UTC (permalink / raw)
To: herbert; +Cc: nhorman, eric.dumazet, bmb, tgraf, nhorman, netdev
In-Reply-To: <20100523.234441.66200781.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sun, 23 May 2010 23:44:41 -0700 (PDT)
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Sat, 22 May 2010 11:49:57 +1000
>
>> On Fri, May 21, 2010 at 12:40:54PM -0400, Neil Horman wrote:
>>>
>>> There may also be an issue with the setting of the classid (possible use of the
>>> wrong subsys id value when grabbing our cgroup_subsys_state), but I'm checking
>>> on that now.
>>
>> Actually, I think it's because my patch mistook CONFIG_CGROUP
>> for CONFIG_CGROUPS.
>>
>> Here is a fixed version (also includes a build fix on sk->classid).
>>
>> cls_cgroup: Store classid in struct sock
>
> BTW I made sure to apply this version.
Actually I had to revert, doesn't build:
CC [M] drivers/net/pppoe.o
In file included from net/socket.c:97:
include/net/cls_cgroup.h:22: error: field ‘css’ has incomplete type
make[1]: *** [net/socket.o] Error 1
make: *** [net] Error 2
make: *** Waiting for unfinished jobs....
Probably you only tested the build with cgroups enabled?
^ permalink raw reply
* Re: [PATCH 1/2] ipv6: Store ndisc_nodeid in IP6CB().
From: David Miller @ 2010-05-24 6:58 UTC (permalink / raw)
To: bmb; +Cc: tgraf, nhorman, nhorman, eric.dumazet, herbert, netdev
In-Reply-To: <20100519.195536.32704411.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 19 May 2010 19:55:36 -0700 (PDT)
>
> There is no reason we need to use up space in the generic
> SKB area for this. All packet input paths in ipv6 explicitly
> clear out the IP6CB() area and therefore the default value
> for ndisc_nodeid will be correct.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Turns out the patch doesn't build, because it throws the
DCCP control block beyond the skb->cb[] size of 48 bytes
with ipv6 enabled on 64-bit.
Ho hum...
^ permalink raw reply
* Re: cls_cgroup: Store classid in struct sock
From: Herbert Xu @ 2010-05-24 7:07 UTC (permalink / raw)
To: David Miller; +Cc: nhorman, eric.dumazet, bmb, tgraf, nhorman, netdev
In-Reply-To: <20100523.235557.165343768.davem@davemloft.net>
On Sun, May 23, 2010 at 11:55:57PM -0700, David Miller wrote:
>
> Probably you only tested the build with cgroups enabled?
Indeed, that does seem to be the problem here. It turns out
that their struct is only declared when CONFIG_CGROUPS is defined,
how annoying.
Oh well I guess I'll follow their example :)
cls_cgroup: Store classid in struct sock
Up until now cls_cgroup has relied on fetching the classid out of
the current executing thread. This runs into trouble when a packet
processing is delayed in which case it may execute out of another
thread's context.
Furthermore, even when a packet is not delayed we may fail to
classify it if soft IRQs have been disabled, because this scenario
is indistinguishable from one where a packet unrelated to the
current thread is processed by a real soft IRQ.
In fact, the current semantics is inherently broken, as a single
skb may be constructed out of the writes of two different tasks.
A different manifestation of this problem is when the TCP stack
transmits in response of an incoming ACK. This is currently
unclassified.
As we already have a concept of packet ownership for accounting
purposes in the skb->sk pointer, this is a natural place to store
the classid in a persistent manner.
This patch adds the cls_cgroup classid in struct sock, filling up
an existing hole on 64-bit :)
The value is set at socket creation time. So all sockets created
via socket(2) automatically gains the ID of the thread creating it.
Whenever another process touches the socket by either reading or
writing to it, we will change the socket classid to that of the
process if it has a valid (non-zero) classid.
For sockets created on inbound connections through accept(2), we
inherit the classid of the original listening socket through
sk_clone, possibly preceding the actual accept(2) call.
In order to minimise risks, I have not made this the authoritative
classid. For now it is only used as a backup when we execute
with soft IRQs disabled. Once we're completely happy with its
semantics we can use it as the sole classid.
Footnote: I have rearranged the error path on cls_group module
creation. If we didn't do this, then there is a window where
someone could create a tc rule using cls_group before the cgroup
subsystem has been registered.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/include/net/cls_cgroup.h b/include/net/cls_cgroup.h
new file mode 100644
index 0000000..f9a0b01
--- /dev/null
+++ b/include/net/cls_cgroup.h
@@ -0,0 +1,63 @@
+/*
+ * cls_cgroup.h Control Group Classifier
+ *
+ * Authors: Thomas Graf <tgraf@suug.ch>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ */
+
+#ifndef _NET_CLS_CGROUP_H
+#define _NET_CLS_CGROUP_H
+
+#include <linux/cgroup.h>
+#include <linux/hardirq.h>
+#include <linux/rcupdate.h>
+
+#ifdef CONFIG_CGROUPS
+struct cgroup_cls_state
+{
+ struct cgroup_subsys_state css;
+ u32 classid;
+};
+
+#ifdef CONFIG_NET_CLS_CGROUP
+static inline u32 task_cls_classid(struct task_struct *p)
+{
+ if (in_interrupt())
+ return 0;
+
+ return container_of(task_subsys_state(p, net_cls_subsys_id),
+ struct cgroup_cls_state, css).classid;
+}
+#else
+extern int net_cls_subsys_id;
+
+static inline u32 task_cls_classid(struct task_struct *p)
+{
+ int id;
+ u32 classid;
+
+ if (in_interrupt())
+ return 0;
+
+ rcu_read_lock();
+ id = rcu_dereference(net_cls_subsys_id);
+ if (id >= 0)
+ classid = container_of(task_subsys_state(p, id),
+ struct cgroup_cls_state, css)->classid;
+ rcu_read_unlock();
+
+ return classid;
+}
+#endif
+#else
+static inline u32 task_cls_classid(struct task_struct *p)
+{
+ return 0;
+}
+#endif
+#endif /* _NET_CLS_CGROUP_H */
diff --git a/include/net/sock.h b/include/net/sock.h
index 5697caf..d24f382 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -312,7 +312,7 @@ struct sock {
void *sk_security;
#endif
__u32 sk_mark;
- /* XXX 4 bytes hole on 64 bit */
+ u32 sk_classid;
void (*sk_state_change)(struct sock *sk);
void (*sk_data_ready)(struct sock *sk, int bytes);
void (*sk_write_space)(struct sock *sk);
@@ -1074,6 +1074,14 @@ extern void *sock_kmalloc(struct sock *sk, int size,
extern void sock_kfree_s(struct sock *sk, void *mem, int size);
extern void sk_send_sigurg(struct sock *sk);
+#ifdef CONFIG_CGROUPS
+extern void sock_update_classid(struct sock *sk);
+#else
+static inline void sock_update_classid(struct sock *sk)
+{
+}
+#endif
+
/*
* Functions to fill in entries in struct proto_ops when a protocol
* does not implement a particular function.
diff --git a/net/core/sock.c b/net/core/sock.c
index bf88a16..a05ae7f 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -123,6 +123,7 @@
#include <linux/net_tstamp.h>
#include <net/xfrm.h>
#include <linux/ipsec.h>
+#include <net/cls_cgroup.h>
#include <linux/filter.h>
@@ -217,6 +218,11 @@ __u32 sysctl_rmem_default __read_mostly = SK_RMEM_MAX;
int sysctl_optmem_max __read_mostly = sizeof(unsigned long)*(2*UIO_MAXIOV+512);
EXPORT_SYMBOL(sysctl_optmem_max);
+#if defined(CONFIG_CGROUPS) && !defined(CONFIG_NET_CLS_CGROUP)
+int net_cls_subsys_id = -1;
+EXPORT_SYMBOL_GPL(net_cls_subsys_id);
+#endif
+
static int sock_set_timeout(long *timeo_p, char __user *optval, int optlen)
{
struct timeval tv;
@@ -1050,6 +1056,16 @@ static void sk_prot_free(struct proto *prot, struct sock *sk)
module_put(owner);
}
+#ifdef CONFIG_CGROUPS
+void sock_update_classid(struct sock *sk)
+{
+ u32 classid = task_cls_classid(current);
+
+ if (classid && classid != sk->sk_classid)
+ sk->sk_classid = classid;
+}
+#endif
+
/**
* sk_alloc - All socket objects are allocated here
* @net: the applicable net namespace
@@ -1073,6 +1089,8 @@ struct sock *sk_alloc(struct net *net, int family, gfp_t priority,
sock_lock_init(sk);
sock_net_set(sk, get_net(net));
atomic_set(&sk->sk_wmem_alloc, 1);
+
+ sock_update_classid(sk);
}
return sk;
diff --git a/net/sched/cls_cgroup.c b/net/sched/cls_cgroup.c
index 2211803..766124b 100644
--- a/net/sched/cls_cgroup.c
+++ b/net/sched/cls_cgroup.c
@@ -16,14 +16,11 @@
#include <linux/errno.h>
#include <linux/skbuff.h>
#include <linux/cgroup.h>
+#include <linux/rcupdate.h>
#include <net/rtnetlink.h>
#include <net/pkt_cls.h>
-
-struct cgroup_cls_state
-{
- struct cgroup_subsys_state css;
- u32 classid;
-};
+#include <net/sock.h>
+#include <net/cls_cgroup.h>
static struct cgroup_subsys_state *cgrp_create(struct cgroup_subsys *ss,
struct cgroup *cgrp);
@@ -112,6 +109,10 @@ static int cls_cgroup_classify(struct sk_buff *skb, struct tcf_proto *tp,
struct cls_cgroup_head *head = tp->root;
u32 classid;
+ rcu_read_lock();
+ classid = task_cls_state(current)->classid;
+ rcu_read_unlock();
+
/*
* Due to the nature of the classifier it is required to ignore all
* packets originating from softirq context as accessing `current'
@@ -122,12 +123,12 @@ static int cls_cgroup_classify(struct sk_buff *skb, struct tcf_proto *tp,
* calls by looking at the number of nested bh disable calls because
* softirqs always disables bh.
*/
- if (softirq_count() != SOFTIRQ_OFFSET)
- return -1;
-
- rcu_read_lock();
- classid = task_cls_state(current)->classid;
- rcu_read_unlock();
+ if (softirq_count() != SOFTIRQ_OFFSET) {
+ /* If there is an sk_classid we'll use that. */
+ if (!skb->sk)
+ return -1;
+ classid = skb->sk->sk_classid;
+ }
if (!classid)
return -1;
@@ -289,18 +290,35 @@ static struct tcf_proto_ops cls_cgroup_ops __read_mostly = {
static int __init init_cgroup_cls(void)
{
- int ret = register_tcf_proto_ops(&cls_cgroup_ops);
- if (ret)
- return ret;
+ int ret;
+
ret = cgroup_load_subsys(&net_cls_subsys);
if (ret)
- unregister_tcf_proto_ops(&cls_cgroup_ops);
+ goto out;
+
+#ifndef CONFIG_NET_CLS_CGROUP
+ /* We can't use rcu_assign_pointer because this is an int. */
+ smp_wmb();
+ net_cls_subsys_id = net_cls_subsys.subsys_id;
+#endif
+
+ ret = register_tcf_proto_ops(&cls_cgroup_ops);
+ if (ret)
+ cgroup_unload_subsys(&net_cls_subsys);
+
+out:
return ret;
}
static void __exit exit_cgroup_cls(void)
{
unregister_tcf_proto_ops(&cls_cgroup_ops);
+
+#ifndef CONFIG_NET_CLS_CGROUP
+ net_cls_subsys_id = -1;
+ synchronize_rcu();
+#endif
+
cgroup_unload_subsys(&net_cls_subsys);
}
diff --git a/net/socket.c b/net/socket.c
index f9f7d08..367d547 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -94,6 +94,7 @@
#include <net/compat.h>
#include <net/wext.h>
+#include <net/cls_cgroup.h>
#include <net/sock.h>
#include <linux/netfilter.h>
@@ -558,6 +559,8 @@ static inline int __sock_sendmsg(struct kiocb *iocb, struct socket *sock,
struct sock_iocb *si = kiocb_to_siocb(iocb);
int err;
+ sock_update_classid(sock->sk);
+
si->sock = sock;
si->scm = NULL;
si->msg = msg;
@@ -684,6 +687,8 @@ static inline int __sock_recvmsg_nosec(struct kiocb *iocb, struct socket *sock,
{
struct sock_iocb *si = kiocb_to_siocb(iocb);
+ sock_update_classid(sock->sk);
+
si->sock = sock;
si->scm = NULL;
si->msg = msg;
@@ -777,6 +782,8 @@ static ssize_t sock_splice_read(struct file *file, loff_t *ppos,
if (unlikely(!sock->ops->splice_read))
return -EINVAL;
+ sock_update_classid(sock->sk);
+
return sock->ops->splice_read(sock, ppos, pipe, len, flags);
}
@@ -3069,6 +3076,8 @@ int kernel_setsockopt(struct socket *sock, int level, int optname,
int kernel_sendpage(struct socket *sock, struct page *page, int offset,
size_t size, int flags)
{
+ sock_update_classid(sock->sk);
+
if (sock->ops->sendpage)
return sock->ops->sendpage(sock, page, offset, size, flags);
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: cls_cgroup: Store classid in struct sock
From: David Miller @ 2010-05-24 7:14 UTC (permalink / raw)
To: herbert; +Cc: nhorman, eric.dumazet, bmb, tgraf, nhorman, netdev
In-Reply-To: <20100524070743.GA26871@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 24 May 2010 17:07:43 +1000
> On Sun, May 23, 2010 at 11:55:57PM -0700, David Miller wrote:
>>
>> Probably you only tested the build with cgroups enabled?
>
> Indeed, that does seem to be the problem here. It turns out
> that their struct is only declared when CONFIG_CGROUPS is defined,
> how annoying.
>
> Oh well I guess I'll follow their example :)
>
> cls_cgroup: Store classid in struct sock
Thanks for fixing this up, applied.
^ permalink raw reply
* [PATCH] fec: add support for PHY interface platform data
From: Baruch Siach @ 2010-05-24 7:31 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Baruch Siach, Sascha Hauer
In-Reply-To: <20100523.233224.186495044.davem@davemloft.net>
The i.MX25 PDK uses RMII to communicate with its PHY. This patch adds the
ability to configure RMII, based on platform data.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Acked-by: Greg Ungerer <gerg@uclinux.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/net/fec.c | 22 ++++++++++++++++++++++
drivers/net/fec.h | 2 ++
include/linux/fec.h | 21 +++++++++++++++++++++
3 files changed, 45 insertions(+), 0 deletions(-)
create mode 100644 include/linux/fec.h
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 42d9ac9..326465f 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -41,6 +41,7 @@
#include <linux/clk.h>
#include <linux/platform_device.h>
#include <linux/phy.h>
+#include <linux/fec.h>
#include <asm/cacheflush.h>
@@ -182,6 +183,7 @@ struct fec_enet_private {
struct phy_device *phy_dev;
int mii_timeout;
uint phy_speed;
+ phy_interface_t phy_interface;
int index;
int link;
int full_duplex;
@@ -1191,6 +1193,21 @@ fec_restart(struct net_device *dev, int duplex)
/* Set MII speed */
writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
+#ifdef FEC_MIIGSK_ENR
+ if (fep->phy_interface == PHY_INTERFACE_MODE_RMII) {
+ /* disable the gasket and wait */
+ writel(0, fep->hwp + FEC_MIIGSK_ENR);
+ while (readl(fep->hwp + FEC_MIIGSK_ENR) & 4)
+ udelay(1);
+
+ /* configure the gasket: RMII, 50 MHz, no loopback, no echo */
+ writel(1, fep->hwp + FEC_MIIGSK_CFGR);
+
+ /* re-enable the gasket */
+ writel(2, fep->hwp + FEC_MIIGSK_ENR);
+ }
+#endif
+
/* And last, enable the transmit and receive processing */
writel(2, fep->hwp + FEC_ECNTRL);
writel(0, fep->hwp + FEC_R_DES_ACTIVE);
@@ -1226,6 +1243,7 @@ static int __devinit
fec_probe(struct platform_device *pdev)
{
struct fec_enet_private *fep;
+ struct fec_platform_data *pdata;
struct net_device *ndev;
int i, irq, ret = 0;
struct resource *r;
@@ -1259,6 +1277,10 @@ fec_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ndev);
+ pdata = pdev->dev.platform_data;
+ if (pdata)
+ fep->phy_interface = pdata->phy;
+
/* This device has up to three irqs on some platforms */
for (i = 0; i < 3; i++) {
irq = platform_get_irq(pdev, i);
diff --git a/drivers/net/fec.h b/drivers/net/fec.h
index cc47f3f..2c48b25 100644
--- a/drivers/net/fec.h
+++ b/drivers/net/fec.h
@@ -43,6 +43,8 @@
#define FEC_R_DES_START 0x180 /* Receive descriptor ring */
#define FEC_X_DES_START 0x184 /* Transmit descriptor ring */
#define FEC_R_BUFF_SIZE 0x188 /* Maximum receive buff size */
+#define FEC_MIIGSK_CFGR 0x300 /* MIIGSK Configuration reg */
+#define FEC_MIIGSK_ENR 0x308 /* MIIGSK Enable reg */
#else
diff --git a/include/linux/fec.h b/include/linux/fec.h
new file mode 100644
index 0000000..5d3523d
--- /dev/null
+++ b/include/linux/fec.h
@@ -0,0 +1,21 @@
+/* include/linux/fec.h
+ *
+ * Copyright (c) 2009 Orex Computed Radiography
+ * Baruch Siach <baruch@tkos.co.il>
+ *
+ * Header file for the FEC platform data
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __LINUX_FEC_H__
+#define __LINUX_FEC_H__
+
+#include <linux/phy.h>
+
+struct fec_platform_data {
+ phy_interface_t phy;
+};
+
+#endif
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] fec: add support for PHY interface platform data
From: David Miller @ 2010-05-24 7:36 UTC (permalink / raw)
To: baruch; +Cc: netdev, s.hauer
In-Reply-To: <3fdc6da7f1b53fdea0e056d47d828e106c4e76c8.1274686230.git.baruch@tkos.co.il>
From: Baruch Siach <baruch@tkos.co.il>
Date: Mon, 24 May 2010 10:31:05 +0300
> The i.MX25 PDK uses RMII to communicate with its PHY. This patch adds the
> ability to configure RMII, based on platform data.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> Acked-by: Greg Ungerer <gerg@uclinux.org>
Applied, thanks.
^ permalink raw reply
* RE: Receiving of priority tagged packets
From: Vladislav Zolotarov @ 2010-05-24 7:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <1274646751.5020.78.camel@edumazet-laptop>
Great! Thanks. I'll check it shortly.
However this patch handles the problem only in the HW accelerated path, which is used only when the NIC supports the HW acceleration of RX VLAN parsing and (the most important) at least one VLAN is configured for the current device (this will initialize the dev->vlgrp, otherwise it's NULL and u r not allowed to call vlan_hwaccel_rx()). So if I haven’t configured any VLAN this patch won't help. Namely we need to fix netif_receive_skb(skb) as well.
I would also like to ask u another question: formally VID=0 is not a valid VID (according to the same spec).
However there is this ethX.0 semantics which is a bit confusing. So, don't u think that together with the patch below and the addition described above we should also forbid the configuration of VID=0 (vconfig add ethX 0)?
Thanks a lot again.
Vlad
> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: Sunday, May 23, 2010 11:33 PM
> To: Vladislav Zolotarov
> Cc: netdev@vger.kernel.org
> Subject: RE: Receiving of priority tagged packets
>
> Le dimanche 23 mai 2010 à 03:51 -0700, Vladislav Zolotarov a écrit :
> >
> > > -----Original Message-----
> > > From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On
> > > Behalf Of Vladislav Zolotarov
> > > Sent: Sunday, May 23, 2010 1:23 PM
> > > To: Eric Dumazet
> > > Cc: netdev@vger.kernel.org
> > > Subject: RE: Receiving of priority tagged packets
> > >
> > >
> > > > -----Original Message-----
> > > > From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> > > > Sent: Sunday, May 23, 2010 1:07 PM
> > > > To: Vladislav Zolotarov
> > > > Cc: netdev@vger.kernel.org
> > > > Subject: Re: Receiving of priority tagged packets
> > > >
> > > > Le dimanche 23 mai 2010 à 02:36 -0700, Vladislav Zolotarov a écrit :
> > > > > Hello,
> > > > > We were playing with FCoE in our labs and saw the strange behavior of
> > > Linux
> > > > networking stack in regard to priority-tagged frames (the ones that
> have a
> > > > zero VID in a VLAN tag). We saw that until we explicitly added a zero
> vlan
> > > > interface (vconfig add ethX 0) the stack refused to accept such packets
> > > both
> > > > in HW VLAN acceleration mode (skb is indicated using
> > > > vlan_hwaccel_receive_skb()) and in a regular mode (skb is indicated
> with
> > > > netif_receive_skb()).
> > > > >
> > > > > However "IEEE Std 802.1Q, 2006 Edition DRAFT D0.1" in section 6.7
> states
> > > > the following:
> > > > >
> > > > > Each Bridge Port shall support the following parameters for use by
> these
> > > > (EISS tagging and detagging) functions:
> > > > > c) an Acceptable Frame Types parameter with at least one of the
> > > > following values:
> > > > > 1) Admit Only VLAN-tagged frames;
> > > > > 2) Admit Only Untagged and Priority-tagged frames;
> > > > > 3) Admit All frames
> > > > >
> > > > > So I guess this means that priority tagged frames should be accepted
> > > > together with the untagged frames on the default interface ethX.
> > > > >
> > > > > Could anyone explain, pls., what's the expected behavior of the Linux
> > > > Networking Stack in regard to the priority-tagged frames and what's
> > > expected
> > > > to be configured in order to start accepting them?
> > > > >
> > > > > Thanks in advance,
> > > > > vlad
> > > >
> > > > So if eth0.0 is setup, incoming vlanid=0 frames are delivered to
> eth0.0,
> > > > OK ? (This works in and out since commit 05423b241311c93)
> > > >
> > > > Now, if eth0.0 is not setup, you believe these frames should be
> directed
> > > > to eth0, as if they were not tagged ?
> > > >
> > > > That seems a bit strange.
> > >
> > > Well, as far as I understood this is what IEEE 802.1Q spec states...
> >
> > From the same spec:
> >
> > ***************
> > 3.38 Priority-tagged frame: A tagged frame whose tag header carries
> priority information but carries no
> > VLAN identification information.
> > ***************
> >
> > Namely priority-tagged frames are frames that carry no VLAN identification
> information and namely should be treated as non-VLAN packets.
> >
> > However, as u mentioned above, current Networking Stack implementation
> handles them as if they have VID 0.
> >
> > These two are quite different ways to handle the frame, don’t u think?
>
> Following patch should fix it ?
>
> Fallback to ethX is ethX.0 is not used.
>
> diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
> index bd537fc..909f6e7 100644
> --- a/net/8021q/vlan_core.c
> +++ b/net/8021q/vlan_core.c
> @@ -8,6 +8,9 @@
> int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp,
> u16 vlan_tci, int polling)
> {
> + struct net_device *vlan_dev;
> + u16 vlan_id;
> +
> if (netpoll_rx(skb))
> return NET_RX_DROP;
>
> @@ -16,10 +19,14 @@ int __vlan_hwaccel_rx(struct sk_buff *skb, struct
> vlan_group *grp,
>
> skb->skb_iif = skb->dev->ifindex;
> __vlan_hwaccel_put_tag(skb, vlan_tci);
> - skb->dev = vlan_group_get_device(grp, vlan_tci & VLAN_VID_MASK);
> + vlan_id = vlan_tci & VLAN_VID_MASK;
> + vlan_dev = vlan_group_get_device(grp, vlan_id);
>
> - if (!skb->dev)
> - goto drop;
> + if (vlan_dev)
> + skb->dev = vlan_dev;
> + else
> + if (vlan_id)
> + goto drop;
>
> return (polling ? netif_receive_skb(skb) : netif_rx(skb));
>
> @@ -82,16 +89,22 @@ vlan_gro_common(struct napi_struct *napi, struct
> vlan_group *grp,
> unsigned int vlan_tci, struct sk_buff *skb)
> {
> struct sk_buff *p;
> + struct net_device *vlan_dev;
> + u16 vlan_id;
>
> if (skb_bond_should_drop(skb, ACCESS_ONCE(skb->dev->master)))
> goto drop;
>
> skb->skb_iif = skb->dev->ifindex;
> __vlan_hwaccel_put_tag(skb, vlan_tci);
> - skb->dev = vlan_group_get_device(grp, vlan_tci & VLAN_VID_MASK);
> -
> - if (!skb->dev)
> - goto drop;
> + vlan_id = vlan_tci & VLAN_VID_MASK;
> + vlan_dev = vlan_group_get_device(grp, vlan_id);
> +
> + if (vlan_dev)
> + skb->dev = vlan_dev;
> + else
> + if (vlan_id)
> + goto drop;
>
> for (p = napi->gro_list; p; p = p->next) {
> NAPI_GRO_CB(p)->same_flow =
>
>
>
>
^ permalink raw reply
* net/dccp: expansion of error code size
From: Yoichi Yuasa @ 2010-05-24 6:45 UTC (permalink / raw)
To: David S. Miller; +Cc: yuasa, linux-mips, netdev
Because MIPS's EDQUOT value is 1133(0x46d).
It's larger than u8.
Signed-off-by: Yoichi Yuasa <yuasa@linux-mips.org>
---
net/dccp/input.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/dccp/input.c b/net/dccp/input.c
index 58f7bc1..6beb6a7 100644
--- a/net/dccp/input.c
+++ b/net/dccp/input.c
@@ -124,9 +124,9 @@ static int dccp_rcv_closereq(struct sock *sk, struct sk_buff *skb)
return queued;
}
-static u8 dccp_reset_code_convert(const u8 code)
+static u16 dccp_reset_code_convert(const u8 code)
{
- const u8 error_code[] = {
+ const u16 error_code[] = {
[DCCP_RESET_CODE_CLOSED] = 0, /* normal termination */
[DCCP_RESET_CODE_UNSPECIFIED] = 0, /* nothing known */
[DCCP_RESET_CODE_ABORTED] = ECONNRESET,
@@ -148,7 +148,7 @@ static u8 dccp_reset_code_convert(const u8 code)
static void dccp_rcv_reset(struct sock *sk, struct sk_buff *skb)
{
- u8 err = dccp_reset_code_convert(dccp_hdr_reset(skb)->dccph_reset_code);
+ u16 err = dccp_reset_code_convert(dccp_hdr_reset(skb)->dccph_reset_code);
sk->sk_err = err;
--
1.7.1
^ permalink raw reply related
* RE: Receiving of priority tagged packets
From: Vladislav Zolotarov @ 2010-05-24 9:05 UTC (permalink / raw)
To: Vladislav Zolotarov, Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <8628FE4E7912BF47A96AE7DD7BAC0AADDDC6675C68@SJEXCHCCR02.corp.ad.broadcom.com>
HW accelerated flow worked:
1) I've configured ethX.0 interface on one side (RH5.4 standard kernel) and a regular interface ethY above the patched upstream kernel on the other side. ethX.0 and ethY IPs were configured to reside in the same subnet.
2) Then I've configured VID=7 interface above ethY to enable HW acceleration flow.
3) Configured a static ARP entry for ethX.0 for ethY IP and MAC. (ARP replies from ethY were sent without any VLAN tag and apparently haven't arrived to ethX.0. That's an example, why ethX.0 semantics is somewhat problematic).
4) Then I successfully pinged both ethX.0 from ethY and vice versa.
So, considering my previous post this patch looks like working.
Thanks,
vlad
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
> Behalf Of Vladislav Zolotarov
> Sent: Monday, May 24, 2010 10:44 AM
> To: Eric Dumazet
> Cc: netdev@vger.kernel.org
> Subject: RE: Receiving of priority tagged packets
>
> Great! Thanks. I'll check it shortly.
>
> However this patch handles the problem only in the HW accelerated path, which
> is used only when the NIC supports the HW acceleration of RX VLAN parsing and
> (the most important) at least one VLAN is configured for the current device
> (this will initialize the dev->vlgrp, otherwise it's NULL and u r not allowed
> to call vlan_hwaccel_rx()). So if I haven’t configured any VLAN this patch
> won't help. Namely we need to fix netif_receive_skb(skb) as well.
>
> I would also like to ask u another question: formally VID=0 is not a valid
> VID (according to the same spec).
> However there is this ethX.0 semantics which is a bit confusing. So, don't u
> think that together with the patch below and the addition described above we
> should also forbid the configuration of VID=0 (vconfig add ethX 0)?
>
> Thanks a lot again.
> Vlad
>
>
>
> > -----Original Message-----
> > From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> > Sent: Sunday, May 23, 2010 11:33 PM
> > To: Vladislav Zolotarov
> > Cc: netdev@vger.kernel.org
> > Subject: RE: Receiving of priority tagged packets
> >
> > Le dimanche 23 mai 2010 à 03:51 -0700, Vladislav Zolotarov a écrit :
> > >
> > > > -----Original Message-----
> > > > From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org]
> > On
> > > > Behalf Of Vladislav Zolotarov
> > > > Sent: Sunday, May 23, 2010 1:23 PM
> > > > To: Eric Dumazet
> > > > Cc: netdev@vger.kernel.org
> > > > Subject: RE: Receiving of priority tagged packets
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> > > > > Sent: Sunday, May 23, 2010 1:07 PM
> > > > > To: Vladislav Zolotarov
> > > > > Cc: netdev@vger.kernel.org
> > > > > Subject: Re: Receiving of priority tagged packets
> > > > >
> > > > > Le dimanche 23 mai 2010 à 02:36 -0700, Vladislav Zolotarov a écrit :
> > > > > > Hello,
> > > > > > We were playing with FCoE in our labs and saw the strange behavior
> of
> > > > Linux
> > > > > networking stack in regard to priority-tagged frames (the ones that
> > have a
> > > > > zero VID in a VLAN tag). We saw that until we explicitly added a zero
> > vlan
> > > > > interface (vconfig add ethX 0) the stack refused to accept such
> packets
> > > > both
> > > > > in HW VLAN acceleration mode (skb is indicated using
> > > > > vlan_hwaccel_receive_skb()) and in a regular mode (skb is indicated
> > with
> > > > > netif_receive_skb()).
> > > > > >
> > > > > > However "IEEE Std 802.1Q, 2006 Edition DRAFT D0.1" in section 6.7
> > states
> > > > > the following:
> > > > > >
> > > > > > Each Bridge Port shall support the following parameters for use by
> > these
> > > > > (EISS tagging and detagging) functions:
> > > > > > c) an Acceptable Frame Types parameter with at least one of the
> > > > > following values:
> > > > > > 1) Admit Only VLAN-tagged frames;
> > > > > > 2) Admit Only Untagged and Priority-tagged frames;
> > > > > > 3) Admit All frames
> > > > > >
> > > > > > So I guess this means that priority tagged frames should be
> accepted
> > > > > together with the untagged frames on the default interface ethX.
> > > > > >
> > > > > > Could anyone explain, pls., what's the expected behavior of the
> Linux
> > > > > Networking Stack in regard to the priority-tagged frames and what's
> > > > expected
> > > > > to be configured in order to start accepting them?
> > > > > >
> > > > > > Thanks in advance,
> > > > > > vlad
> > > > >
> > > > > So if eth0.0 is setup, incoming vlanid=0 frames are delivered to
> > eth0.0,
> > > > > OK ? (This works in and out since commit 05423b241311c93)
> > > > >
> > > > > Now, if eth0.0 is not setup, you believe these frames should be
> > directed
> > > > > to eth0, as if they were not tagged ?
> > > > >
> > > > > That seems a bit strange.
> > > >
> > > > Well, as far as I understood this is what IEEE 802.1Q spec states...
> > >
> > > From the same spec:
> > >
> > > ***************
> > > 3.38 Priority-tagged frame: A tagged frame whose tag header carries
> > priority information but carries no
> > > VLAN identification information.
> > > ***************
> > >
> > > Namely priority-tagged frames are frames that carry no VLAN
> identification
> > information and namely should be treated as non-VLAN packets.
> > >
> > > However, as u mentioned above, current Networking Stack implementation
> > handles them as if they have VID 0.
> > >
> > > These two are quite different ways to handle the frame, don’t u think?
> >
> > Following patch should fix it ?
> >
> > Fallback to ethX is ethX.0 is not used.
> >
> > diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
> > index bd537fc..909f6e7 100644
> > --- a/net/8021q/vlan_core.c
> > +++ b/net/8021q/vlan_core.c
> > @@ -8,6 +8,9 @@
> > int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp,
> > u16 vlan_tci, int polling)
> > {
> > + struct net_device *vlan_dev;
> > + u16 vlan_id;
> > +
> > if (netpoll_rx(skb))
> > return NET_RX_DROP;
> >
> > @@ -16,10 +19,14 @@ int __vlan_hwaccel_rx(struct sk_buff *skb, struct
> > vlan_group *grp,
> >
> > skb->skb_iif = skb->dev->ifindex;
> > __vlan_hwaccel_put_tag(skb, vlan_tci);
> > - skb->dev = vlan_group_get_device(grp, vlan_tci & VLAN_VID_MASK);
> > + vlan_id = vlan_tci & VLAN_VID_MASK;
> > + vlan_dev = vlan_group_get_device(grp, vlan_id);
> >
> > - if (!skb->dev)
> > - goto drop;
> > + if (vlan_dev)
> > + skb->dev = vlan_dev;
> > + else
> > + if (vlan_id)
> > + goto drop;
> >
> > return (polling ? netif_receive_skb(skb) : netif_rx(skb));
> >
> > @@ -82,16 +89,22 @@ vlan_gro_common(struct napi_struct *napi, struct
> > vlan_group *grp,
> > unsigned int vlan_tci, struct sk_buff *skb)
> > {
> > struct sk_buff *p;
> > + struct net_device *vlan_dev;
> > + u16 vlan_id;
> >
> > if (skb_bond_should_drop(skb, ACCESS_ONCE(skb->dev->master)))
> > goto drop;
> >
> > skb->skb_iif = skb->dev->ifindex;
> > __vlan_hwaccel_put_tag(skb, vlan_tci);
> > - skb->dev = vlan_group_get_device(grp, vlan_tci & VLAN_VID_MASK);
> > -
> > - if (!skb->dev)
> > - goto drop;
> > + vlan_id = vlan_tci & VLAN_VID_MASK;
> > + vlan_dev = vlan_group_get_device(grp, vlan_id);
> > +
> > + if (vlan_dev)
> > + skb->dev = vlan_dev;
> > + else
> > + if (vlan_id)
> > + goto drop;
> >
> > for (p = napi->gro_list; p; p = p->next) {
> > NAPI_GRO_CB(p)->same_flow =
> >
> >
> >
> >
>
> N�����r��y���b�X��ǧv�^�){.n�+���z�^�)���w*
> jg���\x1e�����ݢj/���z�ޖ��2�ޙ���&�)ߡ�a��\x7f��\x1e�G���h�\x0f�j:+v���w�٥
^ permalink raw reply
* RE: ixgbe and SRIOV failure in driver?
From: Fischer, Anna @ 2010-05-24 9:49 UTC (permalink / raw)
To: Rose, Gregory V; +Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org
In-Reply-To: <43F901BD926A4E43B106BF17856F0755A79C061C@orsmsx508.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2045 bytes --]
> Subject: RE: ixgbe and SRIOV failure in driver?
>
> >-----Original Message-----
> >From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> >On Behalf Of Fischer, Anna
> >Sent: Friday, May 21, 2010 9:33 AM
> >To: e1000-devel@lists.sourceforge.net; netdev@vger.kernel.org
> >Subject: ixgbe and SRIOV failure in driver?
> >
> >I am running a system with 3 Intel NICs. Two of them are 82598 devices,
> >and one is a SRIOV capable 82599.
> >
> >All devices use the ixgbe driver. What happens (I believe) now is that
> >when the driver loads at first, it sees the 82598 first (because of its
> >position in the PCI tree) and then it says "Device not IOV capable -
> >switching off IOV."
> >
> >So then it switches into non-IOV mode, and I can never enable SRIOV on
> >my 82599, because the driver does not enable it any more for further
> >devices.
> >
> >So to get around this issue, I tried to use pciback.hide to hide the
> >82598 devices from the OS. That way I was hoping that the driver would
> >switch on SRIOV on my 82599. However, then I got a kernel panic on boot
> >(see below).
> >
> >I am running Xen 4 and the Dom0 kernel is a 2.6.31 kernel.
>
> The ixgbe driver included with the 2.6.31 kernel does not support SR-IOV.
> Where did you get the driver that does? Please run ethtool -i <ethx>
> and
> post the results.
I have installed the driver separately on my pv-ops kernel.
[root@211052610-f-cpu ~]# ethtool -i eth
driver: ixgbe
version: 2.0.75.7-NAPI
firmware-version: 0.9-3
bus-info: 0000:05:00.0
I have attached a log on when the drivers loads. There is a bit more debugging information enabled. You can see that the driver loads at first on devices 0000:02:00.0 and 0000:02:00.1 which are 82598 devices and don't support SRIOV. So the driver switches off SRIOV. When it loads it on the 82599 which sits on 0000:05:00.0, it does not even have the SRIOV parameter enabled anymore, even though I load the driver with 'modprobe ixgbe max_vfs=4'.
Thanks,
Anna
[-- Attachment #2: ixgbe-error.log --]
[-- Type: application/octet-stream, Size: 4755 bytes --]
[ 719.100280] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 2.0.75.7-NAPI
[ 719.100289] Copyright (c) 1999-2010 Intel Corporation.
[ 719.100383] ixgbe 0000:02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 719.100443] ixgbe 0000:02:00.0: setting latency timer to 64
[ 719.159312] ixgbe: I/O Virtualization (IOV) set to 2
[ 719.159321] ixgbe: 0000:02:00.0: ixgbe_check_options: Checking IOV capabilities.
[ 719.159328] ixgbe: 0000:02:00.0: ixgbe_check_options: IOV is not supported on this hardware. Disabling IOV.
[ 719.159336] ixgbe: 0000:02:00.0: ixgbe_probe: SR-IOV disabled! Not probing VF.
[ 719.164704] ixgbe 0000:02:00.0: irq 37 for MSI/MSI-X
[ 719.164714] ixgbe 0000:02:00.0: irq 38 for MSI/MSI-X
[ 719.164722] ixgbe 0000:02:00.0: irq 39 for MSI/MSI-X
[ 719.164789] ixgbe: 0000:02:00.0: ixgbe_init_interrupt_scheme: Multiqueue Enabled: Rx Queue count = 2, Tx Queue count = 2
[ 719.165779] ixgbe: eth0: ixgbe_probe: (PCI Express:2.5Gb/s:Width x8) 00:24:a8:c5:08:09
[ 719.165857] ixgbe: eth0: ixgbe_probe: MAC: 1, PHY: 0, PBA No: e15728-001
[ 719.165859] ixgbe: eth0: ixgbe_probe: GRO is enabled
[ 719.165860] ixgbe: eth0: ixgbe_probe: Intel(R) 10 Gigabit Network Connection
[ 719.165883] ixgbe 0000:02:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[ 719.165908] ixgbe 0000:02:00.1: setting latency timer to 64
[ 719.223063] ixgbe: 0000:02:00.1: ixgbe_check_options: Checking IOV capabilities.
[ 719.223071] ixgbe: 0000:02:00.1: ixgbe_check_options: IOV disabled.
[ 719.223077] ixgbe: 0000:02:00.1: ixgbe_probe: SR-IOV disabled! Not probing VF.
[ 719.228517] ixgbe 0000:02:00.1: irq 40 for MSI/MSI-X
[ 719.228526] ixgbe 0000:02:00.1: irq 41 for MSI/MSI-X
[ 719.228535] ixgbe 0000:02:00.1: irq 42 for MSI/MSI-X
[ 719.228589] ixgbe: 0000:02:00.1: ixgbe_init_interrupt_scheme: Multiqueue Enabled: Rx Queue count = 2, Tx Queue count = 2
[ 719.229595] ixgbe: eth1: ixgbe_probe: (PCI Express:2.5Gb/s:Width x8) 00:24:a8:c5:08:08
[ 719.229675] ixgbe: eth1: ixgbe_probe: MAC: 1, PHY: 0, PBA No: e15728-001
[ 719.229677] ixgbe: eth1: ixgbe_probe: GRO is enabled
[ 719.229679] ixgbe: eth1: ixgbe_probe: Intel(R) 10 Gigabit Network Connection
[ 719.229699] ixgbe 0000:05:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 719.229732] ixgbe 0000:05:00.0: setting latency timer to 64
[ 719.305494] ixgbe: 0000:05:00.0: ixgbe_check_options: Checking IOV capabilities.
[ 719.305503] ixgbe: 0000:05:00.0: ixgbe_check_options: IOV disabled.
[ 719.305510] ixgbe: 0000:05:00.0: ixgbe_check_options: Flow Director hash filtering enabled
[ 719.305516] ixgbe: 0000:05:00.0: ixgbe_check_options: Flow Director allocated 64kB of packet buffer
[ 719.305524] ixgbe: 0000:05:00.0: ixgbe_check_options: ATR Tx Packet sample rate set to default of 20
[ 719.305530] ixgbe: 0000:05:00.0: ixgbe_probe: SR-IOV disabled! Not probing VF.
[ 719.331724] ixgbe 0000:05:00.0: irq 43 for MSI/MSI-X
[ 719.331734] ixgbe 0000:05:00.0: irq 44 for MSI/MSI-X
[ 719.331741] ixgbe 0000:05:00.0: irq 45 for MSI/MSI-X
[ 719.331810] ixgbe: 0000:05:00.0: ixgbe_init_interrupt_scheme: Multiqueue Enabled: Rx Queue count = 2, Tx Queue count = 2
[ 719.334841] ixgbe: eth1: ixgbe_probe: (PCI Express:5.0Gb/s:Width x4) 00:1b:21:5a:29:5a
[ 719.334932] ixgbe: eth1: ixgbe_probe: MAC: 2, PHY: 15, SFP+: 5, PBA No: e68787-002
[ 719.334934] ixgbe: eth1: ixgbe_probe: GRO is enabled
[ 719.334936] ixgbe: eth1: ixgbe_probe: HW RSC is enabled
[ 719.335750] ixgbe: eth1: ixgbe_probe: Intel(R) 10 Gigabit Network Connection
[ 719.675998] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 719.688653] ixgbe: eth0: ixgbe_watchdog_task: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[ 719.739952] ADDRCONF(NETDEV_UP): eth2: link is not ready
[ 719.744768] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 719.750402] ixgbe: eth2: ixgbe_watchdog_task: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[ 719.753023] ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
[ 719.993939] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 720.007018] ixgbe: eth0: ixgbe_watchdog_task: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[ 720.050958] ADDRCONF(NETDEV_UP): eth2: link is not ready
[ 720.053396] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 720.062087] ixgbe: eth2: ixgbe_watchdog_task: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[ 720.062925] ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
[ 730.684244] eth0: no IPv6 routers present
[ 730.788245] eth2: no IPv6 routers present
[ 781.234515] ADDRCONF(NETDEV_UP): eth: link is not ready
[ 781.374284] ixgbe: eth: ixgbe_watchdog_task: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[ 781.376958] ADDRCONF(NETDEV_CHANGE): eth: link becomes ready
[ 792.102249] eth: no IPv6 routers present
^ permalink raw reply
* Re: [regression] fib6_del() bug from 2.6.34-rc1 still present in 2.6.34
From: Julien BLACHE @ 2010-05-24 9:54 UTC (permalink / raw)
To: Shan Wei; +Cc: netdev, linux-kernel
In-Reply-To: <4BF9DCB7.8040308@cn.fujitsu.com>
Shan Wei <shanwei@cn.fujitsu.com> wrote:
Hi,
> I saw the warning on 2.6.34-rc3. But on net-next tree the warning disappeared.
> So I think the bug is fixed in net-next tree. My NIC driver is r8169.
>
> The net-next tree is newer than 2.6.34, maybe the fix is not queued to 2.6.34.
> So the warning also be present in 2.6.34.
> Can you try net-next tree firstly?
Unfortunately, this tree has a number of issues that prevent a
successful boot into userland on my machine :/
Any idea what the fix(es) is so I can test it out?
JB.
--
Julien BLACHE <http://www.jblache.org>
<jb@jblache.org> GPG KeyID 0xF5D65169
^ 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