* Re: [PATCH] ipv6: use rt6_get_dflt_router to get default router in rt6_route_rcv
From: David Miller @ 2013-11-08 20:18 UTC (permalink / raw)
To: duanj.fnst; +Cc: hannes, netdev
In-Reply-To: <527C44E5.70606@cn.fujitsu.com>
From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Date: Fri, 08 Nov 2013 09:56:53 +0800
>
> As the rfc 4191 said, the Router Preference and Lifetime values in a
> ::/0 Route Information Option should override the preference and lifetime
> values in the Router Advertisement header. But when the kernel deals with
> a ::/0 Route Information Option, the rt6_get_route_info() always return
> NULL, that means that overriding will not happen, because those default
> routers were added without flag RTF_ROUTEINFO in rt6_add_dflt_router().
>
> In order to deal with that condition, we should call rt6_get_dflt_router
> when the prefix length is 0.
>
> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH v2 net-next] inet: fix a UFO regression
From: Sridhar Samudrala @ 2013-11-08 20:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alexei Starovoitov, David Miller, netdev, Hannes Frederic Sowa
In-Reply-To: <1383913124.9412.223.camel@edumazet-glaptop2.roam.corp.google.com>
On 11/8/2013 4:18 AM, Eric Dumazet wrote:
> On Thu, 2013-11-07 at 22:41 -0800, Sridhar Samudrala wrote:
>
>> Does this fix also help vxlan performance between 2 VMs on 2 different
>> physical m/cs across 10G NIC?
>> What is the throughput you are seeing via 10G nics?
>> With linux 3.12, i am only seeing around 2Gbps (iperf TCP_STREAM with
>> 16K messages) between 2 VMs when using vxlan across a 10G nic.
>> Is this due to the overhead of software GSO and not doing GRO at the
>> receiver?
> What NIC is used at sender, what NIC is used at receiver ?
I am seeing almost similar results with both Emulex and Intel 10Gb NICs
at both sender and receiver.
>
> If you use GRE instead of VXLAN, do you get any difference in speed ?
With GRE, i am seeing slightly better results. 3.2Gb/s compared to
1.8Gb/s with vxlan.
Thanks
Sridhar
^ permalink raw reply
* Re: [net-next PATCH 0/2] ixgbe: macvlan fixes
From: David Miller @ 2013-11-08 20:21 UTC (permalink / raw)
To: john.fastabend; +Cc: jeffrey.t.kirsher, netdev, nhorman
In-Reply-To: <20131108084654.6935.36501.stgit@nitbit.x32>
From: John Fastabend <john.fastabend@gmail.com>
Date: Fri, 08 Nov 2013 00:50:07 -0800
> Two additional fixes for ixgbe l2 forwarding acceleration. One
> was reported by kbuild build bot and the second after hardening
> my test scripts.
>
> Typically I would send ixgbe fixes through JeffK's tree but I
> know a few people who are looking at the feature in their setup's
> so wanted to be sure the patches were visible.
>
> For reference the ixgbe accelerated macvlan patch is here:
>
> commit 2a47fa45d4dfbc54659d28de311a1f764b296a3c
> Author: John Fastabend <john.r.fastabend@intel.com>
> Date: Wed Nov 6 09:54:52 2013 -0800
>
> ixgbe: enable l2 forwarding acceleration for macvlans
Both applied, thanks John.
^ permalink raw reply
* kernel network panic stack traces on ubuntu 12.04
From: Templin, Fred L @ 2013-11-08 20:40 UTC (permalink / raw)
To: netdev@vger.kernel.org
In-Reply-To: <20131108.152148.475567353347933697.davem@davemloft.net>
Hi,
I am hacking the kernel network stack on a Dell running ubuntu 12.04
and when I add code that I know for sure is causing a panic the system
locks up as if it is hung and never prints out a stack trace. The only
way out is to hard reset using the power button. This happens on several
different linux kernel versions - the most recent being 3.10.17. Any
ideas how I can get a stack trace?
Thanks - Fred
^ permalink raw reply
* Re: [RFC] Revert "sierra_net: keep status interrupt URB active"
From: Bjørn Mork @ 2013-11-08 20:44 UTC (permalink / raw)
To: Dan Williams; +Cc: netdev, linux-usb, John Henderson
In-Reply-To: <1383938944.29096.7.camel@dcbw.foobar.com>
Dan Williams <dcbw@redhat.com> writes:
> On Mon, 2013-11-04 at 14:27 -0600, Dan Williams wrote:
>> On Fri, 2013-11-01 at 13:53 +0100, Bjørn Mork wrote:
>> > This reverts commit 7b0c5f21f348a66de495868b8df0284e8dfd6bbf.
>> >
>> > It's not easy to create a driver for all the various firmware
>> > bugs out there.
>> >
>> > This change caused regressions for a number of devices, which
>> > started to fail link detection and therefore became completely
>> > non-functional. The exact reason is yet unknown, it looks like
>> > the affected firmwares might actually need all or some of the
>> > additional SYNC messages the patch got rid of.
>> >
>> > Reverting is not optimal, as it will re-introduce the original
>> > problem, but it is currently the only alternative known to fix
>> > this issue.
>>
>> Instead, how does the following patch work for you?
>
> Bjorn, did you have a chance to try this patch out on your devices?
The only DirectIP device I have is the MC7710, which never had any of
the firmware issues you are trying to fix. I only tried to forward Johns
issue.
When this patch worked for John, then I am pretty confident that you
have solved the problem here.
Thanks,
Bjørn
^ permalink raw reply
* Re: [PATCH linux-2.6.32.y] sctp: unbalanced rcu lock in ip_queue_xmit()
From: Willy Tarreau @ 2013-11-08 20:48 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev, davem, eric.dumazet, ben, stable
In-Reply-To: <1383905635-20444-1-git-send-email-nicolas.dichtel@6wind.com>
Hi Nicolas,
On Fri, Nov 08, 2013 at 11:13:55AM +0100, Nicolas Dichtel wrote:
> The bug was introduced by commit b8710128e201 ("inet: add RCU protection to
> inet->opt") (it's a backport of upstream commit f6d8bd051c39).
>
> In SCTP case, packet is already routed, hence we jump to the label
> 'packet_routed', but without rcu_read_lock(). After this label,
> rcu_read_unlock() is called unconditionally.
I've just queued it for 2.6.32.62. Thanks!
Willy
^ permalink raw reply
* Re: [PATCH v2 net-next] inet: fix a UFO regression
From: Eric Dumazet @ 2013-11-08 20:57 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: Alexei Starovoitov, David Miller, netdev, Hannes Frederic Sowa
In-Reply-To: <527D478E.4020607@gmail.com>
On Fri, 2013-11-08 at 12:20 -0800, Sridhar Samudrala wrote:
> I am seeing almost similar results with both Emulex and Intel 10Gb NICs
> at both sender and receiver.
> >
> > If you use GRE instead of VXLAN, do you get any difference in speed ?
> With GRE, i am seeing slightly better results. 3.2Gb/s compared to
> 1.8Gb/s with vxlan.
Thanks, it seems to point a bottleneck at receiver, as we have GRO
support for GRE, but not yet for VXLAN.
^ permalink raw reply
* Re: [PATCH net-next 3/8] bonding: add downdelay netlink support
From: Jay Vosburgh @ 2013-11-08 21:15 UTC (permalink / raw)
To: Scott Feldman; +Cc: Veaceslav Falico, andy, netdev, Shrijeet Mukherjee
In-Reply-To: <5C31F7A9-945E-4DA5-A2E2-92AE0A556970@cumulusnetworks.com>
Scott Feldman <sfeldma@cumulusnetworks.com> wrote:
>
>On Nov 7, 2013, at 7:05 AM, Jay Vosburgh <fubar@us.ibm.com> wrote:
>
>> Scott Feldman <sfeldma@cumulusnetworks.com> wrote:
>>
>>> +int bond_option_downdelay_set(struct bonding *bond, int downdelay)
>>> +{
>>> + if (!(bond->params.miimon)) {
>>> + pr_err("%s: Unable to set down delay as MII monitoring is disabled\n", bond->dev->name);
>>> + return -EPERM;
>>> + }
>>
>> I would argue that it is better to permit this option to be set
>> at any time, regardless of whether miimon is enabled or not. This
>> removes an ordering constraint and makes things generally easier to deal
>> with. Setting the option has no effect if miimon is not set, but that's
>> ok.
>>
>> My comment here would also apply to other options that are
>> "secondary," in the sense that they affect the behavior of other options
>> or modes, e.g., updelay, arp_validate (in another path of this series),
>> arp_ip_targets, etc.
>>
>> I'm aware that this is simply duplicating the existing behavior
>> of the sysfs API, but I'd be in favor of changing that, too. These
>> limitations are a holdover from the module paramters days, and should
>> have been made more flexible a long time ago.
>
>What I’d like to propose, and I hope that you’ll agree, is we tackle
>this in two phases. The first phase is to finish the current
>duplication effort to enable netlink equivalents of the attributes in
>sysfs. This is a fairly mechanical process, preserving existing
>behavior as you point out, and keeps the patches single-minded and easy
>to review.
>
>The second phase is to revisit ordering constraints and find places
>where we can remove constraints or streamline the dependency checks.
>
>Sound like a plan?
Well, maybe.
What I want to avoid for the iproute / netlink bonding support
is all of the hoops that the initscripts / sysconfig scripts had to jump
through to obey the current sysfs ordering limtations.
The primary user of this is going to be iproute. Will the above
quoted limitations (and their equivalents for various other options)
make any difference with regards to the following:
ip [...] bond arp_validate all arp_interval 1000
ip [...] bond arp_interval 1000 arp_validate all
I.e., does the ordering matter at the iproute level when
multiple options are specified simultaneously?
What happens if I do:
ip [...] bond arp_interval 1000 arp_validate all miimon 100
This is separate from simply changing one thing at a time, e.g.,
ip [...] bond arp_validate all
ip [...] bond arp_interval 1000
will presuambly hit the test above, and this is where the
ordering stuff comes into play for sure.
Also, as I look at the iproute patch, it doesn't appear to
accept the text names for the options, only numeric values (e.g., "ip
[...] bond arp_validate 3"). That appears to be a limitation of Jiri's
original iproute patch as well. Am I the only person that perfers the
text labels (e.g., arp_validate as "all") to numbers (arp_validate as
"3")?
That number-only limitation also may make life for initscripts /
sysconfig more difficult, or at least the upgrade path more of a hassle,
since currently the ifcfg-bond* files can have the bonding options
specified as text labels in addition to the numeric values.
So, honestly, I think if the ordering constraints are going to
be relaxed, it should happen sooner rather than later. Perhaps not in
the same patch as the netlink support, but ideally at least in the same
series, so there is no real release with the constraints. Changing the
constraints after the script, etc, conversion is done doesn't really
help much.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH net] ipv4: fix wildcard search with inet_confirm_addr()
From: Julian Anastasov @ 2013-11-08 21:24 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: davem, netdev
In-Reply-To: <1383921428-4313-1-git-send-email-nicolas.dichtel@6wind.com>
Hello,
On Fri, 8 Nov 2013, Nicolas Dichtel wrote:
> Help of this function says: "in_dev: only on this interface, 0=any interface",
> but in fact the code supposes that it will never be NULL.
>
> Note that this function was never called with in_dev == NULL, but it's exported
> and may be used by an external module.
The initial idea was that arp_ignore=3 can provide
dev=NULL. Later argument was changed to in_dev but we should
allow the NULL value. As you are going to change the arguments
may be we can partially revert commit
39a6d06300128d32f361f4f790beba0ca83730eb, i.e. to add the
missing in_dev = NULL in arp_ignore() and also revert this change:
- if (in_dev != NULL)
+ if (scope != RT_SCOPE_LINK)
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
>
> This bug was spotted by code review.
>
> drivers/net/bonding/bonding.h | 10 +++-------
> include/linux/inetdevice.h | 3 ++-
> net/ipv4/arp.c | 3 ++-
> net/ipv4/devinet.c | 8 ++++----
> 4 files changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
> index 03cf3fd14490..448895e90ccb 100644
> --- a/drivers/net/bonding/bonding.h
> +++ b/drivers/net/bonding/bonding.h
> @@ -407,15 +407,11 @@ static inline bool bond_is_slave_inactive(struct slave *slave)
>
> static inline __be32 bond_confirm_addr(struct net_device *dev, __be32 dst, __be32 local)
> {
> - struct in_device *in_dev;
> - __be32 addr = 0;
> + __be32 addr;
>
> rcu_read_lock();
> - in_dev = __in_dev_get_rcu(dev);
> -
> - if (in_dev)
> - addr = inet_confirm_addr(in_dev, dst, local, RT_SCOPE_HOST);
> -
> + addr = inet_confirm_addr(dev_net(dev), __in_dev_get_rcu(dev), dst,
> + local, RT_SCOPE_HOST);
As in_dev = NULL should be allowed, above change
will not be needed, we should keep the 'if (in_dev)' there.
> rcu_read_unlock();
> return addr;
> }
> diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h
> index 79640e015a86..5870f7060917 100644
> --- a/include/linux/inetdevice.h
> +++ b/include/linux/inetdevice.h
> @@ -164,7 +164,8 @@ extern int devinet_ioctl(struct net *net, unsigned int cmd, void __user *);
> extern void devinet_init(void);
> extern struct in_device *inetdev_by_index(struct net *, int);
> extern __be32 inet_select_addr(const struct net_device *dev, __be32 dst, int scope);
> -extern __be32 inet_confirm_addr(struct in_device *in_dev, __be32 dst, __be32 local, int scope);
> +__be32 inet_confirm_addr(struct net *net, struct in_device *in_dev, __be32 dst,
> + __be32 local, int scope);
> extern struct in_ifaddr *inet_ifa_byprefix(struct in_device *in_dev, __be32 prefix, __be32 mask);
>
> static __inline__ int inet_ifa_match(__be32 addr, struct in_ifaddr *ifa)
> diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
> index 7808093cede6..fc5ebc7e1962 100644
> --- a/net/ipv4/arp.c
> +++ b/net/ipv4/arp.c
> @@ -408,7 +408,8 @@ static int arp_ignore(struct in_device *in_dev, __be32 sip, __be32 tip)
> default:
> return 0;
> }
> - return !inet_confirm_addr(in_dev, sip, tip, scope);
> + return !inet_confirm_addr(dev_net(in_dev->dev), in_dev, sip, tip,
> + scope);
We will need initial struct net *net = dev_net(in_dev->dev)
because later we will set in_dev to NULL for arp_ignore=3.
Then we will provide 'net' to inet_confirm_addr.
> }
>
> static int arp_filter(__be32 sip, __be32 tip, struct net_device *dev)
> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
> index a1b5bcbd04ae..47cdb035f817 100644
> --- a/net/ipv4/devinet.c
> +++ b/net/ipv4/devinet.c
> @@ -1236,22 +1236,22 @@ static __be32 confirm_addr_indev(struct in_device *in_dev, __be32 dst,
>
> /*
> * Confirm that local IP address exists using wildcards:
> + * - net: netns to check, cannot be NULL
> * - in_dev: only on this interface, 0=any interface
NULL is better than 0
> * - dst: only in the same subnet as dst, 0=any dst
> * - local: address, 0=autoselect the local address
> * - scope: maximum allowed scope value for the local address
> */
> -__be32 inet_confirm_addr(struct in_device *in_dev,
> +__be32 inet_confirm_addr(struct net *net, struct in_device *in_dev,
> __be32 dst, __be32 local, int scope)
> {
> __be32 addr = 0;
> struct net_device *dev;
> - struct net *net;
>
> if (scope != RT_SCOPE_LINK)
Use if (in_dev)
> - return confirm_addr_indev(in_dev, dst, local, scope);
> + return in_dev ? confirm_addr_indev(in_dev, dst, local, scope) :
> + 0;
We will not need the above change.
> - net = dev_net(in_dev->dev);
> rcu_read_lock();
> for_each_netdev_rcu(net, dev) {
> in_dev = __in_dev_get_rcu(dev);
> --
> 1.8.4.1
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [RFC] Revert "sierra_net: keep status interrupt URB active"
From: Dan Williams @ 2013-11-08 21:29 UTC (permalink / raw)
To: Bjørn Mork
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
John Henderson
In-Reply-To: <87txfm8vz5.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
On Fri, 2013-11-08 at 21:44 +0100, Bjørn Mork wrote:
> Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> > On Mon, 2013-11-04 at 14:27 -0600, Dan Williams wrote:
> >> On Fri, 2013-11-01 at 13:53 +0100, Bjørn Mork wrote:
> >> > This reverts commit 7b0c5f21f348a66de495868b8df0284e8dfd6bbf.
> >> >
> >> > It's not easy to create a driver for all the various firmware
> >> > bugs out there.
> >> >
> >> > This change caused regressions for a number of devices, which
> >> > started to fail link detection and therefore became completely
> >> > non-functional. The exact reason is yet unknown, it looks like
> >> > the affected firmwares might actually need all or some of the
> >> > additional SYNC messages the patch got rid of.
> >> >
> >> > Reverting is not optimal, as it will re-introduce the original
> >> > problem, but it is currently the only alternative known to fix
> >> > this issue.
> >>
> >> Instead, how does the following patch work for you?
> >
> > Bjorn, did you have a chance to try this patch out on your devices?
>
> The only DirectIP device I have is the MC7710, which never had any of
> the firmware issues you are trying to fix. I only tried to forward Johns
> issue.
>
> When this patch worked for John, then I am pretty confident that you
> have solved the problem here.
Well, "solved", since I still have no idea why the original patch would
cause the device behavior based on what I know and have read about the
expected firmware/host handshaking sequence. But the patch there
appears to fix the problem *and* not blindly send tons of SYNCs forever.
So I'll go ahead and submit a proper version of it.
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: iproute2: potential upgrade regression with 58a3e827
From: Eric W. Biederman @ 2013-11-08 21:36 UTC (permalink / raw)
To: Chris J Arges; +Cc: shemminger, netdev
In-Reply-To: <527D2768.1030403@canonical.com>
Chris J Arges <chris.j.arges@canonical.com> writes:
> Hi,
> The commit
> https://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/commit/?id=58a3e8270fe72f8ed92687d3a3132c2a708582dd
> could be potentially introducing a regression on an upgrade.
>
> I've noticed that upgrading iproute while there are active namespaces
> could cause the following error:
> seting the network namespace failed: Invalid argument
>
> Here's a test case:
> Build and install iproute2 with 4395d48c78a77a99c5a8618403211032356fe552
>
> In one terminal run:
> ip netns add netns_old
> ip link add name if_old type veth peer name if_old_peer
> ip link set dev if_old_peer netns netns_old
> ip netns exec netns_old bash
>
> Build and install iproute2 with 58a3e8270fe72f8ed92687d3a3132c2a708582dd
>
> In the same terminal as you typed the original commands run:
> ip netns add netns_one
> ip link add name if_one type veth peer name if_one_peer
> ip link set dev if_one_peer netns netns_one
> ip netns exec netns_one bash
> ip netns exec netns_old bash
>
> You'll get:
> seting the network namespace failed: Invalid argument
>
> If you just run the above without transitioning to the code in 58a3e827,
> then it works.
ip netns exec is fundamentally designed to run code that knows nothing
about network namespaces without modification. If we can make network
namespace aware code work that is great but the entire point of ip netns
exec is to remove the need to convert every network aware program in
linux to be network namespace aware.
Shared subtree support that is added in 58a3e827 should make things a
little better, by letting changes that happen in the initial mount
namespace propogate into children running inside of ip netns exec.
It appears that somehow you wound up in a mount namespace where the
mount of netns_one did not propagate too. Which is weird. I expect
we are missing an error message somewhere.
So far nothing allows network namespaces added like:
ip netns exec ns1 ip netns add ns2
to propogate up to the initial mount namespace and that will definitely
cause problems, but not the problem you are seeing.
Shrug. I will be happy to review patches to make this better but I
don't care enough to investigate. If you aren't up to writing patches
to make ip netns work inside of ip netns exec I recommend you don't do
that then.
Eric
^ permalink raw reply
* Re: Using HTB over MultiQ
From: Eric Dumazet @ 2013-11-08 21:56 UTC (permalink / raw)
To: Anton 'EvilMan' Danilov; +Cc: John Fastabend, netdev
In-Reply-To: <CAEzD07LmgvvfNhNuxzwjy7fxLsCBLiofeXJ61qbdOBQCiSRefw@mail.gmail.com>
On Fri, 2013-11-08 at 19:53 +0400, Anton 'EvilMan' Danilov wrote:
> Hm.. I think I need another way to classify packets for using of mq
> qdisc, because it don't support classify at root (not supported error
> on try attach filter).
I think it might be time to add filters on the device, and run them
without any lock (rcu protection only)
John, I think you had some previous work ?
> On next week i'll try to write ipset extension for setting of priority
> and queue_mapping value through the IPSET netfilter target.
Sounds a nice idea as well.
^ permalink raw reply
* [PATCH] libertas_usb: fix leak at failure path in if_usb_probe()
From: Alexey Khoroshilov @ 2013-11-08 21:57 UTC (permalink / raw)
To: John W. Linville
Cc: Alexey Khoroshilov, libertas-dev, linux-wireless, netdev,
linux-kernel, ldv-project
Error handling code in if_usb_probe() misses usb_put_dev(udev).
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
---
drivers/net/wireless/libertas/if_usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/libertas/if_usb.c b/drivers/net/wireless/libertas/if_usb.c
index 2798077..7aec7b2 100644
--- a/drivers/net/wireless/libertas/if_usb.c
+++ b/drivers/net/wireless/libertas/if_usb.c
@@ -285,6 +285,7 @@ static int if_usb_probe(struct usb_interface *intf,
return 0;
err_get_fw:
+ usb_put_dev(udev);
lbs_remove_card(priv);
err_add_card:
if_usb_reset_device(cardp);
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH net] net: sch_red: Fix race between timer and red_destroy()
From: Vijay Subramanian @ 2013-11-08 21:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Stephen Hemminger, Eric Dumazet
In-Reply-To: <20131105.221633.636594084725891709.davem@davemloft.net>
> del_timer_sync() waits for all instances of the timer handler which
> are running to complete, and then it deletes the timer from any of
> the scheduled timer lists.
>
> Your patch is making the mod_timer() in the timer handler conditional,
> and this really shouldn't be necessary.
>
> The whole point of del_timer_sync() is to address these kinds of
> situations.
Thanks for the explanation Dave. I am trying to reconcile your
explanation with the text above del_timer_sync()
vim +1013 kernel/timer.c
" * This function only differs from del_timer() on SMP: besides deactivating
* the timer it also makes sure the handler has finished executing on other
* CPUs.
*
* Synchronization rules: Callers must prevent restarting of the timer,
* otherwise this function is meaningless. ..."
This seems to suggest simply calling del_timer_sync() is not enough.
In fact, for the same reason I was recently pointed towards
commit 980c478ddbb72 (sch_sfq: use del_timer_sync() in sfq_destroy() )
and I based the patch on how q->perturb_period is reset in
sfq_destroy() and used in sfq_perturbation().
Based on your explanation , I think we do not need (in sched/sch_sfq.c)
q->perturb_period = 0; in sfq_destroy() and just del_timer_sync()
should be enough.
Thanks,
Vijay
^ permalink raw reply
* Re: [patch net-next 1/2] ip6_output: fragment outgoing reassembled skb properly
From: Hannes Frederic Sowa @ 2013-11-08 22:20 UTC (permalink / raw)
To: David Miller
Cc: jiri, netdev, pablo, netfilter-devel, yoshfuji, kadlec, kaber,
mleitner, kuznet, jmorris, wensong, horms, ja, edumazet, pshelar,
jasowang, alexander.h.duyck, fw
In-Reply-To: <20131108.144915.635810300359291522.davem@davemloft.net>
On Fri, Nov 08, 2013 at 02:49:15PM -0500, David Miller wrote:
> Perhaps I don't understand completely the intentions and logic of
> dst_allfrag() in the ipv6 case, and maybe you can explain it to me.
dst_allfrag gets active if we receive a PMTU packet indicating a MTU
smaller than 1280. Of course IPv6 may not go below 1280 but this indicates
e.g. a IPv6->IPv4 migration technology is on the path which needs the
IPv6 fragment header and its fragment id to generate IPv4 fragment ids
out of the IPv6 ones to produce IPv4 fragments just after this migration
router which could well be smaller than 1280.
Maybe this does help a bit,
Hannes
^ permalink raw reply
* Re: iproute2: potential upgrade regression with 58a3e827
From: Chris J Arges @ 2013-11-08 22:30 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: shemminger, netdev
In-Reply-To: <87k3gi4lub.fsf@xmission.com>
On 11/08/2013 03:36 PM, Eric W. Biederman wrote:
> Chris J Arges <chris.j.arges@canonical.com> writes:
>
>> Hi,
>> The commit
>> https://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/commit/?id=58a3e8270fe72f8ed92687d3a3132c2a708582dd
>> could be potentially introducing a regression on an upgrade.
>>
>> I've noticed that upgrading iproute while there are active namespaces
>> could cause the following error:
>> seting the network namespace failed: Invalid argument
>>
>> Here's a test case:
>> Build and install iproute2 with 4395d48c78a77a99c5a8618403211032356fe552
>>
>> In one terminal run:
>> ip netns add netns_old
>> ip link add name if_old type veth peer name if_old_peer
>> ip link set dev if_old_peer netns netns_old
>> ip netns exec netns_old bash
>>
>> Build and install iproute2 with 58a3e8270fe72f8ed92687d3a3132c2a708582dd
>>
>> In the same terminal as you typed the original commands run:
>> ip netns add netns_one
>> ip link add name if_one type veth peer name if_one_peer
>> ip link set dev if_one_peer netns netns_one
>> ip netns exec netns_one bash
>> ip netns exec netns_old bash
>>
>> You'll get:
>> seting the network namespace failed: Invalid argument
>>
>> If you just run the above without transitioning to the code in 58a3e827,
>> then it works.
>
> ip netns exec is fundamentally designed to run code that knows nothing
> about network namespaces without modification. If we can make network
> namespace aware code work that is great but the entire point of ip netns
> exec is to remove the need to convert every network aware program in
> linux to be network namespace aware.
>
> Shared subtree support that is added in 58a3e827 should make things a
> little better, by letting changes that happen in the initial mount
> namespace propogate into children running inside of ip netns exec.
>
> It appears that somehow you wound up in a mount namespace where the
> mount of netns_one did not propagate too. Which is weird. I expect
> we are missing an error message somewhere.
>
> So far nothing allows network namespaces added like:
> ip netns exec ns1 ip netns add ns2
> to propogate up to the initial mount namespace and that will definitely
> cause problems, but not the problem you are seeing.
>
> Shrug. I will be happy to review patches to make this better but I
> don't care enough to investigate. If you aren't up to writing patches
> to make ip netns work inside of ip netns exec I recommend you don't do
> that then.
>
> Eric
Fair enough. I really wanted to get a feel if this seemed like an actual
bug, or rather it's behaving like we'd expect. I don't mind writing
code, but I want to know if I'm hunting a bug, or adding a feature.
Thanks for the quick reply,
--chris j arges
^ permalink raw reply
* Re: iproute2: potential upgrade regression with 58a3e827
From: Eric W. Biederman @ 2013-11-08 22:42 UTC (permalink / raw)
To: Chris J Arges; +Cc: shemminger, netdev
In-Reply-To: <527D65FB.8000407@canonical.com>
Chris J Arges <chris.j.arges@canonical.com> writes:
> Fair enough. I really wanted to get a feel if this seemed like an actual
> bug, or rather it's behaving like we'd expect. I don't mind writing
> code, but I want to know if I'm hunting a bug, or adding a feature.
Making it ip netns add work reliably inside of ip netns exec and
handling all of the permutations is adding a feature.
Understanding why ip netns exec is failing in your specific case sounds
like there may be a missing error message. Clearly you get into a
context where /var/run/netns/netns_old is no the bind mount we would
expect it to be.
I saw nothing that should unmake /var/run/netns/nnetns_old as a mount
point. So something strange is going on.
So you might want to go through and inspect to see what is happening.
Perhaps there is a missing error message somewhere.
Without understanding why that mountpoint fails to exist I can't say if
it is a real bug or if it just something weird caused by using an ip
netns exec it was not designed to be used and is known not to be 100%
robust in.
Eric
^ permalink raw reply
* Re: [PATCH v3] can: add Renesas R-Car CAN driver
From: Sergei Shtylyov @ 2013-11-08 22:54 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: netdev, wg, linux-can, linux-sh, vksavl
In-Reply-To: <527CAC38.6040800@pengutronix.de>
Hello.
On 11/08/2013 12:17 PM, Marc Kleine-Budde wrote:
>>>> Index: linux-can-next/drivers/net/can/rcar_can.c
>>>> ===================================================================
>>>> --- /dev/null
>>>> +++ linux-can-next/drivers/net/can/rcar_can.c
>>>> @@ -0,0 +1,893 @@
[...]
>>>> +#define DRV_NAME "rcar_can"
>>>> +
>>>> +/* Mailbox configuration:
>>>> + * mailbox 0 - not used
>>>> + * mailbox 1-31 - Rx
>>>> + * mailbox 32-63 - Tx
>>>> + * no FIFO mailboxes
>>>> + */
>>>> +#define N_MBX 64
>>>> +#define FIRST_TX_MB 32
>>>> +#define N_TX_MB (N_MBX - FIRST_TX_MB)
>>>> +#define RX_MBX_MASK 0xFFFFFFFE
>>> Please use a common prefix for all defines.
>> OK, done now. Could you however explain why the file-local #define's
>> should be prefixed? It's not quite obvious to me...
> It's about readability and maintainability. If you don't know the
> driver, but all driver local defines and functions have a common prefix,
> it's much easier to read if you are not the author of the driver IMHO.
Well, actually I think the last changes somewhat impaired the readability.
My idea was that you want to exclude name conflicts with #include'd headers
this way...
>> [...]
>>>> +static netdev_tx_t rcar_can_start_xmit(struct sk_buff *skb,
>>>> + struct net_device *ndev)
>>>> +{
>>>> + struct rcar_can_priv *priv = netdev_priv(ndev);
>>>> + struct can_frame *cf = (struct can_frame *)skb->data;
>>>> + u32 data, mier1, mbxno, i;
>>>> + unsigned long flags;
>>>> + u8 mctl = 0;
>>>> +
>>>> + if (can_dropped_invalid_skb(ndev, skb))
>>>> + return NETDEV_TX_OK;
>>>> +
>>>> + spin_lock_irqsave(&priv->mier_lock, flags);
>>>> + mier1 = readl(&priv->regs->mier1);
>>>> + if (mier1) {
>>>> + i = __builtin_clz(mier1);
>>>> + mbxno = i ? N_MBX - i : FIRST_TX_MB;
>>>> + } else {
>>>> + mbxno = FIRST_TX_MB;
>>>> + }
>>> Can you explain how the hardware arbitration works, and you do you
>>> guarantee the CAN frames are send by the hardware in the same order you
>>> put them into the hardware.
>> Tx mailbox with the smallest mailbox number has the highest priority.
>> The other possible Tx mailbox selection rule (not used by the driver
>> now) is ID priority transmit mode (as defined in the ISO 11898-1 specs).
>> The algorithm used guarantees the mailboxes are filled sequentially.
Well, not quite, unfortunately -- it wraps at the last mailbox...
> I see. You are using mier1 to track the used mailboxes....correct?
Yes, the mailbox interrupts in MIER1 are enabled only for used mailboxes.
>> + if (unlikely(mier1 == 0xffffffff))
>> + netif_stop_queue(ndev);
> Then you have a race condition in your tx-complete handler
> rcar_can_tx_done(), as you call netif_wake_queue() unconditionally. If
Yes, I'm seeing it now...
> mier1 == 0xffffffff you must wait until _all_ mailboxes are transmitted
That 0xffffffff criterion seems wrong for me now, I changed the algorithm
and moved the criterion but didn't update it. The correct one seems to be:
if (unlikely(mier1 & 0x80000000))
netif_stop_queue(ndev);
> until you are allowed to reenable the mailboxes. Have a look at the
> at91_can driver, it's using a similar scheme. The lowest mailbox is
> transmitted first, but there are three additional bits that indicate the
> priority.
You mean 4 bits? Priorities are from 0 to 15...
>> I've used 'canfdtest' as suggested by Wolfgang Grandegger to verify, see
>> the log below:
>> root@am335x-evm:~# ./canfdtest -v -g can0
>> interface = can0, family = 29, type = 3, proto = 1
>> ...............................................................................C
>>
>> Test messages sent and received: 483203
>> Exiting...
>> root@am335x-evm:~#
As you can see, 'canfdtest' didn't detect any race, maybe you could
recommend a test which would help to detect it?
>> [...]
>>>> +static int rcar_can_rx_poll(struct napi_struct *napi, int quota)
>>>> +{
>>>> + struct rcar_can_priv *priv = container_of(napi,
>>>> + struct rcar_can_priv, napi);
>>>> + int num_pkts = 0;
>>>> +
>>>> + /* Find mailbox */
>>>> + while (num_pkts < quota) {
>>>> + u8 mctl, mbx;
>>>> +
>>>> + mbx = readb(&priv->regs->mssr);
>>> How does the RX work? Is it a hardware FIFO?
>> In short, the MSSR register provides the smallest Rx mailbox number
>> that is looked up in the Rx search mode. We read MSSR until no search
>> results can be obtained, so it is some sort of FIFO.
> This looks racy....
Could you please elaborate?
>> And there is separate FIFO operation mode: some mailboxes can be
>> configured as FIFO and serviced by special registers but this operation
>> mode is not supported by the driver.
> if you hardware supports a real FIFO then I strongly suggest to make use
> of it.
Well, Tx/Rx FIFOs are only 4 frames deep (although I haven't seen more
than 2 Rx mailboxes ready in a row, there are 32 Tx mailboxes); also FIFO mode
is less documented than mailbox mode (hence some nasty surprises are
possible). We still can use mailboxes when in FIFO mode, it's just 8 of them
are reserved for Tx/Rx FIFOs.
>> [...]
>>>> +static int rcar_can_probe(struct platform_device *pdev)
>>>> +{
[...]
>>>> + ndev->netdev_ops = &rcar_can_netdev_ops;
>>>> + ndev->irq = irq;
>>>> + ndev->flags |= IFF_ECHO;
>>>> + priv->ndev = ndev;
>>>> + priv->regs = addr;
>>>> + priv->clock_select = pdata->clock_select;
>>>> + priv->can.clock.freq = clk_get_rate(priv->clk);
>>>> + priv->can.bittiming_const = &rcar_can_bittiming_const;
>>>> + priv->can.do_set_bittiming = rcar_can_set_bittiming;
>>> Please call this function directly during the open() function.
>> OK, done, and the method installation was removed. However, I'm not
>> sure why you requested this as many drivers are still using the method.
> The callback was there from the beginning, but then we figured out that
> we don't need it in the driver, but no one has cleaned up the drivers
> yet. So don't use it in new drivers. I know it's not documented anywhere :(
You should have clarified that in your first review -- that would have
prevented me from going the wrong way...
> regards,
> Marc
WBR, Sergei
^ permalink raw reply
* Re: Using HTB over MultiQ
From: John Fastabend @ 2013-11-08 23:11 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Anton 'EvilMan' Danilov, netdev
In-Reply-To: <1383947802.16391.3.camel@edumazet-glaptop2.roam.corp.google.com>
On 11/8/2013 1:56 PM, Eric Dumazet wrote:
> On Fri, 2013-11-08 at 19:53 +0400, Anton 'EvilMan' Danilov wrote:
>
>> Hm.. I think I need another way to classify packets for using of mq
>> qdisc, because it don't support classify at root (not supported error
>> on try attach filter).
>
> I think it might be time to add filters on the device, and run them
> without any lock (rcu protection only)
>
> John, I think you had some previous work ?
Yes, I have a net-next fork with this but I currently introduced a bug
in the u32 classifier. I'll resurrect this next week and send something
out. We can take a look and see if its useful.
>
>> On next week i'll try to write ipset extension for setting of priority
>> and queue_mapping value through the IPSET netfilter target.
>
> Sounds a nice idea as well.
>
Another thought would be to put a netfilter hook above the qdisc and on
ingress (not in the bridge module). I've been meaning to take a look
at nftables I'm not sure how much duplication exists between nftables
and tc classifiers at this point.
>
> --
> 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
>
^ permalink raw reply
* Re: [RFC] tcp: randomize TCP source ports
From: Rick Jones @ 2013-11-08 23:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1383876294.9412.136.camel@edumazet-glaptop2.roam.corp.google.com>
On 11/07/2013 06:04 PM, Eric Dumazet wrote:
> On Thu, 2013-11-07 at 17:07 -0800, Rick Jones wrote:
>
>> For perhaps most definitions of well deployed. There is at least one
>> load balancer which, while it offers TCP Window Scaling, does not also
>> offer TCP Time Stamps...
>>
>> By rights they should (must) be offering TCP Time Stamps, and they are,
>> I am told, "working on it."
>>
>> Is all going to be "well" when it is the (non-Linux) remote system which
>> has the TIME_WAIT endpoint?
>
> Hey, tell us why netperf does a bind(port=0, addr=ANY) and SO_REUSEADDR
> tricks before connect()
>
> It seems you do request randomization, but you do not want it for
> applications written by innocent people...
That bind() call is not there to request randomization of the TCP source
port.
The bind() call in src/nettest_bsd.c/create_data_socket() is so
netserver can report a port number back to netperf. It is also there so
a TCP_CRR test can explicitly use more than the configured ephemeral
port range. It is also used when setting explicit port numbers for
getting through firewalls.
In the establish_control() path the bind() call is also there to allow
specifying an explicit port number for the control connection. I just
don't bother avoiding the call when someone hasn't selected an explicit
client-side port number for the control connection.
happy benchmarking,
rick jones
^ permalink raw reply
* Re: [RFC] tcp: randomize TCP source ports
From: Eric Dumazet @ 2013-11-08 23:42 UTC (permalink / raw)
To: Rick Jones; +Cc: David Miller, netdev
In-Reply-To: <527D7320.4050008@hp.com>
On Fri, 2013-11-08 at 15:26 -0800, Rick Jones wrote:
> On 11/07/2013 06:04 PM, Eric Dumazet wrote:
> >
> > It seems you do request randomization, but you do not want it for
> > applications written by innocent people...
>
> That bind() call is not there to request randomization of the TCP source
> port.
I was actually doing some kind of humor, I should have added a ;)
Thanks
^ permalink raw reply
* Re: [RFC] tcp: randomize TCP source ports
From: Rick Jones @ 2013-11-08 23:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1383954154.16391.4.camel@edumazet-glaptop2.roam.corp.google.com>
On 11/08/2013 03:42 PM, Eric Dumazet wrote:
> On Fri, 2013-11-08 at 15:26 -0800, Rick Jones wrote:
>> On 11/07/2013 06:04 PM, Eric Dumazet wrote:
>>>
>>> It seems you do request randomization, but you do not want it for
>>> applications written by innocent people...
>>
>> That bind() call is not there to request randomization of the TCP source
>> port.
>
> I was actually doing some kind of humor, I should have added a ;)
Sorry - been watching one of my kids most of the day, my humor/snark
detectors were offline :)
rick
^ permalink raw reply
* Re: [PATCH net] netlink: fix netlink_ack with large messages
From: Thomas Graf @ 2013-11-09 0:04 UTC (permalink / raw)
To: David Miller; +Cc: jbenc, netdev, pablo
In-Reply-To: <20131108.150741.966018155704146843.davem@davemloft.net>
On 11/08/13 at 03:07pm, David Miller wrote:
> From: Jiri Benc <jbenc@redhat.com>
> Date: Thu, 7 Nov 2013 19:57:45 +0100
>
> > Commit c05cdb1b864f ("netlink: allow large data transfers from user-space")
> > does not handle cases where netlink_ack is used to report an error. In such
> > case, the original message is copied to the ack message, which needs to be
> > large enough.
> >
> > Signed-off-by: Jiri Benc <jbenc@redhat.com>
>
> I have two problems with this change.
>
> First of all, if netlink_ack() has this problem, do not extend the
> netlink_alloc_large_skb() usage to dumps too as your patch is
> doing here.
>
> Secondly, it seems sort of over the top to quote such enormous
> messages, and in fact wasteful. We have the sequence number in
> the netlink header, so the user can tell exactly which message
> we are erroring.
>
> Just quoting such huge requests in ACKs by default doesn't seem
> to make any sense. I would say that we should have a way to
> turn off the quoting, or at least limit it, and turn this knob
> off for things like nftables that can hit these kinds of cases.
I agree it seems over the top for pure ACKs but we also use
netlink_ack() to report errors where it makes sense to quote
the full message.
^ permalink raw reply
* [RFC PATCH net-next 2/2] udp: add sk opt to allow sending pkt with src 0.0.0.0
From: Nicolas Dichtel @ 2013-11-09 0:54 UTC (permalink / raw)
To: hannes
Cc: netdev, davem, David.Laight, jiri, vyasevich, kuznet, jmorris,
yoshfuji, kaber, thaller, stephen, Nicolas Dichtel
In-Reply-To: <1383958474-6255-1-git-send-email-nicolas.dichtel@6wind.com>
This feature allows to a send packets with address source set to 0.0.0.0 even if
an ip address is available on another interface.
It's useful for DHCP client, to allow them to use UDP sockets and be compliant
with the RFC2131, Section 4.1:
4.1 Constructing and sending DHCP messages
...
DHCP messages broadcast by a client prior to that client obtaining
its IP address must have the source address field in the IP header
set to 0.
Based on a previous work from
Guillaume Gaudonville <guillaume.gaudonville@6wind.com>.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
include/linux/udp.h | 3 ++-
include/uapi/linux/udp.h | 1 +
net/ipv4/udp.c | 21 +++++++++++++++++++++
3 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/include/linux/udp.h b/include/linux/udp.h
index 42278bbf7a88..ca947206f0fe 100644
--- a/include/linux/udp.h
+++ b/include/linux/udp.h
@@ -63,7 +63,8 @@ struct udp_sock {
#define UDPLITE_SEND_CC 0x2 /* set via udplite setsockopt */
#define UDPLITE_RECV_CC 0x4 /* set via udplite setsocktopt */
__u8 pcflag; /* marks socket as UDP-Lite if > 0 */
- __u8 unused[3];
+ __u8 src_any:1; /* saddr to 0 when no IP is available */
+ __u8 unused[2];
/*
* For encapsulation sockets.
*/
diff --git a/include/uapi/linux/udp.h b/include/uapi/linux/udp.h
index e2bcfd75a30d..daf4a48face1 100644
--- a/include/uapi/linux/udp.h
+++ b/include/uapi/linux/udp.h
@@ -29,6 +29,7 @@ struct udphdr {
/* UDP socket options */
#define UDP_CORK 1 /* Never send partially complete segments */
#define UDP_ENCAP 100 /* Set the socket to accept encapsulated packets */
+#define UDP_SRC_ANY 101 /* Set src addr to 0 when no IP is available */
/* UDP encapsulation types */
#define UDP_ENCAP_ESPINUDP_NON_IKE 1 /* draft-ietf-ipsec-nat-t-ike-00/01 */
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 89909dd730dd..f58945187dbd 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -111,6 +111,7 @@
#include <linux/static_key.h>
#include <trace/events/skb.h>
#include <net/busy_poll.h>
+#include <linux/inetdevice.h>
#include "udp_impl.h"
struct udp_table udp_table __read_mostly;
@@ -1015,6 +1016,18 @@ int udp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
goto do_confirm;
back_from_confirm:
+ if (up->src_any && sk->sk_bound_dev_if) {
+ struct net_device *dev;
+ struct in_device *in_dev;
+
+ rcu_read_lock();
+ dev = dev_get_by_index_rcu(sock_net(sk), sk->sk_bound_dev_if);
+ in_dev = dev ? __in_dev_get_rcu(dev) : NULL;
+ if (!inet_confirm_addr(sock_net(sk), in_dev, 0, 0,
+ RT_SCOPE_HOST))
+ fl4->saddr = 0;
+ rcu_read_unlock();
+ }
saddr = fl4->saddr;
if (!ipc.addr)
daddr = ipc.addr = fl4->daddr;
@@ -2045,6 +2058,10 @@ int udp_lib_setsockopt(struct sock *sk, int level, int optname,
up->pcflag |= UDPLITE_RECV_CC;
break;
+ case UDP_SRC_ANY:
+ up->src_any = val ? 1 : 0;
+ break;
+
default:
err = -ENOPROTOOPT;
break;
@@ -2107,6 +2124,10 @@ int udp_lib_getsockopt(struct sock *sk, int level, int optname,
val = up->pcrlen;
break;
+ case UDP_SRC_ANY:
+ val = up->src_any;
+ break;
+
default:
return -ENOPROTOOPT;
}
--
1.8.4.1
^ permalink raw reply related
* [RFC PATCH net-next 1/2] ipv4: fix wildcard search with inet_confirm_addr()
From: Nicolas Dichtel @ 2013-11-09 0:54 UTC (permalink / raw)
To: hannes
Cc: netdev, davem, David.Laight, jiri, vyasevich, kuznet, jmorris,
yoshfuji, kaber, thaller, stephen, Nicolas Dichtel
In-Reply-To: <20131105205744.GK8832@order.stressinduktion.org>
Help of this function says: "in_dev: only on this interface, 0=any interface",
but in fact the code supposes that it will never be NULL.
Note that this function was never called with in_dev == NULL, but it's exported
and may be used by an external module.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
This patch has been submitted formally for net (some rework are needed), but the
next one is based on it, it's why I send it here.
drivers/net/bonding/bonding.h | 10 +++-------
include/linux/inetdevice.h | 4 ++--
net/ipv4/arp.c | 3 ++-
net/ipv4/devinet.c | 8 ++++----
4 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 77a07a12e77f..203deaf30f83 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -377,15 +377,11 @@ static inline bool bond_is_slave_inactive(struct slave *slave)
static inline __be32 bond_confirm_addr(struct net_device *dev, __be32 dst, __be32 local)
{
- struct in_device *in_dev;
- __be32 addr = 0;
+ __be32 addr;
rcu_read_lock();
- in_dev = __in_dev_get_rcu(dev);
-
- if (in_dev)
- addr = inet_confirm_addr(in_dev, dst, local, RT_SCOPE_HOST);
-
+ addr = inet_confirm_addr(dev_net(dev), __in_dev_get_rcu(dev), dst,
+ local, RT_SCOPE_HOST);
rcu_read_unlock();
return addr;
}
diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h
index 0d678aefe69d..f188e7598edd 100644
--- a/include/linux/inetdevice.h
+++ b/include/linux/inetdevice.h
@@ -164,8 +164,8 @@ int devinet_ioctl(struct net *net, unsigned int cmd, void __user *);
void devinet_init(void);
struct in_device *inetdev_by_index(struct net *, int);
__be32 inet_select_addr(const struct net_device *dev, __be32 dst, int scope);
-__be32 inet_confirm_addr(struct in_device *in_dev, __be32 dst, __be32 local,
- int scope);
+__be32 inet_confirm_addr(struct net *net, struct in_device *in_dev, __be32 dst,
+ __be32 local, int scope);
struct in_ifaddr *inet_ifa_byprefix(struct in_device *in_dev, __be32 prefix,
__be32 mask);
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index 7808093cede6..fc5ebc7e1962 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -408,7 +408,8 @@ static int arp_ignore(struct in_device *in_dev, __be32 sip, __be32 tip)
default:
return 0;
}
- return !inet_confirm_addr(in_dev, sip, tip, scope);
+ return !inet_confirm_addr(dev_net(in_dev->dev), in_dev, sip, tip,
+ scope);
}
static int arp_filter(__be32 sip, __be32 tip, struct net_device *dev)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index a1b5bcbd04ae..47cdb035f817 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1236,22 +1236,22 @@ static __be32 confirm_addr_indev(struct in_device *in_dev, __be32 dst,
/*
* Confirm that local IP address exists using wildcards:
+ * - net: netns to check, cannot be NULL
* - in_dev: only on this interface, 0=any interface
* - dst: only in the same subnet as dst, 0=any dst
* - local: address, 0=autoselect the local address
* - scope: maximum allowed scope value for the local address
*/
-__be32 inet_confirm_addr(struct in_device *in_dev,
+__be32 inet_confirm_addr(struct net *net, struct in_device *in_dev,
__be32 dst, __be32 local, int scope)
{
__be32 addr = 0;
struct net_device *dev;
- struct net *net;
if (scope != RT_SCOPE_LINK)
- return confirm_addr_indev(in_dev, dst, local, scope);
+ return in_dev ? confirm_addr_indev(in_dev, dst, local, scope) :
+ 0;
- net = dev_net(in_dev->dev);
rcu_read_lock();
for_each_netdev_rcu(net, dev) {
in_dev = __in_dev_get_rcu(dev);
--
1.8.4.1
^ permalink raw reply related
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