Netdev List
 help / color / mirror / Atom feed
* 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: [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: 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 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: [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: 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 0/5] ipv4_tunnels: Modularize ipv4 tunneling.
From: David Miller @ 2013-01-10  7:52 UTC (permalink / raw)
  To: pshelar; +Cc: dev, netdev, jesse
In-Reply-To: <1357612292-1682-1-git-send-email-pshelar@nicira.com>

From: Pravin B Shelar <pshelar@nicira.com>
Date: Mon,  7 Jan 2013 18:31:32 -0800

> Following patch series restructure GRE and IPIP tunneling code
> to make it modular. It adds ip_tunnel module which acts as
> generic tunneling layer which has common code. I have patch
> to do same for VXLAN too.
> 
> In Addidtion to restructuring it adds demultiplexer for ipgre
> protocol, so that linux kernel IPGRE module and OVS gre module
> can co-exist.
> Last patch adds linux state updates to tunnel device from
> lower device.

Please resubmit this when you can also submit the patches which
actually use this new modularity.

Otherwise the value proposition is impossible to analyze.

Thanks.

^ permalink raw reply

* Re: [patch] bnx2x: NULL dereference on error in debug code
From: David Miller @ 2013-01-10  7:53 UTC (permalink / raw)
  To: dan.carpenter; +Cc: eilong, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20130108134213.GA23742@elgon.mountain>

From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue, 8 Jan 2013 16:42:14 +0300

> "vfop" is NULL here.  I've changed the debugging to not use it.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

Applied, thanks Dan.

^ permalink raw reply

* Re: [PATCH v2] net: set default_ethtool_ops in register_netdevice
From: David Miller @ 2013-01-10  7:57 UTC (permalink / raw)
  To: sgruszka
  Cc: netdev, edumazet, greearb, bjorn, linux-wireless, bhutchings,
	mirqus
In-Reply-To: <20130108153850.GA10464@redhat.com>

From: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Tue, 8 Jan 2013 16:38:51 +0100

> Since:
> 
> commit 2c60db037034d27f8c636403355d52872da92f81
> Author: Eric Dumazet <edumazet@google.com>
> Date:   Sun Sep 16 09:17:26 2012 +0000
> 
>     net: provide a default dev->ethtool_ops
> 
> wireless core does not correctly assign ethtool_ops. In order to fix
> the problem, move assignement of default_ethtool_ops to
> register_netdevice(). This is safe because both register_netdevice()
> and dev_ethtool() are protected by RTNL lock.
> 
> Patch is besed on hint of Michał Mirosław.
> 
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> Cc: stable@vger.kernel.org # 3.7+
> ---
> v1 -> v2: change order of default_ethtool_ops initialization to avoid
> the problem. Change the subject accordingly.

I don't understand this.  Why is the assignment of default_ethtool_ops
at netdev allocation time not working?  Is wireless really not using
alloc_netdev*()?

^ permalink raw reply

* [PATCH 3.8-rc] tuntap: refuse to re-attach to different tun_struct
From: Stefan Hajnoczi @ 2013-01-10  7:59 UTC (permalink / raw)
  To: David S. Miller
  Cc: Jason Wang, Michael S. Tsirkin, netdev, linux-kernel,
	Stefan Hajnoczi

Multiqueue tun devices support detaching a tun_file from its tun_struct
and re-attaching at a later point in time.  This allows users to disable
a specific queue temporarily.

ioctl(TUNSETIFF) allows the user to specify the network interface to
attach by name.  This means the user can attempt to attach to interface
"B" after detaching from interface "A".

The driver is not designed to support this so check we are re-attaching
to the right tun_struct.  Failure to do so may lead to oops.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
This fix is for 3.8-rc.

 drivers/net/tun.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index fbd106e..cf6da6e 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -491,6 +491,8 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
 	err = -EINVAL;
 	if (rcu_dereference_protected(tfile->tun, lockdep_rtnl_is_held()))
 		goto out;
+	if (tfile->detached && tun != tfile->detached)
+		goto out;
 
 	err = -EBUSY;
 	if (!(tun->flags & TUN_TAP_MQ) && tun->numqueues == 1)
-- 
1.8.0.2

^ permalink raw reply related

* Re: [PATCH v2 3/3] net: stmmac: add gmac autonego set for ethtool support
From: David Miller @ 2013-01-10  8:02 UTC (permalink / raw)
  To: bh74.an; +Cc: netdev, linux-kernel, peppe.cavallaro, jeffrey.t.kirsher,
	kgene.kim
In-Reply-To: <000601cdedf8$5d39bdf0$17ad39d0$@samsung.com>

From: Byungho An <bh74.an@samsung.com>
Date: Tue, 08 Jan 2013 15:32:02 -0800

> @@ -348,6 +349,10 @@ stmmac_set_pauseparam(struct net_device *netdev,
>  
>  	if (phy->autoneg) {
>  		if (netif_running(netdev))
> +			if((interface == PHY_INTERFACE_MODE_SGMII) ||
> +				(interface == PHY_INTERFACE_MODE_TBI) ||
> +				(interface == PHY_INTERFACE_MODE_RTBI)) 
> +				priv->hw->mac->set_autoneg(priv->ioaddr);

This is improperly indented and formatted, use this style:

	if (A ||
	    B ||
	    C)
		statement();

I can tell what you're trying to do, you are just trying to use TAB
characters exclusivly to indent because you are lazy.  But that's not
the objective here.

^ permalink raw reply

* Re: [PATCH V2 0/4] DSA: Fix checkpatch.pl output for DSA drivers
From: David Miller @ 2013-01-10  8:04 UTC (permalink / raw)
  To: barry; +Cc: netdev
In-Reply-To: <1357697156-5767-1-git-send-email-barry@grussling.com>

From: Barry Grussling <barry@grussling.com>
Date: Tue,  8 Jan 2013 18:05:52 -0800

> This set of patches performs routine maintenance on the DSA drivers
> by removing all checkpatch.pl errors.
> 
> These patches do the following things:
>  * Switch to network-style comments
>  * Convert msleep calls to timeout/usleep_range calls
>  * Convert printk calls to netdev_info calls
>  * Fix whitespace issues

All applied, thanks.

^ permalink raw reply

* Re: [PATCH net-next] cxgb4: Fix incorrect PFVF CMASK
From: David Miller @ 2013-01-10  8:06 UTC (permalink / raw)
  To: vipul; +Cc: netdev, divy, dm, abhishek, jay
In-Reply-To: <1357753369-26471-1-git-send-email-vipul@chelsio.com>

From: Vipul Pandya <vipul@chelsio.com>
Date: Wed,  9 Jan 2013 23:12:49 +0530

> With Hard-Wired firmware configuration it was incorrectly provisioning the VFs
> Channel Access Rights Mask.
> 
> Signed-off-by: Jay Hernandez <jay@chelsio.com>
> Signed-off-by: Vipul Pandya <vipul@chelsio.com>

Applied, thanks.

^ permalink raw reply

* Re: pull request: wireless 2013-01-09
From: David Miller @ 2013-01-10  8:12 UTC (permalink / raw)
  To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20130109191817.GA17321@tuxdriver.com>

From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 9 Jan 2013 14:18:18 -0500

> Included is a mac80211 pull, of which Johannes says the following:
> 
> 'This includes a number of fixes for various pieces of mac80211. I've
> also included Thomas's memory RMC hash table optimisation since it
> saves so much memory.'
> 
> Also from Johannes is an iwlwifi pull:
> 
> 'I have two fixes for iwlwifi: one to fix a lost return value that was
> dropped in a previous patch and could cause "nobody cared" IRQ messages,
> and one to work around a firmware issue.'
> 
> Amitkumar Karwar brings an mwifiex for a typo in an comparison.
> 
> Bing Zhao gives us an mwifiex fix to properly check the return value
> from wait_event_interruptible and handle it properly.
> 
> Chen Gang provides a fix to make iwlegacy use strlcpy instead of
> strncpy, avoiding a potential buffer underflow.
> 
> Julian Wollrath fixes a typo in an error message in rtlwifi.
> 
> Larry Finger brings a b43 fix for a firmware loading problem.
> 
> Nickolai Zeldovich avoids a use-after-free in the mwl8k driver.
> 
> Vladimir Kondratiev brings the last big piece, the new Qualcomm/Atheros
> wil6210 802.11ad driver.  Since it is for new hardware, I hope that
> taking it for 3.8 is not a problem.
> 
> Please let me know if there are problems!

Pulled, thanks John.

^ permalink raw reply

* Re: [PATCH v2] net: set default_ethtool_ops in register_netdevice
From: Stanislaw Gruszka @ 2013-01-10  8:36 UTC (permalink / raw)
  To: David Miller
  Cc: netdev, edumazet, greearb, bjorn, linux-wireless, bhutchings,
	mirqus
In-Reply-To: <20130109.235738.467651533138068641.davem@davemloft.net>

On Wed, Jan 09, 2013 at 11:57:38PM -0800, David Miller wrote:
> From: Stanislaw Gruszka <sgruszka@redhat.com>
> Date: Tue, 8 Jan 2013 16:38:51 +0100
> 
> > Since:
> > 
> > commit 2c60db037034d27f8c636403355d52872da92f81
> > Author: Eric Dumazet <edumazet@google.com>
> > Date:   Sun Sep 16 09:17:26 2012 +0000
> > 
> >     net: provide a default dev->ethtool_ops
> > 
> > wireless core does not correctly assign ethtool_ops. In order to fix
> > the problem, move assignement of default_ethtool_ops to
> > register_netdevice(). This is safe because both register_netdevice()
> > and dev_ethtool() are protected by RTNL lock.
> > 
> > Patch is besed on hint of Michał Mirosław.
> > 
> > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> > Cc: stable@vger.kernel.org # 3.7+
> > ---
> > v1 -> v2: change order of default_ethtool_ops initialization to avoid
> > the problem. Change the subject accordingly.
> 
> I don't understand this.  Why is the assignment of default_ethtool_ops
> at netdev allocation time not working?  Is wireless really not using
> alloc_netdev*()?

It does. This is done on individual cfg80211 drivers , i.e. on mac80211
or full mac drivers. After alloc_netdev*() call, some cfg80211 drivers
provide they own ethtool_ops, but some do not. For them, wireless core
provide generic cfg80211_ethtool_ops, which is assigned in
NETDEV_REGISTER notify call: 

	if (!dev->ethtool_ops)
		dev->ethtool_ops = &cfg80211_ethtool_ops;

But after Eric's commit, dev->ethtool_ops is no longer NULL (on cfg80211
drivers without custom ethtool_ops), but points to &default_ethtool_ops.

Stanislaw

^ permalink raw reply

* Re: [PATCH] drivers/net/wireless/iwlegacy: use strlcpy instead of strncpy
From: Chen Gang F T @ 2013-01-10  8:48 UTC (permalink / raw)
  To: Stanislaw Gruszka; +Cc: Chen Gang, linville, linux-wireless, netdev
In-Reply-To: <20130107111752.GD6931@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 181 bytes --]

于 2013年01月07日 19:17, Stanislaw Gruszka 写道:
>> > Signed-off-by: Chen Gang <gang.chen@asianux.com>
> ACK

  thank you very much.

  :-)

-- 
Chen Gang

Flying Transformer

[-- Attachment #2: chen_gang_flying_transformer.vcf --]
[-- Type: text/x-vcard, Size: 67 bytes --]

begin:vcard
fn:Chen Gang
n:;Chen Gang
version:2.1
end:vcard


^ permalink raw reply

* [patch] bnx2x: move debugging code before the return
From: Dan Carpenter @ 2013-01-10  8:58 UTC (permalink / raw)
  To: Eilon Greenstein; +Cc: netdev, kernel-janitors

I move the return down a line after the debugging printk.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
index 292634f..d7029c8 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
@@ -2768,10 +2768,10 @@ static int bnx2x_set_rss_flags(struct bnx2x *bp, struct ethtool_rxnfc *info)
 		} else if ((info->flow_type == UDP_V6_FLOW) &&
 			   (bp->rss_conf_obj.udp_rss_v6 != udp_rss_requested)) {
 			bp->rss_conf_obj.udp_rss_v6 = udp_rss_requested;
-			return bnx2x_config_rss_pf(bp, &bp->rss_conf_obj, 0);
 			DP(BNX2X_MSG_ETHTOOL,
 			   "rss re-configured, UDP 4-tupple %s\n",
 			   udp_rss_requested ? "enabled" : "disabled");
+			return bnx2x_config_rss_pf(bp, &bp->rss_conf_obj, 0);
 		} else {
 			return 0;
 		}

^ permalink raw reply related

* Re: ppoll() stuck on POLLIN while TCP peer is sending
From: Eric Wong @ 2013-01-10  9:25 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: <20130109133746.GD13304@suse.de>

Mel Gorman <mgorman@suse.de> wrote:
> page->pfmemalloc can be left set for captured pages so try this but as
> capture is rarely used I'm strongly favouring a partial revert even if
> this works for you. I haven't reproduced this using your workload yet
> but I have found that high-order allocation stress tests for 3.8-rc2 are
> completely screwed. 71% success rates at rest in 3.7 and 6% in 3.8-rc2 so
> I have to chase that down too.
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 9d20c13..c242d21 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2180,8 +2180,10 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
>  	current->flags &= ~PF_MEMALLOC;
>  
>  	/* If compaction captured a page, prep and use it */
> -	if (page && !prep_new_page(page, order, gfp_mask))
> +	if (page && !prep_new_page(page, order, gfp_mask)) {
> +		page->pfmemalloc = false;
>  		goto got_page;
> +	}
>  
>  	if (*did_some_progress != COMPACT_SKIPPED) {
>  		/* Page migration frees to the PCP lists but we want merging */

This (on top of your previous patch) seems to work great after several
hours of testing on both my VM and real machine.  I haven't tried your
partial revert, yet.  Will try that in a bit on the VM.

--
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-rc] tuntap: refuse to re-attach to different tun_struct
From: Jason Wang @ 2013-01-10  9:25 UTC (permalink / raw)
  To: Stefan Hajnoczi; +Cc: David S. Miller, Michael S. Tsirkin, netdev, linux-kernel
In-Reply-To: <1357804788-19976-1-git-send-email-stefanha@redhat.com>

On Thursday, January 10, 2013 08:59:48 AM Stefan Hajnoczi wrote:
> Multiqueue tun devices support detaching a tun_file from its tun_struct
> and re-attaching at a later point in time.  This allows users to disable
> a specific queue temporarily.
> 
> ioctl(TUNSETIFF) allows the user to specify the network interface to
> attach by name.  This means the user can attempt to attach to interface
> "B" after detaching from interface "A".
> 
> The driver is not designed to support this so check we are re-attaching
> to the right tun_struct.  Failure to do so may lead to oops.
> 
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> ---
> This fix is for 3.8-rc.
> 
>  drivers/net/tun.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index fbd106e..cf6da6e 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -491,6 +491,8 @@ static int tun_attach(struct tun_struct *tun, struct
> file *file) err = -EINVAL;
>  	if (rcu_dereference_protected(tfile->tun, lockdep_rtnl_is_held()))
>  		goto out;
> +	if (tfile->detached && tun != tfile->detached)
> +		goto out;
> 
>  	err = -EBUSY;
>  	if (!(tun->flags & TUN_TAP_MQ) && tun->numqueues == 1)

Thanks.

Acked-by: Jason Wang <jasowang@redhat.com>

^ permalink raw reply

* Re: [PATCH V3 1/2] virtio-net: fix the set affinity bug when CPU IDs are not consecutive
From: Wanlong Gao @ 2013-01-10  9:26 UTC (permalink / raw)
  To: Rusty Russell, Eric Dumazet
  Cc: Michael S. Tsirkin, netdev, linux-kernel, virtualization
In-Reply-To: <87a9sh3lru.fsf@rustcorp.com.au>

On 01/10/2013 08:49 AM, Rusty Russell wrote:
> 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?

How about just remove this loop? 

Eric, can you give a help here?

Thanks,
Wanlong Gao

> 
> Thanks,
> Rusty.
> 

^ permalink raw reply

* Re: [PATCH 1/1] ipv6: use addrconf_get_prefix_route for prefix route lookup [v2] (was [PATCH 1/2] ipv6: avoid blackhole and prohibited entries upon prefix purge [v3])
From: YOSHIFUJI Hideaki @ 2013-01-10  9:44 UTC (permalink / raw)
  To: Romain KUNTZ, davem
  Cc: nicolas.dichtel, netdev@vger.kernel.org, Eric Dumazet,
	YOSHIFUJI Hideaki
In-Reply-To: <683E9BA1-C85B-43E0-AF98-397D50E302F6@ipflavors.com>

Romain KUNTZ wrote:

> 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;
> 

Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>

--yoshfuji

^ permalink raw reply

* Your mailbox has exceeded the storage limit of 2.GB
From: sistema di posta elettronica Web Admin @ 2013-01-10  9:32 UTC (permalink / raw)


Your mailbox has exceeded the storage limit of 2.GB
Set the administrator is currently  2.30GB, can not send or receive new messages until you re-validate your e-mail
Click the link below to validate your e-mail

https://docs.google.com/spreadsheet/viewform?formkey=dDliaWtndjNLT0o0VHRrZXhicWFBelE6MQ

thank you
system administrator

^ permalink raw reply

* RE: [patch] bnx2x: move debugging code before the return
From: Ariel Elior @ 2013-01-10  9:53 UTC (permalink / raw)
  To: Dan Carpenter, Eilon Greenstein
  Cc: netdev@vger.kernel.org, kernel-janitors@vger.kernel.org
In-Reply-To: <20130110085807.GB23063@elgon.mountain>

> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Dan Carpenter
> Sent: Thursday, January 10, 2013 10:58 AM
> To: Eilon Greenstein
> Cc: netdev@vger.kernel.org; kernel-janitors@vger.kernel.org
> Subject: [patch] bnx2x: move debugging code before the return
> 
> I move the return down a line after the debugging printk.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> 
> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
> b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
> index 292634f..d7029c8 100644
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
> @@ -2768,10 +2768,10 @@ static int bnx2x_set_rss_flags(struct bnx2x *bp,
> struct ethtool_rxnfc *info)
>  		} else if ((info->flow_type == UDP_V6_FLOW) &&
>  			   (bp->rss_conf_obj.udp_rss_v6 !=
> udp_rss_requested)) {
>  			bp->rss_conf_obj.udp_rss_v6 = udp_rss_requested;
> -			return bnx2x_config_rss_pf(bp, &bp->rss_conf_obj,
> 0);
>  			DP(BNX2X_MSG_ETHTOOL,
>  			   "rss re-configured, UDP 4-tupple %s\n",
>  			   udp_rss_requested ? "enabled" : "disabled");
> +			return bnx2x_config_rss_pf(bp, &bp->rss_conf_obj,
> 0);
>  		} else {
>  			return 0;
>  		}
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thanks Dan.
Acked-by: Ariel Elior <ariele@broadcom.com>

^ permalink raw reply

* Re: [PATCH 1/1] ipv6: fix the noflags test in addrconf_get_prefix_route
From: YOSHIFUJI Hideaki @ 2013-01-10 10:00 UTC (permalink / raw)
  To: Romain KUNTZ, davem@davemloft.net
  Cc: netdev@vger.kernel.org, linux-kernel, Andreas Hofmeister,
	YOSHIFUJI Hideaki
In-Reply-To: <470C14E4-2866-4C55-89A3-D6751E1587C4@ipflavors.com>

Romain KUNTZ wrote:
> From e7ece201c35615c44a3cfdc10ee28ad5a5878f41 Mon Sep 17 00:00:00 2001
> From: Romain Kuntz <r.kuntz@ipflavors.com>
> Date: Wed, 9 Jan 2013 15:02:26 +0100
> Subject: [PATCH 1/1] ipv6: fix the noflags test in addrconf_get_prefix_route
> 
> The tests on the flags in addrconf_get_prefix_route() does no make
> much sense: the 'noflags' parameter contains the set of flags that
> must not match with the route flags, so the test must be done
> against 'noflags', and not against 'flags'.
> 
> Signed-off-by: Romain Kuntz <r.kuntz@ipflavors.com>
> ---
>  net/ipv6/addrconf.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 408cac4a..29ba4ff 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -1877,7 +1877,7 @@ static struct rt6_info *addrconf_get_prefix_route(const struct in6_addr *pfx,
>  			continue;
>  		if ((rt->rt6i_flags & flags) != flags)
>  			continue;
> -		if ((noflags != 0) && ((rt->rt6i_flags & flags) != 0))
> +		if ((rt->rt6i_flags & noflags) != 0)
>  			continue;
>  		dst_hold(&rt->dst);
>  		break;
> 

Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>

--yoshfuji

^ permalink raw reply

* Re: recvmmsg() timeout behavior strangeness
From: Steven Whitehouse @ 2013-01-10 10:04 UTC (permalink / raw)
  To: Chris Friesen
  Cc: Michael Kerrisk, 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,
	Rémi Denis-Courmont
In-Reply-To: <50EDF01E.10709-b7o/lNNmKxtBDgjK7y7TUQ@public.gmane.org>

Hi,

On Wed, 2013-01-09 at 16:33 -0600, Chris Friesen wrote:
> 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

Which timeout are we talking about? I've been copied into the thread
without seeing the start of it.

If this is the rcvtimeo then afaik this is supposed to be the max time
that the call waits for data, but is overridden by MSG_DONTWAIT, for
example, on a per call basis. I'd assume that recvmmsg should work
exactly like recvmsg in this case unless there is a good reason for it
to differ,

Steve.


--
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


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox