* Re: [PATCH V6] bgmac: driver for GBit MAC core on BCMA bus
From: Rafał Miłecki @ 2013-01-10 7:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev, romieu, joe
In-Reply-To: <20130109.233744.2066803110314306055.davem@davemloft.net>
2013/1/10 David Miller <davem@davemloft.net>:
> Applied, thanks.
Great! :)
I wish to say big "thank you" too all of you who helped me getting
this driver in shape and making it acceptable for net inclusion. I
really appreciate your help and as always, thanks to you, I've learned
new things. Sorry you had to repeat some of them multiple times ;)
I'm leaving for a week tomorrow and my Internet access will be very
limited. I plan to get back to the development when I'm back. Any help
is welcome of course :)
--
Rafał
^ permalink raw reply
* Re: [PATCH net-next 0/6] Use FIELD_SIZEOF().
From: David Miller @ 2013-01-10 7:38 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
In-Reply-To: <50EDA6A1.6070409@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Thu, 10 Jan 2013 02:19:29 +0900
> Use FIELD_SIZEOF() macro instead of dummy pointer to check size
> of cb in struct sk_buff.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH V6] bgmac: driver for GBit MAC core on BCMA bus
From: David Miller @ 2013-01-10 7:37 UTC (permalink / raw)
To: zajec5; +Cc: netdev, romieu, joe
In-Reply-To: <1357711583-10779-1-git-send-email-zajec5@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: tainted warnings with tcp splicing in 3.7.1
From: Willy Tarreau @ 2013-01-10 7:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Christian Becker, David Miller, netdev@vger.kernel.org
In-Reply-To: <1357801149.27446.1142.camel@edumazet-glaptop>
On Wed, Jan 09, 2013 at 10:59:09PM -0800, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> On Wed, 2013-01-09 at 09:09 -0800, Eric Dumazet wrote:
>
> > My feeling is that tcp_recv_skb() should eat skbs instead of only
> > finding the right one
> >
>
> Thats indeed the case.
>
> > Thats because skb_splice_bits() releases the socket lock before calling
> > splice_to_pipe()
> >
> > Once socket is released, other incoming TCP frames can be processed, and
> > the skb we are actually processing might be 'collapsed' into smaller
> > units.
> >
> > Christian, if I send you patches, are you OK to test them ?
> >
> >
>
> Here is the patch fixing this issue.
>
> Thanks a lot for your report, this is a very very old bug.
>
> GRO being more deployed, and with TCP coalescing as well, chances to
> trigger this bug increased a lot.
>
> To reproduce it, I had to force MSS=400 and stress the receiver,
> adding extra delays in skb_splice_bits() with socket lock being not
> held.
FWIW, I tested your patch here and did not notice any regression
compared to last week-end tests, at various MTU size combinations.
Cheers,
Willy
^ permalink raw reply
* Re: [PATCH 1/2] ipv6: avoid blackhole and prohibited entries upon prefix purge [v3]
From: Romain KUNTZ @ 2013-01-10 7:06 UTC (permalink / raw)
To: nicolas.dichtel
Cc: YOSHIFUJI Hideaki, netdev@vger.kernel.org, Eric Dumazet, davem
In-Reply-To: <50ED88AF.3040705@6wind.com>
On Jan 9, 2013, at 16:11 , Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> Le 09/01/2013 15:37, Romain KUNTZ a écrit :
>> On Jan 8, 2013, at 18:18 , YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> wrote:
>>> Nicolas Dichtel wrote:
>>>> Le 08/01/2013 12:38, Romain KUNTZ a écrit :
>>>>> On Jan 7, 2013, at 16:43 , Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
>>>>>> Le 07/01/2013 12:30, Romain KUNTZ a écrit :
>>>>>>> Hello Nicolas,
>>>>>>>
>>>>>>> On Jan 7, 2013, at 11:25 , Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
>>>>>>>
>>>>>>>> Le 05/01/2013 22:44, Romain KUNTZ a écrit :
>>>>>>>>> Mobile IPv6 provokes a kernel Oops since commit 64c6d08e (ipv6:
>>>>>>>>> del unreachable route when an addr is deleted on lo), because
>>>>>>>>> ip6_route_lookup() may also return blackhole and prohibited
>>>>>>>>> entry. However, these entries have a NULL rt6i_table argument,
>>>>>>>>> which provokes an Oops in __ip6_del_rt() when trying to lock
>>>>>>>>> rt6i_table->tb6_lock.
>>>>>>>>>
>>>>>>>>> Beside, when purging a prefix, blakhole and prohibited entries
>>>>>>>>> should not be selected because they are not what we are looking
>>>>>>>>> for.
>>>>>>>>>
>>>>>>>>> We fix this by adding two new lookup flags (RT6_LOOKUP_F_NO_BLK_HOLE
>>>>>>>>> and RT6_LOOKUP_F_NO_PROHIBIT) in order to ensure that such entries
>>>>>>>>> are skipped during lookup and that the correct entry is returned.
>>>>>>>>>
>>>>>>>>> [v2]: use 'goto out;' instead of 'goto again;' to avoid unnecessary
>>>>>>>>> oprations on rt (as suggested by Eric Dumazet).
>>>>>>>>>
>>>>>>>>> Signed-off-by: Romain Kuntz <r.kuntz@ipflavors.com>
>>>>>>>>> ---
>>>>>>>>> include/net/ip6_route.h | 2 ++
>>>>>>>>> net/ipv6/addrconf.c | 4 +++-
>>>>>>>>> net/ipv6/fib6_rules.c | 4 ++++
>>>>>>>>> 3 files changed, 9 insertions(+), 1 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
>>>>>>>>> index 27d8318..3c93743 100644
>>>>>>>>> --- a/include/net/ip6_route.h
>>>>>>>>> +++ b/include/net/ip6_route.h
>>>>>>>>> @@ -30,6 +30,8 @@ struct route_info {
>>>>>>>>> #define RT6_LOOKUP_F_SRCPREF_TMP 0x00000008
>>>>>>>>> #define RT6_LOOKUP_F_SRCPREF_PUBLIC 0x00000010
>>>>>>>>> #define RT6_LOOKUP_F_SRCPREF_COA 0x00000020
>>>>>>>>> +#define RT6_LOOKUP_F_NO_BLK_HOLE 0x00000040
>>>>>>>>> +#define RT6_LOOKUP_F_NO_PROHIBIT 0x00000080
>>>>>>>>>
>>>>>>>>> /*
>>>>>>>>> * rt6_srcprefs2flags() and rt6_flags2srcprefs() translate
>>>>>>>>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>>>>>>>>> index 408cac4a..1891e23 100644
>>>>>>>>> --- a/net/ipv6/addrconf.c
>>>>>>>>> +++ b/net/ipv6/addrconf.c
>>>>>>>>> @@ -948,7 +948,9 @@ static void ipv6_del_addr(struct inet6_ifaddr *ifp)
>>>>>>>>> fl6.flowi6_oif = ifp->idev->dev->ifindex;
>>>>>>>>> fl6.daddr = prefix;
>>>>>>>>> rt = (struct rt6_info *)ip6_route_lookup(net, &fl6,
>>>>>>>>> - RT6_LOOKUP_F_IFACE);
>>>>>>>>> + RT6_LOOKUP_F_IFACE |
>>>>>>>>> + RT6_LOOKUP_F_NO_BLK_HOLE |
>>>>>>>>> + RT6_LOOKUP_F_NO_PROHIBIT);
>>>>>>>>>
>>>>>>>>> if (rt != net->ipv6.ip6_null_entry &&
>>>>>>>> Is it not simpler to test the result here (net->ipv6.ip6_blk_hole_entry and
>>>>>>>> net->ipv6.ip6_prohibit_entry) like for the null_entry?
>>>>>>>> It will also avoid adding more flags.
>>>>>>>
>>>>>>> Your proposal would only solve part of the problem (the Oops in __ip6_del_rt()). Another problem here is that blackhole and prohibited rules should not be selected when trying to purge a prefix (correct me if I'm wrong) because they are not what we are looking for. This can prevent the targeted prefix from being purged.
>>>>>> In fact, I'm not sure to get the scenario. This part of the code just tries
>>>>>> to remove the connected prefix, added by the kernel when the address was added.
>>>>>> Can you describe your scenario?
>>>>>
>>>>>
>>>>> I should have given more details from the beginning, my mistake. The scenario where this happens is quite simple:
>>>>>
>>>>> - install a blackhole rule (e.g. "from 2001:db8::1000 blackhole" - the source address does not matter at all) with the FIB_RULE_FIND_SADDR flag set (setting this flag is not possible with iproute2, but for test purpose you can use the enclosed patch against the latest iproute2 tree and then use "./ip -6 rule add from 2001:db8::1000/128 blackhole prio 1000").
>>>>>
>>>>> - try to delete an address from one of your interface (any address, it can be different from the one you used for the blackhole rule): "ip -6 addr del <v6-addr>/64 dev eth<x>"
>>>>>
>>>>> and you get an Oops. When trying to remove the connected prefix, the fib6_rule_match() function will match the blackhole rule because RT6_LOOKUP_F_HAS_SADDR is not set and FIB_RULE_FIND_SADDR is set.
>>>>>
>>>>> With your proposal, the Oops is fixed but the connected prefix route is not deleted. With my initial patch, the Oops is fixed and the connected prefix route is also deleted.
>>>> Ok, I get it. I thin,there is two bugs: the oops and the wrong lookup.
>>>>
>>>> Your proposal fix only a particular case. Try this (with your ip route2 patch):
>>>> ip -6 addr add 2002::1/64 dev eth0
>>>> ip -6 route add 2002::/64 table 257 dev eth0
>>
>> (you also need to add a rule such as this one:)
>> ip -6 rule to 2002::/64 table 257
>>
>>>> ip -6 addr del 2002::1/64 dev eth0
>>>>
>>>> The route deleted is not the connected prefix, but the route added in table 257.
>>
>> You are right.
>>
>>>> The connected prefix is still here in the main table. It's not what we want.
>>>> Maybe the lookup should be done directly into the right table, ie table RT6_TABLE_PREFIX. What do you think?
>>>
>>> I agree. I think we can use addrconf_get_prefix_route() here.
>>
>> Right, thanks for the hint! What about the below patch?
>>
>> Note that addrconf_get_prefix_route() also requires a fix (I believe it does not handle the 'noflags' parameter correctly), I have sent a patch in a separate mail (subject "ipv6: fix the noflags test in addrconf_get_prefix_route").
>>
>> Thanks,
>> Romain
>>
>>
>>
>> From 2a79f191042ee8d48119b095b2ef7527a89817fc Mon Sep 17 00:00:00 2001
>> From: Romain Kuntz <r.kuntz@ipflavors.com>
>> Date: Wed, 9 Jan 2013 15:11:08 +0100
>> Subject: [PATCH 1/1] ipv6: use addrconf_get_prefix_route for prefix route lookup
>>
>> Replace ip6_route_lookup() with addrconf_get_prefix_route() when
>> looking up for a prefix route. This ensures that the connected prefix
>> is looked up in the main table, and avoids the selection of other
>> matching route located in different tables.
>>
>> As a consequence, the function addrconf_is_prefix_route() is not
>> used anymore and is removed.
> Because this patch also fix an oops, I think it's interesting to tell it in the commit log and point the commit that introduce this oops.
>
>>
>> Signed-off-by: Romain Kuntz <r.kuntz@ipflavors.com>
>> ---
>> net/ipv6/addrconf.c | 24 ++++++++++--------------
>> 1 files changed, 10 insertions(+), 14 deletions(-)
>>
>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>> index 29ba4ff..409dd47 100644
>> --- a/net/ipv6/addrconf.c
>> +++ b/net/ipv6/addrconf.c
>> @@ -154,6 +154,10 @@ static void addrconf_type_change(struct net_device *dev,
>> unsigned long event);
>> static int addrconf_ifdown(struct net_device *dev, int how);
>>
>> +static struct rt6_info *addrconf_get_prefix_route(const struct in6_addr *pfx,
>> + int plen, const struct net_device *dev,
>> + u32 flags, u32 noflags);
> These args should be aligned to the previous '('.
>
>> +
>> static void addrconf_dad_start(struct inet6_ifaddr *ifp);
>> static void addrconf_dad_timer(unsigned long data);
>> static void addrconf_dad_completed(struct inet6_ifaddr *ifp);
>> @@ -250,12 +254,6 @@ static inline bool addrconf_qdisc_ok(const struct net_device *dev)
>> return !qdisc_tx_is_noop(dev);
>> }
>>
>> -/* Check if a route is valid prefix route */
>> -static inline int addrconf_is_prefix_route(const struct rt6_info *rt)
>> -{
>> - return (rt->rt6i_flags & (RTF_GATEWAY | RTF_DEFAULT)) == 0;
>> -}
>> -
>> static void addrconf_del_timer(struct inet6_ifaddr *ifp)
>> {
>> if (del_timer(&ifp->timer))
>> @@ -941,17 +939,15 @@ static void ipv6_del_addr(struct inet6_ifaddr *ifp)
>> if ((ifp->flags & IFA_F_PERMANENT) && onlink < 1) {
>> struct in6_addr prefix;
>> struct rt6_info *rt;
>> - struct net *net = dev_net(ifp->idev->dev);
>> - struct flowi6 fl6 = {};
>>
>> ipv6_addr_prefix(&prefix, &ifp->addr, ifp->prefix_len);
>> - fl6.flowi6_oif = ifp->idev->dev->ifindex;
>> - fl6.daddr = prefix;
>> - rt = (struct rt6_info *)ip6_route_lookup(net, &fl6,
>> - RT6_LOOKUP_F_IFACE);
>>
>> - if (rt != net->ipv6.ip6_null_entry &&
>> - addrconf_is_prefix_route(rt)) {
>> + rt = addrconf_get_prefix_route(&prefix,
>> + ifp->prefix_len,
>> + ifp->idev->dev,
>> + 0, RTF_GATEWAY | RTF_DEFAULT);
> Same here.
>
>> +
>> + if (rt) {
>> if (onlink == 0) {
>> ip6_del_rt(rt);
>> rt = NULL;
>>
> After, you can add my "Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>" ;-)
Thanks Nicolas, here is the new version.
From 203474c87f45da40b5c9d9e629164561307b4199 Mon Sep 17 00:00:00 2001
From: Romain Kuntz <r.kuntz@ipflavors.com>
Date: Thu, 10 Jan 2013 07:41:36 +0100
Subject: [PATCH 1/1] ipv6: use addrconf_get_prefix_route for prefix route lookup [v2]
Replace ip6_route_lookup() with addrconf_get_prefix_route() when
looking up for a prefix route. This ensures that the connected prefix
is looked up in the main table, and avoids the selection of other
matching routes located in different tables as well as blackhole
or prohibited entries.
In addition, this fixes an Opps introduced by commit 64c6d08e (ipv6:
del unreachable route when an addr is deleted on lo), that would occur
when a blackhole or prohibited entry is selected by ip6_route_lookup().
Such entries have a NULL rt6i_table argument, which is accessed by
__ip6_del_rt() when trying to lock rt6i_table->tb6_lock.
The function addrconf_is_prefix_route() is not used anymore and is
removed.
[v2] Minor indentation cleanup and log updates.
Signed-off-by: Romain Kuntz <r.kuntz@ipflavors.com>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv6/addrconf.c | 25 +++++++++++--------------
1 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 29ba4ff..ec3e065 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -154,6 +154,11 @@ static void addrconf_type_change(struct net_device *dev,
unsigned long event);
static int addrconf_ifdown(struct net_device *dev, int how);
+static struct rt6_info *addrconf_get_prefix_route(const struct in6_addr *pfx,
+ int plen,
+ const struct net_device *dev,
+ u32 flags, u32 noflags);
+
static void addrconf_dad_start(struct inet6_ifaddr *ifp);
static void addrconf_dad_timer(unsigned long data);
static void addrconf_dad_completed(struct inet6_ifaddr *ifp);
@@ -250,12 +255,6 @@ static inline bool addrconf_qdisc_ok(const struct net_device *dev)
return !qdisc_tx_is_noop(dev);
}
-/* Check if a route is valid prefix route */
-static inline int addrconf_is_prefix_route(const struct rt6_info *rt)
-{
- return (rt->rt6i_flags & (RTF_GATEWAY | RTF_DEFAULT)) == 0;
-}
-
static void addrconf_del_timer(struct inet6_ifaddr *ifp)
{
if (del_timer(&ifp->timer))
@@ -941,17 +940,15 @@ static void ipv6_del_addr(struct inet6_ifaddr *ifp)
if ((ifp->flags & IFA_F_PERMANENT) && onlink < 1) {
struct in6_addr prefix;
struct rt6_info *rt;
- struct net *net = dev_net(ifp->idev->dev);
- struct flowi6 fl6 = {};
ipv6_addr_prefix(&prefix, &ifp->addr, ifp->prefix_len);
- fl6.flowi6_oif = ifp->idev->dev->ifindex;
- fl6.daddr = prefix;
- rt = (struct rt6_info *)ip6_route_lookup(net, &fl6,
- RT6_LOOKUP_F_IFACE);
- if (rt != net->ipv6.ip6_null_entry &&
- addrconf_is_prefix_route(rt)) {
+ rt = addrconf_get_prefix_route(&prefix,
+ ifp->prefix_len,
+ ifp->idev->dev,
+ 0, RTF_GATEWAY | RTF_DEFAULT);
+
+ if (rt) {
if (onlink == 0) {
ip6_del_rt(rt);
rt = NULL;
--
1.7.2.5
^ permalink raw reply related
* Re: [Xen-devel] xen-netback notify DomU to send ARP.
From: jianhai luan @ 2013-01-10 7:00 UTC (permalink / raw)
To: Ian Campbell; +Cc: Jan Beulich, xen-devel, netdev
In-Reply-To: <50EDA624.1010008@163.com>
[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]
The patch main to fix the below circumstance:
Bonding run in Active-Backup mode.
Out PC --> switcher
port A --> eth0 --> bond0 --> xenbr0 --> netbackend --> DomU
port B -- eth1 /
Or
Out PC (R)--> switcher A --> eth0 --> bond0 --> xenbr0 --> netbackend
--> DomU
\ switcher B -- eth1 /
When Switcher Port A (active port) don't reach, or switcher A don't reach,
the surroundings will changed to the below circumstance.
Out PC --> switcher
port A -X- eth0 -- bond0 -- xenbr0 -- netbackend -- DomU
port B -- eth1 /
Or
Out PC (R)--> switcher A -X- eth0 -- bond0 -- xenbr0 -- netbackend -- DomU
\ switcher B -- eth1 /
So, the former traffic will be unreachable before find the correct path
(by sending
ARP request).
So, the patch is main to found the bonding change event, and gratutious
ARP initialtivly
to out PC find the correct path.
the correct path should be the below circumstance:
Out PC --> switcher
port A -X- eth0 --> bond0 --> xenbr0 --> netbackend --> DomU
port B --> eth1 /
Or
Out PC (R)--> switcher A -X- eth0 --> bond0 --> xenbr0 --> netbackend
--> DomU
\ switcher B --> eth1 /
Thanks,
Jason
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-xen-netback-notify-frontend-to-send-gratuitous-ARP.patch --]
[-- Type: text/plain; charset=gb18030; name="0001-xen-netback-notify-frontend-to-send-gratuitous-ARP.patch", Size: 3502 bytes --]
From cd5a33f9137a60f27c2a8c6c77a520d2df356c7a Mon Sep 17 00:00:00 2001
From: Jason Luan <jianhai.luan@oracle.com>
Date: Fri, 28 Dec 2012 15:43:06 +0800
Subject: [PATCH] xen-netback notify frontend to send gratuitous ARP.
In the real network environment, some cause will lead
to Active-Backup mode bonding chose new actived port.
After that, the trffic, destinated to DomU by inactived
port (former actived port), will be unreachable at now.
DomU should send gratutious ARP initialtivly to find the
new corrected path.
By netback's Connected->Connected transition, frontend
will watch the change, and send gratuitous ARP.
Signed-off-by: Jason Luan <jianhai.luan@oracle.com>
---
drivers/net/xen-netback/xenbus.c | 68 ++++++++++++++++++++++++++++++++++++++
1 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 410018c..ebea683 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -26,6 +26,7 @@ struct backend_info {
struct xenvif *vif;
enum xenbus_state frontend_state;
struct xenbus_watch hotplug_status_watch;
+ struct notifier_block vif_notifier;
u8 have_hotplug_status_watch:1;
};
@@ -34,11 +35,74 @@ static void connect(struct backend_info *);
static void backend_create_xenvif(struct backend_info *be);
static void unregister_hotplug_status_watch(struct backend_info *be);
+/*
+ * By Connected->Connected transition, netfront will watch the change and
+ * send gratuitous ARP.
+ */
+static void notify_front_arping(struct xenbus_device *dev)
+{
+ struct xenbus_transaction xbt;
+ int err;
+
+ if (xenbus_read_driver_state(dev->nodename) != XenbusStateConnected)
+ return;
+
+again:
+ err = xenbus_transaction_start(&xbt);
+ if (err) {
+ pr_fmt("Error starting transaction");
+ return;
+ }
+
+ err = xenbus_printf(xbt, dev->nodename, "state", "%d", dev->state);
+ if (err) {
+ pr_fmt("Error writing the state");
+ goto abort;
+ }
+
+ err = xenbus_transaction_end(xbt, 0);
+ if (err == -EAGAIN)
+ goto again;
+ if (err)
+ pr_fmt("Error ending transaction");
+
+ return;
+abort:
+ xenbus_transaction_end(xbt, 1);
+}
+
+#define nb_to_backend(nb) container_of(nb, struct backend_info, vif_notifier)
+/**
+ * When network condition of vif change, notify the frontend.
+ */
+static int netback_netdev_event(struct notifier_block *this,
+ unsigned long event, void *ptr)
+{
+ struct net_device *event_dev = ptr;
+ struct backend_info *be = nb_to_backend(this);
+
+ pr_debug("event_dev: %s, event: %lx\n",
+ event_dev ? event_dev->name : "None", event);
+
+ if (!be->vif)
+ return NOTIFY_DONE;
+
+ switch (event) {
+ case NETDEV_NOTIFY_PEERS:
+ /* Notify frontend to Send gratuitous ARP */
+ notify_front_arping(be->dev);
+ break;
+ }
+
+ return NOTIFY_DONE;
+}
+
static int netback_remove(struct xenbus_device *dev)
{
struct backend_info *be = dev_get_drvdata(&dev->dev);
unregister_hotplug_status_watch(be);
+ unregister_netdevice_notifier(&be->vif_notifier);
if (be->vif) {
kobject_uevent(&dev->dev.kobj, KOBJ_OFFLINE);
xenbus_rm(XBT_NIL, dev->nodename, "hotplug-status");
@@ -129,6 +193,10 @@ static int netback_probe(struct xenbus_device *dev,
/* This kicks hotplug scripts, so do it immediately. */
backend_create_xenvif(be);
+ /* Register Frontend Event Notify */
+ be->vif_notifier.notifier_call = netback_netdev_event;
+ register_netdevice_notifier(&be->vif_notifier);
+
return 0;
abort_transaction:
--
1.7.6.5
^ permalink raw reply related
* Re: tainted warnings with tcp splicing in 3.7.1
From: Eric Dumazet @ 2013-01-10 6:59 UTC (permalink / raw)
To: Christian Becker, David Miller; +Cc: netdev@vger.kernel.org, Willy Tarreau
In-Reply-To: <1357751372.27446.40.camel@edumazet-glaptop>
From: Eric Dumazet <edumazet@google.com>
On Wed, 2013-01-09 at 09:09 -0800, Eric Dumazet wrote:
> My feeling is that tcp_recv_skb() should eat skbs instead of only
> finding the right one
>
Thats indeed the case.
> Thats because skb_splice_bits() releases the socket lock before calling
> splice_to_pipe()
>
> Once socket is released, other incoming TCP frames can be processed, and
> the skb we are actually processing might be 'collapsed' into smaller
> units.
>
> Christian, if I send you patches, are you OK to test them ?
>
>
Here is the patch fixing this issue.
Thanks a lot for your report, this is a very very old bug.
GRO being more deployed, and with TCP coalescing as well, chances to
trigger this bug increased a lot.
To reproduce it, I had to force MSS=400 and stress the receiver,
adding extra delays in skb_splice_bits() with socket lock being not
held.
[PATCH] tcp: fix splice() and tcp collapsing interaction
Under unusual circumstances, TCP collapse can split a big GRO TCP packet
while its being used in a splice(socket->pipe) operation.
skb_splice_bits() releases the socket lock before calling
splice_to_pipe().
[ 1081.353685] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
[ 1081.371956] Hardware name: System x3690 X5 -[7148Z68]-
[ 1081.391820] cleanup rbuf bug: copied AD3BCF1 seq AD370AF rcvnxt AD3CF13
To fix this problem, we must eat skbs in tcp_recv_skb().
Remove the inline keyword from tcp_recv_skb() definition since
it has three call sites.
Reported-by: Christian Becker <c.becker@traviangames.com>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/tcp.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 1ca2536..1f901be 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1428,12 +1428,12 @@ static void tcp_service_net_dma(struct sock *sk, bool wait)
}
#endif
-static inline struct sk_buff *tcp_recv_skb(struct sock *sk, u32 seq, u32 *off)
+static struct sk_buff *tcp_recv_skb(struct sock *sk, u32 seq, u32 *off)
{
struct sk_buff *skb;
u32 offset;
- skb_queue_walk(&sk->sk_receive_queue, skb) {
+ while ((skb = skb_peek(&sk->sk_receive_queue)) != NULL) {
offset = seq - TCP_SKB_CB(skb)->seq;
if (tcp_hdr(skb)->syn)
offset--;
@@ -1441,6 +1441,11 @@ static inline struct sk_buff *tcp_recv_skb(struct sock *sk, u32 seq, u32 *off)
*off = offset;
return skb;
}
+ /* This looks weird, but this can happen if TCP collapsing
+ * splitted a fat GRO packet, while we released socket lock
+ * in skb_splice_bits()
+ */
+ sk_eat_skb(sk, skb, false);
}
return NULL;
}
@@ -1520,8 +1525,10 @@ int tcp_read_sock(struct sock *sk, read_descriptor_t *desc,
tcp_rcv_space_adjust(sk);
/* Clean up data we have read: This will do ACK frames. */
- if (copied > 0)
+ if (copied > 0) {
+ tcp_recv_skb(sk, seq, &offset);
tcp_cleanup_rbuf(sk, copied);
+ }
return copied;
}
EXPORT_SYMBOL(tcp_read_sock);
^ permalink raw reply related
* Re: [patch net-next 5/7] net: remove unnecessary NET_ADDR_RANDOM "bitclean"
From: Antonio Quartulli @ 2013-01-10 2:55 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem
In-Reply-To: <1357047019-1037-6-git-send-email-jiri@resnulli.us>
Il 01.01.2013 15:30 Jiri Pirko ha scritto:
> NET_ADDR_SET is set in dev_set_mac_address() no need to alter
> dev->addr_assign_type value in drivers.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Hello Jiri,
please, next time it would be good if you CC all the poeple involved in
a patch: in this way
everybody can easily realise that the code they are maintaining is
going to be touched/modified.
If you don't (like this time) we have to wait some somebody/something
comparing net-next with
our tree to trigger a reaction in our repo.
The get_maintainer.pl script will give you all the email addresses that
you should include
(some of them can possibly be skept).
Thanks a lot,
Antonio
--
Antonio Quartulli
^ permalink raw reply
* Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
From: Andy King @ 2013-01-10 2:42 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Dmitry Torokhov, pv-drivers, gregkh, linux-kernel, virtualization,
netdev, David Miller
In-Reply-To: <50ED25E7.9010609@redhat.com>
> > Our position is that VSOCK feature set is more complete and that it
> > should be possible to use transports other than VMCI for VSOCK
> > traffic, should interested parties implement them,
>
> Implementing other transports requires restructing vsock (and vmci)
> first as the current vsock code is not a hypervisor neutral service.
I'm going to bite the bullet and spend the next couple of days doing
just that: factoring out the VMCI bits and hiding them behind a
transport layer. It'll be a bit rough, but it'll be a start. We'll
submit another patch series next week with that. I'm hoping that'll
get us over this hump, since it should by hypervisor agnostic at
that point. It'll be up to you guys to add virtio, though :)
And in the meantime, are there any other glaring errors that we need
to address?
Thanks!
- Andy
^ permalink raw reply
* Re: niu interface automatically goes up then down
From: Jan Engelhardt @ 2013-01-10 1:52 UTC (permalink / raw)
To: Julian Calaby; +Cc: Linux Networking Developer Mailing List, sparclinux
In-Reply-To: <CAGRGNgX6u=Q4_8pFhLNHDQYRCv1m3ULBgyc+wA=+_KDjDDbSjQ@mail.gmail.com>
On Thursday 2013-01-10 02:27, Julian Calaby wrote:
>
>> The issue is not pressing, since it's just service processors
>> which are connected.
>
>Ok, I'm guessing that this is production so heavy debugging isn't
>going to happen.
No production, free to toy.
>I'm out of ideas. Tag?
Here is a fun fact. If I disable autonegotiation (via ethtool) on the
link on the niu side, the remote side will deassert the carrier and
won't return it until autoneg is turned on again.
In fact, if I do `ethtool -s eth7 autoneg off; ethtool -s eth7 autoneg
on;`, it will take a good exact second (~1.000400 s) for the HW to
reestablish an autonegotiated link. This delay is of the same magnitude
and value as when the link bounces on its own.
Hypothesis: maybe the niu HW drops autoneg for a splitsecond (or it
gets lost due to some other reason), causing the observed bounces.
^ permalink raw reply
* Re: niu interface automatically goes up then down
From: Julian Calaby @ 2013-01-10 1:27 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Linux Networking Developer Mailing List, sparclinux
In-Reply-To: <alpine.LNX.2.01.1301100134300.29388@nerf07.vanv.qr>
Hi Jan,
Thanks for the answers.
On Thu, Jan 10, 2013 at 11:55 AM, Jan Engelhardt <jengelh@inai.de> wrote:
>
> On Thursday 2013-01-10 01:24, Julian Calaby wrote:
>>>
>>> The interface itself is marked UP, and is part of a bridge,
>>> if that matters. The kernel version is 3.7.1 on sparc64.
>>>
>>> 6: eth4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500
>>> qdisc mq master br0 state DOWN qlen 1000
>>> link/ether 00:21:28:71:32:5a brd ff:ff:ff:ff:ff:ff
>>> inet6 fe80::221:28ff:fe71:325a/64 scope link
>>> valid_lft forever preferred_lft forever
>>
>>That is rather odd. Is this particular interface connected to anything
>>that could be causing this?
>
> Nope, there is nothing connected to eth4. UP indicates that
> I had issue `ip link set dev eth4 up`.
I assumed that from the "NO-CARRIER" status, but I had to check: for
all I know it's some sort of failover connection and is hooked up to a
disabled port on a different switch.
>>> At the same time, eth5, to which a cable+machine _is_ connected,
>>> randomly goes out. At first I thought it might be the connected peer,
>>> but seeing that eth4 randomly does a up-down cycle leads me to assume
>>> that niu is doing a cycle here rather than the peer.
>>>
>>> [ 3839.724721] niu 0000:10:00.1 eth5: Link is down
>>> [ 3839.725077] br0: port 5(eth5) entered disabled state
>>> [ 3840.725016] niu 0000:10:00.1 eth5: Link is up at 100Mbit/sec, half duplex
>>> [ 3840.725195] br0: port 5(eth5) entered forwarding state
>>> [ 3840.725327] br0: port 5(eth5) entered forwarding state
>>> [ 3855.762171] br0: port 5(eth5) entered forwarding state
>>
>>Again, could it be the device at the end of the link?
>>Out of curiosity, why do you have these two ports bridged together and
>>what is the purpose of this configuration?
>
> Nobody expects the... lack of a switch. And since there are
> plenty of ports in the machine anyway, might as well use them as a
> software switch as an intermediate solution.
True that. I have an overabundance of PCI network cards and have built
temporary servers with two of them bridged together so I'm not
stealing a port that might be needed.
> eth0 through eth3 is a quad-port e1000e.
> eth4 through eth7 is the quad-port niu.
>
> The e1000e ports don't flake out at all, therefore I rate
> the peer(s) being at fault with a very low probability.
Makes sense.
> The issue is not pressing, since it's just service processors
> which are connected.
Ok, I'm guessing that this is production so heavy debugging isn't
going to happen.
I'm out of ideas. Tag?
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: [PATCH 01/19] netfilter: move nf_conntrack initialize out of pernet operations
From: Gao feng @ 2013-01-10 1:03 UTC (permalink / raw)
To: canqun zhang
Cc: netfilter-devel, netdev@vger.kernel.org, Patrick McHardy, pablo,
Eric W. Biederman
In-Reply-To: <CAFFEFTXU1Yptqx0x6CjtqXMU+7HYu4F7Hk7u29oPCeghZ9Wc_Q@mail.gmail.com>
Hi canqun,
On 2012/12/28 16:48, canqun zhang wrote:
> ok, I can help you take a test, please send a big patch container this
> patchset to my email.
>
Can you give me your tested-by to this patchset besides patch [19/19]?
Thanks!
>
> 2012/12/28 Gao feng <gaofeng@cn.fujitsu.com>:
>> On 12/28/12 11:52, canqun zhang wrote:
>>> Hi all
>>> As discussed above,if the host machine create several linux
>>> containers, there will be several net namespaces.Resources with "nf
>>> conntrack" are registered or unregistered on the first net
>>> namespace(init_net),But init_net is not unregistered lastly,so
>>> cleanuping other net namespaces will triger painic.
>>> If net namespaces are created with the order of 1,2,...n,they should
>>> be cleaned with the order of n,...2,1,so in this case init_net will be
>>> unregistered lastly.
>>> I fixed it up (see below). I have taken a lot of test!
>>>
>>
>> I thinks this BUG is a netfilter BUG,not a netns BUG.
>> Other subsystems implemented netns support don't use init_net to
>> do some special works((un)register/(un)set).
>>
>> In fact,we can't use init_net to do this job well.such as function
>> nf_conntrack_clean,we shoud set ip_ct_attach to NULL before any
>> netns doing cleanup jobs, and set nf_ct_destroy to NULL after all of
>> netns finish these cleanup jobs.
>>
>> So I think finally we still need this patchset,And this is a regular
>> way to fix this problem.
>>
>> Can you help me to test if the panic bug is fixed by this patchset?
>> and then give me your tested-by?
>>
>> thank you very much!
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-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: niu interface automatically goes up then down
From: Jan Engelhardt @ 2013-01-10 0:55 UTC (permalink / raw)
To: Julian Calaby; +Cc: Linux Networking Developer Mailing List, sparclinux
In-Reply-To: <CAGRGNgWqweBphbr+rpTZ2Fe=yLG_xNSvS4sf8XteoCiAx8b81A@mail.gmail.com>
On Thursday 2013-01-10 01:24, Julian Calaby wrote:
>>
>> The interface itself is marked UP, and is part of a bridge,
>> if that matters. The kernel version is 3.7.1 on sparc64.
>>
>> 6: eth4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500
>> qdisc mq master br0 state DOWN qlen 1000
>> link/ether 00:21:28:71:32:5a brd ff:ff:ff:ff:ff:ff
>> inet6 fe80::221:28ff:fe71:325a/64 scope link
>> valid_lft forever preferred_lft forever
>
>That is rather odd. Is this particular interface connected to anything
>that could be causing this?
Nope, there is nothing connected to eth4. UP indicates that
I had issue `ip link set dev eth4 up`.
>> At the same time, eth5, to which a cable+machine _is_ connected,
>> randomly goes out. At first I thought it might be the connected peer,
>> but seeing that eth4 randomly does a up-down cycle leads me to assume
>> that niu is doing a cycle here rather than the peer.
>>
>> [ 3839.724721] niu 0000:10:00.1 eth5: Link is down
>> [ 3839.725077] br0: port 5(eth5) entered disabled state
>> [ 3840.725016] niu 0000:10:00.1 eth5: Link is up at 100Mbit/sec, half duplex
>> [ 3840.725195] br0: port 5(eth5) entered forwarding state
>> [ 3840.725327] br0: port 5(eth5) entered forwarding state
>> [ 3855.762171] br0: port 5(eth5) entered forwarding state
>
>Again, could it be the device at the end of the link?
>Out of curiosity, why do you have these two ports bridged together and
>what is the purpose of this configuration?
Nobody expects the... lack of a switch. And since there are
plenty of ports in the machine anyway, might as well use them as a
software switch as an intermediate solution.
eth0 through eth3 is a quad-port e1000e.
eth4 through eth7 is the quad-port niu.
The e1000e ports don't flake out at all, therefore I rate
the peer(s) being at fault with a very low probability.
The issue is not pressing, since it's just service processors
which are connected.
^ permalink raw reply
* Re: [PATCH V3 1/2] virtio-net: fix the set affinity bug when CPU IDs are not consecutive
From: Rusty Russell @ 2013-01-10 0:49 UTC (permalink / raw)
To: Wanlong Gao
Cc: Michael S. Tsirkin, netdev, linux-kernel, virtualization,
Eric Dumazet
In-Reply-To: <50ECCDF3.9050403@cn.fujitsu.com>
Wanlong Gao <gaowanlong@cn.fujitsu.com> writes:
> On 01/09/2013 07:31 AM, Rusty Russell wrote:
>> Wanlong Gao <gaowanlong@cn.fujitsu.com> writes:
>>> */
>>> static u16 virtnet_select_queue(struct net_device *dev, struct sk_buff *skb)
>>> {
>>> - int txq = skb_rx_queue_recorded(skb) ? skb_get_rx_queue(skb) :
>>> - smp_processor_id();
>>> + int txq = 0;
>>> +
>>> + if (skb_rx_queue_recorded(skb))
>>> + txq = skb_get_rx_queue(skb);
>>> + else if ((txq = per_cpu(vq_index, smp_processor_id())) == -1)
>>> + txq = 0;
>>
>> You should use __get_cpu_var() instead of smp_processor_id() here, ie:
>>
>> else if ((txq = __get_cpu_var(vq_index)) == -1)
>>
>> And AFAICT, no reason to initialize txq to 0 to start with.
>>
>> So:
>>
>> int txq;
>>
>> if (skb_rx_queue_recorded(skb))
>> txq = skb_get_rx_queue(skb);
>> else {
>> txq = __get_cpu_var(vq_index);
>> if (txq == -1)
>> txq = 0;
>> }
>
> Got it, thank you.
>
>>
>> Now, just to confirm, I assume this can happen even if we use vq_index,
>> right, because of races with virtnet_set_channels?
>
> I still can't understand this race, could you explain more? thank you.
I assume that someone can call virtnet_set_channels() while we are
inside virtnet_select_queue(), so they reduce dev->real_num_tx_queues,
causing virtnet_set_channels to do:
while (unlikely(txq >= dev->real_num_tx_queues))
txq -= dev->real_num_tx_queues;
Otherwise, when is this loop called?
Thanks,
Rusty.
^ permalink raw reply
* Re: niu interface automatically goes up then down
From: Julian Calaby @ 2013-01-10 0:24 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Linux Networking Developer Mailing List, sparclinux
In-Reply-To: <alpine.LNX.2.01.1301092342290.21351@nerf07.vanv.qr>
Hi Jan,
I'm not familiar with the hardware or drivers, so I won't be able to
help you that much either, but I can ask a couple of pointed
questions. =)
On Thu, Jan 10, 2013 at 9:58 AM, Jan Engelhardt <jengelh@inai.de> wrote:
> Hi,
>
> I am observing that a machine with a niu card/driver automatically
> enables itself and then goes dormant again.
>
> [ 4410.930078] niu 0000:10:00.0 eth4: Link is up at 100Mbit/sec, full duplex
> [ 4410.930137] br0: port 4(eth4) entered forwarding state
> [ 4410.930156] br0: port 4(eth4) entered forwarding state
> [ 4420.957745] niu 0000:10:00.0 eth4: Link is down
>
> The interface itself is marked UP, and is part of a bridge,
> if that matters. The kernel version is 3.7.1 on sparc64.
>
> 6: eth4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500
> qdisc mq master br0 state DOWN qlen 1000
> link/ether 00:21:28:71:32:5a brd ff:ff:ff:ff:ff:ff
> inet6 fe80::221:28ff:fe71:325a/64 scope link
> valid_lft forever preferred_lft forever
That is rather odd. Is this particular interface connected to anything
that could be causing this?
> At the same time, eth5, to which a cable+machine _is_ connected,
> randomly goes out. At first I thought it might be the connected peer,
> but seeing that eth4 randomly does a up-down cycle leads me to assume
> that niu is doing a cycle here rather than the peer.
>
> [ 3839.724721] niu 0000:10:00.1 eth5: Link is down
> [ 3839.725077] br0: port 5(eth5) entered disabled state
> [ 3840.725016] niu 0000:10:00.1 eth5: Link is up at 100Mbit/sec, half duplex
> [ 3840.725195] br0: port 5(eth5) entered forwarding state
> [ 3840.725327] br0: port 5(eth5) entered forwarding state
> [ 3855.762171] br0: port 5(eth5) entered forwarding state
Again, could it be the device at the end of the link?
Out of curiosity, why do you have these two ports bridged together and
what is the purpose of this configuration?
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: niu interface automatically goes up then down
From: David Miller @ 2013-01-09 23:56 UTC (permalink / raw)
To: jengelh; +Cc: netdev, sparclinux
In-Reply-To: <alpine.LNX.2.01.1301092342290.21351@nerf07.vanv.qr>
I'm just letting you know ahead of time that, given my current
workload and travel schedule, I will not be able to look into
this problem at all and someone else will need to do so.
Thanks.
^ permalink raw reply
* niu interface automatically goes up then down
From: Jan Engelhardt @ 2013-01-09 22:58 UTC (permalink / raw)
To: Linux Networking Developer Mailing List; +Cc: sparclinux
Hi,
I am observing that a machine with a niu card/driver automatically
enables itself and then goes dormant again.
[ 4410.930078] niu 0000:10:00.0 eth4: Link is up at 100Mbit/sec, full duplex
[ 4410.930137] br0: port 4(eth4) entered forwarding state
[ 4410.930156] br0: port 4(eth4) entered forwarding state
[ 4420.957745] niu 0000:10:00.0 eth4: Link is down
The interface itself is marked UP, and is part of a bridge,
if that matters. The kernel version is 3.7.1 on sparc64.
6: eth4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500
qdisc mq master br0 state DOWN qlen 1000
link/ether 00:21:28:71:32:5a brd ff:ff:ff:ff:ff:ff
inet6 fe80::221:28ff:fe71:325a/64 scope link
valid_lft forever preferred_lft forever
At the same time, eth5, to which a cable+machine _is_ connected,
randomly goes out. At first I thought it might be the connected peer,
but seeing that eth4 randomly does a up-down cycle leads me to assume
that niu is doing a cycle here rather than the peer.
[ 3839.724721] niu 0000:10:00.1 eth5: Link is down
[ 3839.725077] br0: port 5(eth5) entered disabled state
[ 3840.725016] niu 0000:10:00.1 eth5: Link is up at 100Mbit/sec, half duplex
[ 3840.725195] br0: port 5(eth5) entered forwarding state
[ 3840.725327] br0: port 5(eth5) entered forwarding state
[ 3855.762171] br0: port 5(eth5) entered forwarding state
dmesg for niu:
[ 60.158957] niu: niu.c:v1.1 (Apr 22, 2010)
[ 60.160457] niu: niu0: Found PHY 002060b1 type MII at phy_port 10
[ 60.160887] niu: niu0: Found PHY 002060b1 type MII at phy_port 11
[ 60.161314] niu: niu0: Found PHY 002060b1 type MII at phy_port 12
[ 60.161739] niu: niu0: Found PHY 002060b1 type MII at phy_port 13
[ 60.168250] niu: niu0: Port 0 [4 RX chans] [6 TX chans]
[ 60.168319] niu: niu0: Port 1 [4 RX chans] [6 TX chans]
[ 60.168386] niu: niu0: Port 2 [4 RX chans] [6 TX chans]
[ 60.168452] niu: niu0: Port 3 [4 RX chans] [6 TX chans]
[ 60.168519] niu: niu0: Port 0 RDC tbl(0) [ 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 ]
[ 60.168913] niu: niu0: Port 0 RDC tbl(1) [ 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 ]
[ 60.169213] niu: niu0: Port 1 RDC tbl(2) [ 4 5 6 7 4 5 6 7 4 5 6 7 4 5 6 7 ]
[ 60.169503] niu: niu0: Port 1 RDC tbl(3) [ 4 5 6 7 4 5 6 7 4 5 6 7 4 5 6 7 ]
[ 60.169790] niu: niu0: Port 2 RDC tbl(4) [ 8 9 10 11 8 9 10 11 8 9 10 11 8 9 10 11 ]
[ 60.170078] niu: niu0: Port 2 RDC tbl(5) [ 8 9 10 11 8 9 10 11 8 9 10 11 8 9 10 11 ]
[ 60.170366] niu: niu0: Port 3 RDC tbl(6) [ 12 13 14 15 12 13 14 15 12 13 14 15 12 13 14 15 ]
[ 60.170657] niu: niu0: Port 3 RDC tbl(7) [ 12 13 14 15 12 13 14 15 12 13 14 15 12 13 14 15 ]
[ 60.416607] niu: eth4: NIU Ethernet 00:21:28:71:32:5a
[ 60.416679] niu: eth4: Port type[XMAC] mode[1G:COPPER] XCVR[MII] phy[mif]
[ 60.624669] niu: eth5: NIU Ethernet 00:21:28:71:32:5b
[ 60.624741] niu: eth5: Port type[XMAC] mode[1G:COPPER] XCVR[MII] phy[mif]
[ 60.832774] niu: eth6: NIU Ethernet 00:21:28:71:32:5c
[ 60.832845] niu: eth6: Port type[BMAC] mode[1G:COPPER] XCVR[MII] phy[mif]
[ 61.040806] niu: eth7: NIU Ethernet 00:21:28:71:32:5d
[ 61.040877] niu: eth7: Port type[BMAC] mode[1G:COPPER] XCVR[MII] phy[mif]
lspci:
10:00.0 Ethernet controller: Sun Microsystems Computer Corp. Multithreaded 10-Gigabit Ethernet Network Controller (rev 01)
Subsystem: Sun Microsystems Computer Corp. Device 0000
Flags: bus master, fast devsel, latency 0, IRQ 00000015
Memory at 01000000 (64-bit, non-prefetchable) [size=16M]
Memory at 00d00000 (64-bit, non-prefetchable) [size=32K]
Memory at 00d08000 (64-bit, non-prefetchable) [size=32K]
Expansion ROM at 00e00000 [disabled] [size=1M]
Capabilities: [40] Power Management version 2
Capabilities: [50] MSI: Enable- Count=1/32 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=32 Masked-
Capabilities: [80] Express Endpoint, MSI 00
Capabilities: [94] Vendor Specific Information: Len=08 <?>
Capabilities: [9c] Vendor Specific Information: Len=40 <?>
Capabilities: [100] Advanced Error Reporting
Kernel driver in use: niu
10:00.1 Ethernet controller: Sun Microsystems Computer Corp. Multithreaded 10-Gigabit Ethernet Network Controller (rev 01)
Subsystem: Sun Microsystems Computer Corp. Device 0000
Flags: bus master, fast devsel, latency 0, IRQ 00000016
Memory at 02000000 (64-bit, non-prefetchable) [size=16M]
Memory at 00d10000 (64-bit, non-prefetchable) [size=32K]
Memory at 00d18000 (64-bit, non-prefetchable) [size=32K]
Expansion ROM at 00f00000 [disabled] [size=1M]
Capabilities: [40] Power Management version 2
Capabilities: [50] MSI: Enable- Count=1/32 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=32 Masked-
Capabilities: [80] Express Endpoint, MSI 00
Capabilities: [94] Vendor Specific Information: Len=08 <?>
Capabilities: [9c] Vendor Specific Information: Len=40 <?>
Capabilities: [100] Advanced Error Reporting
Kernel driver in use: niu
10:00.2 Ethernet controller: Sun Microsystems Computer Corp. Multithreaded 10-Gigabit Ethernet Network Controller (rev 01)
Subsystem: Sun Microsystems Computer Corp. Device 0000
Flags: bus master, fast devsel, latency 0, IRQ 00000017
Memory at 03000000 (64-bit, non-prefetchable) [size=16M]
Memory at 00d20000 (64-bit, non-prefetchable) [size=32K]
Memory at 00d28000 (64-bit, non-prefetchable) [size=32K]
Expansion ROM at 04000000 [disabled] [size=1M]
Capabilities: [40] Power Management version 2
Capabilities: [50] MSI: Enable- Count=1/32 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=32 Masked-
Capabilities: [80] Express Endpoint, MSI 00
Capabilities: [94] Vendor Specific Information: Len=08 <?>
Capabilities: [9c] Vendor Specific Information: Len=40 <?>
Capabilities: [100] Advanced Error Reporting
Kernel driver in use: niu
10:00.3 Ethernet controller: Sun Microsystems Computer Corp. Multithreaded 10-Gigabit Ethernet Network Controller (rev 01)
Subsystem: Sun Microsystems Computer Corp. Device 0000
Flags: bus master, fast devsel, latency 0, IRQ 00000014
Memory at 05000000 (64-bit, non-prefetchable) [size=16M]
Memory at 00d30000 (64-bit, non-prefetchable) [size=32K]
Memory at 00d38000 (64-bit, non-prefetchable) [size=32K]
Expansion ROM at 04100000 [disabled] [size=1M]
Capabilities: [40] Power Management version 2
Capabilities: [50] MSI: Enable- Count=1/32 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=32 Masked-
Capabilities: [80] Express Endpoint, MSI 00
Capabilities: [94] Vendor Specific Information: Len=08 <?>
Capabilities: [9c] Vendor Specific Information: Len=40 <?>
Capabilities: [100] Advanced Error Reporting
Kernel driver in use: niu
Any other info needed?
^ permalink raw reply
* Re: recvmmsg() timeout behavior strangeness
From: Chris Friesen @ 2013-01-09 22:33 UTC (permalink / raw)
To: Michael Kerrisk
Cc: Arnaldo Carvalho de Melo, Caitlin Bestler, David Miller,
netdev-u79uwXL29TY76Z2rM5mHXA, Chris Van Hoof, Clark Williams,
Neil Horman, Arnaldo Carvalho de Melo, Andrew Grover,
Elie De Brauwer, linux-man-u79uwXL29TY76Z2rM5mHXA,
Steven Whitehouse, Rémi Denis-Courmont
In-Reply-To: <CAHO5Pa2goUtiBU8ye2beTBExL4it2-aDCPBhDOGyO3NX_PV_pQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 12/23/2012 02:50 PM, Michael Kerrisk wrote:
> If I understand correctly, the *intended* purpose of the timeout
> argument is to set a limit on how long to wait for additional
> datagrams after the arrival of an initial datagram. However, the
> syscall behaves in quite a different way. Instead, it potentially
> blocks forever, regardless of the timeout.
Looking at the code, I think you're correct.
The comments for a2e2725 say the timeout works like for ppoll(), where
it is "an upper limit on the time for which poll() will block, in
milliseconds."
I wonder if we could play some games with sk->sk_rcvtimeo to accomplish
this?
Chris
--
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
* [PATCH net-next] doc: Clarify behavior when sysctl tcp_ecn = 1
From: Vijay Subramanian @ 2013-01-09 22:21 UTC (permalink / raw)
To: netdev; +Cc: davem, edumazet, rick.jones2, Vijay Subramanian
Recent commit (commit 7e3a2dc52953 doc: make the description of how tcp_ecn
works more explicit and clear ) clarified the behavior of tcp_ecn sysctl
variable but description is inconsistent. When requested by incoming conections,
ECN is enabled with not just tcp_ecn = 2 but also with tcp_ecn = 1.
This patch makes it clear that with tcp_ecn = 1, ECN is enabled when requested
by incoming connections.
Also fix spelling of 'incoming'.
Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
---
Documentation/networking/ip-sysctl.txt | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index dd52d51..51dcd52 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -214,8 +214,9 @@ tcp_ecn - INTEGER
congestion before having to drop packets.
Possible values are:
0 Disable ECN. Neither initiate nor accept ECN.
- 1 Always request ECN on outgoing connection attempts.
- 2 Enable ECN when requested by incomming connections
+ 1 Enable ECN when requested by incoming connections and
+ also request ECN on outgoing connection attempts.
+ 2 Enable ECN when requested by incoming connections
but do not request ECN on outgoing connections.
Default: 2
--
1.7.0.4
^ permalink raw reply related
* Re: [E1000-devel] [PATCH net-next] igbvf: fix setting addr_assign_type if PF is up
From: Greg Rose @ 2013-01-09 21:37 UTC (permalink / raw)
To: Williams, Mitch A
Cc: Stefan Assmann, netdev@vger.kernel.org,
e1000-devel@lists.sourceforge.net
In-Reply-To: <AAEA33E297BCAC4B9BB20A7C2DF0AB8D1F8B539A@FMSMSX107.amr.corp.intel.com>
On Wed, 9 Jan 2013 18:56:36 +0000
"Williams, Mitch A" <mitch.a.williams@intel.com> wrote:
> > >> When the PF is up and igbvf is loaded the MAC address is not
> > >> generated using eth_hw_addr_random(). This results in
> > >> addr_assign_type not to be set.
> > >> Make sure it gets set.
> > >>
> > >
> > > NAK - In this case, the address may or may not be random. The
> > > user may have (and should have!) explicitly set this address from
> > > the host to ensure that the VF device receives the same address
> > > each time it
> > boots.
> >
> > Maybe you can give me some advice on this then. Why is there
> > different behaviour depending on the PF being up or down? The
> > problem I'm facing is that if the user did not set a MAC address
> > for the VF manually and the PF is up during igbvf_probe it will not
> > be labelled as random although it is.
> > What about checking IGB_VF_FLAG_PF_SET_MAC and only set
> > NET_ADDR_RANDOM if the flag is cleared?
> >
>
> The difference in behavior is because we cannot get any MAC address
> at all if the PF is down. The interface won't operate at all in this
> case, but if the PF comes up sometime later, we can start working.
> The other alternative is to leave the MAC address as all zeros and
> forcing the user to assign an address manually. We chose to use a
> random address to at least give it a chance of working once the PF
> woke up.
Having been around at the inception of SR-IOV in Linux I recall that
the primary reason we used a random ethernet address was so
that the VF could at least work because there was no infrastructure
to allow the host administrator to set the MAC address of the VF. This
hobbled testing and validation because the user would have to go to
each VM and use a command local to the VM to set the VF MAC address to
some LAA via ifconfig or ip. When testing large numbers of VFs this was
a definite pain.
Now that has changed and I wonder if maybe we shouldn't back out the
random ethernet address assignment and go ahead with all zeros, leaving
the device non-functional until the user has intentionally set either
an LAA through the VF itself, or an administratively assigned MAC
through the ip tool via the PF.
Use of the random MAC address is not recommended by Intel's own best
known methods literature, it was used mostly so that we could get the
technology working and it should probably be at least considered for
deprecation or out right elimination.
My two cents...
- Greg
^ permalink raw reply
* Re: ppoll() stuck on POLLIN while TCP peer is sending
From: Eric Wong @ 2013-01-09 21:29 UTC (permalink / raw)
To: Mel Gorman
Cc: linux-mm, netdev, linux-kernel, Rik van Riel, Minchan Kim,
Eric Dumazet, Andrew Morton, Linus Torvalds
In-Reply-To: <20130108224313.GA13304@suse.de>
Mel Gorman <mgorman@suse.de> wrote:
> When I looked at it for long enough I found a number of problems. Most
> affect timing but two serious issues are in there. One affects how long
> kswapd spends compacting versus reclaiming and the other increases lock
> contention meaning that async compaction can abort early. Both are serious
> and could explain why a driver would fail high-order allocations.
>
> Please try the following patch. However, even if it works the benefit of
> capture may be so marginal that partially reverting it and simplifying
> compaction.c is the better decision.
Btw, I'm still testing this patch with the "page->pfemalloc = false"
change on top of it.
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 6b807e4..03c82c0 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -857,7 +857,8 @@ static int compact_finished(struct zone *zone,
> } else {
> unsigned int order;
> for (order = cc->order; order < MAX_ORDER; order++) {
> - struct free_area *area = &zone->free_area[cc->order];
> + struct free_area *area = &zone->free_area[order];
I noticed something like this hunk wasn't in your latest partial revert
(<20130109135010.GB13475@suse.de>)
I admit I don't understand this code, but this jumped out at me.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [patch 3.8-rc2] drivers/net/ethernet/micrel/ks8851_mll
From: Ben Hutchings @ 2013-01-09 20:59 UTC (permalink / raw)
To: Choi, David; +Cc: davem@davemloft.net, netdev@vger.kernel.org, Doong, Ping
In-Reply-To: <FD9AD8C5375B924CABC56D982DB3A802079D2520@EXMB1.micrel.com>
Again this needs a proper subject, like 'ks8851_mll: Implement basic
statistics'.
It should be based on the 'net-next' tree.
On Wed, 2013-01-09 at 20:17 +0000, Choi, David wrote:
> From: David J. Choi <david.choi@micrel.com>
>
> Summary of changes:
> .add codes to collect statistical information(for example rx/tx packets/bytes, error packets)
> about Ethernet packets.
>
> Signed-off-by: David J. Choi <david.choi@micrel.com>
> ---
>
> --- linux-3.8-rc2/drivers/net/ethernet/micrel/ks8851_mll.c.orig 2013-01-03 09:45:57.830447923 -0800
> +++ linux-3.8-rc2/drivers/net/ethernet/micrel/ks8851_mll.c 2013-01-03 10:05:57.675756568 -0800
> @@ -801,7 +801,14 @@ static void ks_rcv(struct ks_net *ks, st
> skb_put(skb, frame_hdr->len);
> skb->protocol = eth_type_trans(skb, netdev);
> netif_rx(skb);
> + netdev->stats.rx_packets++;
> + netdev->stats.rx_bytes += (frame_hdr->len - 4);
You're subtracting 4 for the CRC? That really shouldn't be visible to
the kernel (unless the NETIF_F_RXFCS feature is enabled on the device).
So you should also substract 4 from the length passed to skb_put().
(That would be a separate patch, probably suitable for the 'net' tree.)
> } else {
> + netdev->stats.rx_dropped++;
> + if ((frame_hdr->len >= RX_BUF_SIZE) || (frame_hdr->len == 0))
> + netdev->stats.rx_length_errors++;
> + if (frame_hdr->sts & RXFSHR_RXFV)
> + netdev->stats.rx_frame_errors++;
[...]
These two increment statements are indented wrongly.
Ben.
--
Ben Hutchings, Staff 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
* Re: [patch 3.8-rc2] drivers/net/phy/micrel.c
From: Ben Hutchings @ 2013-01-09 20:54 UTC (permalink / raw)
To: Choi, David; +Cc: davem@davemloft.net, netdev@vger.kernel.org, Doong, Ping
In-Reply-To: <FD9AD8C5375B924CABC56D982DB3A802079D2509@EXMB1.micrel.com>
You'll need to give this a proper subject, like 'micrel_phy: Add support
for new PHYs'.
On Wed, 2013-01-09 at 20:09 +0000, Choi, David wrote:
> From: David J. Choi <david.choi@micrel.com>
>
> Summary of changes:
> This patch is primarily intended to cover more Ethernet phys from Micrel Inc. Additionally it
> .supports ksz8081/91, ksz8061, ksz9051 device.
This is new hardware support which is probably acceptable for the 'net'
tree.
The additional cleanup:
> .changes KSxxx to KSZxxx for unified naming convention. For example, change KS8737 to KSZ8737.
> .changes 9021 to 90x1 for commonly used names between 9021 and 9031 device, as this patch includes
> KSZ9031 which belongs to same family as 9021.
[...]
should be a separate patch that goes into the 'net-next' tree.
Ben.
--
Ben Hutchings, Staff 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
* [ 084/123] batman-adv: fix random jitter calculation
From: Greg Kroah-Hartman @ 2013-01-09 20:35 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Greg Kroah-Hartman, alan, Akinobu Mita, Antonio Quartulli,
Marek Lindner, Simon Wunderlich, David S. Miller, b.a.t.m.a.n,
netdev
In-Reply-To: <20130109201458.392601412@linuxfoundation.org>
3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Akinobu Mita <akinobu.mita@gmail.com>
[ Upstream commit 143cdd8f33909ff5a153e3f02048738c5964ba26 ]
batadv_iv_ogm_emit_send_time() attempts to calculates a random integer
in the range of 'orig_interval +- BATADV_JITTER' by the below lines.
msecs = atomic_read(&bat_priv->orig_interval) - BATADV_JITTER;
msecs += (random32() % 2 * BATADV_JITTER);
But it actually gets 'orig_interval' or 'orig_interval - BATADV_JITTER'
because '%' and '*' have same precedence and associativity is
left-to-right.
This adds the parentheses at the appropriate position so that it matches
original intension.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Acked-by: Antonio Quartulli <ordex@autistici.org>
Cc: Marek Lindner <lindner_marek@yahoo.de>
Cc: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Cc: Antonio Quartulli <ordex@autistici.org>
Cc: b.a.t.m.a.n@lists.open-mesh.org
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/batman-adv/bat_iv_ogm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/batman-adv/bat_iv_ogm.c
+++ b/net/batman-adv/bat_iv_ogm.c
@@ -119,7 +119,7 @@ batadv_iv_ogm_emit_send_time(const struc
unsigned int msecs;
msecs = atomic_read(&bat_priv->orig_interval) - BATADV_JITTER;
- msecs += (random32() % 2 * BATADV_JITTER);
+ msecs += random32() % (2 * BATADV_JITTER);
return jiffies + msecs_to_jiffies(msecs);
}
^ permalink raw reply
* [ 57/80] batman-adv: fix random jitter calculation
From: Greg Kroah-Hartman @ 2013-01-09 20:35 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Greg Kroah-Hartman, alan, Akinobu Mita, Antonio Quartulli,
Marek Lindner, Simon Wunderlich, David S. Miller, b.a.t.m.a.n,
netdev
In-Reply-To: <20130109201500.410171651@linuxfoundation.org>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Akinobu Mita <akinobu.mita@gmail.com>
[ Upstream commit 143cdd8f33909ff5a153e3f02048738c5964ba26 ]
batadv_iv_ogm_emit_send_time() attempts to calculates a random integer
in the range of 'orig_interval +- BATADV_JITTER' by the below lines.
msecs = atomic_read(&bat_priv->orig_interval) - BATADV_JITTER;
msecs += (random32() % 2 * BATADV_JITTER);
But it actually gets 'orig_interval' or 'orig_interval - BATADV_JITTER'
because '%' and '*' have same precedence and associativity is
left-to-right.
This adds the parentheses at the appropriate position so that it matches
original intension.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Acked-by: Antonio Quartulli <ordex@autistici.org>
Cc: Marek Lindner <lindner_marek@yahoo.de>
Cc: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Cc: Antonio Quartulli <ordex@autistici.org>
Cc: b.a.t.m.a.n@lists.open-mesh.org
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/batman-adv/bat_iv_ogm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/batman-adv/bat_iv_ogm.c
+++ b/net/batman-adv/bat_iv_ogm.c
@@ -72,7 +72,7 @@ static unsigned long bat_iv_ogm_emit_sen
{
return jiffies + msecs_to_jiffies(
atomic_read(&bat_priv->orig_interval) -
- JITTER + (random32() % 2*JITTER));
+ JITTER + (random32() % (2*JITTER)));
}
/* when do we schedule a ogm packet to be sent */
^ 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