Re: [net-next PATCH v3] udp: Resolve NULL pointer dereference over flow-based vxlan device

From: Alexander Duyck Date: Thu, 12 May 2016 16:23:44 -0700 > While testing an OpenStack configuration using VXLANs I saw the following > call trace: ... > The following trace is seen when receiving a DHCP request over a flow-based > VXLAN tunnel. I believe this is caused

[PATCH] ixgbe: take online CPU number as MQ max limit when alloc_etherdev_mq()

Allocating 64 Tx/Rx as default doesn't benefit perfomrnace when less CPUs were assigned. especially when DCB is enabled, so we should take num_online_cpus() as top limit, and aslo to make sure every TC has at least one queue, take the MAX_TRAFFIC_CLASS as bottom limit of queues number.

Re: [PATCH net-next] sunrpc: set SOCK_FASYNC

From: Eric Dumazet Date: Thu, 12 May 2016 21:41:39 -0700 > From: Eric Dumazet > > sunrpc is using SOCKWQ_ASYNC_NOSPACE without setting SOCK_FASYNC, > so the recent optimizations done in sk_set_bit() and sk_clear_bit() > broke it. > > There is still

[PATCH net-next] sock: ignore TIMESTAMP, RXQ_OVFL, WIFI_STATUS in sock_cmsg_send

From: Soheil Hassas Yeganeh SO_TIMESTAMP(NS), RXQ_OVFL, and WIFI_STATUS can be returned as receive-side control messages from recvmsg(). Although invalid, some applications may reflect those receive-side control messages back to sendmsg(). Since socket-level control messages

Re: [net-next PATCH v3] udp: Resolve NULL pointer dereference over flow-based vxlan device

On Thu, 2016-05-12 at 16:23 -0700, Alexander Duyck wrote: > While testing an OpenStack configuration using VXLANs I saw the following > call trace: > The following trace is seen when receiving a DHCP request over a flow-based > VXLAN tunnel. I believe this is caused by the metadata dst having a

[PATCH net-next] sunrpc: set SOCK_FASYNC

From: Eric Dumazet sunrpc is using SOCKWQ_ASYNC_NOSPACE without setting SOCK_FASYNC, so the recent optimizations done in sk_set_bit() and sk_clear_bit() broke it. There is still the risk that a subsequent sock_fasync() call would clear SOCK_FASYNC, but sunrpc does not use

Re: [PATCH net-next 06/13] ipv6: Fix nexthdr for reinjection

Hi Tom, On Thu, 12 May 2016 14:45:36 -0700 Tom Herbert wrote: > On Thu, May 12, 2016 at 1:23 PM, Shmulik Ladkani > wrote: > > On Wed, 11 May 2016 09:47:26 -0700 Tom Herbert > > wrote: > >> In ip6_input_finish the

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

> >>+ gpiod = fwnode_get_named_gpiod(>fwnode, "reset-gpios"); > >>+ /* Deassert the reset signal */ > >>+ if (!IS_ERR(gpiod)) > >>+ gpiod_direction_output(gpiod, 0); > > > >This is wrong I think. You must only ignore -ENODEV, all other error > >At least -ENOSYS should also be

Re: [PATCH] cfg80211/nl80211: add wifi tx power mode switching support

On Fri, May 13, 2016 at 6:02 AM, Arend van Spriel wrote: > On 12-05-16 11:34, Wei-Ning Huang wrote: >> On Thu, May 12, 2016 at 2:33 AM, Dan Williams wrote: >>> On Wed, 2016-05-11 at 13:03 +0800, Wei-Ning Huang wrote: On Fri, May 6, 2016 at 4:19

Re: [PATCHv2 bluetooth-next 00/10] 6lowpan: introduce basic 6lowpan-nd

Hi, Marcel Holtmann wrote: > Hi Dave, : >> include/linux/netdevice.h | 6 +- >> include/net/6lowpan.h | 24 ++ >> include/net/addrconf.h| 3 + >> include/net/ndisc.h | 124 - >> net/6lowpan/6lowpan_i.h | 2 + >> net/6lowpan/Makefile | 2 +-

[PATCH v2 net-next 0/2] Enable SW only or HW only offloads with u32 classifier

This set of patches export TCA_CLS_FLAGS_SKIP_HW to userspace and also introduces another flag TCA_CLS_FLAGS_SKIP_SW. These flags enable offloading u32 filters to either SW or HW only. The default semantics with no flags is to add the filter to HW if possible and also into SW. With SKIP_HW

[PATCH v2 net-next 1/2] net: sched: Move TCA_CLS_FLAGS_SKIP_HW to uapi header file.

Signed-off-by: Sridhar Samudrala --- include/net/pkt_cls.h| 3 --- include/uapi/linux/pkt_cls.h | 3 +++ 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h index caa5e18..339ef08 100644 ---

[PATCH v2 net-next 2/2] net: cls_u32: Add support for skip-sw flag to tc u32 classifier.

On devices that support TC U32 offloads, this flag enables a filter to be added only to HW. skip-sw and skip-hw are mutually exclusive flags. By default without any flags, the filter is added to both HW and SW, but no error checks are done in case of failure to add to HW. With skip-sw, failure to

[net-next PATCH v3] udp: Resolve NULL pointer dereference over flow-based vxlan device

While testing an OpenStack configuration using VXLANs I saw the following call trace: RIP: 0010:[] udp4_lib_lookup_skb+0x49/0x80 RSP: 0018:88103867bc50 EFLAGS: 00010286 RAX: 88103269bf00 RBX: 88103269bf00 RCX: RDX: 4300 RSI: RDI:

r8169 bug report

Hi Devs, I have the following system: Ubuntu 14.04.4 with the latest kernel 3.13.0-86-generic (x86_64), it has an MSI Z87-G55 motherboard with the latest BIOS (v10.7), there is the Realtek 8111G NIC on it, which is handled by the r8169 module by default. I had the following issue: 1. I woke the

Re: [patch net-next 1/4] netdevice: add SW statistics ndo

2016-05-12 14:10 GMT-07:00 Roopa Prabhu : > On 5/12/16, 4:48 AM, Jiri Pirko wrote: >> From: Nogah Frankel >> >> Till now we had a ndo statistics function that returned SW statistics. >> We want to change the "basic" statistics to return HW

Re: [PATCH] cfg80211/nl80211: add wifi tx power mode switching support

On 12-05-16 11:34, Wei-Ning Huang wrote: > On Thu, May 12, 2016 at 2:33 AM, Dan Williams wrote: >> On Wed, 2016-05-11 at 13:03 +0800, Wei-Ning Huang wrote: >>> On Fri, May 6, 2016 at 4:19 PM, Wei-Ning Huang >>> wrote: On Fri, May 6, 2016 at 12:07

Re: [PATCH net-next 06/13] ipv6: Fix nexthdr for reinjection

On Thu, May 12, 2016 at 1:23 PM, Shmulik Ladkani wrote: > Hi Tom, > > On Wed, 11 May 2016 09:47:26 -0700 Tom Herbert wrote: >> In ip6_input_finish the protocol handle returns a value greater than >> zero the packet needs to be resubmitted using

Re: [PATCH] phy: add support for a reset-gpio specification

On 05/12/2016 01:00 PM, Uwe Kleine-König wrote: The framework only asserts (for now) that the reset gpio is not active. Signed-off-by: Uwe Kleine-König --- Documentation/devicetree/bindings/net/phy.txt | 3 +++ drivers/net/phy/phy_device.c | 8

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/12/2016 09:42 PM, Uwe Kleine-König wrote: [we already talked about this patch in #armlinux, I'm now just forwarding my comments on the list. Background was that I sent an easier and less complete patch with the same idea. See http://patchwork.ozlabs.org/patch/621418/] [added

Re: [PATCH net-next 1/1] tipc: eliminate risk of double link_up events

From: Jon Maloy Date: Wed, 11 May 2016 19:15:45 -0400 > When an ACTIVATE or data packet is received in a link in state > ESTABLISHING, the link does not immediately change state to > ESTABLISHED, but does instead return a LINK_UP event to the caller, > which will execute

Re: [patch net-next 1/4] netdevice: add SW statistics ndo

On 5/12/16, 4:48 AM, Jiri Pirko wrote: > From: Nogah Frankel > > Till now we had a ndo statistics function that returned SW statistics. > We want to change the "basic" statistics to return HW statistics if > available. > In this case we need to expose a new ndo to return the

Re: [PATCH] r8169: default to 64-bit DMA on systems without memory below 4 GB

Francois Romieu : > Ard Biesheuvel : > > On 12 May 2016 at 16:09, Francois Romieu wrote: > [...] > > By resurrecting 353176888386, I mean the patch that changes the > > default for PCI express devices, so I think we are in

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Thu, 2016-05-12 at 22:58 +0200, Paolo Abeni wrote: > On Thu, 2016-05-12 at 13:49 -0700, Eric Dumazet wrote: > > On Thu, 2016-05-12 at 22:07 +0200, Paolo Abeni wrote: > > > > > > > static inline bool ksoftirqd_running(void) > > > > > { > > > > > return __this_cpu_read(ksoftirqd)->state ==

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Thu, 2016-05-12 at 13:49 -0700, Eric Dumazet wrote: > On Thu, 2016-05-12 at 22:07 +0200, Paolo Abeni wrote: > > > > > static inline bool ksoftirqd_running(void) > > > > { > > > > return __this_cpu_read(ksoftirqd)->state == TASK_RUNNING; > > > > here something like: > > > > struct

Re: [PATCH] net: mvneta: bm: fix dependencies again

From: Arnd Bergmann Date: Wed, 11 May 2016 22:13:23 +0200 > I tried to fix this before, but my previous fix was incomplete > and we can still get the same link error in randconfig builds > because of the way that Kconfig treats the > > default y if MVNETA=y &&

Re: [PATCH net-next] phy: micrel: Use MICREL_PHY_ID_MASK definition

From: Fabio Estevam Date: Wed, 11 May 2016 17:02:05 -0300 > From: Fabio Estevam > > Replace the hardcoded mask 0x00f0 with MICREL_PHY_ID_MASK for > better readability. > > Suggested-by: Andrew Lunn > Signed-off-by: Fabio Estevam

Re: [net-next PATCH v2] udp: Resolve NULL pointer dereference over flow-based vxlan device

On Thu, 2016-05-12 at 13:27 -0700, Alexander Duyck wrote: > I'm assuming this was using skb_dst(skb)->dev in order to allow for > use of this function by other callers since the original function > __udp4_lib_lookup_skb was using that. If we change this then it > reduces the likelihood of the

Re: [PATCH 2/2] gre: Fix wrong tpi->proto in WCCP

From: Haishuang Yan Date: Wed, 11 May 2016 18:48:32 +0800 > When dealing with WCCP in gre6 tunnel, it sets the wrong tpi->protocol, > that is, ETH_P_IP instead of ETH_P_IPV6 for the encapuslated traffic. > > Signed-off-by: Haishuang Yan

Re: [PATCH 1/2] ip6_gre: Fix get_size calculation for gre6 tunnel

From: Haishuang Yan Date: Wed, 11 May 2016 18:48:31 +0800 > Do not include attribute IFLA_GRE_TOS. > > Signed-off-by: Haishuang Yan Applied.

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Thu, 2016-05-12 at 22:07 +0200, Paolo Abeni wrote: > > > static inline bool ksoftirqd_running(void) > > > { > > > return __this_cpu_read(ksoftirqd)->state == TASK_RUNNING; > > here something like: > > struct task_struct *tsk = __this_cpu_read(ksoftirqd); > return tsk &&

Re: [PATCH] r8169: default to 64-bit DMA on systems without memory below 4 GB

Ard Biesheuvel : > On 12 May 2016 at 16:09, Francois Romieu wrote: [...] > By resurrecting 353176888386, I mean the patch that changes the > default for PCI express devices, so I think we are in agreement here ? Almost 353176888386: please modify

Re: where is the ethernet device number determined?

On 05/12/2016 02:19 PM, Cong Wang wrote: On Thu, May 12, 2016 at 1:05 PM, Chris Friesen wrote: I hope this is a simple question...with legacy naming ethernet devices are named ethX. Where is that X determined? I've been looking in alloc_netdev_mqs() and friends, but

Re: [PATCH net-next 06/13] ipv6: Fix nexthdr for reinjection

Hi Tom, On Wed, 11 May 2016 09:47:26 -0700 Tom Herbert wrote: > In ip6_input_finish the protocol handle returns a value greater than > zero the packet needs to be resubmitted using the returned protocol. > The returned protocol is being ignored and each time through

Re: [net-next PATCH v2] udp: Resolve NULL pointer dereference over flow-based vxlan device

On Thu, May 12, 2016 at 12:55 PM, Eric Dumazet wrote: > On Thu, 2016-05-12 at 12:51 -0700, Alexander Duyck wrote: >> While testing an OpenStack configuration using VXLANs I saw the following >> call trace: > >> The following trace is seen when receiving a DHCP request over

Re: where is the ethernet device number determined?

On Thu, May 12, 2016 at 1:05 PM, Chris Friesen wrote: > > Hi, > > I hope this is a simple question...with legacy naming ethernet devices are > named ethX. Where is that X determined? I've been looking in > alloc_netdev_mqs() and friends, but haven't found it yet.

Re: [net-next PATCH v2] udp: Resolve NULL pointer dereference over flow-based vxlan device

On Thu, May 12, 2016 at 1:02 PM, Cong Wang wrote: > On Thu, May 12, 2016 at 12:51 PM, Alexander Duyck wrote: >> The following trace is seen when receiving a DHCP request over a flow-based >> VXLAN tunnel. I believe this is caused by the metadata

where is the ethernet device number determined?

Hi, I hope this is a simple question...with legacy naming ethernet devices are named ethX. Where is that X determined? I've been looking in alloc_netdev_mqs() and friends, but haven't found it yet. Thanks, Chris

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Wed, 2016-05-11 at 14:56 -0700, Eric Dumazet wrote: > On Wed, 2016-05-11 at 08:55 +0200, Peter Zijlstra wrote: > > On Tue, May 10, 2016 at 03:51:37PM -0700, Eric Dumazet wrote: > > > diff --git a/kernel/softirq.c b/kernel/softirq.c > > > index 17caf4b63342..22463217e3cf 100644 > > > ---

Re: [net-next PATCH v2] udp: Resolve NULL pointer dereference over flow-based vxlan device

On Thu, May 12, 2016 at 12:51 PM, Alexander Duyck wrote: > The following trace is seen when receiving a DHCP request over a flow-based > VXLAN tunnel. I believe this is caused by the metadata dst having a NULL > dev value and as a result dev_net(dev) is causing a NULL

Re: [net-next PATCH v2] udp: Resolve NULL pointer dereference over flow-based vxlan device

On Thu, 2016-05-12 at 12:51 -0700, Alexander Duyck wrote: > While testing an OpenStack configuration using VXLANs I saw the following > call trace: > The following trace is seen when receiving a DHCP request over a flow-based > VXLAN tunnel. I believe this is caused by the metadata dst having a

[net-next PATCH v2] udp: Resolve NULL pointer dereference over flow-based vxlan device

While testing an OpenStack configuration using VXLANs I saw the following call trace: RIP: 0010:[] udp4_lib_lookup_skb+0x49/0x80 RSP: 0018:88103867bc50 EFLAGS: 00010286 RAX: 88103269bf00 RBX: 88103269bf00 RCX: RDX: 4300 RSI: RDI:

Re: [PATCH net-next 4/5] treewide: replace dev->trans_start update with helper

On 05/03/2016 10:33 AM, Florian Westphal wrote: > Replace all trans_start updates with netif_trans_update helper. > change was done via spatch: > > struct net_device *d; > @@ > - d->trans_start = jiffies > + netif_trans_update(d) > > Compile tested only. > > Cc:

Re: [PATCH net-next 2/5] drivers: replace dev->trans_start accesses with dev_trans_start

On 05/03/2016 10:30 AM, Florian Westphal wrote: > a trans_start struct member exists twice: > - in struct net_device (legacy) > - in struct netdev_queue > > Instead of open-coding dev->trans_start usage to obtain the current > trans_start value, use dev_trans_start() instead. > > This is not

[RFC] wcn36xx: Implement firmware assisted scan

Using the software based channel scan mechanism from mac80211 keeps us offline for 10-15 second, we should instead issue a start_scan/end_scan on each channel reducing this time. Signed-off-by: Bjorn Andersson --- With this implementation I see a reduction of

Re: [PATCH net-next] gtp: put back reference to netns when not required anymore

From: Pablo Neira Ayuso Date: Thu, 12 May 2016 17:16:31 +0200 > This patch fixes a netns leak. > > Fixes: 93edb8c7f94f ("gtp: reload GTPv1 header after pskb_may_pull()") > Reported-by: Cong Wang > Signed-off-by: Pablo Neira Ayuso

Re: [PATCH net-next v2 00/14] qed*: Add SR-IOV support

From: Yuval Mintz Date: Wed, 11 May 2016 16:36:11 +0300 > This patch adds SR-IOV support to qed/qede drivers, adding a new PCI > device ID for a VF that is shared between all the various PFs that > support IOV. Series applied.

Re: [PATCH net-next 05/13] fou: Add encap ops for IPv6 tunnels

Hi, On Wed, 11 May 2016 09:47:25 -0700 Tom Herbert wrote: > This patch adds IP tunnel encapsulation operations for IPv6. This > includes the infrastructure to add and delete operations. IPv6 variants > of fou6_build_header and gue6_build_header are added in a new > fou6

Re: [PATCH net-next 04/13] fou: Split out {fou,gue}_build_header

Hi Tom, On Wed, 11 May 2016 09:47:24 -0700 Tom Herbert wrote: > > -int fou_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e, > - u8 *protocol, struct flowi4 *fl4); > -int gue_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e, > -

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello Sergei, [we already talked about this patch in #armlinux, I'm now just forwarding my comments on the list. Background was that I sent an easier and less complete patch with the same idea. See http://patchwork.ozlabs.org/patch/621418/] [added Linus Walleij to Cc, there is a question for

Re: [PATCH net-next] gtp: put back reference to netns when not required anymore

On Thu, May 12, 2016 at 8:16 AM, Pablo Neira Ayuso wrote: > This patch fixes a netns leak. > > Fixes: 93edb8c7f94f ("gtp: reload GTPv1 header after pskb_may_pull()") > Reported-by: Cong Wang > Signed-off-by: Pablo Neira Ayuso

Re: [PATCH] r8169: default to 64-bit DMA on systems without memory below 4 GB

On 12 May 2016 at 16:09, Francois Romieu wrote: >> On 12 May 2016 at 01:58, David Miller wrote: >> > From: Ard Biesheuvel >> > Date: Wed, 11 May 2016 09:47:49 +0200 > [...] >> > I think we should just seriously consider

[PATCH net] driver: ixgbevf: ixgbevf_write/read_posted_mbx should use IXGBE_ERR_MBX to initialize ret_val

Now ixgbevf_write/read_posted_mbx use -IXGBE_ERR_MBX as the initiative return value, but it's incorrect, cause in ixgbevf_vlan_rx_add_vid(), it use err == IXGBE_ERR_MBX, the err returned from mac.ops.set_vfta, and in ixgbevf_set_vfta_vf, it return from write/read_posted. so we should initialize

Re: mlx5 core/en oops in 4.6-rc6+

On 05/05/2016 04:51 PM, Saeed Mahameed wrote: > On Thu, May 5, 2016 at 8:16 PM, Doug Ledford wrote: >> >> That depends on which interface actually generated the oops. If it was >> the base interface, then I don't manually set any special params on it. >> If it's one of the

Re: [net-next PATCH] udp: Resolve NULL pointer dereference

On Wed, May 11, 2016 at 8:43 PM, Eric Dumazet wrote: > On Wed, 2016-05-11 at 19:24 -0700, Alexander Duyck wrote: >> While testing an OpenStack configuration using VXLANs I saw the following >> call trace: > >> >> I believe the trace is pointing to the call to dev_net(dev)

Re: [PATCH nf V2] netfilter: fix oops in nfqueue during netns error unwinding

Eric W. Biederman wrote: > > On Wed, May 11, 2016 at 05:41:13PM +0200, Florian Westphal wrote: > >> diff --git a/net/netfilter/nf_queue.c b/net/netfilter/nf_queue.c > >> index 5baa8e2..9722819 100644 > >> --- a/net/netfilter/nf_queue.c > >> +++ b/net/netfilter/nf_queue.c >

Re: [PATCH nf V2] netfilter: fix oops in nfqueue during netns error unwinding

Pablo Neira Ayuso writes: > On Wed, May 11, 2016 at 05:41:13PM +0200, Florian Westphal wrote: >> diff --git a/net/netfilter/nf_queue.c b/net/netfilter/nf_queue.c >> index 5baa8e2..9722819 100644 >> --- a/net/netfilter/nf_queue.c >> +++ b/net/netfilter/nf_queue.c >> @@ -102,6

Aw: Re: [PATCH 0/6] hv_netvsc: avoid races on mtu change/set channels

> It's worse: before the patch series we get 'struct hv_device' (as it is > called from core VMBus code and we simply cannot get to 'struct > net_device' we need without traveling through 'struct > netvsc_device'. This structure is removed and re-created by both > netvsc_set_channels() and

Re: [PATCH] phy: add support for a reset-gpio specification

Hello, On Thu, May 12, 2016 at 05:16:56PM +0300, Roger Quadros wrote: > On 12/05/16 17:02, Roger Quadros wrote: > > On 12/05/16 16:50, Nishanth Menon wrote: > >> On 05/12/2016 05:00 AM, Uwe Kleine-König wrote: > >>> The framework only asserts (for now) that the reset gpio is not active. > >>> >

RE: [Xen-devel] [PATCH net-next v2 0/4] xen-netback: support for control ring

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of > David Miller > Sent: 12 May 2016 16:52 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org; netdev@vger.kernel.org > Subject: Re: [Xen-devel] [PATCH net-next v2 0/4] xen-netback: support for

Re: [PATCH net-next v2 0/4] xen-netback: support for control ring

From: Paul Durrant Date: Wed, 11 May 2016 16:16:26 +0100 > My recent patch to import an up-to-date include/xen/interface/io/netif.h > from the Xen Project brought in the necessary definitions to support the > new control shared ring and protocol. This patch series

Re: [patch net-next 2/4] rtnetlink: add HW/SW stats distinction in rtnl_fill_stats

From: Jiri Pirko Date: Thu, 12 May 2016 13:48:48 +0200 > sp = nla_data(attr); > dev_get_stats(dev, sp); > > + err = dev_get_sw_stats(dev, _stats); > + if (!err) { > + attr = nla_reserve_64bit(skb, IFLA_SW_STATS64, > +

Re: pull-request: mac80211-next 2016-05-12

From: Johannes Berg Date: Thu, 12 May 2016 13:06:01 +0200 > A few more patches for 4.7 - I listed the notable ones below in the tag > message. > > Note that this isn't the tip of my tree - I merged the namespace work > for nl80211 and hwsim there, but at least the

Re: [PATCH] net: mvneta: bm: fix dependencies again

Hi Arnd, On mer., mai 11 2016, Arnd Bergmann wrote: > I tried to fix this before, but my previous fix was incomplete > and we can still get the same link error in randconfig builds > because of the way that Kconfig treats the > > default y if MVNETA=y && MVNETA_BM_ENABLE

[PATCH net-next] gtp: put back reference to netns when not required anymore

This patch fixes a netns leak. Fixes: 93edb8c7f94f ("gtp: reload GTPv1 header after pskb_may_pull()") Reported-by: Cong Wang Signed-off-by: Pablo Neira Ayuso --- drivers/net/gtp.c | 15 --- 1 file changed, 12 insertions(+), 3

Re: Aw: [PATCH 0/6] hv_netvsc: avoid races on mtu change/set channels

"Lino Sanfilippo" writes: > Hi, > >> >> MTU change and set channels operations are implemented as netvsc device >> re-creation destroying internal structures (struct net_device stays). This >> is really unfortunate but there is no support from Hyper-V host to do it >> in a

Re: [patch net-next 0/4] return offloaded stats as default and expose original sw start

On Thu, May 12, 2016 at 11:59:54AM +0200, Jiri Pirko wrote: > From: Jiri Pirko > > Until now we had stats functions return SW statistics. However, it makes > a lot of sense to return HW stats as default. Hi Jiri DSA has always returned the HW stats, i.e, ethtool -S shows the

Aw: [PATCH 0/6] hv_netvsc: avoid races on mtu change/set channels

Hi, > > MTU change and set channels operations are implemented as netvsc device > re-creation destroying internal structures (struct net_device stays). This > is really unfortunate but there is no support from Hyper-V host to do it > in a different way. Such re-creation is unsurprisingly racy,

Re: [patch net-next 0/4] return offloaded stats as default and expose original sw start

Thu, May 12, 2016 at 04:36:45PM CEST, and...@lunn.ch wrote: >On Thu, May 12, 2016 at 11:59:54AM +0200, Jiri Pirko wrote: >> From: Jiri Pirko >> >> Until now we had stats functions return SW statistics. However, it makes >> a lot of sense to return HW stats as default. > >Hi

[PATCH net] xen-netback: fix extra_info handling in xenvif_tx_err()

Patch 562abd39 "xen-netback: support multiple extra info fragments passed from frontend" contained a mistake which can result in an in- correct number of responses being generated when handling errors encountered when processing packets containing extra info fragments. This patch fixes the

Re: [PATCH] phy: add support for a reset-gpio specification

On 5/12/2016 5:16 PM, Roger Quadros wrote: The framework only asserts (for now) that the reset gpio is not active. Signed-off-by: Uwe Kleine-König --- Documentation/devicetree/bindings/net/phy.txt | 3 +++ drivers/net/phy/phy_device.c | 8

Re: [PATCH] phy: add support for a reset-gpio specification

On 12/05/16 17:02, Roger Quadros wrote: > Hi, > > On 12/05/16 16:50, Nishanth Menon wrote: >> On 05/12/2016 05:00 AM, Uwe Kleine-König wrote: >>> The framework only asserts (for now) that the reset gpio is not active. >>> >>> Signed-off-by: Uwe Kleine-König >>>

Re: [PATCH net] xen-netback: fix extra_info handling in xenvif_tx_err()

On Thu, May 12, 2016 at 02:43:03PM +0100, Paul Durrant wrote: > Patch 562abd39 "xen-netback: support multiple extra info fragments > passed from frontend" contained a mistake which can result in an in- > correct number of responses being generated when handling errors > encountered when processing

Re: [PATCH] phy: add support for a reset-gpio specification

On 05/12/2016 09:02 AM, Roger Quadros wrote: [...] >> This looks like the right approach to me at least: I see that TI EVMs >> will also benefit with this approach. >> > > Agreed. Although on some of our boards we actually need a RESET pulse > to get the PHY in a sane state. I can send a patch on

Re: [PATCH] r8169: default to 64-bit DMA on systems without memory below 4 GB

> On 12 May 2016 at 01:58, David Miller wrote: > > From: Ard Biesheuvel > > Date: Wed, 11 May 2016 09:47:49 +0200 [...] > > I think we should just seriously consider changing the default, it's > > a really outdated reasoning behind the current

Re: [RFC] Reset pins of phys and their representation in a device tree

Hello ChenYu On Thu, May 12, 2016 at 9:49 AM, Chen-Yu Tsai wrote: > Hi, > > On Thu, May 12, 2016 at 9:40 PM, Javier Martinez Canillas > wrote: >> [adding Krzysztof as cc] >> >> On Thu, May 12, 2016 at 8:25 AM, Sergei Shtylyov >>

Re: [PATCH] phy: add support for a reset-gpio specification

Hi, On 12/05/16 16:50, Nishanth Menon wrote: > On 05/12/2016 05:00 AM, Uwe Kleine-König wrote: >> The framework only asserts (for now) that the reset gpio is not active. >> >> Signed-off-by: Uwe Kleine-König >> --- >> Documentation/devicetree/bindings/net/phy.txt

Re: [PATCH] phy: add support for a reset-gpio specification

On 05/12/2016 05:00 AM, Uwe Kleine-König wrote: > The framework only asserts (for now) that the reset gpio is not active. > > Signed-off-by: Uwe Kleine-König > --- > Documentation/devicetree/bindings/net/phy.txt | 3 +++ > drivers/net/phy/phy_device.c

Re: [RFC] Reset pins of phys and their representation in a device tree

Hi, On Thu, May 12, 2016 at 9:40 PM, Javier Martinez Canillas wrote: > [adding Krzysztof as cc] > > On Thu, May 12, 2016 at 8:25 AM, Sergei Shtylyov > wrote: >> Hello. >> >> >> On 5/12/2016 10:15 AM, Uwe Kleine-König wrote: >> >>> I have

Re: [RFC] Reset pins of phys and their representation in a device tree

[adding Krzysztof as cc] On Thu, May 12, 2016 at 8:25 AM, Sergei Shtylyov wrote: > Hello. > > > On 5/12/2016 10:15 AM, Uwe Kleine-König wrote: > >> I have a machine here where the reset pin of the phy is connected to a >> GPIO. >> >> There are different

Re: [PATCH net] drivers: net: Don't print unpopulated net_device name

Hi Stephen, On 10/05/16 19:31, Stephen Hemminger wrote: On Tue, 10 May 2016 17:43:21 +0100 Harvey Hunt wrote: For ethernet devices, net_device.name will be eth%d before register_netdev() is called. Don't print the net_device name until the format string is replaced.

Re: [PATCH net] drivers: net: Don't print unpopulated net_device name

Hi David, On 12/05/16 00:26, David Miller wrote: From: Harvey Hunt Date: Tue, 10 May 2016 17:43:21 +0100 @@ -1686,8 +1686,7 @@ dm9000_probe(struct platform_device *pdev) } if (!is_valid_ether_addr(ndev->dev_addr)) { - dev_warn(db->dev,

[PATCH 0/6] hv_netvsc: avoid races on mtu change/set channels

MTU change and set channels operations are implemented as netvsc device re-creation destroying internal structures (struct net_device stays). This is really unfortunate but there is no support from Hyper-V host to do it in a different way. Such re-creation is unsurprisingly racy, Haiyang reported

[PATCH 5/6] hv_netvsc: synchronize netvsc_change_mtu()/netvsc_set_channels() with netvsc_remove()

When netvsc device is removed during mtu change or channels setup we get into troubles as both paths are trying to remove the device. Synchronize them with start_remove flag and rtnl lock. Signed-off-by: Vitaly Kuznetsov --- drivers/net/hyperv/netvsc_drv.c | 9 +++-- 1

[PATCH 3/6] hv_netvsc: untangle the pointer mess

We have the following structures keeping netvsc adapter state: - struct net_device - struct net_device_context - struct netvsc_device - struct rndis_device - struct hv_device and there are pointers/dependencies between them: - struct net_device_context is contained in struct net_device - struct

[PATCH 2/6] hv_netvsc: use start_remove flag to protect netvsc_link_change()

netvsc_link_change() can race with netvsc_change_mtu() or netvsc_set_channels() as these functions destroy struct netvsc_device and rndis filter. Use start_remove flag for syncronization. As netvsc_change_mtu()/netvsc_set_channels() are called with rtnl lock held we need to take it before checking

[PATCH 1/6] hv_netvsc: move start_remove flag to net_device_context

struct netvsc_device is destroyed on mtu change so keeping the protection flag there is not a good idea. Move it to struct net_device_context which is preserved. Signed-off-by: Vitaly Kuznetsov --- drivers/net/hyperv/hyperv_net.h | 4 +++- drivers/net/hyperv/netvsc.c |

[PATCH 4/6] hv_netvsc: get rid of struct net_device pointer in struct netvsc_device

Simplify netvsvc pointer graph by getting rid of the redundant ndev pointer. We can always get a pointer to struct net_device from somewhere else. Signed-off-by: Vitaly Kuznetsov --- drivers/net/hyperv/hyperv_net.h | 2 -- drivers/net/hyperv/netvsc.c | 30

[PATCH 6/6] hv_netvsc: set nvdev link after populating chn_table

Crash in netvsc_send() is observed when netvsc device is re-created on mtu change/set channels. The crash is caused by dereferencing of NULL channel pointer which comes from chn_table. The root cause is a mixture of two facts: - we set nvdev pointer in net_device_context in alloc_net_device()

Re: [RFC] Reset pins of phys and their representation in a device tree

Hello. On 5/12/2016 10:15 AM, Uwe Kleine-König wrote: I have a machine here where the reset pin of the phy is connected to a GPIO. There are different possibilities available today to handle this situation, here are the ones I'm aware of: - Use a gpio-hog to set the reset gpio to non-active

[patch net-next 3/4] net: core: add SW stats to if_stats_msg

From: Nogah Frankel If there is a dedicated ndo to return SW stats - use it. Otherwise (indicates that there is no HW stats) use the default stats ndo. Return results under IFLA_STATS_LINK_SW_64. Signed-off-by: Nogah Frankel Reviewed-by: Ido Schimmel

[patch net-next 1/4] netdevice: add SW statistics ndo

From: Nogah Frankel Till now we had a ndo statistics function that returned SW statistics. We want to change the "basic" statistics to return HW statistics if available. In this case we need to expose a new ndo to return the SW statistics. Add a new ndo declaration to get SW

[patch net-next 2/4] rtnetlink: add HW/SW stats distinction in rtnl_fill_stats

From: Nogah Frankel Since hardware stats are now returned by default, add a way to query only software stats. They are saved in IFLA_SW_STATS64. (This option is valid only if the driver return HW stats in the default ndo stats) Signed-off-by: Nogah Frankel

[patch net-next 4/4] mlxsw: spectrum: Implement SW stats ndo and expose HW stats by default

From: Nogah Frankel Add a function to get the SW statistics with an ndo Change the default statistics ndo to return HW statistics (like the one returned by ethtool_ops) Signed-off-by: Nogah Frankel Reviewed-by: Ido Schimmel

[patch net-next 0/4] return offloaded stats as default and expose original sw start

From: Jiri Pirko Until now we had stats functions return SW statistics. However, it makes a lot of sense to return HW stats as default. The existing apps count with having the defaults stats complete, but that is not true now as the offloaded forward traffic is not visible

Re: [patch net-next 3/4] net: core: add SW stats to if_stats_msg

Thu, May 12, 2016 at 01:33:11PM CEST, niko...@cumulusnetworks.com wrote: > >> On May 12, 2016, at 12:59 PM, Jiri Pirko wrote: >> >> From: Nogah Frankel >> >> If there is a dedicated ndo to return SW stats - use >> it. Otherwise (indicates that there is no

Re: [patch net-next 3/4] net: core: add SW stats to if_stats_msg

> On May 12, 2016, at 12:59 PM, Jiri Pirko wrote: > > From: Nogah Frankel > > If there is a dedicated ndo to return SW stats - use > it. Otherwise (indicates that there is no HW stats) use > the default stats ndo. > Return results under

CHECK MESSAGE.

I have profitable business opportunity i would like to introduce to you, reply with your name and your location. Best regards, Mr. Matthew Daniels.

pull-request: mac80211-next 2016-05-12

Hi Dave, A few more patches for 4.7 - I listed the notable ones below in the tag message. Note that this isn't the tip of my tree - I merged the namespace work for nl80211 and hwsim there, but at least the hwsim one needs some more follow-up work which I don't want to send in after the merge

Re: [PATCH net-next] sfc: allocate rx pages on the same node as the interrupt

On 10/05/16 15:57, Eric Dumazet wrote: > On Tue, 2016-05-10 at 07:55 -0700, Eric Dumazet wrote: >> If you care only of the initial pages allocated with GFP_KERNEL at >> device start, really that is a small detail as they should be consumed >> and replaced quite fast. This patch was addressing

  1   2   >