Re: [PATCH v3 2/2] ip6_tunnel: fix ip6 tunnel lookup in collect_md mode

> On 2017年9月6日, at 上午11:14, Alexei Starovoitov wrote: > > On 9/4/17 1:36 AM, Haishuang Yan wrote: >> In collect_md mode, if the tun dev is down, it still can call >> __ip6_tnl_rcv to receive on packets, and the rx statistics increase >> improperly. >> >> Fixes: 8d79266bc48c

Re: [Intel-wired-lan] [PATCH net-next v3] e1000e: Be drop monitor friendly

On 8/26/2017 04:14, Florian Fainelli wrote: e1000e_put_txbuf() can be called from normal reclamation path as well as when a DMA mapping failure, so we need to differentiate these two cases when freeing SKBs to be drop monitor friendly. e1000e_tx_hwtstamp_work() and e1000_remove() are processing

Re: [RFC net-next] net: sch_clsact: add support for global per-netns classifier mode

Wed, Sep 06, 2017 at 06:04:17AM CEST, ro...@cumulusnetworks.com wrote: >On Tue, Sep 5, 2017 at 3:45 PM, Daniel Borkmann wrote: >> On 09/06/2017 12:01 AM, Roopa Prabhu wrote: >>> >>> On Tue, Sep 5, 2017 at 11:18 AM, Cong Wang >>> wrote: On

[PATCH] tipc: remove unnecessary call to dev_net()

The net device is already stored in the 'net' variable, so no need to call dev_net() again. Signed-off-by: Kleber Sacilotto de Souza --- net/tipc/bearer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/tipc/bearer.c b/net/tipc/bearer.c index

Re: [PATCH 6/10] ixgbe: Use ARRAY_SIZE macro

On Tue, Sep 05, 2017 at 02:22:05PM -0700, David Miller wrote: > From: Joe Perches > Date: Tue, 05 Sep 2017 13:01:18 -0700 > > > On Tue, 2017-09-05 at 21:45 +0200, Thomas Meyer wrote: > >> On Tue, Sep 05, 2017 at 11:50:44AM -0700, David Miller wrote: > >> > From: Thomas Meyer

Re: [PATCH net-next] net: cpsw: Don't handle SIOC[GS]HWTSTAMP when CPTS is disabled

On Tue, Sep 05, 2017 at 04:25:22PM -0500, Grygorii Strashko wrote: > I'd like to clarify one thing here - what is the preferable time-stamping > device: PHY over MAC, or MAC over PHY? > my understanding it's PHY and ethtool_get_ts_info() seems already implemented > this way. We simply do not

[PATCH v13 1/5] block: DAC960: Replace PCI pool old API

The PCI pool API is deprecated. This commit replaces the PCI pool old API by the appropriate function with the DMA pool API. Signed-off-by: Romain Perier Acked-by: Peter Senna Tschudin Tested-by: Peter Senna Tschudin

[PATCH v13 0/5] Replace PCI pool by DMA pool API

by the dma pool API and remove the defines. Changes in v13: - Rebased series onto next-20170906 - Added a new commit for the hinic ethernet driver - Remove previously merged patches Changes in v12: - Rebased series onto next-20170822 Changes in v11: - Rebased series onto next-20170809 - Removed

Re: [PATCH net-next v6 3/3] openvswitch: enable NSH support

Jan Scheurich writes: >> >> Yes, I wrote that in my previous mail. I wonder why NSH context metadata >> >> is not in tun_metadata as well? >> > >> > tun_metadata is tunnel metadata, GENEVE needs tunnel port, but NSH is >> > not so, NSH can't directly use tun_metadata,

Re: [PATCH net-next v6 3/3] openvswitch: enable NSH support

Jan Scheurich writes: >> > There is no way we can re-use the existing TLV tunnel metadata >> > infrastructure in OVS for matching and setting NSH MD2 TLV headers. We >> > will need to introduce a new (perhaps similar) scheme for modelling >> > generic TLV match

Re: [Patch net] net_sched: fix a memory leak of filter chain

Wed, Sep 06, 2017 at 07:03:10AM CEST, xiyou.wangc...@gmail.com wrote: >tcf_chain_destroy() is called by tcf_block_put() and tcf_chain_put(). >tcf_chain_put() is refcn'ed and paired with tcf_chain_get(), >but tcf_block_put() is not, it should be paired with tcf_block_get() >and we still need to

Re: [PATCH net-next v6 3/3] openvswitch: enable NSH support

"Yang, Yi" writes: > On Tue, Sep 05, 2017 at 09:12:09PM +0800, Hannes Frederic Sowa wrote: >> "Yang, Yi" writes: >> >> > We can change this later if we really find a better way to handle this >> > because it isn't defined in

[PATCH net 1/2] i40e: Fix comment about locking for __i40e_read_nvm_word()

Caller needs to acquire the lock. Called functions will not. Fixes: 09f79fd49d94 ("i40e: avoid NVM acquire deadlock during NVM update") Signed-off-by: Stefano Brivio --- drivers/net/ethernet/intel/i40e/i40e_nvm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH net 2/2] i40e: Avoid some useless variables and initializers in nvm functions

Fixes: 09f79fd49d94 ("i40e: avoid NVM acquire deadlock during NVM update") Signed-off-by: Stefano Brivio --- drivers/net/ethernet/intel/i40e/i40e_nvm.c | 20 +++- 1 file changed, 7 insertions(+), 13 deletions(-) diff --git

[PATCH net 0/2] i40e: Two trivial fixes for 09f79fd49d94

Two trivial fixes for recently introduced 09f79fd49d94 ("i40e: avoid NVM acquire deadlock during NVM update"): 1/2 fixes a comment about locking and 2/2 gets rid of two useless variables and one initializer in nvm functions. Stefano Brivio (2): i40e: Fix comment about locking for

RE: [PATCH net-next v6 3/3] openvswitch: enable NSH support

> > There is no way we can re-use the existing TLV tunnel metadata > > infrastructure in OVS for matching and setting NSH MD2 TLV headers. We > > will need to introduce a new (perhaps similar) scheme for modelling > > generic TLV match registers in OVS that are assigned to protocol TLVs > > by the

Re: [PATCH] DSA support for Micrel KSZ8895

2017-08-31 0:32 GMT+03:00 : >> On Mon 2017-08-28 16:09:27, Andrew Lunn wrote: >> > > I may be confused here, but AFAICT: >> > > >> > > 1) Yes, it has standard layout when accessed over MDIO. >> > >> > >> > Section 4.8 of the datasheet says: >> > >> > All the

RE: [PATCH net-next v6 3/3] openvswitch: enable NSH support

> >> Yes, I wrote that in my previous mail. I wonder why NSH context metadata > >> is not in tun_metadata as well? > > > > tun_metadata is tunnel metadata, GENEVE needs tunnel port, but NSH is > > not so, NSH can't directly use tun_metadata, for MD type 2, we need to a > > lot of rework on

RE: hns3 use of pci_enable_msix_range

Hi Christoph, Thanks for bringing this into notice. I will change and send this patch in the next cycle after we have tested it internally. Best regards Salil > -Original Message- > From: Christoph Hellwig [mailto:h...@lst.de] > Sent: Friday, September 01, 2017 9:27 AM > To: Salil Mehta

[PATCH v13 4/5] hinic: Replace PCI pool old API

The PCI pool API is deprecated. This commit replaces the PCI pool old API by the appropriate function with the DMA pool API. Signed-off-by: Romain Perier --- drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c | 10 +-

[PATCH v13 2/5] dmaengine: pch_dma: Replace PCI pool old API

The PCI pool API is deprecated. This commit replaces the PCI pool old API by the appropriate function with the DMA pool API. Signed-off-by: Romain Perier Acked-by: Peter Senna Tschudin Tested-by: Peter Senna Tschudin

[PATCH v13 5/5] PCI: Remove PCI pool macro functions

Now that all the drivers use dma pool API, we can remove the macro functions for PCI pool. Signed-off-by: Romain Perier Reviewed-by: Peter Senna Tschudin --- include/linux/pci.h | 9 - 1 file changed, 9 deletions(-) diff --git

[PATCH v13 3/5] net: e100: Replace PCI pool old API

The PCI pool API is deprecated. This commit replaces the PCI pool old API by the appropriate function with the DMA pool API. Signed-off-by: Romain Perier Acked-by: Peter Senna Tschudin Acked-by: Jeff Kirsher

Re: [PATCH net-next RFC 1/2] tun: enable NAPI for TUN/TAP driver

On Wed, Sep 6, 2017 at 12:51 AM, Stephen Hemminger wrote: > On Tue, 5 Sep 2017 15:35:50 -0700 > Petar Penkov wrote: > >> Changes TUN driver to use napi_gro_receive() upon receiving packets >> rather than netif_rx_ni(). Adds flag CONFIG_TUN_NAPI

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

On 06/09/17 03:11, Stephen Hemminger wrote: > On Wed, 6 Sep 2017 01:35:02 +0200 > Andrew Lunn wrote: > >> After the very useful feedback from Nikolay, i threw away what i had, >> and started again. To recap: >> >> The linux bridge supports IGMP snooping. It will listen to IGMP

Re: [RFC net-next] net: sch_clsact: add support for global per-netns classifier mode

On 06/09/17 01:45, Daniel Borkmann wrote: > On 09/06/2017 12:01 AM, Roopa Prabhu wrote: >> On Tue, Sep 5, 2017 at 11:18 AM, Cong Wang wrote: >>> On Tue, Sep 5, 2017 at 5:48 AM, Nikolay Aleksandrov >>> wrote: Hi all, This RFC adds a

hung task in mac80211

Hi, I have an hung task on vanilla 4.13 kernel which I haven't on 4.12. The problem is present both on my AP and on my notebook, so it seems it affects AP and STA mode as well. The generated messages are: INFO: task kworker/u16:6:120 blocked for more than 120 seconds. Not tainted 4.13.0

Re: [PATCH 4/8] tty/bcm63xx_uart: allow naming clock in device tree

On 6 September 2017 at 14:17, Greg Kroah-Hartman wrote: > On Wed, Sep 06, 2017 at 01:01:32PM +0200, Jonas Gorski wrote: >> Hi Greg, >> >> On 2 August 2017 at 11:34, Jonas Gorski wrote: >> > Codify using a named clock for the refclk of the uart.

Re: [PATCH 6/8] bcm63xx_enet: just use "enet" as the clock name

Hi David, On 2 August 2017 at 11:34, Jonas Gorski wrote: > Now that we have the individual clocks available as "enet" we > don't need to rely on the device id for them anymore. > > Signed-off-by: Jonas Gorski Could I please get a (N)Ack so Ralf

[patch net] net: sched: fix memleak for chain zero

From: Jiri Pirko There's a memleak happening for chain 0. The thing is, chain 0 needs to be always present, not created on demand. Therefore tcf_block_get upon creation of block calls the tcf_chain_create function directly. The chain is created with refcnt == 1, which is not

Re: hung task in mac80211

On Wednesday, September 6, 2017 1:57:47 PM CEST Matteo Croce wrote: > Hi, > > I have an hung task on vanilla 4.13 kernel which I haven't on 4.12. > The problem is present both on my AP and on my notebook, > so it seems it affects AP and STA mode as well. > The generated messages are: > > INFO:

ipset losing entries on its own

I am having ipset 6.32 The hash type is hash:ip I am adding/deleting IP addresses to it dynamically using scripts. However, it has been observed that at times few IPs (3-4 out of 4000) are not found in the set though it was added. Also, logs show there was not request for deletion of that IP

Re: ipset losing entries on its own

output of ipset -L -t Name: STORE Type: hash:ip Revision: 4 Header: family inet hashsize 1024 maxelem 65536 Size in memory: 50480 References: 1

[PATCH net 1/4] lan78xx: Fix for crash associated with System suspend

From: Nisar Sayed Fix for crash associated with System suspend Since ndo_stop removes phydev which makes phydev NULL. Whenever system suspend is initiated or after "ifconfig down", if set_wol or get_wol is triggered phydev is NULL leads system crash. Hence

Re: [PATCH net-next v6 3/3] openvswitch: enable NSH support

On Wed, Sep 06, 2017 at 04:03:29PM +0800, Hannes Frederic Sowa wrote: > "Yang, Yi" writes: > >> > >> > If you check GENEVE implementation, tun_metadata* can be set or matched > >> > as any other match field. > >> > >> Yes, I wrote that in my previous mail. I wonder why NSH

Re: ipset losing entries on its own

On 2017-09-06 13:08, Akshat Kakkar wrote: I am having ipset 6.32 The hash type is hash:ip I am adding/deleting IP addresses to it dynamically using scripts. However, it has been observed that at times few IPs (3-4 out of 4000) are not found in the set though it was added. Also, logs show

[PATCH net 0/4] lan78xx: Fixes and Enhancements to lan78xx driver

From: Nisar Sayed This series of patches are for lan78xx driver. These patches supports fixes and enhancements to lan78xx driver Nisar Sayed (4): Fix for crash associated with System suspend Add fixed_phy device support for LAN7801 device Fix for eeprom

[PATCH net 4/4] lan78xx: Use default value loaded from EEPROM/OTP when resetting the chip

From: Nisar Sayed Use default value loaded from EEPROM/OTP when resetting the chip Signed-off-by: Nisar Sayed --- drivers/net/usb/lan78xx.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/usb/lan78xx.c

[PATCH net 2/4] lan78xx: Add fixed_phy device support for LAN7801 device

From: Nisar Sayed Add fixed_phy device support for LAN7801 device When LAN7801 device connected to PHY Device which does not have MDIO/MDC access, fixex_phy device will be added. Signed-off-by: Nisar Sayed --- drivers/net/usb/Kconfig |

Re: [net 0/2][pull request] Intel Wired LAN Driver Updates 2017-09-05

On Tue, 5 Sep 2017 18:04:16 -0700 Jeff Kirsher wrote: > This series contains fixes for i40e only. > > These two patches fix an issue where our nvmupdate tool does not work on RHEL > 7.4 > and newer kernels, in fact, the use of the nvmupdate tool on newer kernels

[PATCH net 3/4] lan78xx: Fix for eeprom read/write when device autosuspend

From: Nisar Sayed Fix for eeprom read/write when device autosuspend Signed-off-by: Nisar Sayed --- drivers/net/usb/lan78xx.c | 26 ++ 1 file changed, 22 insertions(+), 4 deletions(-) diff --git

Re: [PATCH 4/8] tty/bcm63xx_uart: allow naming clock in device tree

Hi Greg, On 2 August 2017 at 11:34, Jonas Gorski wrote: > Codify using a named clock for the refclk of the uart. This makes it > easier if we might need to add a gating clock (like present on the > BCM6345). > > Signed-off-by: Jonas Gorski Could

Re: [PATCH 4/8] tty/bcm63xx_uart: allow naming clock in device tree

On Wed, Sep 06, 2017 at 01:01:32PM +0200, Jonas Gorski wrote: > Hi Greg, > > On 2 August 2017 at 11:34, Jonas Gorski wrote: > > Codify using a named clock for the refclk of the uart. This makes it > > easier if we might need to add a gating clock (like present on the > >

Re: [PATCH] tipc: remove unnecessary call to dev_net()

On 09/06/2017 05:08 PM, Kleber Sacilotto de Souza wrote: > The net device is already stored in the 'net' variable, so no need to call > dev_net() again. > > Signed-off-by: Kleber Sacilotto de Souza Acked-by: Ying Xue > --- >

Re: hung task in mac80211

On Wed, 2017-09-06 at 13:57 +0200, Matteo Croce wrote: > I have an hung task on vanilla 4.13 kernel which I haven't on 4.12. > The problem is present both on my AP and on my notebook, > so it seems it affects AP and STA mode as well. > The generated messages are: > > INFO: task kworker/u16:6:120

Re: hung task in mac80211

On Wed, 2017-09-06 at 14:48 +0200, Johannes Berg wrote: > > I'm surprised nobody saw this before - though perhaps Sebastian's > useless report is the same. Oh, that's because this is only for the offloaded manager thing, and that's only ath10k. johannes

Re: hung task in mac80211

Am 06.09.2017 um 15:03 schrieb Johannes Berg: On Wed, 2017-09-06 at 14:48 +0200, Johannes Berg wrote: I'm surprised nobody saw this before - though perhaps Sebastian's useless report is the same. Oh, that's because this is only for the offloaded manager thing, and that's only ath10k. johannes

Re: hung task in mac80211

On Wed, 06 Sep 2017 15:21:00 +0200 Johannes Berg wrote: > On Wed, 2017-09-06 at 15:19 +0200, Stefano Brivio wrote: > > On Wed, 06 Sep 2017 14:48:35 +0200 > > Johannes Berg wrote: > > > > > I'll look in a bit - but > > > > > > > +

Re: hung task in mac80211

On Wed, 06 Sep 2017 15:30:10 +0200 Johannes Berg wrote: > So for example replacing the loop of tid = 0..NUM_TIDS-1 with a > list_for_each_entry() would already be unsafe with the dropping if the > list were to require the mutex for locking. Sure. Still, it would need

Re: hung task in mac80211

On Wed, 6 Sep 2017 13:57:47 +0200 Matteo Croce wrote: > Hi, > > I have an hung task on vanilla 4.13 kernel which I haven't on 4.12. > The problem is present both on my AP and on my notebook, > so it seems it affects AP and STA mode as well. > The generated messages are: > >

[PATCH] ath10: mark PM functions as __maybe_unused

When CONFIG_PM_SLEEP is disabled, we get a compile-time warning: drivers/net/wireless/ath/ath10k/pci.c:3417:12: error: 'ath10k_pci_pm_resume' defined but not used [-Werror=unused-function] static int ath10k_pci_pm_resume(struct device *dev) ^~~~

Re: hung task in mac80211

On Wed, 2017-09-06 at 15:19 +0200, Stefano Brivio wrote: > On Wed, 06 Sep 2017 14:48:35 +0200 > Johannes Berg wrote: > > > I'll look in a bit - but > > > > > + mutex_unlock(>ampdu_mlme.mtx); > > >   ___ieee80211_stop_rx_ba_session( > >

Re: hung task in mac80211

On Wed, 2017-09-06 at 15:27 +0200, Stefano Brivio wrote: > > Yes, that was based on the assumption that the initial part of > __ieee80211_start_rx_ba_session() can't really affect the AMPDU > state-machine in any way. That's not really the point, if that changes that function would have to move

Re: hung task in mac80211

I'll look in a bit - but > + mutex_unlock(>ampdu_mlme.mtx); >   ___ieee80211_stop_rx_ba_session( >   sta, tid, WLAN_BACK_RECIPIENT, >   WLAN_REASON_QSTA_TIMEOUT, true); This already has three

Re: hung task in mac80211

On Wed, Sep 6, 2017 at 2:40 PM, Stefano Brivio wrote: > On Wed, 6 Sep 2017 13:57:47 +0200 > Matteo Croce wrote: > >> Hi, >> >> I have an hung task on vanilla 4.13 kernel which I haven't on 4.12. >> The problem is present both on my AP and on my notebook, >>

[PATCH net] udp: drop head states only when all skb references are gone

After commit 0ddf3fb2c43d ("udp: preserve skb->dst if required for IP options processing") we clear the skb head state as soon as the skb carrying them is first processed. Since the same skb can be processed several times when MSG_PEEK is used, we can end up lacking the required head states, and

Re: hung task in mac80211

On Wed, 06 Sep 2017 14:48:35 +0200 Johannes Berg wrote: > I'll look in a bit - but > > > + mutex_unlock(>ampdu_mlme.mtx); > >   ___ieee80211_stop_rx_ba_session( > >   sta, tid, WLAN_BACK_RECIPIENT, > >  

[PATCH] isdn: isdnloop: fix logic error in isdnloop_sendbuf

gcc-7 found an ancient bug in the loop driver, leading to a condition that is always false, meaning we ignore the contents of 'card->flags' here: drivers/isdn/isdnloop/isdnloop.c:412:37: error: ?: using integer constants in boolean context, the expression will always evaluate to 'true'

Re: [PATCH net 1/4] lan78xx: Fix for crash associated with System suspend

On Wed, Sep 06, 2017 at 10:51:31AM +, nisar.sa...@microchip.com wrote: > From: Nisar Sayed > > Fix for crash associated with System suspend > > Since ndo_stop removes phydev which makes phydev NULL. > Whenever system suspend is initiated or after "ifconfig down",

RE: [iproute PATCH 1/6] utils: Implement strlcpy() and strlcat()

From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: 04 September 2017 19:25 > On Mon, 4 Sep 2017 17:00:15 +0200 > Phil Sutter wrote: > > > On Mon, Sep 04, 2017 at 02:49:20PM +, David Laight wrote: > > > From: Phil Sutter > > > > Sent: 01 September 2017 17:53 > >

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

Hi Andrew, Andrew Lunn writes: > So there is the third issue. It affects just DSA, but it possible > affects all DSA drivers. > > This patchset broken broadcast with the Marvell drivers. It could > break broadcast on others drivers as well. > > What i found is that the Marvell

Re: [PATCH net 2/4] lan78xx: Add fixed_phy device support for LAN7801 device

On Wed, Sep 06, 2017 at 10:51:44AM +, nisar.sa...@microchip.com wrote: > From: Nisar Sayed > > Add fixed_phy device support for LAN7801 device > > When LAN7801 device connected to PHY Device which does not have > MDIO/MDC access, fixex_phy device will be added.

Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

> On Aug 31, 2017, at 1:54 PM, Stefan Hajnoczi wrote: > > On Tue, Aug 29, 2017 at 03:37:07PM +, Jorgen S. Hansen wrote: >>> On Aug 29, 2017, at 4:36 AM, Dexuan Cui wrote: >> If we allow multiple host side transports, virtio host side support and >>

Re: [RFC net-next] net: sch_clsact: add support for global per-netns classifier mode

On Wed, Sep 6, 2017 at 12:24 AM, Jiri Pirko wrote: > Wed, Sep 06, 2017 at 06:04:17AM CEST, ro...@cumulusnetworks.com wrote: >>On Tue, Sep 5, 2017 at 3:45 PM, Daniel Borkmann wrote: >>> On 09/06/2017 12:01 AM, Roopa Prabhu wrote: On Tue, Sep 5,

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

On 06/09/17 02:47, Andrew Lunn wrote: Should this be done at the DSA level, or at the driver level? Do any chips do broadcast flooding in hardware already? Hence they currently see broadcast duplication? If i add a broadcast mdb at the DSA level, and the chip is already hard wired to flooding

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

On 06/09/17 02:47, Andrew Lunn wrote: >> The third and last issue will be explained in a followup email. > > Hi DSA hackers > > So there is the third issue. It affects just DSA, but it possible > affects all DSA drivers. > > This patchset broken broadcast with the Marvell drivers. It could >

Re: hung task in mac80211

On Wed, Sep 6, 2017 at 2:58 PM, Johannes Berg wrote: > On Wed, 2017-09-06 at 13:57 +0200, Matteo Croce wrote: > >> I have an hung task on vanilla 4.13 kernel which I haven't on 4.12. >> The problem is present both on my AP and on my notebook, >> so it seems it affects

Re: hung task in mac80211

On Wed, 2017-09-06 at 17:04 +0200, Matteo Croce wrote: > > I confirm that this patch fixes the hang too. Cool, I'll go apply it. > I'm curious to see if there are noticeable performance differences > between the two solutions. Nope, you hit this code path essentially once. johannes

[PATCH 0/2] 9p: Fixes for hard-to-hit bugs

These two patches fix two hard-to-hit (but really annoying) bugs in 9p. The first one was posted earlier in February (with one R-b), the second is a new one. Both of these have had soaking in NixOS distribution kernels for a couple of months with no ill effects. Tuomas Tynkkynen (2): fs/9p:

Re: hung task in mac80211

On Wed, 06 Sep 2017 14:58:48 +0200 Johannes Berg wrote: > +void __ieee80211_start_rx_ba_session(struct sta_info *sta, > + u8 dialog_token, u16 timeout, > + u16 start_seq_num, u16 ba_policy, u16 tid, > +

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 31/08/2017 21:18, Florian Fainelli wrote: On 08/31/2017 12:09 PM, Mason wrote: 1) nb8800_link_reconfigure() calls phy_print_status() which prints the "Link down" and "Link up" messages to the console. With the patch reverted, nothing is printed when the link goes down, and the result is

Re: [PATCH v2 rfc 8/8] net: dsa: Fix SWITCHDEV_ATTR_ID_PORT_PARENT_ID

> > Use the MAC address of the master interface as the parent ID. This is > > the same for all switches in a cluster, and should be unique if there > > are multiple clusters. > > That is not correct. Support for multiple CPU ports is coming and in > this case, you can have two CPU host interfaces

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

On Wed, Sep 06, 2017 at 04:46:51PM +0200, Matthias May wrote: > > Hi Andrew > We are using the 88E6321. > In our setup we are using openvswitch and not a bridge, however the problem > you describe seems to be the same. > > We had to configure the switch to flood unknown multicast (Egress Floods

[PATCH net-next 0/1] netvsc hot plug fix

This is one fix for problems with hot add of network device on Windows Server. Stephen Hemminger (1): hv_netvsc: fix deadlock on hotplug drivers/net/hyperv/hyperv_net.h | 1 + drivers/net/hyperv/netvsc_drv.c | 8 +-- drivers/net/hyperv/rndis_filter.c | 106

[PATCH net-next 1/1] hv_netvsc: fix deadlock on hotplug

When a virtual device is added dynamically (via host console), then the vmbus sends an offer message for the primary channel. The processing of this message for networking causes the network device to then initialize the sub channels. The problem is that setting up the sub channels needs to wait

Re: [PATCH net 3/4] lan78xx: Fix for eeprom read/write when device autosuspend

Hi Nisar > + else if ((ee->magic == LAN78XX_EEPROM_MAGIC) && > + (ee->offset >= 0 && ee->offset < MAX_EEPROM_SIZE) && > + (ee->len > 0 && (ee->offset + ee->len) <= MAX_EEPROM_SIZE)) > + ret = lan78xx_write_raw_eeprom(dev, ee->offset, ee->len, data); This

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

> > What i found is that the Marvell chips don't flood broadcast frames > > between bridged ports. What appears to happen is there is a fdb miss, > > so it gets forwarded to the CPU port for the host to deal with. The > > software bridge when floods it out all ports of the bridge. > > Do you have

Re: hung task in mac80211

On Wed, 2017-09-06 at 16:27 +0200, Stefano Brivio wrote: > > Sorry for the extended bothering :) but here, you're extending quite > a bit the scope of the lock also > when__ieee80211_start_rx_ba_session() is called by > ieee80211_process_addba_request(). I know, but it doesn't matter. > No idea

Re: [PATCH 6/10] ixgbe: Use ARRAY_SIZE macro

On Wed, 2017-09-06 at 11:08 +0200, Thomas Meyer wrote: > On Tue, Sep 05, 2017 at 02:22:05PM -0700, David Miller wrote: > > nothing prevented you from CC:'ing the maintainer, > > Jeff Kirscher. [] > That's the other condition in my script. I only send to the role > "maintainer" from the output of

Re: [PATCH net-next] xdp: implement xdp_redirect_map for generic XDP

On Wed, 06 Sep 2017 18:24:07 +0200 Daniel Borkmann wrote: > On 09/06/2017 05:26 PM, Jesper Dangaard Brouer wrote: > > Using bpf_redirect_map is allowed for generic XDP programs, but the > > appropriate map lookup was never performed in xdp_do_generic_redirect(). > > > >

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 09/06/2017 07:55 AM, Mason wrote: > On 31/08/2017 21:18, Florian Fainelli wrote: > >> On 08/31/2017 12:09 PM, Mason wrote: >> >>> 1) nb8800_link_reconfigure() calls phy_print_status() >>> which prints the "Link down" and "Link up" messages >>> to the console. With the patch reverted, nothing

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 09/06/2017 08:51 AM, Mason wrote: > On 31/08/2017 21:18, Florian Fainelli wrote: > >> On 08/31/2017 12:09 PM, Mason wrote: >> >>> On 31/08/2017 19:03, Florian Fainelli wrote: >>> On 08/31/2017 05:29 AM, Marc Gonzalez wrote: > On 31/08/2017 02:49, Florian Fainelli wrote: >

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

On 09/06/2017 09:42 AM, Andrew Lunn wrote: >>> On the switch asics we work with, the driver has information if the >>> packet was >>> forwarded in hardware. This is per packet reason code telling why the >>> CPU is seeing the packet. >>> The driver can use this information to reset

[PATCH 13/14] netfilter/ipvs: Use %pS printk format for direct addresses

The debug and error printk functions in ipvs uses wrongly the %pF instead of the %pS printk format specifier for printing symbols for the address returned by _builtin_return_address(0). Fix it for the ia64, ppc64 and parisc64 architectures. Signed-off-by: Helge Deller Cc: Wensong

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 09/06/2017 11:59 AM, Florian Fainelli wrote: On 09/06/2017 11:00 AM, David Daney wrote: On 08/31/2017 11:29 AM, Florian Fainelli wrote: On 08/31/2017 11:12 AM, Mason wrote: On 31/08/2017 19:53, Florian Fainelli wrote: On 08/31/2017 10:49 AM, Mason wrote: On 31/08/2017 18:57, Florian

[PATCH v2 net-next 2/2] hv_netvsc: avoid unnecessary wakeups on subchannel creation

Only need to wakeup the initiator after all sub-channels are opened. Signed-off-by: Stephen Hemminger --- drivers/net/hyperv/rndis_filter.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/hyperv/rndis_filter.c

Re: [net-next:master 491/511] xt_hashlimit.c:undefined reference to `__aeabi_uldivmod'

On Wed, Sep 6, 2017 at 5:27 PM, kbuild test robot wrote: > Hi Arnd, > > It's probably a bug fix that unveils the link errors. Correct. >net/netfilter/xt_hashlimit.o: In function `hashlimit_mt_common': >>> xt_hashlimit.c:(.text+0x1f68): undefined reference to

Re: [PATCH] netfilter: xt_hashlimit: avoid 64-bit division

On 09/06/2017 03:57 PM, Arnd Bergmann wrote: > 64-bit division is expensive on 32-bit architectures, and > requires a special function call to avoid a link error like: > > net/netfilter/xt_hashlimit.o: In function `hashlimit_mt_common': > xt_hashlimit.c:(.text+0x1328): undefined reference to

Re: [PATCH] netfilter: xt_hashlimit: avoid 64-bit division

On Wed, Sep 6, 2017 at 10:22 PM, Vishwanath Pai wrote: > On 09/06/2017 03:57 PM, Arnd Bergmann wrote: >> 64-bit division is expensive on 32-bit architectures, and >> requires a special function call to avoid a link error like: >> >> net/netfilter/xt_hashlimit.o: In function

RE: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

> From: Jorgen S. Hansen [mailto:jhan...@vmware.com] > Sent: Wednesday, September 6, 2017 7:11 AM >> ... > > I'm currently working on NFS over AF_VSOCK and sock_diag support (for > > ss(8) and netstat-like tools). > > > > Multi-transport support is lower priority for me at the moment. I'm > >

[PATCH] netfilter: xt_hashlimit: avoid 64-bit division

64-bit division is expensive on 32-bit architectures, and requires a special function call to avoid a link error like: net/netfilter/xt_hashlimit.o: In function `hashlimit_mt_common': xt_hashlimit.c:(.text+0x1328): undefined reference to `__aeabi_uldivmod' In the case of hashlimit_mt_common, we

Re: [patch net] net: sched: fix memleak for chain zero

Wed, Sep 06, 2017 at 07:40:02PM CEST, xiyou.wangc...@gmail.com wrote: >On Wed, Sep 6, 2017 at 4:14 AM, Jiri Pirko wrote: >> From: Jiri Pirko >> >> There's a memleak happening for chain 0. The thing is, chain 0 needs to >> be always present, not created on

[wireless-testsing2:master 4/5] drivers/net//ethernet/marvell/mvpp2.c:7618:2: warning: passing argument 4 of 'mvpp2_port_copy_mac_addr' from incompatible pointer type

tree: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-testing.git master head: d17be7f7503bf9492198a242779a68af93fd92de commit: 96c03618031bae5e9068b16f9e437b79f98f6482 [4/5] Merge remote-tracking branch 'mac80211-next/master' config: xtensa-allyesconfig (attached as

[PATCH v2 net-next 0/2] hv_netvsc: sub channel initialization fixes

One serious deadlock, and one minor optimization. Stephen Hemminger (2): hv_netvsc: fix deadlock on hotplug hv_netvsc: avoid unnecessary wakeups on subchannel creation drivers/net/hyperv/hyperv_net.h | 3 + drivers/net/hyperv/netvsc.c | 3 + drivers/net/hyperv/netvsc_drv.c |

[PATCH v2 net-next 1/2] hv_netvsc: fix deadlock on hotplug

When a virtual device is added dynamically (via host console), then the vmbus sends an offer message for the primary channel. The processing of this message for networking causes the network device to then initialize the sub channels. The problem is that setting up the sub channels needs to wait

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 09/06/2017 07:33 AM, Mason wrote: On 31/08/2017 20:29, Florian Fainelli wrote: On 08/31/2017 11:12 AM, Mason wrote: On 31/08/2017 19:53, Florian Fainelli wrote: On 08/31/2017 10:49 AM, Mason wrote: On 31/08/2017 18:57, Florian Fainelli wrote: And the race is between phy_detach() setting

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 09/06/2017 11:00 AM, David Daney wrote: > On 08/31/2017 11:29 AM, Florian Fainelli wrote: >> On 08/31/2017 11:12 AM, Mason wrote: >>> On 31/08/2017 19:53, Florian Fainelli wrote: On 08/31/2017 10:49 AM, Mason wrote: > On 31/08/2017 18:57, Florian Fainelli wrote: >> And the race is

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 06/09/2017 20:00, David Daney wrote: > On 08/31/2017 11:29 AM, Florian Fainelli wrote: >> On 08/31/2017 11:12 AM, Mason wrote: >>> On 31/08/2017 19:53, Florian Fainelli wrote: On 08/31/2017 10:49 AM, Mason wrote: > On 31/08/2017 18:57, Florian Fainelli wrote: >> And the race is

Re: [patch net] net: sched: fix memleak for chain zero

On Wed, Sep 6, 2017 at 4:14 AM, Jiri Pirko wrote: > From: Jiri Pirko > > There's a memleak happening for chain 0. The thing is, chain 0 needs to > be always present, not created on demand. Therefore tcf_block_get upon > creation of block calls the

RE: [PATCH net 3/4] lan78xx: Fix for eeprom read/write when device autosuspend

Thanks, will make separate patch. > Hi Nisar > > > + else if ((ee->magic == LAN78XX_EEPROM_MAGIC) && > > +(ee->offset >= 0 && ee->offset < MAX_EEPROM_SIZE) && > > +(ee->len > 0 && (ee->offset + ee->len) <= > MAX_EEPROM_SIZE)) > > + ret =

  1   2   >