* Re: [PATCH net 0/2] netns: audit netdevice creation with IFLA_NET_NS_[PID|FD]
From: Alexander Aring @ 2015-01-27 12:23 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev, davem, arvid.brodin, linux-wpan
In-Reply-To: <54C7694C.2060709@6wind.com>
Hi,
(removing the bounced mail address).
On Tue, Jan 27, 2015 at 11:32:44AM +0100, Nicolas Dichtel wrote:
> Le 27/01/2015 10:34, Alexander Aring a écrit :
> >Hi,
> >
> >On Mon, Jan 26, 2015 at 10:28:12PM +0100, Nicolas Dichtel wrote:
> >>
> [snip]
> >>- ieee802154 uses also src_net and does not have NETIF_F_NETNS_LOCAL. Same
> >> question: does this netdevice really supports x-netns?
> >
> >I am not sure if I understand exactly what you mean. First of all, I
> >didn't test anything about net namespaces for the ieee802154 branch.
> >In 802.15.4 branch we have two interfaces: wpan and 6LoWPAN.
> >
> >After running "grep -r "src_net" net" I found this is used in:
> >
> >net/ieee802154/6lowpan/core.c [0]
> Yes, I was talking about this.
>
ok.
> >
> >This file handles the IEEE 802.15.4 6LoWPAN interface to offering a
> >IPv6 interface with an IEEE 802.15.4 6LoWPAN adaption layer.
> >
> >To the codeline "dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));".
> >By calling "ip link add link wpan0 name lowpan0 type lowpan" the
> >lowpan_newlink function will be called and we need to find the wpan interface
> >(returned as real_dev in this case).
> >
> >Namespace setting in wpan interface:
> >
> >Currently we don't use any net namespace settings there, also we don't
> >change the net namespace. The default net namespace for a wpan shoule be
> >"init_net".
> Ok. After grepping for init_net, it seems to be used a lot in net/ieee802154/.
>
Yes, but the code in net/ieee802154 (except net/ieee802154/6lowpan) is only for
the WPAN interface. Currently the WPAN interface is created in mac802154
implementation only [0].
> >
> >So this line could be also written as (I found also some others code which search
> >the wpan interface in &init_net):
> >
> >diff --git a/net/ieee802154/6lowpan/core.c b/net/ieee802154/6lowpan/core.c
> >index 9dbe0d69..495c6ad 100644
> >--- a/net/ieee802154/6lowpan/core.c
> >+++ b/net/ieee802154/6lowpan/core.c
> >@@ -151,7 +151,7 @@ static int lowpan_newlink(struct net *src_net, struct net_device *dev,
> > if (!tb[IFLA_LINK])
> > return -EINVAL;
> > /* find and hold real wpan device */
> >- real_dev = dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
> >+ real_dev = dev_get_by_index(&init_net, nla_get_u32(tb[IFLA_LINK]));
> > if (!real_dev)
> > return -ENODEV;
> > if (real_dev->type != ARPHRD_IEEE802154) {
> >
> >
> >
> >The above code is for finding the wpan interface (the real 802.15.4 L2 interface).
> >For the IEEE 802.15.4 6LoWPAN interface the whole IPv6 implementation is
> >used. This interface will be created inside function "newlink".
> >
> >Running "grep -r "src_net" net/ipv6" reports me alot uses of "src_net".
> >Don't know if this information is really necessary.
> >
> >Should I set now the NETIF_F_NETNS_LOCAL for both interface types?
> I think yes. If it's not set, a user may do:
> $ ip link add link wpan0 name lowpan0 type lowpan
> $ ip netns add foo
> $ ip link set lowpan0 netns foo
>
We should forbid that for the wpan interface. The code line:
real_dev = dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
searches for the "wpan0" interface which is given by:
$ ip link add link wpan0 name lowpan0 type lowpan
The returned real_dev netdevice pointer is the wpan interface. The given
"lowpan0" interface is a virtual interface for making IPv6 stuff.
For 6LoWPAN:
This interface is created in 6lowpan/core.c file and is used in the
whole IPv6 stack, because we set the skb->protocol to htons(ETH_P_IPV6). [1]
The IPv6 stack uses alot of "src_net".
> The flag forbids the last command.
>
> Instead of your patch, what about this one:
>
> From d9a9cd22d5e1db1417b3ffb53cc020481dc761b2 Mon Sep 17 00:00:00 2001
> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Date: Tue, 27 Jan 2015 11:26:20 +0100
> Subject: [PATCH] ieee802154: forbid to create an iface in a netns != init_net
>
> 6LoWPAN currently doesn't supports netns.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
> net/ieee802154/6lowpan/core.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/net/ieee802154/6lowpan/core.c b/net/ieee802154/6lowpan/core.c
> index 055fbb71ba6f..fe8fd022042e 100644
> --- a/net/ieee802154/6lowpan/core.c
> +++ b/net/ieee802154/6lowpan/core.c
> @@ -126,6 +126,7 @@ static void lowpan_setup(struct net_device *dev)
> dev->header_ops = &lowpan_header_ops;
> dev->ml_priv = &lowpan_mlme;
> dev->destructor = free_netdev;
> + dev->features |= NETIF_F_NETNS_LOCAL;
> }
>
> static int lowpan_validate(struct nlattr *tb[], struct nlattr *data[])
> @@ -148,7 +149,9 @@ static int lowpan_newlink(struct net *src_net, struct
> net_device *dev,
>
> pr_debug("adding new link\n");
>
> - if (!tb[IFLA_LINK])
> + if (!tb[IFLA_LINK] ||
> + !net_eq(src_net, &init_net) ||
> + !net_eq(dev_net(dev), &init_net))
> return -EINVAL;
> /* find and hold real wpan device */
> real_dev = dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
With the check of "!net_eq(src_net, &init_net)" we need to be sure
that the wpan interface is always in "init_net". This means we need
definitely a dev->features |= NETIF_F_NETNS_LOCAL; somewhere in [0].
To adding "dev->features |= NETIF_F_NETNS_LOCAL;" for a 6LoWPAN interface,
I am not sure about this. I didn't test it yet and it will not break
anything, but we will lost the support for making net namespaces stuff
inside the IPv6/(netfilter) stack.
Summarize:
I would add the dev->features |= NETIF_F_NETNS_LOCAL; while wpan
interface generation and add only the !net_eq(src_net, &init_net) check
above. I suppose that src_net is the net namespace from "underlaying"
interface wpan by calling:
$ ip link add link wpan0 name lowpan0 type lowpan
- Alex
[0] http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/net/mac802154/iface.c#n532
[1] http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/net/ieee802154/6lowpan/rx.c#n25
^ permalink raw reply
* Re: [PATCH net-next v1 05/18] net: tx4939: use __ethtool_get_ksettings
From: Sergei Shtylyov @ 2015-01-27 12:32 UTC (permalink / raw)
To: David Decotigny, David S. Miller, Ben Hutchings, Amir Vadai,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-api-u79uwXL29TY76Z2rM5mHXA
Cc: Eric Dumazet, Eugenia Emantayev, Or Gerlitz, Ido Shamay,
Joe Perches, Saeed Mahameed, Govindarajulu Varadarajan,
Venkata Duvvuru, Jeff Kirsher, Eyal Perry, Pravin B Shelar,
Ed Swierk, David Decotigny
In-Reply-To: <1422322574-6188-6-git-send-email-ddecotig-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hello.
On 1/27/2015 4:36 AM, David Decotigny wrote:
> From: David Decotigny <decot-Ypc/8FJVVoBWk0Htik3J/w@public.gmane.org>
> Signed-off-by: David Decotigny <decot-Ypc/8FJVVoBWk0Htik3J/w@public.gmane.org>
> ---
> arch/mips/txx9/generic/setup_tx4939.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
I don't think "net: " prefix applies here.
And you should have CC'ed linux-mips-6z/3iImG2C/i7sgoIIk9UQ@public.gmane.org
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net 1/2] caif: remove wrong dev_net_set() call
From: Bjørn Mork @ 2015-01-27 12:41 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: netdev, davem, dmitry.tarnyagin, arvid.brodin, alex.aring,
linux-wpan, Sjur Brændeland, Dmitry Tarnyagin
In-Reply-To: <54C777D0.6090608@6wind.com>
Nicolas Dichtel <nicolas.dichtel@6wind.com> writes:
>> CC: Sjur Brændeland <sjur.brandeland@stericsson.com>
>> CC: Dmitry Tarnyagin <dmitry.tarnyagin@lockless.no>
>
> I got a "Delivery Status Notification (Failure)" for Dmitry Tarnyagin
> (I took the email address from the MAINTAINERS file):
>
> Delivery to the following recipient failed permanently:
>
> dmitry.tarnyagin@lockless.no
>
> Technical details of permanent failure:
> Google tried to deliver your message, but it was rejected by the server for
> the recipient domain lockless.no by mail.lockless.no. [46.29.221.38].
>
> The error that the other server returned was:
> 550 5.1.1 <dmitry.tarnyagin@lockless.no>: Recipient address rejected: User
> unknown in virtual mailbox table
>
> Any suggestions?
He used a gmail address in commit dd9dfb9f95e2 ("cfg80211: merge in
beacon ies of hidden bss."). Probably by accident, but worth trying
anyway...
I guess the stericsson.com addresses could be failing silently now? Ref
http://stericsson.com/ . Or are they still routed to the named recepients?
Bjørn
^ permalink raw reply
* Re: [PATCH net 1/2] caif: remove wrong dev_net_set() call
From: Nicolas Dichtel @ 2015-01-27 12:50 UTC (permalink / raw)
To: Bjørn Mork
Cc: netdev, davem, dmitry.tarnyagin, arvid.brodin, alex.aring,
linux-wpan, Sjur Brændeland, Dmitry Tarnyagin
In-Reply-To: <874mrcwg3q.fsf@nemi.mork.no>
Le 27/01/2015 13:41, Bjørn Mork a écrit :
> Nicolas Dichtel <nicolas.dichtel@6wind.com> writes:
>
>>> CC: Sjur Brændeland <sjur.brandeland@stericsson.com>
>>> CC: Dmitry Tarnyagin <dmitry.tarnyagin@lockless.no>
>>
>> I got a "Delivery Status Notification (Failure)" for Dmitry Tarnyagin
>> (I took the email address from the MAINTAINERS file):
>>
>> Delivery to the following recipient failed permanently:
>>
>> dmitry.tarnyagin@lockless.no
>>
>> Technical details of permanent failure:
>> Google tried to deliver your message, but it was rejected by the server for
>> the recipient domain lockless.no by mail.lockless.no. [46.29.221.38].
>>
>> The error that the other server returned was:
>> 550 5.1.1 <dmitry.tarnyagin@lockless.no>: Recipient address rejected: User
>> unknown in virtual mailbox table
>>
>> Any suggestions?
>
>
> He used a gmail address in commit dd9dfb9f95e2 ("cfg80211: merge in
> beacon ies of hidden bss."). Probably by accident, but worth trying
> anyway...
Ok, I will wait a bit before trying this address.
>
> I guess the stericsson.com addresses could be failing silently now? Ref
> http://stericsson.com/ . Or are they still routed to the named recepients?
I got also a delivery failure for sjur.brandeland@stericsson.com
Thank you,
Nicolas
^ permalink raw reply
* Re: [PATCH net 0/2] netns: audit netdevice creation with IFLA_NET_NS_[PID|FD]
From: Alexander Aring @ 2015-01-27 12:51 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev, davem, arvid.brodin, linux-wpan
In-Reply-To: <20150127122340.GA4338@omega>
On Tue, Jan 27, 2015 at 01:23:40PM +0100, Alexander Aring wrote:
...
> Summarize:
>
> I would add the dev->features |= NETIF_F_NETNS_LOCAL; while wpan
> interface generation and add only the !net_eq(src_net, &init_net) check
> above. I suppose that src_net is the net namespace from "underlaying"
> interface wpan by calling:
>
> $ ip link add link wpan0 name lowpan0 type lowpan
>
should look something like:
diff --git a/net/ieee802154/6lowpan/core.c b/net/ieee802154/6lowpan/core.c
index 055fbb7..a44963c 100644
--- a/net/ieee802154/6lowpan/core.c
+++ b/net/ieee802154/6lowpan/core.c
@@ -148,10 +148,11 @@ static int lowpan_newlink(struct net *src_net, struct net_device *dev,
pr_debug("adding new link\n");
- if (!tb[IFLA_LINK])
+ if (!tb[IFLA_LINK] |
+ !net_eq(src_net, &init_net))
return -EINVAL;
/* find and hold real wpan device */
- real_dev = dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
+ real_dev = dev_get_by_index(&init_net, nla_get_u32(tb[IFLA_LINK]));
if (!real_dev)
return -ENODEV;
if (real_dev->type != ARPHRD_IEEE802154) {
diff --git a/net/ieee802154/core.c b/net/ieee802154/core.c
index 18bc7e7..161f0e5 100644
--- a/net/ieee802154/core.c
+++ b/net/ieee802154/core.c
@@ -229,6 +229,8 @@ static int cfg802154_netdev_notifier_call(struct notifier_block *nb,
list_add_rcu(&wpan_dev->list, &rdev->wpan_dev_list);
rdev->devlist_generation++;
+ /* can only change netns with wpan_phy */
+ dev->features |= NETIF_F_NETNS_LOCAL;
wpan_dev->netdev = dev;
break;
case NETDEV_DOWN:
--
In ieee802154/core.c we set (like wireless it also does) the
dev->features |= NETIF_F_NETNS_LOCAL; for wpan interface.
In net/ieee802154/6lowpan/core.c, we only check if the wpan interface
belongs to !net_eq(src_net, &init_net).
On 6LoWPAN 802.15.4 interfaces it should be still possible to change
the net namespace.
- Alex
^ permalink raw reply related
* Re: [PATCH 1/2] if_link: Add VF multicast promiscuous mode control
From: Hiroshi Shimamoto @ 2015-01-27 12:53 UTC (permalink / raw)
To: Skidmore, Donald C, Alexander Duyck, Bjørn Mork
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Choi, Sy Jong, linux-kernel@vger.kernel.org, David Laight,
Hayato Momma
In-Reply-To: <F6FB0E698C9B3143BDF729DF222866469129C3D0@ORSMSX110.amr.corp.intel.com>
> > On 01/22/2015 04:32 PM, Hiroshi Shimamoto wrote:
> > >> Subject: RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast
> > >> promiscuous mode control
> > >>> "Skidmore, Donald C" <donald.c.skidmore@intel.com> writes:
> > >>>
> > >>>> My hang up is more related to: without the nob to enable it (off by
> > >>>> default) we are letting one VF dictate policy for all the other VFs
> > >>>> and the PF. If one VF needs to be in promiscuous multicast so is
> > >>>> everyone else. Their stacks now needs to deal with all the extra
> > >>>> multicast packets. As you point out this might not be a direct
> > >>>> concern for isolation in that the VM could have 'chosen' to join
> > >>>> any Multicast group and seen this traffic. My concern over
> > >>>> isolation is one VF has chosen that all the other VM now have to
> > >>>> see this multicast traffic.
> > >>> Apologies if this question is stupid, but I just have to ask about
> > >>> stuff I don't understand...
> > >>>
> > >>> Looking at the proposed implementation, the promiscous multicast
> > >>> flag seems to be a per-VF flag:
> > >>>
> > >>> +int ixgbe_ndo_set_vf_mc_promisc(struct net_device *netdev, int vf,
> > >>> +bool
> > >>> +setting) {
> > >>> + struct ixgbe_adapter *adapter = netdev_priv(netdev);
> > >>> + struct ixgbe_hw *hw = &adapter->hw;
> > >>> + u32 vmolr;
> > >>> +
> > >>> + if (vf >= adapter->num_vfs)
> > >>> + return -EINVAL;
> > >>> +
> > >>> + adapter->vfinfo[vf].mc_promisc_enabled = setting;
> > >>> +
> > >>> + vmolr = IXGBE_READ_REG(hw, IXGBE_VMOLR(vf));
> > >>> + if (setting) {
> > >>> + e_info(drv, "VF %u: enabling multicast promiscuous\n", vf);
> > >>> + vmolr |= IXGBE_VMOLR_MPE;
> > >>> + } else {
> > >>> + e_info(drv, "VF %u: disabling multicast promiscuous\n", vf);
> > >>> + vmolr &= ~IXGBE_VMOLR_MPE;
> > >>> + }
> > >>> +
> > >>> + IXGBE_WRITE_REG(hw, IXGBE_VMOLR(vf), vmolr);
> > >>> +
> > >>> + return 0;
> > >>> +}
> > >>> +
> > >>>
> > >>> I haven't read the data sheet, but I took a quick look at the
> > >>> excellent high level driver docs:
> > >>> http://www.intel.com/content/dam/doc/design-guide/82599-sr-iov-
> > drive
> > >>> r-
> > >>> companion-guide.pdf
> > >>>
> > >>> It mentions "Multicast Promiscuous Enable" in its "Thoughts for
> > >>> Customization" section:
> > >>>
> > >>> 7.1 Multicast Promiscuous Enable
> > >>>
> > >>> The controller has provisions to allow each VF to be put into
> > >>> Multicast Promiscuous mode. The Intel reference driver does not
> > >>> configure this option .
> > >>>
> > >>> The capability can be enabled/disabled by manipulating the MPE
> > >>> field (bit
> > >>> 28) of the PF VF L2 Control Register (PFVML2FLT – 0x0F000)
> > >>>
> > >>> and showing a section from the data sheet describing the "PF VM L2
> > >>> Control Register - PFVML2FLT[n] (0x0F000 + 4 * n, n=0...63; RW)"
> > >>>
> > >>> To me it looks like enabling Promiscuos Multicast for a VF won't
> > >>> affect any other VF at all. Is this really not the case?
> > >>>
> > >>>
> > >>>
> > >>> Bjørn
> > >> Clearly not a dumb question at all and I'm glad you mentioned that.
> > >> :) I was going off the assumption, been awhile since I read the
> > >> patch, that the patch was using FCTRL.MPE or MANC.MCST_PASS_L2
> > which would turn multicast promiscuous on for everyone. Since the patch is
> > using PFVML2FLT.MPE this lessens my concern over effect on the entire
> > system.
> > > I believe the patches for this VF multicast promiscuous mode is per VF.
> > >
> > >> That said I still would prefer having a way to override this behavior on the
> > PF, although I admit my argument is weaker.
> > >> I'm still concerned about a VF changing the behavior of the PF
> > >> without any way to prevent it. This might be one part philosophical
> > >> (PF sets policy not the VF) but this still could have a noticeable
> > >> effect on the overall system. If any other VFs (or the PF) are
> > >> receiving MC packets these will have to be replicated which will be a
> > >> performance hit. When we use the MC hash this is limited vs. when
> > anyone is in MC promiscuous every MC packet used by another pool would
> > be replicated. I could imagine in some environments (i.e. public clouds)
> > where you don't trust what is running in your VM you might what to block
> > this from happening.
> > > I understand your request and I'm thinking to submit the patches
> > > 1) Add new mbox API between ixgbe/ixgbevf to turn MC promiscuous on,
> > > and enables it when ixgbevf needs over 30 MC addresses.
> > > 2) Add a policy knob to prevent enabling it from the PF.
> > >
> > > Does it seem okay?
> >
> > I would advise that if such a knob is added it should be set to disabled by
> > default. The main problem with supporting that many multicast addresses
> > per VF is that you run the risk for flooding the PCIe interface on the network
> > adapter if too many adapters were to go into such a mode.
> >
>
> This was my understanding as well. Someone would have to "choose" to allow VM to enter this mode, meaning off by default.
I see you'd like to keep it off unless the administrator wants to configure.
>
> > > BTW, I'm bit worried about to use ndo interface for 2) because adding
> > > a new hook makes core code complicated.
> > > Is it really reasonable to do it with ndo?
> > > I haven't find any other suitable method to do it, right now. And
> > > using ndo VF hook looks standard way to control VF functionality.
> > > Then, I think it's the best way to implement this policy in ndo hook.
> >
> > The ndo is probably the only way to go on this. It is how past controls for the
> > VF network functionality have been implemented.
> >
> > >> In some ways it is almost the mirror image of the issue you brought up:
> > >>
> > >> Adding a new hook for this seems over-complicated to me. And it
> > >> still doesn't solve the real problems that
> > >> a) the user has to know about this limit, and
> > >> b) manually configure the feature
> > >>
> > >> My reverse argument might be that if this happens automatically. It
> > >> might take the VM provider a long time to realize performance has
> > >> taken a hit because some VM asked to join 31 multicast groups and
> > entered MC promiscuous. Then only to find that they have no way to block
> > such behavior.
> > >>
> > >> Maybe I wouldn't as concerned if the patch author could provide some
> > >> performance results to show this won't have as a negative effect as I'm
> > afraid it might?
> > > Hm, what kind of test case would you like to have?
> > > The user A who has 30 MC addresses vs the user B who has 31 MC
> > > addresses, which means that MC promiscuous mode, and coming MC
> > packets the user doesn't expect?
> > >
> > > thanks,
> > > Hiroshi
> >
> > The question I would have is how many of these interfaces do you expect to
> > have supporting the expanded multicast mode? As it currently stands
Right now, we're thinking 1 or 2 VFs per PF will be enabled this feature
in our use case. Another representation, 1 or 2 VMs will be used VF device on
one server, each VM has 2 VFs usually.
> > multicast traffic has the potential to flood the adapter, greatly reduce the
> > overall throughput, and add extra workload to the PF and all VFs.
> > For example if several VFs enable this feature, and then someone on the
> > network sends a stream of multicast traffic what happens to the CPU load for
> > the host system?
I'm not sure why all VFs are affected.
I can imagine that PF and VFs which are enabled this feature could receive
flooding packets, but other VFs never receive such packets.
> >
> > Also how many addresses beyond 30 is it you require? An alternative to
> > adding multicast promiscuous might be to consider extending the mailbox
> > API to support sending more than 30 addresses via something such as a
> > multi-part multicast configuration message. The fm10k driver already has
> > logic similar to this as it adds addresses 1 at a time though a separate Switch
> > interface API between the PF and the Switch. You might be able to reuse
> > some of that code to reach beyond the 30 address limit.
>
> I think this would be a much safer approach and probably scale well for small sets. However I don't think it would work
> for Hiroshi's use case. If I remember correctly he wanted 1000's of MC groups per VM. I imagine there would be considerable
> overhead even loading up our 4K hash table 1 address at a time, likewise with that many address wouldn't this just be
> pretty much the same as being in multicast promiscuous. Still this might be an interesting approach to support those
> needing only a few MC groups over the limit.
We would like to use 2000 IPs usually, and would extend to 4k which comes from VLAN limit.
IIRC, mbox API has only 32 words, it doesn't scale, I think.
And there is a single hash table per PF, not per VF. I guess if we set 4k hash entries
from a specific VF, every VF will receive all MC packets.
>
> Alex's point is worth reiterating, this will effect performance. Have you tested this out under load and still see the
> results you can live with?
I don't have any number in MC load.
In general case, we have enough performance in VM, almost wire rate in our scenario.
thanks,
Hiroshi
>
> -Don Skidmore <donald.c.skidmore@intel.com>
>
> >
> > - Alex
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH net-next 06/10] net/mlx4_core: Fix struct mlx4_vhcr_cmd to make implicit padding explicit
From: Jack Morgenstein @ 2015-01-27 13:00 UTC (permalink / raw)
To: David Laight
Cc: 'Amir Vadai', David S. Miller, netdev@vger.kernel.org,
Or Gerlitz, Yevgeny Petrilin
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CAD3B01@AcuExch.aculab.com>
On Tue, 27 Jan 2015 09:43:27 +0000
David Laight <David.Laight@ACULAB.COM> wrote:
> From: Amir Vadai
> > From: Jack Morgenstein <jackm@dev.mellanox.co.il>
> >
> > Struct mlx4_vhcr was implicitly padded by the gcc compiler.
> > This commit makes that padding explicit, to prevent issues with
> > changing compilers. Note that we added the padding dword (rather
> > than simply packing the structure) in order to maintain
> > compatibility with previous kernels.
>
> It isn't a 'compiler' option, but depends on the architecture.
>
> > Reported-by: Alexander Schmidt <alexs@linux.vnet.ibm.com>
> > Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
> > Signed-off-by: Amir Vadai <amirv@mellanox.com>
> > ---
> > drivers/net/ethernet/mellanox/mlx4/mlx4.h | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4.h
> > b/drivers/net/ethernet/mellanox/mlx4/mlx4.h index 096a81c..595e18a
> > 100644 --- a/drivers/net/ethernet/mellanox/mlx4/mlx4.h
> > +++ b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
> > @@ -196,13 +196,14 @@ struct mlx4_vhcr {
> > struct mlx4_vhcr_cmd {
> > __be64 in_param;
> > __be32 in_modifier;
> > + u32 reserved1;
>
> Adding a pad here changes the alignment on most 32bit architectures
> (eg i386) where 64bit integers are only aligned to 4 byte boundaries.
> So you are not 'maintaining compatibility with previous kernels'.
You are correct. However, this structure is used ONLY for communication
between a Host and a Guest on that host. In the current code (before
this fix), it was not possible to run a 32-bit Guest over a 64-bit Host,
because of the implicit padding that occurred on the 64-bit Host
and did not occur on the 32-bit Guest.
With this fix, a 32-bit Guest (with the fix) will be able to run over a
64-bit Host (with or without the fix).
The padding dword thus serves to maintain 64-bit Host (old or
new) compatibility with 64-bit Guests (old or new), while allowing
64-bit Hosts to support new 32-bit Guests.
I'll fix the changelog for the next submission.
>
> > __be64 out_param;
> > __be16 token;
> > u16 reserved;
> > u8 status;
> > u8 flags;
> > __be16 opcode;
> > -};
> > +} __packed;
>
> Don't add '__packed' unless you expect the structure to be misaligned
> in memory.
> On systems that fault mis-aligned memory requests you've requested the
> compiler generate code to read/write everything using byte sized
> memory accesses and a lot of shifting and masking.
OK, I'll remove the "packed" in the next submission, since with the
padding dword 64-bit arch and 32-bit arch compilers should produce the
same offsets.
>
> David
>
Thanks for the review!
-Jack
^ permalink raw reply
* A problem about ICMP packet-too-big message handler
From: Yang Yingliang @ 2015-01-27 12:58 UTC (permalink / raw)
To: netdev, David S. Miller
Hi,
My kernel is 3.10 LTS.
I got a problem here about handling ICMP packet-too-big message.
Before sending a packet-too-big packet :
# ip -6 route list table local
local ::1 dev lo metric 0
local fe80:: dev lo metric 0
local fe80:: dev lo metric 0
local fe80:: dev lo metric 0
local fe80:: dev lo metric 0
local fe80:: dev lo metric 0
local fe80:: dev lo metric 0
local fe80::1 dev lo metric 0 //It does not have expire value
local fe80::200:ff:fe00:0 dev lo metric 0
local fe80::200:ff:fe00:0 dev lo metric 0
local fe80::200:ff:fe00:0 dev lo metric 0
local fe80::200:ff:fe00:0 dev lo metric 0
local fe80::200:ff:fe00:2 dev lo metric 0
local fe80::5054:ff:fe12:3456 dev lo metric 0
After sending a packet-too-big packet
ip -6 route list table local
local ::1 dev lo metric 0
local fe80:: dev lo metric 0
local fe80:: dev lo metric 0
local fe80:: dev lo metric 0
local fe80:: dev lo metric 0
local fe80:: dev lo metric 0
local fe80:: dev lo metric 0
local fe80::1 dev lo metric 0 expires _597_ //It has expire value
local fe80::200:ff:fe00:0 dev lo metric 0
local fe80::200:ff:fe00:0 dev lo metric 0
local fe80::200:ff:fe00:0 dev lo metric 0
local fe80::200:ff:fe00:0 dev lo metric 0
local fe80::200:ff:fe00:2 dev lo metric 0
local fe80::5054:ff:fe12:3456 dev lo metric 0
When time is up, I can't ping fe80::1 .
Is it ok or a bug ?
Regards,
Yang
^ permalink raw reply
* [PATCH] net/9p: use memcpy() instead of snprintf() in p9_mount_tag_show()
From: Andrey Ryabinin @ 2015-01-27 13:00 UTC (permalink / raw)
To: linux-kernel
Cc: David Laight, Aneesh Kumar K.V, Eric Van Hensbergen, Ron Minnich,
Latchesar Ionkov, David S. Miller, v9fs-developer, netdev,
Andrey Ryabinin
In-Reply-To: <1422290896-25042-1-git-send-email-a.ryabinin@samsung.com>
p9_mount_tag_show() uses '%s' format string to print
non-NULL terminated chan->tag string. This leads
to out of bounds memory read, because format '%s'
implies that string is NULL-terminated.
The length of string is know here, so its simpler and safer
to use memcpy instead of snprintf().
Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
---
net/9p/trans_virtio.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
index daa749c..9d64145 100644
--- a/net/9p/trans_virtio.c
+++ b/net/9p/trans_virtio.c
@@ -504,7 +504,10 @@ static ssize_t p9_mount_tag_show(struct device *dev,
vdev = dev_to_virtio(dev);
chan = vdev->priv;
- return snprintf(buf, chan->tag_len + 1, "%s", chan->tag);
+ memcpy(buf, chan->tag, chan->tag_len);
+ buf[chan->tag_len] = 0;
+
+ return chan->tag_len + 1;
}
static DEVICE_ATTR(mount_tag, 0444, p9_mount_tag_show, NULL);
--
2.2.2
^ permalink raw reply related
* Re: make allyesconfig i386 build failure with next-20150122 (caused by fb_agm1264k-fl driver)
From: Tilman Schmidt @ 2015-01-27 13:04 UTC (permalink / raw)
To: Guenter Roeck, Greg Kroah-Hartman
Cc: Jim Davis, Stephen Rothwell, linux-next, linux-kernel, devel,
isdn, netdev, Thomas Petazzoni
In-Reply-To: <54C6FB28.3000304@roeck-us.net>
Am 27.01.2015 um 03:42 schrieb Guenter Roeck:
> On 01/26/2015 02:46 PM, Greg Kroah-Hartman wrote:
>> On Mon, Jan 26, 2015 at 01:59:59PM -0800, Guenter Roeck wrote:
>>> On Thu, Jan 22, 2015 at 12:10:33PM -0700, Jim Davis wrote:
>>>> make ARCH=i386 allyesconfig fails with
>>>>
>>>> drivers/staging/built-in.o: In function `reset':
>>>> (.text+0x2ae89d): multiple definition of `reset'
>>>> drivers/isdn/built-in.o:(.text+0x185dc2): first defined here
>>>> make[1]: *** [drivers/built-in.o] Error 1
>>>
>>> Culprit:
>>>
>>> commit b2ebd4be6fa1d2329b63531b044f9e25474981cb
>>> Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>>> Date: Wed Dec 31 10:11:10 2014 +0100
>>>
>>> staging: fbtft: add fb_agm1264k-fl driver
>>>
>>> A global function named 'reset' isn't really a good idea.
>>>
>>> Not that the global function with the same name in the isdn code
>>> is better ;-).
>>
>> Agreed, the fbtft code is now fixed. Patches to fix the isdn code would
>> be gladly accepted as well :)
>>
>
> Did you have a look into the isdn code ? It will need someone
> with a lot of spare time to clean this code up.
Cleaning up the entire isdn code certainly will, but that particular
problem is in fact much more limited. The function in question is
declared, along with several other also much too generically named
ones, in drivers/isdn/sc/card.h which is included nowhere outside
drivers/isdn/sc. So these are really private functions of the
SpellCaster driver which could easily be renamed.
OTOH good old SpellCaster was an ISA card, and the sc driver depends
on the deprecated I4L framework. I wonder if it's worth any effort.
Tilman
^ permalink raw reply
* Re: [PATCH 1/2] rhashtable: Introduce rhashtable_walk_*
From: Patrick McHardy @ 2015-01-27 13:09 UTC (permalink / raw)
To: Herbert Xu
Cc: Thomas Graf, David Miller, David.Laight, ying.xue, paulmck,
netdev, netfilter-devel
In-Reply-To: <20150127112304.GA4548@gondor.apana.org.au>
On 27.01, Herbert Xu wrote:
> On Tue, Jan 27, 2015 at 11:16:04AM +0000, Thomas Graf wrote:
> >
> > No objection. I have a patch prepared which allows the user to
> > provide ht->mutex himself so nfset can provide its own existing
> > mutex to rhashtable and lock out the resizes from inserts,
> > removals and dump iterations automatically That would restore the
> > old behaviour of the nfset API without major surgery.
>
> If you take the mutex you might as well just make it synchronous.
> There is zero difference.
>
> Maybe you misunderstood my email. I'm not making it synchronous
> for everybody, just those that always take a lock on inserts/removals
> and therefore don't need per-bucket locks.
Actually I have a patchset queued that adds runtime additions and
removals, both active and timeout based. So netfilter won't have
pure synchronous behaviour anymore.
^ permalink raw reply
* Re: [PATCH net 0/2] netns: audit netdevice creation with IFLA_NET_NS_[PID|FD]
From: Nicolas Dichtel @ 2015-01-27 13:28 UTC (permalink / raw)
To: Alexander Aring; +Cc: netdev, davem, arvid.brodin, linux-wpan
In-Reply-To: <20150127122340.GA4338@omega>
Le 27/01/2015 13:23, Alexander Aring a écrit :
> Hi,
>
> (removing the bounced mail address).
>
> On Tue, Jan 27, 2015 at 11:32:44AM +0100, Nicolas Dichtel wrote:
>> Le 27/01/2015 10:34, Alexander Aring a écrit :
>>> Hi,
>>>
>>> On Mon, Jan 26, 2015 at 10:28:12PM +0100, Nicolas Dichtel wrote:
>>>>
[snip]
>>>
>>> This file handles the IEEE 802.15.4 6LoWPAN interface to offering a
>>> IPv6 interface with an IEEE 802.15.4 6LoWPAN adaption layer.
>>>
>>> To the codeline "dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));".
>>> By calling "ip link add link wpan0 name lowpan0 type lowpan" the
>>> lowpan_newlink function will be called and we need to find the wpan interface
>>> (returned as real_dev in this case).
>>>
>>> Namespace setting in wpan interface:
>>>
>>> Currently we don't use any net namespace settings there, also we don't
>>> change the net namespace. The default net namespace for a wpan shoule be
>>> "init_net".
>> Ok. After grepping for init_net, it seems to be used a lot in net/ieee802154/.
>>
>
> Yes, but the code in net/ieee802154 (except net/ieee802154/6lowpan) is only for
> the WPAN interface. Currently the WPAN interface is created in mac802154
> implementation only [0].
Ok. How is this interface created?
>
>>>
>>> So this line could be also written as (I found also some others code which search
>>> the wpan interface in &init_net):
>>>
>>> diff --git a/net/ieee802154/6lowpan/core.c b/net/ieee802154/6lowpan/core.c
>>> index 9dbe0d69..495c6ad 100644
>>> --- a/net/ieee802154/6lowpan/core.c
>>> +++ b/net/ieee802154/6lowpan/core.c
>>> @@ -151,7 +151,7 @@ static int lowpan_newlink(struct net *src_net, struct net_device *dev,
>>> if (!tb[IFLA_LINK])
>>> return -EINVAL;
>>> /* find and hold real wpan device */
>>> - real_dev = dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
>>> + real_dev = dev_get_by_index(&init_net, nla_get_u32(tb[IFLA_LINK]));
>>> if (!real_dev)
>>> return -ENODEV;
>>> if (real_dev->type != ARPHRD_IEEE802154) {
>>>
>>>
>>>
>>> The above code is for finding the wpan interface (the real 802.15.4 L2 interface).
>>> For the IEEE 802.15.4 6LoWPAN interface the whole IPv6 implementation is
>>> used. This interface will be created inside function "newlink".
>>>
>>> Running "grep -r "src_net" net/ipv6" reports me alot uses of "src_net".
>>> Don't know if this information is really necessary.
>>>
>>> Should I set now the NETIF_F_NETNS_LOCAL for both interface types?
>> I think yes. If it's not set, a user may do:
>> $ ip link add link wpan0 name lowpan0 type lowpan
>> $ ip netns add foo
>> $ ip link set lowpan0 netns foo
>>
>
> We should forbid that for the wpan interface. The code line:
>
> real_dev = dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
>
> searches for the "wpan0" interface which is given by:
> $ ip link add link wpan0 name lowpan0 type lowpan
>
> The returned real_dev netdevice pointer is the wpan interface. The given
> "lowpan0" interface is a virtual interface for making IPv6 stuff.
Yes. But with the current code, it seems that you can also do (not tested):
$ ip link add link wpan0 netns foo name lowpan0 type lowpan
With this cmd, src_net points to the netns where the ip cmd is launched (let's
say init_net in this case) but the interface lowpan0 will be created in the
netns foo. To summarize: wpan0 is in init_net and lowpan0 in foo.
Now, if you use this line:
real_dev = dev_get_by_index(dev_net(dev), nla_get_u32(tb[IFLA_LINK]));
With the same command, dev_net(dev) will point to foo.
>
>
>
> For 6LoWPAN:
>
> This interface is created in 6lowpan/core.c file and is used in the
> whole IPv6 stack, because we set the skb->protocol to htons(ETH_P_IPV6). [1]
>
> The IPv6 stack uses alot of "src_net".
In fact, src_net is used by IP tunnels (sit, ip6gre, ip6_tunnels, ip6_vti). But
these interfaces ignore this parameter.
The IPv6 stack is fully netns aware, thus it will use correctly the netns from
the netdevice and/or from the socket.
>
>> The flag forbids the last command.
>>
>> Instead of your patch, what about this one:
>>
>> From d9a9cd22d5e1db1417b3ffb53cc020481dc761b2 Mon Sep 17 00:00:00 2001
>> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>> Date: Tue, 27 Jan 2015 11:26:20 +0100
>> Subject: [PATCH] ieee802154: forbid to create an iface in a netns != init_net
>>
>> 6LoWPAN currently doesn't supports netns.
>>
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>> ---
>> net/ieee802154/6lowpan/core.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/ieee802154/6lowpan/core.c b/net/ieee802154/6lowpan/core.c
>> index 055fbb71ba6f..fe8fd022042e 100644
>> --- a/net/ieee802154/6lowpan/core.c
>> +++ b/net/ieee802154/6lowpan/core.c
>> @@ -126,6 +126,7 @@ static void lowpan_setup(struct net_device *dev)
>> dev->header_ops = &lowpan_header_ops;
>> dev->ml_priv = &lowpan_mlme;
>> dev->destructor = free_netdev;
>> + dev->features |= NETIF_F_NETNS_LOCAL;
>> }
>>
>> static int lowpan_validate(struct nlattr *tb[], struct nlattr *data[])
>> @@ -148,7 +149,9 @@ static int lowpan_newlink(struct net *src_net, struct
>> net_device *dev,
>>
>> pr_debug("adding new link\n");
>>
>> - if (!tb[IFLA_LINK])
>> + if (!tb[IFLA_LINK] ||
>> + !net_eq(src_net, &init_net) ||
>> + !net_eq(dev_net(dev), &init_net))
>> return -EINVAL;
>> /* find and hold real wpan device */
>> real_dev = dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
>
> With the check of "!net_eq(src_net, &init_net)" we need to be sure
> that the wpan interface is always in "init_net". This means we need
> definitely a dev->features |= NETIF_F_NETNS_LOCAL; somewhere in [0].
>
> To adding "dev->features |= NETIF_F_NETNS_LOCAL;" for a 6LoWPAN interface,
> I am not sure about this. I didn't test it yet and it will not break
> anything, but we will lost the support for making net namespaces stuff
> inside the IPv6/(netfilter) stack.
Adding NETIF_F_NETNS_LOCAL does not mean that the netdevice can be used only
in init_net, this flag means that the netdevice cannot be moved to another
netns. You can still create a netdevice in another netns (if wpan0 is in netns
foo):
$ ip netns exec foo ip link add link wpan0 name lowpan0 type lowpan
I don't know how wpan0 is created and if this interface can be created directly
in another netns than init_net.
>
>
> Summarize:
>
> I would add the dev->features |= NETIF_F_NETNS_LOCAL; while wpan
> interface generation and add only the !net_eq(src_net, &init_net) check
> above. I suppose that src_net is the net namespace from "underlaying"
> interface wpan by calling:
>
> $ ip link add link wpan0 name lowpan0 type lowpan
No. src_net is the netns where the ip command is launched. With this patch, my
previous cmd (ip link add link wpan0 netns foo name lowpan0 type lowpan) will
still work and lowpan0 will be in netns foo.
Note: I just saw your patch proposal in another reply [0], with it, my sentence
is still true I think ;-)
But:
$ git grep "net_eq.*init_net" net/ieee802154/' | wc -l
7
So I wonder if it's really possible to use lowpan0 in another netns than
init_net (my proposal was based on this).
Maybe this can help you to understand my point.
A virtual interface can be across two netns:
- the link netns (the interface receives and sends packets to/from the link
layer into this netns)
- the netns where the interface is visible (the user receives and sends
packets to/from the interface into this netns)
[0] http://patchwork.ozlabs.org/patch/433467/
Regards,
Nicolas
^ permalink raw reply
* RE: [PATCH net-next 06/10] net/mlx4_core: Fix struct mlx4_vhcr_cmd to make implicit padding explicit
From: David Laight @ 2015-01-27 13:38 UTC (permalink / raw)
To: 'Jack Morgenstein'
Cc: 'Amir Vadai', David S. Miller, netdev@vger.kernel.org,
Or Gerlitz, Yevgeny Petrilin
In-Reply-To: <20150127150027.184ba5e8@jpm-OptiPlex-GX620>
From: Jack Morgenstein
> On Tue, 27 Jan 2015 09:43:27 +0000
> David Laight <David.Laight@ACULAB.COM> wrote:
>
> > From: Amir Vadai
> > > From: Jack Morgenstein <jackm@dev.mellanox.co.il>
> > >
> > > Struct mlx4_vhcr was implicitly padded by the gcc compiler.
> > > This commit makes that padding explicit, to prevent issues with
> > > changing compilers. Note that we added the padding dword (rather
> > > than simply packing the structure) in order to maintain
> > > compatibility with previous kernels.
> >
> > It isn't a 'compiler' option, but depends on the architecture.
> >
> > > Reported-by: Alexander Schmidt <alexs@linux.vnet.ibm.com>
> > > Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
> > > Signed-off-by: Amir Vadai <amirv@mellanox.com>
> > > ---
> > > drivers/net/ethernet/mellanox/mlx4/mlx4.h | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4.h
> > > b/drivers/net/ethernet/mellanox/mlx4/mlx4.h index 096a81c..595e18a
> > > 100644 --- a/drivers/net/ethernet/mellanox/mlx4/mlx4.h
> > > +++ b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
> > > @@ -196,13 +196,14 @@ struct mlx4_vhcr {
> > > struct mlx4_vhcr_cmd {
> > > __be64 in_param;
> > > __be32 in_modifier;
> > > + u32 reserved1;
> >
> > Adding a pad here changes the alignment on most 32bit architectures
> > (eg i386) where 64bit integers are only aligned to 4 byte boundaries.
> > So you are not 'maintaining compatibility with previous kernels'.
>
> You are correct. However, this structure is used ONLY for communication
> between a Host and a Guest on that host. In the current code (before
> this fix), it was not possible to run a 32-bit Guest over a 64-bit Host,
> because of the implicit padding that occurred on the 64-bit Host
> and did not occur on the 32-bit Guest.
>
> With this fix, a 32-bit Guest (with the fix) will be able to run over a
> 64-bit Host (with or without the fix).
Haven't you broken communication between an old and new
32bit Guests and 32bit hosts (assuming they exist)?
David
^ permalink raw reply
* Re: [PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
From: Hannes Frederic Sowa @ 2015-01-27 13:47 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Ben Hutchings, Vladislav Yasevich, netdev, virtualization,
edumazet, Vladislav Yasevich
In-Reply-To: <20150127084208.GB21584@redhat.com>
On Di, 2015-01-27 at 10:42 +0200, Michael S. Tsirkin wrote:
> On Tue, Jan 27, 2015 at 02:47:54AM +0000, Ben Hutchings wrote:
> > On Mon, 2015-01-26 at 09:37 -0500, Vladislav Yasevich wrote:
> > > If the IPv6 fragment id has not been set and we perform
> > > fragmentation due to UFO, select a new fragment id.
> > > When we store the fragment id into skb_shinfo, set the bit
> > > in the skb so we can re-use the selected id.
> > > This preserves the behavior of UFO packets generated on the
> > > host and solves the issue of id generation for packet sockets
> > > and tap/macvtap devices.
> > >
> > > This patch moves ipv6_select_ident() back in to the header file.
> > > It also provides the helper function that sets skb_shinfo() frag
> > > id and sets the bit.
> > >
> > > It also makes sure that we select the fragment id when doing
> > > just gso validation, since it's possible for the packet to
> > > come from an untrusted source (VM) and be forwarded through
> > > a UFO enabled device which will expect the fragment id.
> > >
> > > CC: Eric Dumazet <edumazet@google.com>
> > > Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> > > ---
> > > include/linux/skbuff.h | 3 ++-
> > > include/net/ipv6.h | 2 ++
> > > net/ipv6/ip6_output.c | 4 ++--
> > > net/ipv6/output_core.c | 9 ++++++++-
> > > net/ipv6/udp_offload.c | 10 +++++++++-
> > > 5 files changed, 23 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > > index 85ab7d7..3ad5203 100644
> > > --- a/include/linux/skbuff.h
> > > +++ b/include/linux/skbuff.h
> > > @@ -605,7 +605,8 @@ struct sk_buff {
> > > __u8 ipvs_property:1;
> > > __u8 inner_protocol_type:1;
> > > __u8 remcsum_offload:1;
> > > - /* 3 or 5 bit hole */
> > > + __u8 ufo_fragid_set:1;
> > [...]
> >
> > Doesn't the flag belong in struct skb_shared_info, rather than struct
> > sk_buff? Otherwise this looks fine.
> >
> > Ben.
>
> Hmm we seem to be out of tx flags.
> Maybe ip6_frag_id == 0 should mean "not set".
Maybe that is the best idea. Definitely the ufo_fragid_set bit should
move into the skb_shared_info area.
Thanks,
Hannes
^ permalink raw reply
* [PATCH net-next V1 04/11] net/mlx4_core: Adjust command timeouts to conform to the firmware spec
From: Amir Vadai @ 2015-01-27 13:58 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Amir Vadai, Yevgeny Petrilin,
Jack Morgenstein
In-Reply-To: <1422367089-13419-1-git-send-email-amirv@mellanox.com>
From: Jack Morgenstein <jackm@dev.mellanox.co.il>
The firmware spec states that the timeout for all commands should be 60 seconds.
In the past, the spec indicated that there were several classes of timeout
(short, medium, and long). The driver has these different timeout classes.
We leave the class differentiation in the driver as-is (to protect against any
future spec changes), but set the timeout for all classes to be 60 seconds.
In addition, we fix a few commands which had hard-coded numeric timeouts specified.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/fw.c | 19 ++++++++++---------
drivers/net/ethernet/mellanox/mlx4/mr.c | 4 ++--
include/linux/mlx4/cmd.h | 6 +++---
3 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.c b/drivers/net/ethernet/mellanox/mlx4/fw.c
index 2aa7c23..0c90d10 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.c
@@ -1774,8 +1774,8 @@ int mlx4_INIT_HCA(struct mlx4_dev *dev, struct mlx4_init_hca_param *param)
MLX4_PUT(inbox, parser_params, INIT_HCA_VXLAN_OFFSET);
}
- err = mlx4_cmd(dev, mailbox->dma, 0, 0, MLX4_CMD_INIT_HCA, 10000,
- MLX4_CMD_NATIVE);
+ err = mlx4_cmd(dev, mailbox->dma, 0, 0, MLX4_CMD_INIT_HCA,
+ MLX4_CMD_TIME_CLASS_C, MLX4_CMD_NATIVE);
if (err)
mlx4_err(dev, "INIT_HCA returns %d\n", err);
@@ -2029,7 +2029,7 @@ int mlx4_CLOSE_PORT_wrapper(struct mlx4_dev *dev, int slave,
if (dev->caps.port_mask[port] != MLX4_PORT_TYPE_IB) {
if (priv->mfunc.master.init_port_ref[port] == 1) {
err = mlx4_cmd(dev, 0, port, 0, MLX4_CMD_CLOSE_PORT,
- 1000, MLX4_CMD_NATIVE);
+ MLX4_CMD_TIME_CLASS_A, MLX4_CMD_NATIVE);
if (err)
return err;
}
@@ -2040,7 +2040,7 @@ int mlx4_CLOSE_PORT_wrapper(struct mlx4_dev *dev, int slave,
if (!priv->mfunc.master.qp0_state[port].qp0_active &&
priv->mfunc.master.qp0_state[port].port_active) {
err = mlx4_cmd(dev, 0, port, 0, MLX4_CMD_CLOSE_PORT,
- 1000, MLX4_CMD_NATIVE);
+ MLX4_CMD_TIME_CLASS_A, MLX4_CMD_NATIVE);
if (err)
return err;
priv->mfunc.master.slave_state[slave].init_port_mask &= ~(1 << port);
@@ -2055,15 +2055,15 @@ int mlx4_CLOSE_PORT_wrapper(struct mlx4_dev *dev, int slave,
int mlx4_CLOSE_PORT(struct mlx4_dev *dev, int port)
{
- return mlx4_cmd(dev, 0, port, 0, MLX4_CMD_CLOSE_PORT, 1000,
- MLX4_CMD_WRAPPED);
+ return mlx4_cmd(dev, 0, port, 0, MLX4_CMD_CLOSE_PORT,
+ MLX4_CMD_TIME_CLASS_A, MLX4_CMD_WRAPPED);
}
EXPORT_SYMBOL_GPL(mlx4_CLOSE_PORT);
int mlx4_CLOSE_HCA(struct mlx4_dev *dev, int panic)
{
- return mlx4_cmd(dev, 0, 0, panic, MLX4_CMD_CLOSE_HCA, 1000,
- MLX4_CMD_NATIVE);
+ return mlx4_cmd(dev, 0, 0, panic, MLX4_CMD_CLOSE_HCA,
+ MLX4_CMD_TIME_CLASS_C, MLX4_CMD_NATIVE);
}
struct mlx4_config_dev {
@@ -2202,7 +2202,8 @@ int mlx4_SET_ICM_SIZE(struct mlx4_dev *dev, u64 icm_size, u64 *aux_pages)
int mlx4_NOP(struct mlx4_dev *dev)
{
/* Input modifier of 0x1f means "finish as soon as possible." */
- return mlx4_cmd(dev, 0, 0x1f, 0, MLX4_CMD_NOP, 100, MLX4_CMD_NATIVE);
+ return mlx4_cmd(dev, 0, 0x1f, 0, MLX4_CMD_NOP, MLX4_CMD_TIME_CLASS_A,
+ MLX4_CMD_NATIVE);
}
int mlx4_get_phys_port_id(struct mlx4_dev *dev)
diff --git a/drivers/net/ethernet/mellanox/mlx4/mr.c b/drivers/net/ethernet/mellanox/mlx4/mr.c
index 8dbdf1d..d21e884 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mr.c
+++ b/drivers/net/ethernet/mellanox/mlx4/mr.c
@@ -1155,7 +1155,7 @@ EXPORT_SYMBOL_GPL(mlx4_fmr_free);
int mlx4_SYNC_TPT(struct mlx4_dev *dev)
{
- return mlx4_cmd(dev, 0, 0, 0, MLX4_CMD_SYNC_TPT, 1000,
- MLX4_CMD_NATIVE);
+ return mlx4_cmd(dev, 0, 0, 0, MLX4_CMD_SYNC_TPT,
+ MLX4_CMD_TIME_CLASS_A, MLX4_CMD_NATIVE);
}
EXPORT_SYMBOL_GPL(mlx4_SYNC_TPT);
diff --git a/include/linux/mlx4/cmd.h b/include/linux/mlx4/cmd.h
index c989442..ae95adc 100644
--- a/include/linux/mlx4/cmd.h
+++ b/include/linux/mlx4/cmd.h
@@ -165,9 +165,9 @@ enum {
};
enum {
- MLX4_CMD_TIME_CLASS_A = 10000,
- MLX4_CMD_TIME_CLASS_B = 10000,
- MLX4_CMD_TIME_CLASS_C = 10000,
+ MLX4_CMD_TIME_CLASS_A = 60000,
+ MLX4_CMD_TIME_CLASS_B = 60000,
+ MLX4_CMD_TIME_CLASS_C = 60000,
};
enum {
--
1.9.3
^ permalink raw reply related
* [PATCH net-next V1 00/11] Mellanox ethernet driver updates Jan-27-2015
From: Amir Vadai @ 2015-01-27 13:57 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Or Gerlitz, Amir Vadai, Yevgeny Petrilin
Hi,
This patchset introduces some bug fixes, code cleanups and support in a new
firmware event called recoverable error events.
Patches were applied and tested against commit b8665c6 ("net: dsa/mv88e6352:
make mv88e6352_wait generic")
Changes from V0:
- Patch 6/11 ("net/mlx4_core: Fix struct mlx4_vhcr_cmd to make implicit padding
explicit"):
- Removed __packed
- Rephrased commit message
- Added a new patch by Majd ("net/mlx4_core: Update the HCA core clock frequency
after INIT_PORT")
Thanks,
Amir
Jack Morgenstein (7):
net/mlx4_core: Add bad-cable event support
net/mlx4_core: Add reserved lkey for VFs to QUERY_FUNC_CAP
net/mlx4_core: Fix mem leak in SRIOV mlx4_init_one error flow
net/mlx4_core: Adjust command timeouts to conform to the firmware spec
net/mlx4_core: Fix HW2SW_EQ to conform to the firmware spec
net/mlx4_core: Fix struct mlx4_vhcr_cmd to make implicit padding
explicit
net/mlx4_core: Remove duplicate code line from procedure mlx4_bf_alloc
Majd Dibbiny (1):
net/mlx4_core: Update the HCA core clock frequency after INIT_PORT
Matan Barak (1):
net/mlx4: Fix memory corruption in mlx4_MAD_IFC_wrapper
Or Gerlitz (1):
net/mlx4_core: Fix device capabilities dumping
Saeed Mahameed (1):
net/mlx4_en: Use ethtool cmd->autoneg as a hint for ethtool set
settings
drivers/net/ethernet/mellanox/mlx4/cmd.c | 6 +-
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 18 ++---
drivers/net/ethernet/mellanox/mlx4/eq.c | 48 ++++++------
drivers/net/ethernet/mellanox/mlx4/fw.c | 88 +++++++++++++++++-----
drivers/net/ethernet/mellanox/mlx4/fw.h | 1 +
drivers/net/ethernet/mellanox/mlx4/main.c | 5 +-
drivers/net/ethernet/mellanox/mlx4/mlx4.h | 1 +
drivers/net/ethernet/mellanox/mlx4/mr.c | 4 +-
drivers/net/ethernet/mellanox/mlx4/pd.c | 1 -
.../net/ethernet/mellanox/mlx4/resource_tracker.c | 16 +---
include/linux/mlx4/cmd.h | 6 +-
include/linux/mlx4/device.h | 14 +++-
12 files changed, 136 insertions(+), 72 deletions(-)
--
1.9.3
^ permalink raw reply
* [PATCH net-next V1 05/11] net/mlx4_core: Fix HW2SW_EQ to conform to the firmware spec
From: Amir Vadai @ 2015-01-27 13:58 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Amir Vadai, Yevgeny Petrilin,
Jack Morgenstein
In-Reply-To: <1422367089-13419-1-git-send-email-amirv@mellanox.com>
From: Jack Morgenstein <jackm@dev.mellanox.co.il>
The driver incorrectly assigned an out-mailbox to this command,
and used an opcode modifier = 0, which is a reserved value (it
should use opcode modifier = 1).
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/cmd.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/eq.c | 26 ++++------------------
.../net/ethernet/mellanox/mlx4/resource_tracker.c | 16 ++++---------
3 files changed, 9 insertions(+), 35 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/cmd.c b/drivers/net/ethernet/mellanox/mlx4/cmd.c
index 2b48932..928b706 100644
--- a/drivers/net/ethernet/mellanox/mlx4/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c
@@ -1221,7 +1221,7 @@ static struct mlx4_cmd_info cmd_info[] = {
{
.opcode = MLX4_CMD_HW2SW_EQ,
.has_inbox = false,
- .has_outbox = true,
+ .has_outbox = false,
.out_is_imm = false,
.encode_slave_id = true,
.verify = NULL,
diff --git a/drivers/net/ethernet/mellanox/mlx4/eq.c b/drivers/net/ethernet/mellanox/mlx4/eq.c
index 4df006d..264bc15 100644
--- a/drivers/net/ethernet/mellanox/mlx4/eq.c
+++ b/drivers/net/ethernet/mellanox/mlx4/eq.c
@@ -868,12 +868,10 @@ static int mlx4_SW2HW_EQ(struct mlx4_dev *dev, struct mlx4_cmd_mailbox *mailbox,
MLX4_CMD_WRAPPED);
}
-static int mlx4_HW2SW_EQ(struct mlx4_dev *dev, struct mlx4_cmd_mailbox *mailbox,
- int eq_num)
+static int mlx4_HW2SW_EQ(struct mlx4_dev *dev, int eq_num)
{
- return mlx4_cmd_box(dev, 0, mailbox->dma, eq_num,
- 0, MLX4_CMD_HW2SW_EQ, MLX4_CMD_TIME_CLASS_A,
- MLX4_CMD_WRAPPED);
+ return mlx4_cmd(dev, 0, eq_num, 1, MLX4_CMD_HW2SW_EQ,
+ MLX4_CMD_TIME_CLASS_A, MLX4_CMD_WRAPPED);
}
static int mlx4_num_eq_uar(struct mlx4_dev *dev)
@@ -1046,7 +1044,6 @@ static void mlx4_free_eq(struct mlx4_dev *dev,
struct mlx4_eq *eq)
{
struct mlx4_priv *priv = mlx4_priv(dev);
- struct mlx4_cmd_mailbox *mailbox;
int err;
int i;
/* CX3 is capable of extending the CQE/EQE from 32 to 64 bytes, with
@@ -1054,24 +1051,10 @@ static void mlx4_free_eq(struct mlx4_dev *dev,
*/
int npages = PAGE_ALIGN(dev->caps.eqe_size * eq->nent) / PAGE_SIZE;
- mailbox = mlx4_alloc_cmd_mailbox(dev);
- if (IS_ERR(mailbox))
- return;
-
- err = mlx4_HW2SW_EQ(dev, mailbox, eq->eqn);
+ err = mlx4_HW2SW_EQ(dev, eq->eqn);
if (err)
mlx4_warn(dev, "HW2SW_EQ failed (%d)\n", err);
- if (0) {
- mlx4_dbg(dev, "Dumping EQ context %02x:\n", eq->eqn);
- for (i = 0; i < sizeof (struct mlx4_eq_context) / 4; ++i) {
- if (i % 4 == 0)
- pr_cont("[%02x] ", i * 4);
- pr_cont(" %08x", be32_to_cpup(mailbox->buf + i * 4));
- if ((i + 1) % 4 == 0)
- pr_cont("\n");
- }
- }
synchronize_irq(eq->irq);
tasklet_disable(&eq->tasklet_ctx.task);
@@ -1083,7 +1066,6 @@ static void mlx4_free_eq(struct mlx4_dev *dev,
kfree(eq->page_list);
mlx4_bitmap_free(&priv->eq_table.bitmap, eq->eqn, MLX4_USE_RR);
- mlx4_free_cmd_mailbox(dev, mailbox);
}
static void mlx4_free_irqs(struct mlx4_dev *dev)
diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
index 3e93879..79feeb6 100644
--- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
+++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
@@ -4677,7 +4677,6 @@ static void rem_slave_eqs(struct mlx4_dev *dev, int slave)
int state;
LIST_HEAD(tlist);
int eqn;
- struct mlx4_cmd_mailbox *mailbox;
err = move_all_busy(dev, slave, RES_EQ);
if (err)
@@ -4703,20 +4702,13 @@ static void rem_slave_eqs(struct mlx4_dev *dev, int slave)
break;
case RES_EQ_HW:
- mailbox = mlx4_alloc_cmd_mailbox(dev);
- if (IS_ERR(mailbox)) {
- cond_resched();
- continue;
- }
- err = mlx4_cmd_box(dev, slave, 0,
- eqn & 0xff, 0,
- MLX4_CMD_HW2SW_EQ,
- MLX4_CMD_TIME_CLASS_A,
- MLX4_CMD_NATIVE);
+ err = mlx4_cmd(dev, slave, eqn & 0xff,
+ 1, MLX4_CMD_HW2SW_EQ,
+ MLX4_CMD_TIME_CLASS_A,
+ MLX4_CMD_NATIVE);
if (err)
mlx4_dbg(dev, "rem_slave_eqs: failed to move slave %d eqs %d to SW ownership\n",
slave, eqn);
- mlx4_free_cmd_mailbox(dev, mailbox);
atomic_dec(&eq->mtt->ref_count);
state = RES_EQ_RESERVED;
break;
--
1.9.3
^ permalink raw reply related
* [PATCH net-next V1 10/11] net/mlx4_core: Fix device capabilities dumping
From: Amir Vadai @ 2015-01-27 13:58 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Or Gerlitz, Amir Vadai, Yevgeny Petrilin
In-Reply-To: <1422367089-13419-1-git-send-email-amirv@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
We are dumping device capabilities which are supported both by the
firmware and the driver. Align the array that holds the capability
strings with this practice.
Reported-by: Yuval Shaia <yuval.shaia@oracle.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/fw.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.c b/drivers/net/ethernet/mellanox/mlx4/fw.c
index 0c90d10..0ab81a9 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.c
@@ -84,13 +84,10 @@ static void dump_dev_cap_flags(struct mlx4_dev *dev, u64 flags)
[ 1] = "UC transport",
[ 2] = "UD transport",
[ 3] = "XRC transport",
- [ 4] = "reliable multicast",
- [ 5] = "FCoIB support",
[ 6] = "SRQ support",
[ 7] = "IPoIB checksum offload",
[ 8] = "P_Key violation counter",
[ 9] = "Q_Key violation counter",
- [10] = "VMM",
[12] = "Dual Port Different Protocol (DPDP) support",
[15] = "Big LSO headers",
[16] = "MW support",
@@ -99,12 +96,11 @@ static void dump_dev_cap_flags(struct mlx4_dev *dev, u64 flags)
[19] = "Raw multicast support",
[20] = "Address vector port checking support",
[21] = "UD multicast support",
- [24] = "Demand paging support",
- [25] = "Router support",
[30] = "IBoE support",
[32] = "Unicast loopback support",
[34] = "FCS header control",
- [38] = "Wake On LAN support",
+ [37] = "Wake On LAN (port1) support",
+ [38] = "Wake On LAN (port2) support",
[40] = "UDP RSS support",
[41] = "Unicast VEP steering support",
[42] = "Multicast VEP steering support",
--
1.9.3
^ permalink raw reply related
* [PATCH net-next V1 09/11] net/mlx4: Fix memory corruption in mlx4_MAD_IFC_wrapper
From: Amir Vadai @ 2015-01-27 13:58 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Amir Vadai, Yevgeny Petrilin, Matan Barak
In-Reply-To: <1422367089-13419-1-git-send-email-amirv@mellanox.com>
From: Matan Barak <matanb@mellanox.com>
Fix a memory corruption at mlx4_MAD_IFC_wrapper.
A table of size dev->caps.pkey_table_len[port]*sizeof(*table)
was allocated, but get_full_pkey_table() assumes that the number
of entries in the table is a multiplication of 32 (which isn't always
correct).
Fixes: 0a9a018 ('mlx4: MAD_IFC paravirtualization')
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/cmd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/cmd.c b/drivers/net/ethernet/mellanox/mlx4/cmd.c
index 928b706..154effb 100644
--- a/drivers/net/ethernet/mellanox/mlx4/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c
@@ -901,7 +901,9 @@ static int mlx4_MAD_IFC_wrapper(struct mlx4_dev *dev, int slave,
index = be32_to_cpu(smp->attr_mod);
if (port < 1 || port > dev->caps.num_ports)
return -EINVAL;
- table = kcalloc(dev->caps.pkey_table_len[port], sizeof *table, GFP_KERNEL);
+ table = kcalloc((dev->caps.pkey_table_len[port] / 32) + 1,
+ sizeof(*table) * 32, GFP_KERNEL);
+
if (!table)
return -ENOMEM;
/* need to get the full pkey table because the paravirtualized
--
1.9.3
^ permalink raw reply related
* [PATCH net-next V1 11/11] net/mlx4_core: Update the HCA core clock frequency after INIT_PORT
From: Amir Vadai @ 2015-01-27 13:58 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Amir Vadai, Yevgeny Petrilin, Majd Dibbiny
In-Reply-To: <1422367089-13419-1-git-send-email-amirv@mellanox.com>
From: Majd Dibbiny <majd@mellanox.com>
The firmware might change the hca core clock frequency after the driver
issues the INIT_PORT command. Therefore we need to query the new
value again and save in to the cached dev caps.
Fixes: ddd8a6c1 ('net/mlx4_core: Read HCA frequency and map internal clock')
Signed-off-by: Majd Dibbiny <majd@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/fw.c | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.c b/drivers/net/ethernet/mellanox/mlx4/fw.c
index 0ab81a9..dbabfae 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.c
@@ -1897,6 +1897,36 @@ out:
return err;
}
+static int mlx4_hca_core_clock_update(struct mlx4_dev *dev)
+{
+ struct mlx4_cmd_mailbox *mailbox;
+ __be32 *outbox;
+ int err;
+
+ mailbox = mlx4_alloc_cmd_mailbox(dev);
+ if (IS_ERR(mailbox)) {
+ mlx4_warn(dev, "hca_core_clock mailbox allocation failed\n");
+ return PTR_ERR(mailbox);
+ }
+ outbox = mailbox->buf;
+
+ err = mlx4_cmd_box(dev, 0, mailbox->dma, 0, 0,
+ MLX4_CMD_QUERY_HCA,
+ MLX4_CMD_TIME_CLASS_B,
+ !mlx4_is_slave(dev));
+ if (err) {
+ mlx4_warn(dev, "hca_core_clock update failed\n");
+ goto out;
+ }
+
+ MLX4_GET(dev->caps.hca_core_clock, outbox, QUERY_HCA_CORE_CLOCK_OFFSET);
+
+out:
+ mlx4_free_cmd_mailbox(dev, mailbox);
+
+ return err;
+}
+
/* for IB-type ports only in SRIOV mode. Checks that both proxy QP0
* and real QP0 are active, so that the paravirtualized QP0 is ready
* to operate */
@@ -2001,6 +2031,9 @@ int mlx4_INIT_PORT(struct mlx4_dev *dev, int port)
err = mlx4_cmd(dev, 0, port, 0, MLX4_CMD_INIT_PORT,
MLX4_CMD_TIME_CLASS_A, MLX4_CMD_WRAPPED);
+ if (!err)
+ mlx4_hca_core_clock_update(dev);
+
return err;
}
EXPORT_SYMBOL_GPL(mlx4_INIT_PORT);
--
1.9.3
^ permalink raw reply related
* [PATCH net-next V1 01/11] net/mlx4_core: Add bad-cable event support
From: Amir Vadai @ 2015-01-27 13:57 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Amir Vadai, Yevgeny Petrilin,
Jack Morgenstein
In-Reply-To: <1422367089-13419-1-git-send-email-amirv@mellanox.com>
From: Jack Morgenstein <jackm@dev.mellanox.co.il>
If the firmware can detect a bad cable, allow it to generate an
event, and print the problem in the log.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/eq.c | 22 ++++++++++++++++++++++
drivers/net/ethernet/mellanox/mlx4/fw.c | 9 ++++++++-
include/linux/mlx4/device.h | 14 +++++++++++++-
3 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/eq.c b/drivers/net/ethernet/mellanox/mlx4/eq.c
index 2f2e606..4df006d 100644
--- a/drivers/net/ethernet/mellanox/mlx4/eq.c
+++ b/drivers/net/ethernet/mellanox/mlx4/eq.c
@@ -88,6 +88,8 @@ static u64 get_async_ev_mask(struct mlx4_dev *dev)
u64 async_ev_mask = MLX4_ASYNC_EVENT_MASK;
if (dev->caps.flags & MLX4_DEV_CAP_FLAG_PORT_MNG_CHG_EV)
async_ev_mask |= (1ull << MLX4_EVENT_TYPE_PORT_MNG_CHG_EVENT);
+ if (dev->caps.flags2 & MLX4_DEV_CAP_FLAG2_RECOVERABLE_ERROR_EVENT)
+ async_ev_mask |= (1ull << MLX4_EVENT_TYPE_RECOVERABLE_ERROR_EVENT);
return async_ev_mask;
}
@@ -736,6 +738,26 @@ static int mlx4_eq_int(struct mlx4_dev *dev, struct mlx4_eq *eq)
(unsigned long) eqe);
break;
+ case MLX4_EVENT_TYPE_RECOVERABLE_ERROR_EVENT:
+ switch (eqe->subtype) {
+ case MLX4_RECOVERABLE_ERROR_EVENT_SUBTYPE_BAD_CABLE:
+ mlx4_warn(dev, "Bad cable detected on port %u\n",
+ eqe->event.bad_cable.port);
+ break;
+ case MLX4_RECOVERABLE_ERROR_EVENT_SUBTYPE_UNSUPPORTED_CABLE:
+ mlx4_warn(dev, "Unsupported cable detected\n");
+ break;
+ default:
+ mlx4_dbg(dev,
+ "Unhandled recoverable error event detected: %02x(%02x) on EQ %d at index %u. owner=%x, nent=0x%x, ownership=%s\n",
+ eqe->type, eqe->subtype, eq->eqn,
+ eq->cons_index, eqe->owner, eq->nent,
+ !!(eqe->owner & 0x80) ^
+ !!(eq->cons_index & eq->nent) ? "HW" : "SW");
+ break;
+ }
+ break;
+
case MLX4_EVENT_TYPE_EEC_CATAS_ERROR:
case MLX4_EVENT_TYPE_ECC_DETECT:
default:
diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.c b/drivers/net/ethernet/mellanox/mlx4/fw.c
index 982861d..2eadc28 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.c
@@ -145,7 +145,8 @@ static void dump_dev_cap_flags2(struct mlx4_dev *dev, u64 flags)
[16] = "CONFIG DEV support",
[17] = "Asymmetric EQs support",
[18] = "More than 80 VFs support",
- [19] = "Performance optimized for limited rule configuration flow steering support"
+ [19] = "Performance optimized for limited rule configuration flow steering support",
+ [20] = "Recoverable error events support"
};
int i;
@@ -859,6 +860,8 @@ int mlx4_QUERY_DEV_CAP(struct mlx4_dev *dev, struct mlx4_dev_cap *dev_cap)
MLX4_GET(field32, outbox, QUERY_DEV_CAP_ETH_BACKPL_OFFSET);
if (field32 & (1 << 0))
dev_cap->flags2 |= MLX4_DEV_CAP_FLAG2_ETH_BACKPL_AN_REP;
+ if (field32 & (1 << 7))
+ dev_cap->flags2 |= MLX4_DEV_CAP_FLAG2_RECOVERABLE_ERROR_EVENT;
MLX4_GET(field, outbox, QUERY_DEV_CAP_FW_REASSIGN_MAC);
if (field & 1<<6)
dev_cap->flags2 |= MLX4_DEV_CAP_FLAG2_REASSIGN_MAC_EN;
@@ -1562,6 +1565,7 @@ int mlx4_INIT_HCA(struct mlx4_dev *dev, struct mlx4_init_hca_param *param)
#define INIT_HCA_VXLAN_OFFSET 0x0c
#define INIT_HCA_CACHELINE_SZ_OFFSET 0x0e
#define INIT_HCA_FLAGS_OFFSET 0x014
+#define INIT_HCA_RECOVERABLE_ERROR_EVENT_OFFSET 0x018
#define INIT_HCA_QPC_OFFSET 0x020
#define INIT_HCA_QPC_BASE_OFFSET (INIT_HCA_QPC_OFFSET + 0x10)
#define INIT_HCA_LOG_QP_OFFSET (INIT_HCA_QPC_OFFSET + 0x17)
@@ -1668,6 +1672,9 @@ int mlx4_INIT_HCA(struct mlx4_dev *dev, struct mlx4_init_hca_param *param)
dev->caps.userspace_caps |= MLX4_USER_DEV_CAP_LARGE_CQE;
}
+ if (dev->caps.flags2 & MLX4_DEV_CAP_FLAG2_RECOVERABLE_ERROR_EVENT)
+ *(inbox + INIT_HCA_RECOVERABLE_ERROR_EVENT_OFFSET / 4) |= cpu_to_be32(1 << 31);
+
/* QPC/EEC/CQC/EQC/RDMARC attributes */
MLX4_PUT(inbox, param->qpc_base, INIT_HCA_QPC_BASE_OFFSET);
diff --git a/include/linux/mlx4/device.h b/include/linux/mlx4/device.h
index 5ef54e1..c95d659 100644
--- a/include/linux/mlx4/device.h
+++ b/include/linux/mlx4/device.h
@@ -200,7 +200,8 @@ enum {
MLX4_DEV_CAP_FLAG2_CONFIG_DEV = 1LL << 16,
MLX4_DEV_CAP_FLAG2_SYS_EQS = 1LL << 17,
MLX4_DEV_CAP_FLAG2_80_VFS = 1LL << 18,
- MLX4_DEV_CAP_FLAG2_FS_A0 = 1LL << 19
+ MLX4_DEV_CAP_FLAG2_FS_A0 = 1LL << 19,
+ MLX4_DEV_CAP_FLAG2_RECOVERABLE_ERROR_EVENT = 1LL << 20
};
enum {
@@ -280,6 +281,7 @@ enum mlx4_event {
MLX4_EVENT_TYPE_FATAL_WARNING = 0x1b,
MLX4_EVENT_TYPE_FLR_EVENT = 0x1c,
MLX4_EVENT_TYPE_PORT_MNG_CHG_EVENT = 0x1d,
+ MLX4_EVENT_TYPE_RECOVERABLE_ERROR_EVENT = 0x3e,
MLX4_EVENT_TYPE_NONE = 0xff,
};
@@ -289,6 +291,11 @@ enum {
};
enum {
+ MLX4_RECOVERABLE_ERROR_EVENT_SUBTYPE_BAD_CABLE = 1,
+ MLX4_RECOVERABLE_ERROR_EVENT_SUBTYPE_UNSUPPORTED_CABLE = 2,
+};
+
+enum {
MLX4_FATAL_WARNING_SUBTYPE_WARMING = 0,
};
@@ -860,6 +867,11 @@ struct mlx4_eqe {
} __packed tbl_change_info;
} params;
} __packed port_mgmt_change;
+ struct {
+ u8 reserved[3];
+ u8 port;
+ u32 reserved1[5];
+ } __packed bad_cable;
} event;
u8 slave_id;
u8 reserved3[2];
--
1.9.3
^ permalink raw reply related
* [PATCH net-next V1 02/11] net/mlx4_core: Add reserved lkey for VFs to QUERY_FUNC_CAP
From: Amir Vadai @ 2015-01-27 13:58 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Amir Vadai, Yevgeny Petrilin,
Jack Morgenstein
In-Reply-To: <1422367089-13419-1-git-send-email-amirv@mellanox.com>
From: Jack Morgenstein <jackm@dev.mellanox.co.il>
The reserved lKey is different for each VF.
A base lkey value is returned in QUERY_DEV_CAP at offset 0x98.
The reserved L_key value for a VF is:
VF_lkey = base_lkey + (VF_number << 8).
This VF L_key value should be returned in QUERY_FUNC_CAP
(opcode-modifier = 0) at offset 0x48.
To indicate that the lkey value at offset 0x48 is valid, the Hypervisor
sets a flag bit in dword 0x0, offset 27 in the QUERY_FUNC_CAP wrapper
function.
When the VF calls QUERY_FUNC_CAP, it should check if this flag bit is set.
If it is set, the VF should take the reserved lkey value at offset 0x48.
If the bit is not set, the VF should not use a reserved lkey
(i.e., should set its reserved lkey value to 0).
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/fw.c | 19 +++++++++++++++++--
drivers/net/ethernet/mellanox/mlx4/fw.h | 1 +
drivers/net/ethernet/mellanox/mlx4/main.c | 1 +
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.c b/drivers/net/ethernet/mellanox/mlx4/fw.c
index 2eadc28..2aa7c23 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.c
@@ -260,6 +260,7 @@ int mlx4_QUERY_FUNC_CAP_wrapper(struct mlx4_dev *dev, int slave,
#define QUERY_FUNC_CAP_MCG_QUOTA_OFFSET_DEP 0x28
#define QUERY_FUNC_CAP_MAX_EQ_OFFSET 0x2c
#define QUERY_FUNC_CAP_RESERVED_EQ_OFFSET 0x30
+#define QUERY_FUNC_CAP_QP_RESD_LKEY_OFFSET 0x48
#define QUERY_FUNC_CAP_QP_QUOTA_OFFSET 0x50
#define QUERY_FUNC_CAP_CQ_QUOTA_OFFSET 0x54
@@ -274,6 +275,7 @@ int mlx4_QUERY_FUNC_CAP_wrapper(struct mlx4_dev *dev, int slave,
#define QUERY_FUNC_CAP_FLAG_RDMA 0x40
#define QUERY_FUNC_CAP_FLAG_ETH 0x80
#define QUERY_FUNC_CAP_FLAG_QUOTAS 0x10
+#define QUERY_FUNC_CAP_FLAG_RESD_LKEY 0x08
#define QUERY_FUNC_CAP_FLAG_VALID_MAILBOX 0x04
#define QUERY_FUNC_CAP_EXTRA_FLAGS_BF_QP_ALLOC_FLAG (1UL << 31)
@@ -345,9 +347,12 @@ int mlx4_QUERY_FUNC_CAP_wrapper(struct mlx4_dev *dev, int slave,
} else if (vhcr->op_modifier == 0) {
struct mlx4_active_ports actv_ports =
mlx4_get_active_ports(dev, slave);
- /* enable rdma and ethernet interfaces, and new quota locations */
+ /* enable rdma and ethernet interfaces, new quota locations,
+ * and reserved lkey
+ */
field = (QUERY_FUNC_CAP_FLAG_ETH | QUERY_FUNC_CAP_FLAG_RDMA |
- QUERY_FUNC_CAP_FLAG_QUOTAS | QUERY_FUNC_CAP_FLAG_VALID_MAILBOX);
+ QUERY_FUNC_CAP_FLAG_QUOTAS | QUERY_FUNC_CAP_FLAG_VALID_MAILBOX |
+ QUERY_FUNC_CAP_FLAG_RESD_LKEY);
MLX4_PUT(outbox->buf, field, QUERY_FUNC_CAP_FLAGS_OFFSET);
field = min(
@@ -412,6 +417,9 @@ int mlx4_QUERY_FUNC_CAP_wrapper(struct mlx4_dev *dev, int slave,
size = QUERY_FUNC_CAP_EXTRA_FLAGS_BF_QP_ALLOC_FLAG |
QUERY_FUNC_CAP_EXTRA_FLAGS_A0_QP_ALLOC_FLAG;
MLX4_PUT(outbox->buf, size, QUERY_FUNC_CAP_EXTRA_FLAGS_OFFSET);
+
+ size = dev->caps.reserved_lkey + ((slave << 8) & 0xFF00);
+ MLX4_PUT(outbox->buf, size, QUERY_FUNC_CAP_QP_RESD_LKEY_OFFSET);
} else
err = -EINVAL;
@@ -504,6 +512,13 @@ int mlx4_QUERY_FUNC_CAP(struct mlx4_dev *dev, u8 gen_or_port,
MLX4_GET(size, outbox, QUERY_FUNC_CAP_RESERVED_EQ_OFFSET);
func_cap->reserved_eq = size & 0xFFFFFF;
+ if (func_cap->flags & QUERY_FUNC_CAP_FLAG_RESD_LKEY) {
+ MLX4_GET(size, outbox, QUERY_FUNC_CAP_QP_RESD_LKEY_OFFSET);
+ func_cap->reserved_lkey = size;
+ } else {
+ func_cap->reserved_lkey = 0;
+ }
+
func_cap->extra_flags = 0;
/* Mailbox data from 0x6c and onward should only be treated if
diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.h b/drivers/net/ethernet/mellanox/mlx4/fw.h
index 62562b6..f44f7f6 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.h
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.h
@@ -147,6 +147,7 @@ struct mlx4_func_cap {
u32 qp0_proxy_qpn;
u32 qp1_tunnel_qpn;
u32 qp1_proxy_qpn;
+ u32 reserved_lkey;
u8 physical_port;
u8 port_flags;
u8 flags1;
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index 9c7ef0b..46531c2 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -797,6 +797,7 @@ static int mlx4_slave_cap(struct mlx4_dev *dev)
dev->caps.num_mpts = 1 << hca_param.log_mpt_sz;
dev->caps.num_eqs = func_cap.max_eq;
dev->caps.reserved_eqs = func_cap.reserved_eq;
+ dev->caps.reserved_lkey = func_cap.reserved_lkey;
dev->caps.num_pds = MLX4_NUM_PDS;
dev->caps.num_mgms = 0;
dev->caps.num_amgms = 0;
--
1.9.3
^ permalink raw reply related
* [PATCH net-next V1 07/11] net/mlx4_core: Remove duplicate code line from procedure mlx4_bf_alloc
From: Amir Vadai @ 2015-01-27 13:58 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Amir Vadai, Yevgeny Petrilin,
Jack Morgenstein
In-Reply-To: <1422367089-13419-1-git-send-email-amirv@mellanox.com>
From: Jack Morgenstein <jackm@dev.mellanox.co.il>
mlx4_bf_alloc had an unnecessary/duplicate code line. Did no harm,
but not good practice.
Reported by the Mellanox Beijing team.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/pd.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/pd.c b/drivers/net/ethernet/mellanox/mlx4/pd.c
index a42b4c0..609c59d 100644
--- a/drivers/net/ethernet/mellanox/mlx4/pd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/pd.c
@@ -214,7 +214,6 @@ int mlx4_bf_alloc(struct mlx4_dev *dev, struct mlx4_bf *bf, int node)
list_add(&uar->bf_list, &priv->bf_list);
}
- bf->uar = uar;
idx = ffz(uar->free_bf_bmap);
uar->free_bf_bmap |= 1 << idx;
bf->uar = uar;
--
1.9.3
^ permalink raw reply related
* [PATCH net-next V1 08/11] net/mlx4_en: Use ethtool cmd->autoneg as a hint for ethtool set settings
From: Amir Vadai @ 2015-01-27 13:58 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Amir Vadai, Yevgeny Petrilin, Saeed Mahameed
In-Reply-To: <1422367089-13419-1-git-send-email-amirv@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Use cmd->autoneg as a user hint to decide what to set in ethtool set settings callback.
When cmd->autoneg == AUTONEG_ENABLE set according to ethtool->advertise otherwise,
set according to ethtool->speed.
Usage:
- ethtool -s eth<x> speed 56000 autoneg off
- ethtool -s eth<x> advertise 0x800000 autoneg on
While we're here:
- Move proto_admin masking outcome check to be adjacent to the operation.
- Move en_warn("port reset..") print to "port reset" block.
Fixes: 312df74 ("net/mlx4_en: mlx4_en_set_settings() always fails when autoneg is set")
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
index 569eda9..a7b58ba 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
@@ -770,22 +770,20 @@ static int mlx4_en_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
return 0;
}
- proto_admin = cpu_to_be32(ptys_adv);
- if (speed >= 0 && speed != priv->port_state.link_speed)
- /* If speed was set then speed decides :-) */
- proto_admin = speed_set_ptys_admin(priv, speed,
- ptys_reg.eth_proto_cap);
+ proto_admin = cmd->autoneg == AUTONEG_ENABLE ?
+ cpu_to_be32(ptys_adv) :
+ speed_set_ptys_admin(priv, speed,
+ ptys_reg.eth_proto_cap);
proto_admin &= ptys_reg.eth_proto_cap;
-
- if (proto_admin == ptys_reg.eth_proto_admin)
- return 0; /* Nothing to change */
-
if (!proto_admin) {
en_warn(priv, "Not supported link mode(s) requested, check supported link modes.\n");
return -EINVAL; /* nothing to change due to bad input */
}
+ if (proto_admin == ptys_reg.eth_proto_admin)
+ return 0; /* Nothing to change */
+
en_dbg(DRV, priv, "mlx4_ACCESS_PTYS_REG SET: ptys_reg.eth_proto_admin = 0x%x\n",
be32_to_cpu(proto_admin));
@@ -798,9 +796,9 @@ static int mlx4_en_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
return ret;
}
- en_warn(priv, "Port link mode changed, restarting port...\n");
mutex_lock(&priv->mdev->state_lock);
if (priv->port_up) {
+ en_warn(priv, "Port link mode changed, restarting port...\n");
mlx4_en_stop_port(dev, 1);
if (mlx4_en_start_port(dev))
en_err(priv, "Failed restarting port %d\n", priv->port);
--
1.9.3
^ permalink raw reply related
* [PATCH net-next V1 06/11] net/mlx4_core: Fix struct mlx4_vhcr_cmd to make implicit padding explicit
From: Amir Vadai @ 2015-01-27 13:58 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Amir Vadai, Yevgeny Petrilin,
Jack Morgenstein
In-Reply-To: <1422367089-13419-1-git-send-email-amirv@mellanox.com>
From: Jack Morgenstein <jackm@dev.mellanox.co.il>
Struct mlx4_vhcr was implicitly padded by the gcc compiler on 64-bit
architectures.
This commit makes that padding explicit, to prevent issues with
changing compilers and with incompatibilities between 32-bit architecture
implicit padding and 64-bit architecture implicit padding.
This structure is used in virtualization for communication between
the Host and its Guests. The explicit padding allows 64-bit Hosts
(old and new) to continue to interoperate with 64-bit Guests (old and new).
However, without this fix, 64-bit Hosts could not interoperate with 32-bit
Guests (since these did not insert the padding dword). With this fix,
32-bit Guests will be able to interoperate with 64-bit Hosts (since
the structure offsets will be identical on both).
Reported-by: Alexander Schmidt <alexs@linux.vnet.ibm.com>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/mlx4.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4.h b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
index 096a81c..148dc09 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
@@ -196,6 +196,7 @@ struct mlx4_vhcr {
struct mlx4_vhcr_cmd {
__be64 in_param;
__be32 in_modifier;
+ u32 reserved1;
__be64 out_param;
__be16 token;
u16 reserved;
--
1.9.3
^ 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