* Re: [patch net-next] rtnl: make ifla_policy static
From: Jiri Pirko @ 2014-02-18 21:51 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, David Miller, Patrick McHardy,
Stephen Hemminger, vyasevic, jbenc
In-Reply-To: <CAM_iQpUzp7xkj21dyzzXRjZgyO+z5+k4cDM9LoYkzy4OL8807w@mail.gmail.com>
Tue, Feb 18, 2014 at 10:40:55PM CET, xiyou.wangcong@gmail.com wrote:
>On Tue, Feb 18, 2014 at 11:53 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> The only place this is used outside rtnetlink.c is veth. So provide
>> wrapper function for this usage.
>
>Looks good. Or make rtnl_nla_parse_ifla() static inline?
Not possible if we want to kill ifla_policy export...
^ permalink raw reply
* [PATCH v5 net-next 0/12] bonding: add an option to rely on unvalidated arp packets
From: David Miller @ 2014-02-18 21:49 UTC (permalink / raw)
To: vfalico; +Cc: netdev, rob, fubar, andy, dingtianhong, nikolay, nhorman, amwang
In-Reply-To: <1392706127-28390-1-git-send-email-vfalico@redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Tue, 18 Feb 2014 07:48:35 +0100
> Currently, if arp_validate is off (0), slave_last_rx() returns the
> slave->dev->last_rx, which is always updated on *any* packet received by
> slave, and not only arps. This means that, if the validation of arps is
> off, we're treating *any* incoming packet as a proof of slave being up, and
> not only arps.
>
> This might seem logical at the first glance, however it can cause a lot of
> troubles and false-positives, one example would be:
>
> The arp_ip_target is NOT accessible, however someone in the broadcast domain
> spams with any broadcast traffic. This way bonding will be tricked that the
> slave is still up (as in - can access arp_ip_target), while it's not.
>
> The net_device->last_rx is already used in a lot of drivers (even though the
> comment states to NOT do it :)), and it's also ugly to modify it from bonding.
>
> However, some loadbalance setups might rely on the fact that even non-arp
> traffic is a sign of slave being up - and we definitely can't break anyones
> config - so an extension to arp_validate is needed.
>
> So, to fix this, add an option for the user to specify if he wants to
> filter out non-arp traffic on unvalidated slaves, remove the last_rx from
> bonding, *always* call bond_arp_rcv() in slave's rx_handler (which is
> bond_handle_frame), and if we spot an arp there with this option on - update
> the slave->last_arp_rx - and use it instead of net_device->last_rx. Finally,
> rename last_arp_rx to last_rx to reflect the changes.
>
> Also rename slave->jiffies to ->last_link_up, to reflect better its
> meaning, add the new option's documentation and update the arp_validate one
> to be a bit more descriptive.
Series applied, thanks.
^ permalink raw reply
* Re: [RFC v2 2/4] net: enables interface option to skip IP
From: Stephen Hemminger @ 2014-02-18 21:42 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Dan Williams, netdev@vger.kernel.org, xen-devel, kvm,
linux-kernel@vger.kernel.org, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <CAB=NE6XGBp1RwO63W0ac6tTr9JcRM9TB9sap4pa+8PMWwjxu6g@mail.gmail.com>
On Tue, 18 Feb 2014 13:19:15 -0800
"Luis R. Rodriguez" <mcgrof@do-not-panic.com> wrote:
> Sure, but note that the both disable_ipv6 and accept_dada sysctl
> parameters are global. ipv4 and ipv6 interfaces are created upon
> NETDEVICE_REGISTER, which will get triggered when a driver calls
> register_netdev(). The goal of this patch was to enable an early
> optimization for drivers that have no need ever for ipv4 or ipv6
> interfaces.
The trick with ipv6 is to register the device, then have userspace
do the ipv6 sysctl before bringing the device up.
^ permalink raw reply
* Re: [PATCH net-next 00/14] r8152: improvement and new features
From: David Miller @ 2014-02-18 21:41 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1392731351-25502-1-git-send-email-hayeswang@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Tue, 18 Feb 2014 21:48:57 +0800
> Change some flows or behavior to improve the efficiency or make the
> code readable. Besides, support WOL and runtime suspend.
Series applied, but as Florian mentioned you should seriously consider
converting this driver to use phylib.
^ permalink raw reply
* Re: [patch net-next] rtnl: make ifla_policy static
From: Cong Wang @ 2014-02-18 21:40 UTC (permalink / raw)
To: Jiri Pirko
Cc: Linux Kernel Network Developers, David Miller, Patrick McHardy,
Stephen Hemminger, vyasevic, jbenc
In-Reply-To: <1392753198-9437-1-git-send-email-jiri@resnulli.us>
On Tue, Feb 18, 2014 at 11:53 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> The only place this is used outside rtnetlink.c is veth. So provide
> wrapper function for this usage.
Looks good. Or make rtnl_nla_parse_ifla() static inline?
^ permalink raw reply
* Re: [Xen-devel] [RFC v2 3/4] xen-netback: use a random MAC address
From: Luis R. Rodriguez @ 2014-02-18 21:30 UTC (permalink / raw)
To: Ian Campbell
Cc: David Vrabel, netdev@vger.kernel.org, Wei Liu, kvm,
linux-kernel@vger.kernel.org, Paul Durrant, xen-devel
In-Reply-To: <1392722575.11080.28.camel@kazak.uk.xensource.com>
On Tue, Feb 18, 2014 at 3:22 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2014-02-17 at 10:29 +0000, David Vrabel wrote:
>> On 15/02/14 02:59, Luis R. Rodriguez wrote:
>> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
>> >
>> > The purpose of using a static MAC address of FE:FF:FF:FF:FF:FF
>> > was to prevent our backend interfaces from being used by the
>> > bridge and nominating our interface as a root bridge. This was
>> > possible given that the bridge code will use the lowest MAC
>> > address for a port once a new interface gets added to the bridge.
>> > The bridge code has a generic feature now to allow interfaces
>> > to opt out from root bridge nominations, use that instead.
>> [...]
>> > --- a/drivers/net/xen-netback/interface.c
>> > +++ b/drivers/net/xen-netback/interface.c
>> > @@ -42,6 +42,8 @@
>> > #define XENVIF_QUEUE_LENGTH 32
>> > #define XENVIF_NAPI_WEIGHT 64
>> >
>> > +static const u8 xen_oui[3] = { 0x00, 0x16, 0x3e };
>>
>> You shouldn't use a vendor prefix with a random MAC address. You should
>> set the locally administered bit and clear the multicast/unicast bit and
>> randomize the remaining 46 bits.
>
> I'd have thought that eth_hw_addr_random would get this right, *checks*
> yes it does. And then this patch tramples overt the top three bytes.
>
> Might there be any requirement to have a specific MAC on the vif device?
> IOW do we need to figure out a way to plumb this through the Xen tools
> (perhaps having the vif script sort it out).
Based on Stephen's feedback we should be setting IFLA_BRPORT_PROTECT
to the xen-netback and TAP interfaces in topologies where it makes
sense prior to adding them to the bridge. Userspace can surely deal
with the MAC address but I believe removing the static MAC address
would be good once we get userspace to use the IFLA_BRPORT_PROTECT
flag, to avoid the IPv6 duplication issue incurred by the current
static MAC address. The MAC address consideration remains given that
as per Zoltan there are topologies where the xen-netback interfaces
can make use of a either an IPv4 or IPv6 address.
> Speaking of which -- do the Xen tools not overwrite this random mac from
> xen-network-common.sh:_setup_bridge_port. What is the plan to change
> that (in a forwards/backwards compatible manner).
I'm not seeing that happen now ?
Luis
^ permalink raw reply
* Re: [PATCH net-next 0/8] Adds support for Chelsio T5 40G adapter and Misc. fixes
From: David Miller @ 2014-02-18 21:24 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, dm, leedom, nirranjan, kumaras, santosh
In-Reply-To: <1392726375-32001-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Tue, 18 Feb 2014 17:56:07 +0530
> This patch series adds support for Chelsio T5 40G adapters and provides
> miscelleneous fixes for cxgb4 driver.
>
> It also adds device ids of two new T5 adapters.
>
> We would like to request this patch series to get merged via David Miller's
> 'net-next' tree.
>
> We have included all the maintainers of respective drivers. Kindly review the
> change and let us know in case of any review comments.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] ipv4: fix counter in_slow_tot
From: David Miller @ 2014-02-18 21:24 UTC (permalink / raw)
To: duanj.fnst; +Cc: netdev
In-Reply-To: <5301B8FF.6030800@cn.fujitsu.com>
From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Date: Mon, 17 Feb 2014 15:23:43 +0800
> since commit 89aef8921bf("ipv4: Delete routing cache."), the counter
> in_slow_tot can't work correctly.
>
> The counter in_slow_tot increase by one when fib_lookup() return successfully
> in ip_route_input_slow(), but actually the dst struct maybe not be created and
> cached, so we can increase in_slow_tot after the dst struct is created.
>
> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Applied, thanks.
^ permalink raw reply
* Re: [RFC v2 2/4] net: enables interface option to skip IP
From: Luis R. Rodriguez @ 2014-02-18 21:19 UTC (permalink / raw)
To: Dan Williams
Cc: netdev@vger.kernel.org, xen-devel, kvm,
linux-kernel@vger.kernel.org, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <1392668638.21106.5.camel@dcbw.local>
On Mon, Feb 17, 2014 at 12:23 PM, Dan Williams <dcbw@redhat.com> wrote:
> On Fri, 2014-02-14 at 18:59 -0800, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>
>> Some interfaces do not need to have any IPv4 or IPv6
>> addresses, so enable an option to specify this. One
>> example where this is observed are virtualization
>> backend interfaces which just use the net_device
>> constructs to help with their respective frontends.
>>
>> This should optimize boot time and complexity on
>> virtualization environments for each backend interface
>> while also avoiding triggering SLAAC and DAD, which is
>> simply pointless for these type of interfaces.
>
> Would it not be better/cleaner to use disable_ipv6 and then add a
> disable_ipv4 sysctl, then use those with that interface?
Sure, but note that the both disable_ipv6 and accept_dada sysctl
parameters are global. ipv4 and ipv6 interfaces are created upon
NETDEVICE_REGISTER, which will get triggered when a driver calls
register_netdev(). The goal of this patch was to enable an early
optimization for drivers that have no need ever for ipv4 or ipv6
interfaces.
Zoltan has noted though some use cases of IPv4 or IPv6 addresses on
backends though, as such this is no longer applicable as a
requirement. The ipv4 sysctl however still seems like a reasonable
approach to enable optimizations of the network in topologies where
its known we won't need them but -- we'd need to consider a much more
granular solution, not just global as it is now for disable_ipv6, and
we'd also have to figure out a clean way to do this to not incur the
cost of early address interface addition upon register_netdev().
Given that we have a use case for ipv4 and ipv6 addresses on
xen-netback we no longer have an immediate use case for such early
optimization primitives though, so I'll drop this.
> The IFF_SKIP_IP seems to duplicate at least part of what disable_ipv6 is
> already doing.
disable_ipv6 is global, the goal was to make this granular and skip
the cost upon early boot, but its been clarified we don't need this.
Luis
^ permalink raw reply
* Re: [PATCH net] net: sctp: fix sctp_connectx abi for ia32 emulation/compat mode
From: David Miller @ 2014-02-18 21:07 UTC (permalink / raw)
To: dborkman; +Cc: netdev, linux-sctp
In-Reply-To: <1392635471-31528-1-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Mon, 17 Feb 2014 12:11:11 +0100
> SCTP's sctp_connectx() abi breaks for 64bit kernels compiled with 32bit
> emulation (e.g. ia32 emulation or x86_x32). Due to internal usage of
> 'struct sctp_getaddrs_old' which includes a struct sockaddr pointer,
> sizeof(param) check will always fail in kernel as the structure in
> 64bit kernel space is 4bytes larger than for user binaries compiled
> in 32bit mode. Thus, applications making use of sctp_connectx() won't
> be able to run under such circumstances.
>
> Introduce a compat interface in the kernel to deal with such
> situations by using a 'struct compat_sctp_getaddrs_old' structure
> where user data is copied into it, and then sucessively transformed
> into a 'struct sctp_getaddrs_old' structure with the help of
> compat_ptr(). That fixes sctp_connectx() abi without any changes
> needed in user space, and lets the SCTP test suite pass when compiled
> in 32bit and run on 64bit kernels.
>
> Fixes: f9c67811ebc0 ("sctp: Fix regression introduced by new sctp_connectx api")
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [RFC v2 1/4] bridge: enable interfaces to opt out from becoming the root bridge
From: Luis R. Rodriguez @ 2014-02-18 21:02 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev@vger.kernel.org, xen-devel, kvm,
linux-kernel@vger.kernel.org, bridge
In-Reply-To: <20140216105754.63738163@nehalam.linuxnetplumber.net>
On Sun, Feb 16, 2014 at 10:57 AM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> On Fri, 14 Feb 2014 18:59:37 -0800
> "Luis R. Rodriguez" <mcgrof@do-not-panic.com> wrote:
>
>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>
>> It doesn't make sense for some interfaces to become a root bridge
>> at any point in time. One example is virtual backend interfaces
>> which rely on other entities on the bridge for actual physical
>> connectivity. They only provide virtual access.
>>
>> Device drivers that know they should never become part of the
>> root bridge have been using a trick of setting their MAC address
>> to a high broadcast MAC address such as FE:FF:FF:FF:FF:FF. Instead
>> of using these hacks lets the interfaces annotate its intent and
>> generalizes a solution for multiple drivers, while letting the
>> drivers use a random MAC address or one prefixed with a proper OUI.
>> This sort of hack is used by both qemu and xen for their backend
>> interfaces.
>>
>> Cc: Stephen Hemminger <stephen@networkplumber.org>
>> Cc: bridge@lists.linux-foundation.org
>> Cc: netdev@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
>
> This is already supported in a more standard way via the root
> block flag.
Great! For documentation purposes the root_block flag is a sysfs
attribute, added via 3.8 through commit 1007dd1a. The respective
interface flag is IFLA_BRPORT_PROTECT and can be set via the iproute2
bridge utility or through sysfs:
mcgrof@garbanzo ~/linux (git::master)$ find /sys/ -name root_block
/sys/devices/pci0000:00/0000:00:04.0/0000:02:00.0/net/eth0/brport/root_block
/sys/devices/vif-3-0/net/vif3.0/brport/root_block
/sys/devices/virtual/net/vif3.0-emu/brport/root_block
mcgrof@garbanzo ~/devel/iproute2 (git::master)$ cat
/sys/devices/vif-3-0/net/vif3.0/brport/root_block
0
mcgrof@garbanzo ~/devel/iproute2 (git::master)$ sudo bridge link set
dev vif3.0 root_block on
mcgrof@garbanzo ~/devel/iproute2 (git::master)$ cat
/sys/devices/vif-3-0/net/vif3.0/brport/root_block
1
So if we'd want to avoid using the MAC address hack alternative to
skip a root port userspace would need to be updated to simply set this
attribute after adding the device to the bridge. Based on Zoltan's
feedback there seems to be use cases to not enable this always for all
xen-netback interfaces though as such we can just punt this to
userspace for the topologies that require this.
The original motivation for this series was to avoid the IPv6
duplicate address incurred by the MAC address hack for avoiding the
root bridge. Given that Zoltan also noted a use case whereby IPv4 and
IPv6 addresses can be assigned to the backend interfaces we should be
able to avoid the duplicate address situation for IPv6 by using a
proper random MAC address *once* userspace has been updated also to
use IFLA_BRPORT_PROTECT. New userspace can't and won't need to set
this flag for older kernels (older than 3.8) as root_block is not
implemented on those kernels and the MAC address hack would still be
used there. This strategy however does put a requirement on new
kernels to use new userspace as otherwise the MAC address workaround
would not be in place and root_block would not take effect.
Luis
^ permalink raw reply
* Re: [B.A.T.M.A.N.] [PATCH 01/10] batman-adv: fix soft-interface MTU computation
From: Antonio Quartulli @ 2014-02-18 20:57 UTC (permalink / raw)
To: David Miller; +Cc: b.a.t.m.a.n, netdev, mareklindner
In-Reply-To: <20140218.154152.94226033273009453.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 528 bytes --]
On 18/02/14 21:41, David Miller wrote:
> So I pulled this, but I just want you to know that you should really
> start to bear down and minimize the amount of changes you are submitting
> for 'net' as we're starting to get deep into -rc territory.
I decided to wait until the last bugfix was ready before sending the
patchset....but I imagine a better choice is to send the big bunch as
soon as possible and then keep the small remaining bits for later.
I will do that next time.
Thanks!
--
Antonio Quartulli
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: ixgbevf: Use pci_enable_msix_range() instead of pci_enable_msix()
From: David Miller @ 2014-02-18 20:56 UTC (permalink / raw)
To: amirv
Cc: agordeev, linux-kernel, jeffrey.t.kirsher, jesse.brandeburg,
bruce.w.allan, e1000-devel, netdev, linux-pci
In-Reply-To: <20140218120136.GA8770@mtl-eit-vdi-22.mtl.labs.mlnx>
From: Amir Vadai <amirv@mellanox.com>
Date: Tue, 18 Feb 2014 14:01:38 +0200
> On 18/02/14 11:11 +0100, Alexander Gordeev wrote:
>> As result of deprecation of MSI-X/MSI enablement functions
>> pci_enable_msix() and pci_enable_msi_block() all drivers
>> using these two interfaces need to be updated to use the
>> new pci_enable_msi_range() and pci_enable_msix_range()
>> interfaces.
>>
>> Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
>> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
>> Cc: Bruce Allan <bruce.w.allan@intel.com>
>> Cc: e1000-devel@lists.sourceforge.net
>> Cc: netdev@vger.kernel.org
>> Cc: linux-pci@vger.kernel.org
>> ---
>
> Acked-By: Amir Vadai <amirv@mellanox.com>
Since you obviously didn't intend to ACK this, I removed this ACK when
I committed the series.
^ permalink raw reply
* Re: [B.A.T.M.A.N.] [PATCH 01/10] batman-adv: fix soft-interface MTU computation
From: David Miller @ 2014-02-18 20:41 UTC (permalink / raw)
To: antonio; +Cc: b.a.t.m.a.n, netdev, mareklindner
In-Reply-To: <53030165.2050404@meshcoding.com>
From: Antonio Quartulli <antonio@meshcoding.com>
Date: Tue, 18 Feb 2014 07:44:53 +0100
> On 17/02/14 22:13, David Miller wrote:
>> From: Antonio Quartulli <antonio@meshcoding.com>
>> Date: Mon, 17 Feb 2014 21:48:40 +0100
>>
>>> + atomic_set(&bat_priv->packet_size_max, min_mtu);
>>
>> Please fix this.
>>
>> The only operations performed on packet_size_max are 'set' and
>> 'read'. This is not what one uses atomic_t's for.
>>
>> The use of an atomic_t in this context is a NOP. You aren't
>> getting any kind of synchronization at all.
>
> True. Thanks for the suggestion.
> Unfortunately this is not the only "fake-atomic" variable we have.
So I pulled this, but I just want you to know that you should really
start to bear down and minimize the amount of changes you are submitting
for 'net' as we're starting to get deep into -rc territory.
Thanks.
^ permalink raw reply
* [PATCH net-next] ipv6: honor IPV6_PKTINFO with v4 mapped addresses on sendmsg
From: Hannes Frederic Sowa @ 2014-02-18 20:38 UTC (permalink / raw)
To: netdev; +Cc: gert, tore
In case we decide in udp6_sendmsg to send the packet down the ipv4
udp_sendmsg path because the destination is either of family AF_INET or
the destination is an ipv4 mapped ipv6 address, we don't honor the
maybe specified ipv4 mapped ipv6 address in IPV6_PKTINFO.
We simply can check for this option in ip_cmsg_send because no calls to
ipv6 module functions are needed to do so.
Reported-by: Gert Doering <gert@space.net>
Cc: Tore Anderson <tore@fud.no>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
include/net/ip.h | 3 ++-
net/ipv4/ip_sockglue.c | 19 ++++++++++++++++++-
net/ipv4/ping.c | 2 +-
net/ipv4/raw.c | 2 +-
net/ipv4/udp.c | 3 ++-
5 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/include/net/ip.h b/include/net/ip.h
index 23be0fd..4aa781b 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -489,7 +489,8 @@ int ip_options_rcv_srr(struct sk_buff *skb);
void ipv4_pktinfo_prepare(const struct sock *sk, struct sk_buff *skb);
void ip_cmsg_recv(struct msghdr *msg, struct sk_buff *skb);
-int ip_cmsg_send(struct net *net, struct msghdr *msg, struct ipcm_cookie *ipc);
+int ip_cmsg_send(struct net *net, struct msghdr *msg,
+ struct ipcm_cookie *ipc, bool allow_ipv6);
int ip_setsockopt(struct sock *sk, int level, int optname, char __user *optval,
unsigned int optlen);
int ip_getsockopt(struct sock *sk, int level, int optname, char __user *optval,
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 580dd96..0968b28 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -186,7 +186,8 @@ void ip_cmsg_recv(struct msghdr *msg, struct sk_buff *skb)
}
EXPORT_SYMBOL(ip_cmsg_recv);
-int ip_cmsg_send(struct net *net, struct msghdr *msg, struct ipcm_cookie *ipc)
+int ip_cmsg_send(struct net *net, struct msghdr *msg, struct ipcm_cookie *ipc,
+ bool allow_ipv6)
{
int err, val;
struct cmsghdr *cmsg;
@@ -194,6 +195,22 @@ int ip_cmsg_send(struct net *net, struct msghdr *msg, struct ipcm_cookie *ipc)
for (cmsg = CMSG_FIRSTHDR(msg); cmsg; cmsg = CMSG_NXTHDR(msg, cmsg)) {
if (!CMSG_OK(msg, cmsg))
return -EINVAL;
+#if defined(CONFIG_IPV6)
+ if (allow_ipv6 &&
+ cmsg->cmsg_level == SOL_IPV6 &&
+ cmsg->cmsg_type == IPV6_PKTINFO) {
+ struct in6_pktinfo *src_info;
+
+ if (cmsg->cmsg_len < CMSG_LEN(sizeof(*src_info)))
+ return -EINVAL;
+ src_info = (struct in6_pktinfo *)CMSG_DATA(cmsg);
+ if (!ipv6_addr_v4mapped(&src_info->ipi6_addr))
+ return -EINVAL;
+ ipc->oif = src_info->ipi6_ifindex;
+ ipc->addr = src_info->ipi6_addr.s6_addr32[3];
+ continue;
+ }
+#endif
if (cmsg->cmsg_level != SOL_IP)
continue;
switch (cmsg->cmsg_type) {
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index 2d11c09..f4b19e5 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -727,7 +727,7 @@ static int ping_v4_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *m
sock_tx_timestamp(sk, &ipc.tx_flags);
if (msg->msg_controllen) {
- err = ip_cmsg_send(sock_net(sk), msg, &ipc);
+ err = ip_cmsg_send(sock_net(sk), msg, &ipc, false);
if (err)
return err;
if (ipc.opt)
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index c04518f..a9dbe58 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -524,7 +524,7 @@ static int raw_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
ipc.oif = sk->sk_bound_dev_if;
if (msg->msg_controllen) {
- err = ip_cmsg_send(sock_net(sk), msg, &ipc);
+ err = ip_cmsg_send(sock_net(sk), msg, &ipc, false);
if (err)
goto out;
if (ipc.opt)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 77bd16f..4468e1a 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -931,7 +931,8 @@ int udp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
sock_tx_timestamp(sk, &ipc.tx_flags);
if (msg->msg_controllen) {
- err = ip_cmsg_send(sock_net(sk), msg, &ipc);
+ err = ip_cmsg_send(sock_net(sk), msg, &ipc,
+ sk->sk_family == AF_INET6);
if (err)
return err;
if (ipc.opt)
--
1.8.5.3
^ permalink raw reply related
* Re: [PATCH net-next v5 1/9] xen-netback: Introduce TX grant map definitions
From: Zoltan Kiss @ 2014-02-18 20:36 UTC (permalink / raw)
To: Ian Campbell; +Cc: wei.liu2, xen-devel, netdev, linux-kernel, jonathan.davies
In-Reply-To: <1392743214.23084.38.camel@kazak.uk.xensource.com>
On 18/02/14 17:06, Ian Campbell wrote:
> On Mon, 2014-01-20 at 21:24 +0000, Zoltan Kiss wrote:
>> This patch contains the new definitions necessary for grant mapping.
>
> Is this just adding a bunch of (currently) unused functions? That's a
> slightly odd way to structure a series. They don't seem to be "generic
> helpers" or anything so it would be more normal to introduce these as
> they get used -- it's a bit hard to review them out of context.
I've created two patches because they are quite huge even now,
separately. Together they would be a ~500 line change. That was the best
I could figure out keeping in mind that bisect should work. But as I
wrote in the first email, I welcome other suggestions. If you and Wei
prefer this two patch in one big one, I merge them in the next version.
>> v2:
>
> This sort of intraversion changelog should go after the S-o-b and a
> "---" marker. This way they are not included in the final commit
> message.
Ok, I'll do that.
>> @@ -226,6 +248,12 @@ bool xenvif_rx_ring_slots_available(struct xenvif *vif, int needed);
>>
>> void xenvif_stop_queue(struct xenvif *vif);
>>
>> +/* Callback from stack when TX packet can be released */
>> +void xenvif_zerocopy_callback(struct ubuf_info *ubuf, bool zerocopy_success);
>> +
>> +/* Unmap a pending page, usually has to be called before xenvif_idx_release */
>
> "usually" or always? How does one determine when it is or isn't
> appropriate to call it later?
If you haven't unmapped it before, then you have to call it. I'll
clarify the comment
>> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
>> index 7669d49..f0f0c3d 100644
>> --- a/drivers/net/xen-netback/interface.c
>> +++ b/drivers/net/xen-netback/interface.c
>> @@ -38,6 +38,7 @@
>>
>> #include <xen/events.h>
>> #include <asm/xen/hypercall.h>
>> +#include <xen/balloon.h>
>
> What is this for?
For alloc/free_xenballooned_pages
>> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
>> index bb241d0..195602f 100644
>> --- a/drivers/net/xen-netback/netback.c
>> +++ b/drivers/net/xen-netback/netback.c
>> @@ -773,6 +773,20 @@ static struct page *xenvif_alloc_page(struct xenvif *vif,
>> return page;
>> }
>>
>> +static inline void xenvif_tx_create_gop(struct xenvif *vif,
>> + u16 pending_idx,
>> + struct xen_netif_tx_request *txp,
>> + struct gnttab_map_grant_ref *gop)
>> +{
>> + vif->pages_to_map[gop-vif->tx_map_ops] = vif->mmap_pages[pending_idx];
>> + gnttab_set_map_op(gop, idx_to_kaddr(vif, pending_idx),
>> + GNTMAP_host_map | GNTMAP_readonly,
>> + txp->gref, vif->domid);
>> +
>> + memcpy(&vif->pending_tx_info[pending_idx].req, txp,
>> + sizeof(*txp));
>
> Can this not go in xenvif_tx_build_gops? Or conversely should the
> non-mapping code there be factored out?
>
> Given the presence of both kinds of gop the name of this function needs
> to be more specific I think.
It is called from tx_build_gop and get_requests, and the non-mapping
code will go away. I have a patch on top of this series which does grant
copy for the header part, but it doesn't create a separate function for
the single copy operation, and you'll still call this function from
build_gops to handle the rest of the first slot (if any)
So TX will have only one kind of gop.
>
>> +}
>> +
>> static struct gnttab_copy *xenvif_get_requests(struct xenvif *vif,
>> struct sk_buff *skb,
>> struct xen_netif_tx_request *txp,
>> @@ -1612,6 +1626,107 @@ static int xenvif_tx_submit(struct xenvif *vif)
>> return work_done;
>> }
>>
>> +void xenvif_zerocopy_callback(struct ubuf_info *ubuf, bool zerocopy_success)
>> +{
>> + unsigned long flags;
>> + pending_ring_idx_t index;
>> + u16 pending_idx = ubuf->desc;
>> + struct pending_tx_info *temp =
>> + container_of(ubuf, struct pending_tx_info, callback_struct);
>> + struct xenvif *vif = container_of(temp - pending_idx,
>
> This is subtracting a u16 from a pointer?
Yes. I moved this to an ubuf_to_vif helper for the next version of the
patch series
>
>> + struct xenvif,
>> + pending_tx_info[0]);
>> +
>> + spin_lock_irqsave(&vif->dealloc_lock, flags);
>> + do {
>> + pending_idx = ubuf->desc;
>> + ubuf = (struct ubuf_info *) ubuf->ctx;
>> + index = pending_index(vif->dealloc_prod);
>> + vif->dealloc_ring[index] = pending_idx;
>> + /* Sync with xenvif_tx_dealloc_action:
>> + * insert idx then incr producer.
>> + */
>> + smp_wmb();
>
> Is this really needed given that there is a lock held?
Yes, as the comment right above explains. This actually comes from
classic kernel's netif_idx_release
>
> Or what is dealloc_lock protecting against?
The callbacks from each other. So it is checjed only in this function.
>
>> + vif->dealloc_prod++;
>
> What happens if the dealloc ring becomes full, will this wrap and cause
> havoc?
Nope, if the dealloc ring is full, the value of the last increment won't
be used to index the dealloc ring again until some space made available.
Of course if something broke and we have more pending slots than tx ring
or dealloc slots then it can happen. Do you suggest a
BUG_ON(vif->dealloc_prod - vif->dealloc_cons >= MAX_PENDING_REQS)?
>
>> + } while (ubuf);
>> + wake_up(&vif->dealloc_wq);
>> + spin_unlock_irqrestore(&vif->dealloc_lock, flags);
>> +}
>> +
>> +static inline void xenvif_tx_dealloc_action(struct xenvif *vif)
>> +{
>> + struct gnttab_unmap_grant_ref *gop;
>> + pending_ring_idx_t dc, dp;
>> + u16 pending_idx, pending_idx_release[MAX_PENDING_REQS];
>> + unsigned int i = 0;
>> +
>> + dc = vif->dealloc_cons;
>> + gop = vif->tx_unmap_ops;
>> +
>> + /* Free up any grants we have finished using */
>> + do {
>> + dp = vif->dealloc_prod;
>> +
>> + /* Ensure we see all indices enqueued by all
>> + * xenvif_zerocopy_callback().
>> + */
>> + smp_rmb();
>> +
>> + while (dc != dp) {
>> + pending_idx =
>> + vif->dealloc_ring[pending_index(dc++)];
>> +
>> + /* Already unmapped? */
>> + if (vif->grant_tx_handle[pending_idx] ==
>> + NETBACK_INVALID_HANDLE) {
>> + netdev_err(vif->dev,
>> + "Trying to unmap invalid handle! "
>> + "pending_idx: %x\n", pending_idx);
>> + BUG();
>> + }
>> +
>> + pending_idx_release[gop-vif->tx_unmap_ops] =
>> + pending_idx;
>> + vif->pages_to_unmap[gop-vif->tx_unmap_ops] =
>> + vif->mmap_pages[pending_idx];
>> + gnttab_set_unmap_op(gop,
>> + idx_to_kaddr(vif, pending_idx),
>> + GNTMAP_host_map,
>> + vif->grant_tx_handle[pending_idx]);
>> + vif->grant_tx_handle[pending_idx] =
>> + NETBACK_INVALID_HANDLE;
>> + ++gop;
>
> Can we run out of space in the gop array?
No, unless the same thing happen as at my previous answer. BUG_ON() here
as well?
>
>> + }
>> +
>> + } while (dp != vif->dealloc_prod);
>> +
>> + vif->dealloc_cons = dc;
>
> No barrier here?
dealloc_cons only used in the dealloc_thread. dealloc_prod is used by
the callback and the thread as well, that's why we need mb() in
previous. Btw. this function comes from classic's net_tx_action_dealloc
>
>> + if (gop - vif->tx_unmap_ops > 0) {
>> + int ret;
>> + ret = gnttab_unmap_refs(vif->tx_unmap_ops,
>> + vif->pages_to_unmap,
>> + gop - vif->tx_unmap_ops);
>> + if (ret) {
>> + netdev_err(vif->dev, "Unmap fail: nr_ops %x ret %d\n",
>> + gop - vif->tx_unmap_ops, ret);
>> + for (i = 0; i < gop - vif->tx_unmap_ops; ++i) {
>
> This seems liable to be a lot of spew on failure. Perhaps only log the
> ones where gop[i].status != success.
Ok, I'll change that.
>
> Have you considered whether or not the frontend can force this error to
> occur?
Not yet, good point. I guess if we successfully mapped the page, then
there is no way a frontend to prevent unmapping. But worth further checking.
>
>> + netdev_err(vif->dev,
>> + " host_addr: %llx handle: %x status: %d\n",
>> + gop[i].host_addr,
>> + gop[i].handle,
>> + gop[i].status);
>> + }
>> + BUG();
>> + }
>> + }
>> +
>> + for (i = 0; i < gop - vif->tx_unmap_ops; ++i)
>> + xenvif_idx_release(vif, pending_idx_release[i],
>> + XEN_NETIF_RSP_OKAY);
>> +}
>> +
>> +
>> /* Called after netfront has transmitted */
>> int xenvif_tx_action(struct xenvif *vif, int budget)
>> {
>> @@ -1678,6 +1793,25 @@ static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx,
>> vif->mmap_pages[pending_idx] = NULL;
>> }
>>
>> +void xenvif_idx_unmap(struct xenvif *vif, u16 pending_idx)
>
> This is a single shot version of the batched xenvif_tx_dealloc_action
> version? Why not just enqueue the idx to be unmapped later?
This is called only from the NAPI instance. Using the dealloc ring
require synchronization with the callback which can increase lock
contention. On the other hand, if the guest sends small packets
(<PAGE_SIZE), the TLB flushing can cause performance penalty. The above
mentioned upcoming patch which gntcopy the header can prevent that
(together with Malcolm's Xen side patch, which prevents TLB flush if the
page were not touched in Dom0)
>> @@ -1826,6 +1965,28 @@ int xenvif_kthread(void *data)
>> return 0;
>> }
>>
>> +int xenvif_dealloc_kthread(void *data)
>
> Is this going to be a thread per vif?
Yes. In the first versions I've put the dealloc in the NAPI instance
(similarly as in classic, where it happened in tx_action), but that had
an unexpected performance penalty: the callback has to notify whoever
does the dealloc, that there is something to do. If it is the NAPI
instance, it has to call napi_schedule. But if the packet were delivered
to an another guest, the callback is called from thread context, and
according to Eric Dumazet, napi_schedule from thread context can
significantly delay softirq handling. So NAPI instance were delayed with
miliseconds, and it caused terrible performance.
Moving this to the RX thread haven't seemed like a wise decision, so I
made a new thread.
Actually in the next version of the patches I'll reintroduce
__napi_schedule in the callback again, because if the NAPI instance
still have unconsumed requests but not enough pending slots, it
deschedule itself, and the callback has to schedule it again, if:
- unconsumed requests in the ring < XEN_NETBK_LEGACY_SLOTS_MAX
- there are enough free pending slots to handle them
- and the NAPI instance is not scheduled yet
This should really happen if netback is faster than target devices, but
then it doesn't mean a bottleneck.
Zoli
^ permalink raw reply
* Re: [PATCH net-next 00/35] net: Use pci_enable_msix_range() instead of pci_enable_msix()
From: David Miller @ 2014-02-18 20:34 UTC (permalink / raw)
To: agordeev
Cc: linux-kernel, e1000-devel, linux-driver, linux-net-drivers,
linux-pci, linux-rdma, netdev, pv-drivers, wil6210
In-Reply-To: <cover.1392717502.git.agordeev@redhat.com>
From: Alexander Gordeev <agordeev@redhat.com>
Date: Tue, 18 Feb 2014 11:07:52 +0100
> As result of deprecation of MSI-X/MSI enablement functions
> pci_enable_msix() and pci_enable_msi_block() all drivers
> using these two interfaces need to be updated to use the
> new pci_enable_msi_range() and pci_enable_msix_range()
> interfaces.
>
> Cc: e1000-devel@lists.sourceforge.net
> Cc: linux-driver@qlogic.com
> Cc: linux-net-drivers@solarflare.com
> Cc: linux-pci@vger.kernel.org
> Cc: linux-rdma@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Cc: pv-drivers@vmware.com
> Cc: wil6210@qca.qualcomm.com
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] of_mdio: fix phy interrupt passing
From: Sergei Shtylyov @ 2014-02-18 20:29 UTC (permalink / raw)
To: Ben Dooks, grant.likely
Cc: linux-kernel, devicetree, linux-kernel, netdev, linux-sh
In-Reply-To: <1392725818-558-1-git-send-email-ben.dooks@codethink.co.uk>
Hello.
On 02/18/2014 03:16 PM, Ben Dooks wrote:
> The of_mdiobus_register_phy() is not setting phy->irq thus causing
> some drivers to incorrectly assume that the PHY does not have an
> IRQ associated with it. Not only do some drivers report no IRQ
> they do not install an interrupt handler for the PHY.
> Simplify the code setting irq and set the phy->irq at the same
> time so that we cover the following issues, which should cover
> all the cases the code will find:
> - Set phy->irq if node has irq property and mdio->irq is NULL
> - Set phy->irq if node has no irq and mdio->irq is not NULL
> - Leave phy->irq as PHY_POLL default if none of the above
> This fixes the issue:
> net eth0: attached PHY 1 (IRQ -1) to driver Micrel KSZ8041RNLI
> to the correct:
> net eth0: attached PHY 1 (IRQ 416) to driver Micrel KSZ8041RNLI
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
[...]
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index 875b7b6..46d95fc 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
[...]
> @@ -54,12 +54,14 @@ static int of_mdiobus_register_phy(struct mii_bus *mdio, struct device_node *chi
> if (!phy || IS_ERR(phy))
> return 1;
>
> - if (mdio->irq) {
> - prev_irq = mdio->irq[addr];
> - mdio->irq[addr] =
> - irq_of_parse_and_map(child, 0);
> - if (!mdio->irq[addr])
> - mdio->irq[addr] = prev_irq;
> + rc = irq_of_parse_and_map(child, 0);
> + if (rc > 0) {
> + phy->irq = rc;
> + if (mdio->irq)
> + mdio->irq[addr] = rc;
> + } else {
> + if (mdio->irq)
> + phy->irq = mdio->irq[addr];
I have now looked thru the of_mdio.c code and the code it calls.
This case seems to be cared about by phy_device_create() called earlier
via get_phy_device() call just above this hunk; in any case the value will be
PHY_POLL. I don't think this branch is needed at all.
WBR, Sergei
^ permalink raw reply
* [PATCH net-next] hyperv: Add latest NetVSP versions to auto negotiation
From: Haiyang Zhang @ 2014-02-18 20:28 UTC (permalink / raw)
To: davem, netdev; +Cc: olaf, jasowang, driverdev-devel, linux-kernel, haiyangz
It auto negotiates the highest NetVSP version supported by both guest and host.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
---
drivers/net/hyperv/hyperv_net.h | 53 +++++++++++++++++++++++++++++++++++++++
drivers/net/hyperv/netvsc.c | 26 ++++++++++++------
drivers/net/hyperv/netvsc_drv.c | 2 +-
3 files changed, 71 insertions(+), 10 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 01a16ea..39fc230 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -139,6 +139,8 @@ int rndis_filter_set_device_mac(struct hv_device *hdev, char *mac);
#define NVSP_PROTOCOL_VERSION_1 2
#define NVSP_PROTOCOL_VERSION_2 0x30002
+#define NVSP_PROTOCOL_VERSION_4 0x40000
+#define NVSP_PROTOCOL_VERSION_5 0x50000
enum {
NVSP_MSG_TYPE_NONE = 0,
@@ -193,6 +195,23 @@ enum {
NVSP_MSG2_TYPE_ALLOC_CHIMNEY_HANDLE,
NVSP_MSG2_TYPE_ALLOC_CHIMNEY_HANDLE_COMP,
+
+ NVSP_MSG2_MAX = NVSP_MSG2_TYPE_ALLOC_CHIMNEY_HANDLE_COMP,
+
+ /* Version 4 messages */
+ NVSP_MSG4_TYPE_SEND_VF_ASSOCIATION,
+ NVSP_MSG4_TYPE_SWITCH_DATA_PATH,
+ NVSP_MSG4_TYPE_UPLINK_CONNECT_STATE_DEPRECATED,
+
+ NVSP_MSG4_MAX = NVSP_MSG4_TYPE_UPLINK_CONNECT_STATE_DEPRECATED,
+
+ /* Version 5 messages */
+ NVSP_MSG5_TYPE_OID_QUERY_EX,
+ NVSP_MSG5_TYPE_OID_QUERY_EX_COMP,
+ NVSP_MSG5_TYPE_SUBCHANNEL,
+ NVSP_MSG5_TYPE_SEND_INDIRECTION_TABLE,
+
+ NVSP_MSG5_MAX = NVSP_MSG5_TYPE_SEND_INDIRECTION_TABLE,
};
enum {
@@ -447,10 +466,44 @@ union nvsp_2_message_uber {
struct nvsp_2_free_rxbuf free_rxbuf;
} __packed;
+enum nvsp_subchannel_operation {
+ NVSP_SUBCHANNEL_NONE = 0,
+ NVSP_SUBCHANNEL_ALLOCATE,
+ NVSP_SUBCHANNEL_MAX
+};
+
+struct nvsp_5_subchannel_request {
+ u32 op;
+ u32 num_subchannels;
+} __packed;
+
+struct nvsp_5_subchannel_complete {
+ u32 status;
+ u32 num_subchannels; /* Actual number of subchannels allocated */
+} __packed;
+
+struct nvsp_5_send_indirect_table {
+ /* The number of entries in the send indirection table */
+ u32 count;
+
+ /* The offset of the send indireciton table from top of this struct.
+ * The send indirection table tells which channel to put the send
+ * traffic on. Each entry is a channel number.
+ */
+ u32 offset;
+} __packed;
+
+union nvsp_5_message_uber {
+ struct nvsp_5_subchannel_request subchn_req;
+ struct nvsp_5_subchannel_complete subchn_comp;
+ struct nvsp_5_send_indirect_table send_table;
+} __packed;
+
union nvsp_all_messages {
union nvsp_message_init_uber init_msg;
union nvsp_1_message_uber v1_msg;
union nvsp_2_message_uber v2_msg;
+ union nvsp_5_message_uber v5_msg;
} __packed;
/* ALL Messages */
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 9a0e9c6..fc2941c 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -290,7 +290,7 @@ static int negotiate_nvsp_ver(struct hv_device *device,
NVSP_STAT_SUCCESS)
return -EINVAL;
- if (nvsp_ver != NVSP_PROTOCOL_VERSION_2)
+ if (nvsp_ver == NVSP_PROTOCOL_VERSION_1)
return 0;
/* NVSPv2 only: Send NDIS config */
@@ -314,6 +314,10 @@ static int netvsc_connect_vsp(struct hv_device *device)
struct nvsp_message *init_packet;
int ndis_version;
struct net_device *ndev;
+ u32 ver_list[] = {NVSP_PROTOCOL_VERSION_1, NVSP_PROTOCOL_VERSION_2,
+ NVSP_PROTOCOL_VERSION_4, NVSP_PROTOCOL_VERSION_5};
+ int i, num_ver = 4; /* number of different NVSP versions */
+
net_device = get_outbound_net_device(device);
if (!net_device)
@@ -323,13 +327,14 @@ static int netvsc_connect_vsp(struct hv_device *device)
init_packet = &net_device->channel_init_pkt;
/* Negotiate the latest NVSP protocol supported */
- if (negotiate_nvsp_ver(device, net_device, init_packet,
- NVSP_PROTOCOL_VERSION_2) == 0) {
- net_device->nvsp_version = NVSP_PROTOCOL_VERSION_2;
- } else if (negotiate_nvsp_ver(device, net_device, init_packet,
- NVSP_PROTOCOL_VERSION_1) == 0) {
- net_device->nvsp_version = NVSP_PROTOCOL_VERSION_1;
- } else {
+ for (i = num_ver - 1; i >= 0; i--)
+ if (negotiate_nvsp_ver(device, net_device, init_packet,
+ ver_list[i]) == 0) {
+ net_device->nvsp_version = ver_list[i];
+ break;
+ }
+
+ if (i < 0) {
ret = -EPROTO;
goto cleanup;
}
@@ -339,7 +344,10 @@ static int netvsc_connect_vsp(struct hv_device *device)
/* Send the ndis version */
memset(init_packet, 0, sizeof(struct nvsp_message));
- ndis_version = 0x00050001;
+ if (net_device->nvsp_version <= NVSP_PROTOCOL_VERSION_4)
+ ndis_version = 0x00050001;
+ else
+ ndis_version = 0x0006001e;
init_packet->hdr.msg_type = NVSP_MSG1_TYPE_SEND_NDIS_VER;
init_packet->msg.v1_msg.
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 1eadc13..3cc9eb3 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -317,7 +317,7 @@ static int netvsc_change_mtu(struct net_device *ndev, int mtu)
if (nvdev == NULL || nvdev->destroy)
return -ENODEV;
- if (nvdev->nvsp_version == NVSP_PROTOCOL_VERSION_2)
+ if (nvdev->nvsp_version >= NVSP_PROTOCOL_VERSION_2)
limit = NETVSC_MTU;
if (mtu < 68 || mtu > limit)
--
1.7.4.1
^ permalink raw reply related
* Re: [Xen-devel] [RFC v2 4/4] xen-netback: skip IPv4 and IPv6 interfaces
From: Luis R. Rodriguez @ 2014-02-18 20:16 UTC (permalink / raw)
To: Zoltan Kiss
Cc: netdev@vger.kernel.org, Wei Liu, Ian Campbell, kvm,
linux-kernel@vger.kernel.org, Paul Durrant, xen-devel
In-Reply-To: <53021E87.6020607@citrix.com>
On Mon, Feb 17, 2014 at 6:36 AM, Zoltan Kiss <zoltan.kiss@citrix.com> wrote:
> There is a valid scenario to put IP addresses on the backend VIFs:
>
> http://wiki.xen.org/wiki/Xen_Networking#Routing
This is useful thanks!
> Also, the backend is not necessarily Dom0, you can connect two guests with
> backend/frontend pairs.
Can you elaborate a bit more on this type of setup?
Luis
^ permalink raw reply
* Re: [PATCH net-next v2 0/6] gianfar: Device configuration fixes
From: David Miller @ 2014-02-18 20:03 UTC (permalink / raw)
To: claudiu.manoil; +Cc: netdev
In-Reply-To: <1392634399-5456-1-git-send-email-claudiu.manoil@freescale.com>
From: Claudiu Manoil <claudiu.manoil@freescale.com>
Date: Mon, 17 Feb 2014 12:53:13 +0200
> This patchset represents the first part of an effort
> to solve some old device configuration issues in gianfar,
> especially run-time reset and re-configuration problems.
> I'm referring to "on-the-fly" configuration of registers
> against HW specification, concurrency issues during device
> reset / re-configuration operations, and implementing HW
> advisories for these operations.
>
> There's also a good deal of code cleanup and refactoring,
> and some other (minor) fixes as well.
>
> Thank you.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH RFC net-next 0/6] 6lowpan: reimplementation of fragmentation handling
From: Alexander Aring @ 2014-02-18 19:58 UTC (permalink / raw)
To: alex.bluesman.smirnov
Cc: dbaryshkov, davem, linux-zigbee-devel, netdev, martin.townsend
In-Reply-To: <1392539668-2349-1-git-send-email-alex.aring@gmail.com>
Hi,
any suggestions to this patch stack?
I got a:
Tested-by: Martin Townsend <martin.townsend@xsilon.com>
while this time. He is happy that all things works fine now. :-)
Of course I tested it myself with a linux<->linux and linux<->contiki
connection.
If all seems fine. Is there a chance to bring this patch stack mainline?
- Alex
^ permalink raw reply
* [patch net-next] rtnl: make ifla_policy static
From: Jiri Pirko @ 2014-02-18 19:53 UTC (permalink / raw)
To: netdev; +Cc: davem, kaber, xiyou.wangcong, stephen, vyasevic, jbenc
The only place this is used outside rtnetlink.c is veth. So provide
wrapper function for this usage.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
drivers/net/veth.c | 8 ++--
include/net/rtnetlink.h | 2 +-
net/core/rtnetlink.c | 107 +++++++++++++++++++++++++-----------------------
3 files changed, 61 insertions(+), 56 deletions(-)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 91c33c1..34b5263 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -14,6 +14,7 @@
#include <linux/etherdevice.h>
#include <linux/u64_stats_sync.h>
+#include <net/rtnetlink.h>
#include <net/dst.h>
#include <net/xfrm.h>
#include <linux/veth.h>
@@ -323,10 +324,9 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
nla_peer = data[VETH_INFO_PEER];
ifmp = nla_data(nla_peer);
- err = nla_parse(peer_tb, IFLA_MAX,
- nla_data(nla_peer) + sizeof(struct ifinfomsg),
- nla_len(nla_peer) - sizeof(struct ifinfomsg),
- ifla_policy);
+ err = rtnl_nla_parse_ifla(peer_tb,
+ nla_data(nla_peer) + sizeof(struct ifinfomsg),
+ nla_len(nla_peer) - sizeof(struct ifinfomsg));
if (err < 0)
return err;
diff --git a/include/net/rtnetlink.h b/include/net/rtnetlink.h
index 661e45d..72240e5 100644
--- a/include/net/rtnetlink.h
+++ b/include/net/rtnetlink.h
@@ -140,7 +140,7 @@ struct net_device *rtnl_create_link(struct net *net, char *ifname,
struct nlattr *tb[]);
int rtnl_configure_link(struct net_device *dev, const struct ifinfomsg *ifm);
-extern const struct nla_policy ifla_policy[IFLA_MAX+1];
+int rtnl_nla_parse_ifla(struct nlattr **tb, const struct nlattr *head, int len);
#define MODULE_ALIAS_RTNL_LINK(kind) MODULE_ALIAS("rtnl-link-" kind)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 048dc8d..7b2ad56 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1121,56 +1121,7 @@ nla_put_failure:
return -EMSGSIZE;
}
-static int rtnl_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb)
-{
- struct net *net = sock_net(skb->sk);
- int h, s_h;
- int idx = 0, s_idx;
- struct net_device *dev;
- struct hlist_head *head;
- struct nlattr *tb[IFLA_MAX+1];
- u32 ext_filter_mask = 0;
-
- s_h = cb->args[0];
- s_idx = cb->args[1];
-
- rcu_read_lock();
- cb->seq = net->dev_base_seq;
-
- if (nlmsg_parse(cb->nlh, sizeof(struct ifinfomsg), tb, IFLA_MAX,
- ifla_policy) >= 0) {
-
- if (tb[IFLA_EXT_MASK])
- ext_filter_mask = nla_get_u32(tb[IFLA_EXT_MASK]);
- }
-
- for (h = s_h; h < NETDEV_HASHENTRIES; h++, s_idx = 0) {
- idx = 0;
- head = &net->dev_index_head[h];
- hlist_for_each_entry_rcu(dev, head, index_hlist) {
- if (idx < s_idx)
- goto cont;
- if (rtnl_fill_ifinfo(skb, dev, RTM_NEWLINK,
- NETLINK_CB(cb->skb).portid,
- cb->nlh->nlmsg_seq, 0,
- NLM_F_MULTI,
- ext_filter_mask) <= 0)
- goto out;
-
- nl_dump_check_consistent(cb, nlmsg_hdr(skb));
-cont:
- idx++;
- }
- }
-out:
- rcu_read_unlock();
- cb->args[1] = idx;
- cb->args[0] = h;
-
- return skb->len;
-}
-
-const struct nla_policy ifla_policy[IFLA_MAX+1] = {
+static const struct nla_policy ifla_policy[IFLA_MAX+1] = {
[IFLA_IFNAME] = { .type = NLA_STRING, .len = IFNAMSIZ-1 },
[IFLA_ADDRESS] = { .type = NLA_BINARY, .len = MAX_ADDR_LEN },
[IFLA_BROADCAST] = { .type = NLA_BINARY, .len = MAX_ADDR_LEN },
@@ -1197,7 +1148,6 @@ const struct nla_policy ifla_policy[IFLA_MAX+1] = {
[IFLA_NUM_RX_QUEUES] = { .type = NLA_U32 },
[IFLA_PHYS_PORT_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_PORT_ID_LEN },
};
-EXPORT_SYMBOL(ifla_policy);
static const struct nla_policy ifla_info_policy[IFLA_INFO_MAX+1] = {
[IFLA_INFO_KIND] = { .type = NLA_STRING },
@@ -1235,6 +1185,61 @@ static const struct nla_policy ifla_port_policy[IFLA_PORT_MAX+1] = {
[IFLA_PORT_RESPONSE] = { .type = NLA_U16, },
};
+static int rtnl_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb)
+{
+ struct net *net = sock_net(skb->sk);
+ int h, s_h;
+ int idx = 0, s_idx;
+ struct net_device *dev;
+ struct hlist_head *head;
+ struct nlattr *tb[IFLA_MAX+1];
+ u32 ext_filter_mask = 0;
+
+ s_h = cb->args[0];
+ s_idx = cb->args[1];
+
+ rcu_read_lock();
+ cb->seq = net->dev_base_seq;
+
+ if (nlmsg_parse(cb->nlh, sizeof(struct ifinfomsg), tb, IFLA_MAX,
+ ifla_policy) >= 0) {
+
+ if (tb[IFLA_EXT_MASK])
+ ext_filter_mask = nla_get_u32(tb[IFLA_EXT_MASK]);
+ }
+
+ for (h = s_h; h < NETDEV_HASHENTRIES; h++, s_idx = 0) {
+ idx = 0;
+ head = &net->dev_index_head[h];
+ hlist_for_each_entry_rcu(dev, head, index_hlist) {
+ if (idx < s_idx)
+ goto cont;
+ if (rtnl_fill_ifinfo(skb, dev, RTM_NEWLINK,
+ NETLINK_CB(cb->skb).portid,
+ cb->nlh->nlmsg_seq, 0,
+ NLM_F_MULTI,
+ ext_filter_mask) <= 0)
+ goto out;
+
+ nl_dump_check_consistent(cb, nlmsg_hdr(skb));
+cont:
+ idx++;
+ }
+ }
+out:
+ rcu_read_unlock();
+ cb->args[1] = idx;
+ cb->args[0] = h;
+
+ return skb->len;
+}
+
+int rtnl_nla_parse_ifla(struct nlattr **tb, const struct nlattr *head, int len)
+{
+ return nla_parse(tb, IFLA_MAX, head, len, ifla_policy);
+}
+EXPORT_SYMBOL(rtnl_nla_parse_ifla);
+
struct net *rtnl_link_get_net(struct net *src_net, struct nlattr *tb[])
{
struct net *net;
--
1.8.5.3
^ permalink raw reply related
* Re: [Xen-devel] [RFC v2 0/4] net: bridge / ip optimizations for virtual net backends
From: Luis R. Rodriguez @ 2014-02-18 19:43 UTC (permalink / raw)
To: David Vrabel
Cc: netdev@vger.kernel.org, xen-devel, linux-kernel@vger.kernel.org,
kvm
In-Reply-To: <5301E411.5060908@citrix.com>
On Mon, Feb 17, 2014 at 2:27 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> On 15/02/14 02:59, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>
>> This v2 series changes the approach from my original virtualization
>> multicast patch series [0] by abandoning completely the multicast
>> issues and instead generalizing an approach for virtualization
>> backends. There are two things in common with virtualization
>> backends:
>>
>> 0) they should not become the root bridge
>> 1) they don't need ipv4 / ipv6 interfaces
>
> Why? There's no real difference between a backend network device and a
> physical device (from the point of view of the backend domain). I do
> not think these are intrinsic properties of backend devices.
Let me clarify the original motivation as that can likely help explain
how I ended up with this patch series.
SUSE has had reports of xen backend interfaces ending up with
duplicate address notification filling up logs on systems with a
series of guests, these reports go back to 2006. This was root caused
to DAD on IPv6 interfaces, and a work around implemented to disable
DAD [0] on multicast links. Even though this patch as a work around
should not be applicable anymore given that since the xen-netback
upstreaming since 2.6.39 ether_setup is used and that enables the
multicast flag, we should try ensure the issue doesn't creep up
anymore. As per the IPv6 RFCs and Linux IPv6 implementation -- DAD
should be triggered even in the case of manual IP configuration and
when the link goes up, as such SLAAC will always take place on IPv6
interfaces. Although not documented upon my review I determined the
original issue could also be attributed to the corner case documented
on Appendix A of RFC 4862 [1] and this could be more prevalent for
xen-netback given we stuck to the same MAC address for all xen-netback
interfaces. I first tried to generalize the work around and address
the multicast case requirement for IPv6 [2], and explicitly disabling
multicast on xen-netback. Although this approach could likely be
generalized further by taking into account for NBMA links by checking
dev->type I determined we didn't need IPv6 interfaces at all on the
xent-netback interfaces. This lead me to further review if we even
needed IPv4 interfaces as well, and it turns out we do not.
New motivation: removing IPv4 and IPv6 from the backend interfaces can
save up a lot of boiler plate run time code, triggers from ever taking
place, and simplifying the backend interaces. If there is no use for
IPv4 and IPv6 interfaces why do we have them? Note: I have yet to test
the NAT case.
> I can see these being useful knobs for administrators (or management
> toolstacks) to turn on, on a per-device basis.
Agreed but these knobs don't even exist for drivers yet, let alone for
system administrators. I certainly can shoot for another series to let
administrators configure this as a preference but -- if we know a
driver won't need IPv4 and IPv6 interfaces why not just allow drivers
to disable them all together? Consider the simplification of the
interfaces on the host.
[0] https://gitorious.org/opensuse/kernel-source/source/8e16582178a29b03e850468004a47e7be5ed3005:patches.xen/ipv6-no-autoconf
[1] http://tools.ietf.org/html/rfc4862
[2] http://marc.info/?l=linux-netdev&m=139207142110536&w=2
Luis
^ permalink raw reply
* Re: [PATCH net-next 30/35] qlge: Use pci_enable_msix_range() instead of pci_enable_msix()
From: Jitendra Kalsaria @ 2014-02-18 19:20 UTC (permalink / raw)
To: Alexander Gordeev, linux-kernel
Cc: Shahed Shaikh, Ron Mercer, Dept-Eng Linux Driver, netdev,
linux-pci
In-Reply-To: <443a0172bc2fe0aa92fca6044d7374475e2ad4c1.1392717503.git.agordeev@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 812 bytes --]
On 2/18/14 2:11 AM, "Alexander Gordeev" <agordeev@redhat.com> wrote:
>As result of deprecation of MSI-X/MSI enablement functions
>pci_enable_msix() and pci_enable_msi_block() all drivers
>using these two interfaces need to be updated to use the
>new pci_enable_msi_range() and pci_enable_msix_range()
>interfaces.
>
>Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
>Cc: Shahed Shaikh <shahed.shaikh@qlogic.com>
>Cc: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
>Cc: Ron Mercer <ron.mercer@qlogic.com>
>Cc: linux-driver@qlogic.com
>Cc: netdev@vger.kernel.org
>Cc: linux-pci@vger.kernel.org
>---
> drivers/net/ethernet/qlogic/qlge/qlge_main.c | 15 ++++-----------
> 1 files changed, 4 insertions(+), 11 deletions(-)
Acked-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 4634 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox