Re: Regression in 39461af74125 "bitmap: replace bitmap_{from,to}_u32array"

[Yury Norov]

On Mon, Feb 05, 2018 at 07:21:32AM +0100, Heiner Kallweit wrote:
> Recently ethtool started to give incomplete values for supported and
> advertised modes. There seems to be a regression in this commit:
> The bit number parameter in the calls to bitmap_to_arr32() in
> store_link_ksettings_for_user() should be __ETHTOOL_LINK_MODE_MASK_NBITS
> instead of __ETHTOOL_LINK_MODE_MASK_NU32.
> 
> After having changed this ethtool behaves normally again.
> 
> Heiner

Hi Heiner,

Thank you for discovering this, and sorry for my error. 
The patch is below.

Yury

>From af960f7ae1be8e86abfaa39300ba690c24a80e5b Mon Sep 17 00:00:00 2001
From: Yury Norov 
Date: Mon, 5 Feb 2018 10:01:59 +0300
Subject: [PATCH] Fix 39461af74125 "bitmap: replace bitmap_{from,to}_u32array"

During rework, bitmap_to_arr32() was erroneously passed with
__ETHTOOL_LINK_MODE_MASK_NU32 instead of __ETHTOOL_LINK_MODE_MASK_NBITS.

Fixes: 39461af74125fd268 (bitmap: replace bitmap_{from,to}_u32array)
Reported-by: Heiner Kallweit 
Signed-off-by: Yury Norov 
---
 net/core/ethtool.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 1822335518ea..494e6a5d7306 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -642,13 +642,13 @@ store_link_ksettings_for_user(void __user *to,
memcpy(_usettings.base, >base, sizeof(link_usettings));
bitmap_to_arr32(link_usettings.link_modes.supported,
from->link_modes.supported,
-   __ETHTOOL_LINK_MODE_MASK_NU32);
+   __ETHTOOL_LINK_MODE_MASK_NBITS);
bitmap_to_arr32(link_usettings.link_modes.advertising,
from->link_modes.advertising,
-   __ETHTOOL_LINK_MODE_MASK_NU32);
+   __ETHTOOL_LINK_MODE_MASK_NBITS);
bitmap_to_arr32(link_usettings.link_modes.lp_advertising,
from->link_modes.lp_advertising,
-   __ETHTOOL_LINK_MODE_MASK_NU32);
+   __ETHTOOL_LINK_MODE_MASK_NBITS);
 
if (copy_to_user(to, _usettings, sizeof(link_usettings)))
return -EFAULT;
-- 
2.14.1

Regression in 39461af74125 "bitmap: replace bitmap_{from,to}_u32array"

[Heiner Kallweit]

Recently ethtool started to give incomplete values for supported and
advertised modes. There seems to be a regression in this commit:
The bit number parameter in the calls to bitmap_to_arr32() in
store_link_ksettings_for_user() should be __ETHTOOL_LINK_MODE_MASK_NBITS
instead of __ETHTOOL_LINK_MODE_MASK_NU32.

After having changed this ethtool behaves normally again.

Heiner

Re: [PATCH] DT: net: renesas,ravb: document R8A77980 bindings

[Rob Herring]

On Thu, Feb 01, 2018 at 11:13:45PM +0300, Sergei Shtylyov wrote:
> Renesas R-Car V3H (R8A77980) SoC has the R-Car gen3 compatible EtherAVB
> device, so document the SoC specific bindings.
> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
> The patch is against DaveM's 'net-next.git' repo but I wouldn't mind if it's
> applied to 'net.git' instead. :-)
> 
>  Documentation/devicetree/bindings/net/renesas,ravb.txt |1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Rob Herring 

Re: r8169 take too long to complete driver initialization

[Chris Chiu]

On Fri, Feb 2, 2018 at 7:49 PM, Hau  wrote:
>
>> -Original Message-
>> From: Chris Chiu [mailto:c...@endlessm.com]
>> Sent: Friday, February 2, 2018 10:03 AM
>> To: Hau 
>> Cc: nic_swsd ; netdev@vger.kernel.org; Linux
>> Kernel ; Linux Upstreaming Team
>> 
>> Subject: Re: r8169 take too long to complete driver initialization
>>
>> On Tue, Jan 30, 2018 at 8:07 PM, Chris Chiu  wrote:
>> > On Mon, Jan 29, 2018 at 11:24 PM, Hau  wrote:
>> >> Hi Chris,
>> >>
>> >> Could you test following patch?
>> >>
>> >>  DECLARE_RTL_COND(rtl_ocp_tx_cond)
>> >>  {
>> >> void __iomem *ioaddr = tp->mmio_addr;
>> >>
>> >> -   return RTL_R8(IBISR0) & 0x02;
>> >> +   return RTL_R8(IBISR0) & 0x20;
>> >>  }
>> >>
>> >>  static void rtl8168ep_stop_cmac(struct rtl8169_private *tp)  {
>> >> void __iomem *ioaddr = tp->mmio_addr;
>> >>
>> >> RTL_W8(IBCR2, RTL_R8(IBCR2) & ~0x01);
>> >> -   rtl_msleep_loop_wait_low(tp, _ocp_tx_cond, 50, 2000);
>> >> +   rtl_msleep_loop_wait_high(tp, _ocp_tx_cond, 50, 2000);
>> >> RTL_W8(IBISR0, RTL_R8(IBISR0) | 0x20);
>> >> RTL_W8(IBCR0, RTL_R8(IBCR0) & ~0x01);  }
>> >>
>> >> Thanks.
>> >>
>> >
>> > Yes. It completes the initialization in 70 ms. So it means the
>> > rtl_ocp_tx_cond are waiting for incorrect register bit? Can you help work
>> out a patch for this?
>> >
>> > Chris
>> >
>> >
>>
>> Gentle ping,
>> cheers.
>>
>> Chris
>>
>
> I have submitted the patch to kernel team.
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=086ca23d03c0d2f4088f472386778d293e15c5f6
>
>

Cool. Thanks for this.

Chris

> --Please consider the environment before printing this e-mail.
>
>> >>> -Original Message-
>> >>> From: Chris Chiu [mailto:c...@endlessm.com]
>> >>> Sent: Monday, January 29, 2018 6:12 PM
>> >>> To: nic_swsd ; netdev@vger.kernel.org; Linux
>> >>> Kernel ; Linux Upstreaming Team
>> >>> 
>> >>> Subject: Re: r8169 take too long to complete driver initialization
>> >>>
>> >>> On Fri, Jan 5, 2018 at 10:17 AM, Chris Chiu  wrote:
>> >>> > On Wed, Dec 20, 2017 at 4:41 PM, Chris Chiu 
>> wrote:
>> >>> >> Hi,
>> >>> >> We've hit a suspend/resume issue on a Acer desktop caused by
>> >>> >> r8169 driver. The dmseg
>> >>> >>
>> https://gist.github.com/mschiu77/b741849b5070281daaead8dfee312d1a
>> >>> >> shows it's still in msleep() within a mutex lock.
>> >>> >> After looking into the code, it's caused by the
>> >>> >> rtl8168ep_stop_cmac() which is waiting 100 seconds for
>> >>> >> rtl_ocp_tx_cond. The following dmesg states that the r8169 driver
>> >>> >> is loaded.
>> >>> >>
>> >>> >> [   20.270526] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
>> >>> >>
>> >>> >> But it takes > 100 seconds to get the following messages
>> >>> >>
>> >>> >> [  140.400223] r8169 :02:00.0 (unnamed net_device)
>> >>> >> (uninitialized): rtl_ocp_tx_cond == 1 (loop: 2000, delay: 50).
>> >>> >> [  140.413294] r8169 :02:00.0 eth0: RTL8168ep/8111ep at
>> >>> >> 0xb16c80db1000, f8:0f:41:ea:74:0d, XID 10200800 IRQ 46 [
>> >>> >> 140.413297] r8169 :02:00.0 eth0: jumbo features [frames: 9200
>> >>> >> bytes, tx checksumming: ko]
>> >>> >>
>> >>> >> So any trial to suspend the machine during this period would
>> >>> >> always get device/resource busy message then abort. Is this
>> >>> >> rtl_ocp_tx_cond necessary? Because the ethernet is still working
>> >>> >> and I don't see any problem. I don't know it should be considered
>> >>> >> normal or not. Please let me know if any more information
>> >>> >> required. Thanks
>> >>> >>
>> >>> >> Chris
>> >>> >
>> >>> > gentle ping,
>> >>> >
>> >>> > cheers.
>> >>>
>> >>> Hi,
>> >>> Just found a r8168 driver which seems to be authrized by realtek
>> >>> for cross comparison. I tried applying the patch to latest 4.15
>> >>> kernel and the driver done it's initialization in faily short time. The 
>> >>> patch
>> file is here
>> >>> https://gist.github.com/mschiu77/fcf406e64a1a437f46cf2be643f1057d.
>> >>>
>> >>> In mainline r8169.c, the IBISR0 register need to be polled in
>> >>> the rtl8168ep_stop_cmac().
>> >>> In the patch file, there's also the same IBISR0 polling code in
>> >>> Dash2DisableTx(), but it's been bypassed since the chipset maches
>> >>> HW_DASH_SUPPORT_TYPE_2.
>> >>> Per the rtl_chip_info[] in r8168_n.c, CFG_METHOD_23/27/28 are
>> >>> HW_DASH_SUPPORT_TYPE_2, and they happens to be the only 3 named
>> >>> RTL8168EP/8111EP in the rtl_chip_info[].
>> >>>
>> >>> To find the same matches in r8169.c, RTL_GIGA_MAC_VER_49/50/51
>> >>> seems share the same config. Can anyone clarify if the
>> >>> rtl_ocp_tx_cond() really necessary for 8168EP/8111EP?
>> >>> Or we can just ignore the condition check for
>> 

[PATCH v2] net: sched: tbf: handle GSO_BY_FRAGS case in enqueue

[Daniel Axtens]

tbf_enqueue() checks the size of a packet before enqueuing it.
However, the GSO size check does not consider the GSO_BY_FRAGS
case, and so will drop GSO SCTP packets, causing a massive drop
in throughput.

Use skb_gso_validate_mac_len() instead, as it does consider that
case.

Signed-off-by: Daniel Axtens 

---

skb_gso_validate_mac_len() is an out-of-line call, but so is
skb_gso_mac_seglen(), so this is slower but not much slower. I
will send a patch to make the skb_gso_validate_* functions
inline-able shortly.

Also, GSO_BY_FRAGS considered harmful - I'm pretty sure this is
not the only place it causes issues.

v2: put S-o-b in the right spot, thanks Andrew Donnellan

---
 net/sched/sch_tbf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/sched/sch_tbf.c b/net/sched/sch_tbf.c
index 229172d509cc..03225a8df973 100644
--- a/net/sched/sch_tbf.c
+++ b/net/sched/sch_tbf.c
@@ -188,7 +188,8 @@ static int tbf_enqueue(struct sk_buff *skb, struct Qdisc 
*sch,
int ret;
 
if (qdisc_pkt_len(skb) > q->max_size) {
-   if (skb_is_gso(skb) && skb_gso_mac_seglen(skb) <= q->max_size)
+   if (skb_is_gso(skb) &&
+   skb_gso_validate_mac_len(skb, q->max_size))
return tbf_segment(skb, sch, to_free);
return qdisc_drop(skb, sch, to_free);
}
-- 
2.14.1

[PATCH net] dwc-xlgmac: remove Jie Deng as co-maintainer

[Jie Deng]

Jose Abreu is working on this driver and I will leave Synopsys soon.
Thus it does not seem appropriate for me to be a co-maintainer anymore.

Signed-off-by: Jie Deng 
---
 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index b59a8cd..8903842 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13289,7 +13289,6 @@ F:  include/linux/platform_data/dma-dw.h
 F: drivers/dma/dw/
 
 SYNOPSYS DESIGNWARE ENTERPRISE ETHERNET DRIVER
-M: Jie Deng 
 M: Jose Abreu 
 L: netdev@vger.kernel.org
 S: Supported
-- 
2.7.4

[PATCH] net: sched: tbf: handle GSO_BY_FRAGS case in enqueue

[Daniel Axtens]

tbf_enqueue() checks the size of a packet before enqueuing it.
However, the GSO size check does not consider the GSO_BY_FRAGS
case, and so will drop GSO SCTP packets, causing a massive drop
in throughput.

Use skb_gso_validate_mac_len() instead, as it does consider that
case.

---

skb_gso_validate_mac_len() is an out-of-line call, but so is
skb_gso_mac_seglen(), so this is slower but not much slower. I
will send a patch to make the skb_gso_validate_* functions
inline-able shortly.

Also, GSO_BY_FRAGS considered harmful - I'm pretty sure this is
not the only place it causes issues.

Signed-off-by: Daniel Axtens 
---
 net/sched/sch_tbf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/sched/sch_tbf.c b/net/sched/sch_tbf.c
index 229172d509cc..03225a8df973 100644
--- a/net/sched/sch_tbf.c
+++ b/net/sched/sch_tbf.c
@@ -188,7 +188,8 @@ static int tbf_enqueue(struct sk_buff *skb, struct Qdisc 
*sch,
int ret;
 
if (qdisc_pkt_len(skb) > q->max_size) {
-   if (skb_is_gso(skb) && skb_gso_mac_seglen(skb) <= q->max_size)
+   if (skb_is_gso(skb) &&
+   skb_gso_validate_mac_len(skb, q->max_size))
return tbf_segment(skb, sch, to_free);
return qdisc_drop(skb, sch, to_free);
}
-- 
2.14.1

[PATCH v3] RDS: IB: Fix null pointer issue

[Guanglei Li]

Scenario:
1. Port down and do fail over
2. Ap do rds_bind syscall

PID: 47039  TASK: 89887e2fe640  CPU: 47  COMMAND: "kworker/u:6"
 #0 [898e35f159f0] machine_kexec at 8103abf9
 #1 [898e35f15a60] crash_kexec at 810b96e3
 #2 [898e35f15b30] oops_end at 8150f518
 #3 [898e35f15b60] no_context at 8104854c
 #4 [898e35f15ba0] __bad_area_nosemaphore at 81048675
 #5 [898e35f15bf0] bad_area_nosemaphore at 810487d3
 #6 [898e35f15c00] do_page_fault at 815120b8
 #7 [898e35f15d10] page_fault at 8150ea95
[exception RIP: unknown or invalid address]
RIP:   RSP: 898e35f15dc8  RFLAGS: 00010282
RAX: fffe  RBX: 889b77f6fc00  RCX:81c99d88
RDX:   RSI: 896019ee08e8  RDI:889b77f6fc00
RBP: 898e35f15df0   R8: 896019ee08c8  R9:
R10: 0400  R11:   R12:896019ee08c0
R13: 889b77f6fe68  R14: 81c99d80  R15: a022a1e0
ORIG_RAX:   CS: 0010 SS: 0018
 #8 [898e35f15dc8] cma_ndev_work_handler at a022a228 [rdma_cm]
 #9 [898e35f15df8] process_one_work at 8108a7c6
 #10 [898e35f15e58] worker_thread at 8108bda0
 #11 [898e35f15ee8] kthread at 81090fe6

PID: 45659  TASK: 880d313d2500  CPU: 31  COMMAND: "oracle_45659_ap"
 #0 [881024ccfc98] __schedule at 8150bac4
 #1 [881024ccfd40] schedule at 8150c2cf
 #2 [881024ccfd50] __mutex_lock_slowpath at 8150cee7
 #3 [881024ccfdc0] mutex_lock at 8150cdeb
 #4 [881024ccfde0] rdma_destroy_id at a022a027 [rdma_cm]
 #5 [881024ccfe10] rds_ib_laddr_check at a0357857 [rds_rdma]
 #6 [881024ccfe50] rds_trans_get_preferred at a0324c2a [rds]
 #7 [881024ccfe80] rds_bind at a031d690 [rds]
 #8 [881024ccfeb0] sys_bind at 8142a670

PID: 45659  PID: 47039
rds_ib_laddr_check
  /* create id_priv with a null event_handler */
  rdma_create_id
  rdma_bind_addr
cma_acquire_dev
  /* add id_priv to cma_dev->id_list */
  cma_attach_to_dev
cma_ndev_work_handler
  /* event_hanlder is null */
  id_priv->id.event_handler

Signed-off-by: Guanglei Li 
Signed-off-by: Honglei Wang 
Reviewed-by: Junxiao Bi 
Reviewed-by: Yanjun Zhu 
Reviewed-by: Leon Romanovsky 
Acked-by: Santosh Shilimkar 
---
 net/rds/ib.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/rds/ib.c b/net/rds/ib.c
index b2a5067..ff0c980 100644
--- a/net/rds/ib.c
+++ b/net/rds/ib.c
@@ -345,7 +345,8 @@ static int rds_ib_laddr_check(struct net *net, __be32 addr)
/* Create a CMA ID and try to bind it. This catches both
 * IB and iWARP capable NICs.
 */
-   cm_id = rdma_create_id(_net, NULL, NULL, RDMA_PS_TCP, IB_QPT_RC);
+   cm_id = rdma_create_id(_net, rds_rdma_cm_event_handler,
+  NULL, RDMA_PS_TCP, IB_QPT_RC);
if (IS_ERR(cm_id))
return PTR_ERR(cm_id);
 
-- 
2.7.4

[PATCH] doc: Change the min default value of tcp_wmem/tcp_rmem.

[Tonghao Zhang]

The SK_MEM_QUANTUM was changed from PAGE_SIZE to 4096. And the
tcp_wmem/tcp_rmem min default values are 4096.

Fixes: bd68a2a854ad ("net: set SK_MEM_QUANTUM to 4096")
Cc: Eric Dumazet 
Signed-off-by: Tonghao Zhang 
---
 Documentation/networking/ip-sysctl.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/networking/ip-sysctl.txt 
b/Documentation/networking/ip-sysctl.txt
index 3f2c40d..a553d4e 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -508,7 +508,7 @@ tcp_rmem - vector of 3 INTEGERs: min, default, max
min: Minimal size of receive buffer used by TCP sockets.
It is guaranteed to each TCP socket, even under moderate memory
pressure.
-   Default: 1 page
+   Default: 4K
 
default: initial size of receive buffer used by TCP sockets.
This value overrides net.core.rmem_default used by other protocols.
@@ -667,7 +667,7 @@ tcp_window_scaling - BOOLEAN
 tcp_wmem - vector of 3 INTEGERs: min, default, max
min: Amount of memory reserved for send buffers for TCP sockets.
Each TCP socket has rights to use it due to fact of its birth.
-   Default: 1 page
+   Default: 4K
 
default: initial size of send buffer used by TCP sockets.  This
value overrides net.core.wmem_default used by other protocols.
-- 
1.8.3.1

[PATCH 18/20] iwlwifi: fix malformed CONFIG_IWLWIFI_PCIE_RTPM default

[Ulf Magnusson]

'default false' should be 'default n', though they happen to have the
same effect here, due to undefined symbols ('false' in this case)
evaluating to n in a tristate sense.

Remove the default instead of changing it. bool and tristate symbols
implicitly default to n.

Discovered with the
https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined.py
script.

Signed-off-by: Ulf Magnusson 
---
 drivers/net/wireless/intel/iwlwifi/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/Kconfig 
b/drivers/net/wireless/intel/iwlwifi/Kconfig
index c5f2ddf9b0fe..e5a2fc738ac3 100644
--- a/drivers/net/wireless/intel/iwlwifi/Kconfig
+++ b/drivers/net/wireless/intel/iwlwifi/Kconfig
@@ -91,7 +91,6 @@ config IWLWIFI_BCAST_FILTERING
 config IWLWIFI_PCIE_RTPM
bool "Enable runtime power management mode for PCIe devices"
depends on IWLMVM && PM && EXPERT
-   default false
help
  Say Y here to enable runtime power management for PCIe
  devices.  If enabled, the device will go into low power mode
-- 
2.14.1

Re: [PATCH net] sctp: fix dst reference leak in sctp_v4_get_dst

[Marcelo Ricardo Leitner]

Hi,

On Sun, Feb 04, 2018 at 11:02:39AM +0200, Tommi Rantala wrote:
> Fix dst reference leak in sctp_v4_get_dst() introduced in commit
> 410f03831 ("sctp: add routing output fallback"):
> 
> When walking the address_list, successive ip_route_output_key() calls
> may return the same rt->dst with the reference incremented on each call.
> 
> The code would not decrement the dst refcount when the dst pointer was
> identical from the previous iteration, causing the dst leak.
> 
> Testcase:
>   ip netns add TEST
>   ip netns exec TEST ip link set lo up
>   ip link add dummy0 type dummy
>   ip link add dummy1 type dummy
>   ip link add dummy2 type dummy
>   ip link set dev dummy0 netns TEST
>   ip link set dev dummy1 netns TEST
>   ip link set dev dummy2 netns TEST
>   ip netns exec TEST ip addr add 192.168.1.1/24 dev dummy0
>   ip netns exec TEST ip link set dummy0 up
>   ip netns exec TEST ip addr add 192.168.1.2/24 dev dummy1
>   ip netns exec TEST ip link set dummy1 up
>   ip netns exec TEST ip addr add 192.168.1.3/24 dev dummy2
>   ip netns exec TEST ip link set dummy2 up
>   ip netns exec TEST sctp_test -H 192.168.1.2 -P 20002 -h 192.168.1.1 -p 
> 2 -s -B 192.168.1.3
>   ip netns del TEST

Thanks for the detailed steps. I'll adapt and include it on
github/sctp/sctp-tests

> 
> In 4.4 and 4.9 kernels this results to:

I wonder why you couldn't reproduce this on newer kernels. Maybe
something masked it?

>   [  354.179591] unregister_netdevice: waiting for lo to become free. Usage 
> count = 1
>   [  364.419674] unregister_netdevice: waiting for lo to become free. Usage 
> count = 1
>   [  374.663664] unregister_netdevice: waiting for lo to become free. Usage 
> count = 1
>   [  384.903717] unregister_netdevice: waiting for lo to become free. Usage 
> count = 1
>   [  395.143724] unregister_netdevice: waiting for lo to become free. Usage 
> count = 1
>   [  405.383645] unregister_netdevice: waiting for lo to become free. Usage 
> count = 1
>   ...
> 
> Fixes: 410f03831 ("sctp: add routing output fallback")
> Acked-by: Neil Horman 
> Cc: Marcelo Ricardo Leitner 
> Cc: Alexey Kodanev 
> Signed-off-by: Tommi Rantala 
> ---
>  net/sctp/protocol.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
> index 8b4ff315695e..aadb9e7f60e2 100644
> --- a/net/sctp/protocol.c
> +++ b/net/sctp/protocol.c
> @@ -508,21 +508,20 @@ static void sctp_v4_get_dst(struct sctp_transport *t, 
> union sctp_addr *saddr,
>   if (IS_ERR(rt))
>   continue;
>  
> - if (!dst)
> - dst = >dst;
> -
>   /* Ensure the src address belongs to the output
>* interface.
>*/
>   odev = __ip_dev_find(sock_net(sk), laddr->a.v4.sin_addr.s_addr,
>false);
>   if (!odev || odev->ifindex != fl4->flowi4_oif) {
> - if (>dst != dst)
> + if (!dst)
> + dst = >dst;
> + else
>   dst_release(>dst);
>   continue;
>   }
>  
> - if (dst != >dst)
> + if (dst && dst != >dst)
>   dst_release(dst);
>   dst = >dst;
>   break;
> -- 
> 2.15.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH bpf] bpf: fix selftests/bpf test_kmod.sh failure when CONFIG_BPF_JIT_ALWAYS_ON=y

[Daniel Borkmann]

On 02/03/2018 07:37 AM, Yonghong Song wrote:
> With CONFIG_BPF_JIT_ALWAYS_ON is defined in the config file,
> tools/testing/selftests/bpf/test_kmod.sh failed like below:
[...]
> With this logic, Test #297 always gets return value -ENOTSUPP
> when CONFIG_BPF_JIT_ALWAYS_ON is defined, causing the test failure.
> 
> This patch fixed the failure by marking Test #297 as expected failure
> when CONFIG_BPF_JIT_ALWAYS_ON is defined.
> 
> Fixes: 290af86629b2 (bpf: introduce BPF_JIT_ALWAYS_ON config)
> Signed-off-by: Yonghong Song 

Applied to bpf tree, thanks Yonghong!

Re: pull-request: bpf 2018-02-02

[David Miller]

From: Alexei Starovoitov 
Date: Fri, 2 Feb 2018 18:09:13 -0800

> The following pull-request contains BPF updates for your *net* tree.
> 
> The main changes are:
> 
> 1) support XDP attach in libbpf, from Eric.
> 
> 2) minor fixes, from Daniel, Jakub, Yonghong, Alexei.
> 
> Please consider pulling these changes from:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
> 
> Should be no merge conflicts.

Pulled, thanks Alexei.

Re: [Intel-wired-lan] [PATCH] e1000e: allocate ring descriptors with dma_zalloc_coherent

[Alexander Duyck]

On Sun, Feb 4, 2018 at 12:01 PM, Florian Fainelli  wrote:
>
>
> On 01/26/2018 02:24 AM, Pierre-Yves Kerbrat wrote:
>> Descriptor rings were not initialized at zero when allocated
>> When area contained garbage data, it caused skb_over_panic in
>> e1000_clean_rx_irq (if data had E1000_RXD_STAT_DD bit set)
>>
>> This patch makes use of dma_zalloc_coherent to make sure the
>> ring is memset at 0 to prevent the area from containing garbage.
>>
>> Following is the signature of the panic:
>> IODDR0@0.0: skbuff: skb_over_panic: text:80407b20 len:64010 put:64010 
>> head:ab46d800 data:ab46d842 tail:0xab47d24c end:0xab46df40 dev:eth0
>> IODDR0@0.0: BUG: failure at net/core/skbuff.c:105/skb_panic()!
>> IODDR0@0.0: Kernel panic - not syncing: BUG!
>> IODDR0@0.0:
>> IODDR0@0.0: Process swapper/0 (pid: 0, threadinfo=81728000, task=8173cc00 
>> ,cpu: 0)
>> IODDR0@0.0: SP = <815a1c0c>
>> IODDR0@0.0: Stack:  0001
>> IODDR0@0.0: b2d89800 815e33ac
>> IODDR0@0.0: ea73c040 0001
>> IODDR0@0.0: 60040003 fa0a
>> IODDR0@0.0: 0002
>> IODDR0@0.0:
>> IODDR0@0.0: 804540c0 815a1c70
>> IODDR0@0.0: b2744000 602ac070
>> IODDR0@0.0: 815a1c44 b2d89800
>> IODDR0@0.0: 8173cc00 815a1c08
>> IODDR0@0.0:
>> IODDR0@0.0: 0006
>> IODDR0@0.0: 815a1b50 
>> IODDR0@0.0: 80079434 0001
>> IODDR0@0.0: ab46df40 b2744000
>> IODDR0@0.0: b2d89800
>> IODDR0@0.0:
>> IODDR0@0.0: fa0a 8045745c
>> IODDR0@0.0: 815a1c88 fa0a
>> IODDR0@0.0: 80407b20 b2789f80
>> IODDR0@0.0: 0005 80407b20
>> IODDR0@0.0:
>> IODDR0@0.0:
>> IODDR0@0.0: Call Trace:
>> IODDR0@0.0: [<804540bc>] skb_panic+0xa4/0xa8
>> IODDR0@0.0: [<80079430>] console_unlock+0x2f8/0x6d0
>> IODDR0@0.0: [<80457458>] skb_put+0xa0/0xc0
>> IODDR0@0.0: [<80407b1c>] e1000_clean_rx_irq+0x2dc/0x3e8
>> IODDR0@0.0: [<80407b1c>] e1000_clean_rx_irq+0x2dc/0x3e8
>> IODDR0@0.0: [<804079c8>] e1000_clean_rx_irq+0x188/0x3e8
>> IODDR0@0.0: [<80407b1c>] e1000_clean_rx_irq+0x2dc/0x3e8
>> IODDR0@0.0: [<80468b48>] __dev_kfree_skb_any+0x88/0xa8
>> IODDR0@0.0: [<804101ac>] e1000e_poll+0x94/0x288
>> IODDR0@0.0: [<8046e9d4>] net_rx_action+0x19c/0x4e8
>> IODDR0@0.0:   ...
>> IODDR0@0.0: Maximum depth to print reached. Use 
>> kstack= To specify a custom value (where 0 means to 
>> display the full backtrace)
>> IODDR0@0.0: ---[ end Kernel panic - not syncing: BUG!
>
> Interesting, this dates back from the driver's initial commit, I am
> surprised that not more people did not have that problem, maybe the RX
> ring usually goes through at least one filing cycle?
>
> Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver (currently
> for ICH9 devices only)")

The Rx rings should have been filled long before we triggered this. I
would really want to see more of the call trace before we say this
fixes the bug. For instance I would be curious to see the link
messages and such from the interface. I'm not entirely convinced since
really this does get overwritten by the alloc_rx_buffers function.
Really in order to get into this state I think we would have to have a
significant number of skb allocations and/or the DMA mappings for the
skbs fail.

I'm okay with the patch since it is harmless and just zeroing out the
length field and DD bit in the descriptor. But I would want to know
more information about the architecture and how we got into this state
since it seems like this is an issue that could happen with numerous
possible causes and this addressing only one.

One concern I would have is that we are running into something that is
really more of a race issue, as we have seen in the past with PowerPC,
where the length was getting read before the DD bit due to the
pipeline optimizing things. In that case we had to introduce a barrer
that later became the dma_rmb().

Anyway that is just my $.02 on it. I am good with the patch itself and
I am okay with it being applied.

Reviewed-by: Alexander Duyck 

[PATCH v2 1/2] r8169: Dereference MMIO address immediately before use

[Andy Shevchenko]

There is no need to dereference struct rtl8169_private to get mmio_addr
in almost every function in the driver.

Replace it by using pointer to struct rtl8169_private directly.

No functional change intended.

Next step might be a conversion of RTL_Wxx() / RTL_Rxx() macros
to inline functions for sake of type checking.

Cc: Heiner Kallweit 
Signed-off-by: Andy Shevchenko 
---
 drivers/net/ethernet/realtek/r8169.c | 877 ++-
 1 file changed, 341 insertions(+), 536 deletions(-)

diff --git a/drivers/net/ethernet/realtek/r8169.c 
b/drivers/net/ethernet/realtek/r8169.c
index 0bf7d1759250..19610ab34764 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -99,12 +99,12 @@ static const int multicast_filter_limit = 32;
 #define RTL8169_PHY_TIMEOUT(10*HZ)
 
 /* write/read MMIO register */
-#define RTL_W8(reg, val8)  writeb ((val8), ioaddr + (reg))
-#define RTL_W16(reg, val16)writew ((val16), ioaddr + (reg))
-#define RTL_W32(reg, val32)writel ((val32), ioaddr + (reg))
-#define RTL_R8(reg)readb (ioaddr + (reg))
-#define RTL_R16(reg)   readw (ioaddr + (reg))
-#define RTL_R32(reg)   readl (ioaddr + (reg))
+#define RTL_W8(tp, reg, val8)  writeb((val8), tp->mmio_addr + (reg))
+#define RTL_W16(tp, reg, val16)writew((val16), tp->mmio_addr + (reg))
+#define RTL_W32(tp, reg, val32)writel((val32), tp->mmio_addr + (reg))
+#define RTL_R8(tp, reg)readb(tp->mmio_addr + (reg))
+#define RTL_R16(tp, reg)   readw(tp->mmio_addr + (reg))
+#define RTL_R32(tp, reg)   readl(tp->mmio_addr + (reg))
 
 enum mac_version {
RTL_GIGA_MAC_VER_01 = 0,
@@ -829,7 +829,7 @@ struct rtl8169_private {
void (*phy_reset_enable)(struct rtl8169_private *tp);
void (*hw_start)(struct net_device *);
unsigned int (*phy_reset_pending)(struct rtl8169_private *tp);
-   unsigned int (*link_ok)(void __iomem *);
+   unsigned int (*link_ok)(struct rtl8169_private *tp);
int (*do_ioctl)(struct rtl8169_private *tp, struct mii_ioctl_data 
*data, int cmd);
bool (*tso_csum)(struct rtl8169_private *, struct sk_buff *, u32 *);
 
@@ -984,56 +984,46 @@ static bool rtl_ocp_reg_failure(struct rtl8169_private 
*tp, u32 reg)
 
 DECLARE_RTL_COND(rtl_ocp_gphy_cond)
 {
-   void __iomem *ioaddr = tp->mmio_addr;
-
-   return RTL_R32(GPHY_OCP) & OCPAR_FLAG;
+   return RTL_R32(tp, GPHY_OCP) & OCPAR_FLAG;
 }
 
 static void r8168_phy_ocp_write(struct rtl8169_private *tp, u32 reg, u32 data)
 {
-   void __iomem *ioaddr = tp->mmio_addr;
-
if (rtl_ocp_reg_failure(tp, reg))
return;
 
-   RTL_W32(GPHY_OCP, OCPAR_FLAG | (reg << 15) | data);
+   RTL_W32(tp, GPHY_OCP, OCPAR_FLAG | (reg << 15) | data);
 
rtl_udelay_loop_wait_low(tp, _ocp_gphy_cond, 25, 10);
 }
 
 static u16 r8168_phy_ocp_read(struct rtl8169_private *tp, u32 reg)
 {
-   void __iomem *ioaddr = tp->mmio_addr;
-
if (rtl_ocp_reg_failure(tp, reg))
return 0;
 
-   RTL_W32(GPHY_OCP, reg << 15);
+   RTL_W32(tp, GPHY_OCP, reg << 15);
 
return rtl_udelay_loop_wait_high(tp, _ocp_gphy_cond, 25, 10) ?
-   (RTL_R32(GPHY_OCP) & 0x) : ~0;
+   (RTL_R32(tp, GPHY_OCP) & 0x) : ~0;
 }
 
 static void r8168_mac_ocp_write(struct rtl8169_private *tp, u32 reg, u32 data)
 {
-   void __iomem *ioaddr = tp->mmio_addr;
-
if (rtl_ocp_reg_failure(tp, reg))
return;
 
-   RTL_W32(OCPDR, OCPAR_FLAG | (reg << 15) | data);
+   RTL_W32(tp, OCPDR, OCPAR_FLAG | (reg << 15) | data);
 }
 
 static u16 r8168_mac_ocp_read(struct rtl8169_private *tp, u32 reg)
 {
-   void __iomem *ioaddr = tp->mmio_addr;
-
if (rtl_ocp_reg_failure(tp, reg))
return 0;
 
-   RTL_W32(OCPDR, reg << 15);
+   RTL_W32(tp, OCPDR, reg << 15);
 
-   return RTL_R32(OCPDR);
+   return RTL_R32(tp, OCPDR);
 }
 
 #define OCP_STD_PHY_BASE   0xa400
@@ -1076,16 +1066,12 @@ static int mac_mcu_read(struct rtl8169_private *tp, int 
reg)
 
 DECLARE_RTL_COND(rtl_phyar_cond)
 {
-   void __iomem *ioaddr = tp->mmio_addr;
-
-   return RTL_R32(PHYAR) & 0x8000;
+   return RTL_R32(tp, PHYAR) & 0x8000;
 }
 
 static void r8169_mdio_write(struct rtl8169_private *tp, int reg, int value)
 {
-   void __iomem *ioaddr = tp->mmio_addr;
-
-   RTL_W32(PHYAR, 0x8000 | (reg & 0x1f) << 16 | (value & 0x));
+   RTL_W32(tp, PHYAR, 0x8000 | (reg & 0x1f) << 16 | (value & 0x));
 
rtl_udelay_loop_wait_low(tp, _phyar_cond, 25, 20);
/*
@@ -1097,13 +1083,12 @@ static void r8169_mdio_write(struct rtl8169_private 
*tp, int reg, int value)
 
 static int r8169_mdio_read(struct rtl8169_private *tp, int reg)
 {
-   void __iomem *ioaddr = tp->mmio_addr;
int value;
 
-   RTL_W32(PHYAR, 

[PATCH v2 2/2] r8169: switch to device-managed functions in probe (part 2)

[Andy Shevchenko]

This is a follow up to the commit

  4c45d24a759d ("r8169: switch to device-managed functions in probe")

to move towards managed resources even more.

Cc: Heiner Kallweit 
Signed-off-by: Andy Shevchenko 
---
 drivers/net/ethernet/realtek/r8169.c | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/realtek/r8169.c 
b/drivers/net/ethernet/realtek/r8169.c
index 19610ab34764..774758ff63f3 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -8202,7 +8202,6 @@ static int rtl_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
struct rtl8169_private *tp;
struct mii_if_info *mii;
struct net_device *dev;
-   void __iomem *ioaddr;
int chipset, i;
int rc;
 
@@ -8260,20 +8259,13 @@ static int rtl_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
return -ENODEV;
}
 
-   rc = pci_request_regions(pdev, MODULENAME);
+   rc = pcim_iomap_regions(pdev, BIT(region), MODULENAME);
if (rc < 0) {
-   netif_err(tp, probe, dev, "could not request regions\n");
+   netif_err(tp, probe, dev, "cannot remap MMIO, aborting\n");
return rc;
}
 
-   /* ioremap MMIO region */
-   ioaddr = devm_ioremap(>dev, pci_resource_start(pdev, region),
- R8169_REGS_SIZE);
-   if (!ioaddr) {
-   netif_err(tp, probe, dev, "cannot remap MMIO, aborting\n");
-   return -EIO;
-   }
-   tp->mmio_addr = ioaddr;
+   tp->mmio_addr = pcim_iomap_table(pdev)[region];
 
if (!pci_is_pcie(pdev))
netif_info(tp, probe, dev, "not PCI Express\n");
@@ -8472,7 +8464,7 @@ static int rtl_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
pci_set_drvdata(pdev, dev);
 
netif_info(tp, probe, dev, "%s at 0x%p, %pM, XID %08x IRQ %d\n",
-  rtl_chip_infos[chipset].name, ioaddr, dev->dev_addr,
+  rtl_chip_infos[chipset].name, tp->mmio_addr, dev->dev_addr,
   (u32)(RTL_R32(tp, TxConfig) & 0x9cf0f8ff), pdev->irq);
if (rtl_chip_infos[chipset].jumbo_max != JUMBO_1K) {
netif_info(tp, probe, dev, "jumbo features [frames: %d bytes, "
-- 
2.15.1

Re: [RFC PATCH 05/10] net: dsa: mv88e6xxx: add support for GPIO configuration

[Andrew Lunn]

On Sun, Feb 04, 2018 at 11:53:58AM -0800, Florian Fainelli wrote:
> On 02/03/2018 01:40 PM, Andrew Lunn wrote:
> > From: Brandon Streiff 
> > 
> > MV88E6352 and later switches support GPIO control through the "Scratch
> > & Misc" global2 register. (Older switches do too, though with a slightly
> > different register interface. Only the 6352-style is implemented here.)
> > 
> > Add a new file, global2_scratch.c, for operations in the Scratch & Misc
> > space. Additionally, add a GPIO operations structure to present an
> > abstract view over GPIO manipulation.
> > 
> > Reverse Christmas tree and unsigned has been replaced with unsigned
> > int by Andrew Lunn.
> 
> I thought one of the comments made on Brian's original submission was to
> expose GPIO pins as a proper gpiochip which incidentally might help with
> GPIOs on the switch being used for other purposes (e.g; LEDs, etc.), is
> that an option here?

Hi Florian

The gpiochip part is quite easy. The problem is pinctrl. That is much
harder, since some of the basic assumptions are not true. Any pin can
take any function.

Adding gpiochip and pinctrl is something which can be added later. We
are not defining any DT binding here, so we don't need to consider
backwards compatibility in the future.

  Andrew

Re: PA Semi PWRficient Gigabit Ethernet doesn't work anymore since the first networking updates for the kernel 4.16

[Florian Fainelli]

On 02/04/2018 09:16 AM, Andrew Lunn wrote:
> On Sun, Feb 04, 2018 at 05:47:03PM +0100, Christian Zigotzky wrote:
>> Hello,
>>
>> The PA Semi PWRficient Gigabit Ethernet doesn't work anymore since the first
>> networking updates [1] for the kernel 4.16.
>>
>> Error messages:
>>
>> [    0.634241] libphy: pasemi gpio mdio bus: probed
>> [    0.634749] pasemi gpio mdio bus: Cannot register as MDIO bus, err -38
> 
> -38 is ENOSYS.
> 
>> --- a/drivers/net/phy/mdio_bus.c 2018-02-03 17:34:46.973045321 +0100
>> +++ b/drivers/net/phy/mdio_bus.c 2018-02-04 11:03:14.909093360 +0100
>> @@ -47,41 +47,11 @@
>>  
>>  #include "mdio-boardinfo.h"
>>  
>> -static int mdiobus_register_gpiod(struct mdio_device *mdiodev)
>> -{
>> -struct gpio_desc *gpiod = NULL;
>> -
>> -/* Deassert the optional reset signal */
>> -if (mdiodev->dev.of_node)
>> -gpiod = fwnode_get_named_gpiod(>dev.of_node->fwnode,
>> -   "reset-gpios", 0, GPIOD_OUT_LOW,
>> -   "PHY reset");
> 
> So i think you don't have GPIOLIB enabled. Hence you are hitting
> 
> http://elixir.free-electrons.com/linux/latest/source/include/linux/gpio/consumer.h#L470
> 
> static inline
> struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
>const char *propname, int index,
>enum gpiod_flags dflags,
>const char *label)
> {
>   return ERR_PTR(-ENOSYS);
> }
> 
> So rather than just deleting all this code, breaking other platforms
> that need this gpio, lets try a real fix. Please try this. If it
> works, i will formally submit it.
> 
>Andrew
> 
> From a4210ba306948497d7360927c1e532eb903c58b2 Mon Sep 17 00:00:00 2001
> From: Andrew Lunn 
> Date: Sun, 4 Feb 2018 11:09:20 -0600
> Subject: [PATCH] net: phy: Handle not having GPIO enabled in the kernel
> 
> If CONFIG_GPIOLIB is disabled, fwnode_get_named_gpiod() becomes a stub
> function, which return -ENOSYS. Handle this in the same way as
> -ENOENT, i.e. assume there is no GPIO used to reset the PHYs.
> 
> Reported-by: Christian Zigotzky 
> Signed-off-by: Andrew Lunn 

Reviewed-by: Florian Fainelli 
Fixes: bafbdd527d56 ("phylib: Add device reset GPIO support")

> ---
>  drivers/net/phy/mdio_bus.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 88272b3ac2e2..24b5511222c8 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -56,7 +56,8 @@ static int mdiobus_register_gpiod(struct mdio_device 
> *mdiodev)
>   gpiod = fwnode_get_named_gpiod(>dev.of_node->fwnode,
>  "reset-gpios", 0, GPIOD_OUT_LOW,
>  "PHY reset");
> - if (PTR_ERR(gpiod) == -ENOENT)
> + if (PTR_ERR(gpiod) == -ENOENT ||
> + PTR_ERR(gpiod) == -ENOSYS)
>   gpiod = NULL;
>   else if (IS_ERR(gpiod))
>   return PTR_ERR(gpiod);
> 

-- 
Florian

Re: [PATCH] e1000e: allocate ring descriptors with dma_zalloc_coherent

[Florian Fainelli]

On 01/26/2018 02:24 AM, Pierre-Yves Kerbrat wrote:
> Descriptor rings were not initialized at zero when allocated
> When area contained garbage data, it caused skb_over_panic in
> e1000_clean_rx_irq (if data had E1000_RXD_STAT_DD bit set)
> 
> This patch makes use of dma_zalloc_coherent to make sure the
> ring is memset at 0 to prevent the area from containing garbage.
> 
> Following is the signature of the panic:
> IODDR0@0.0: skbuff: skb_over_panic: text:80407b20 len:64010 put:64010 
> head:ab46d800 data:ab46d842 tail:0xab47d24c end:0xab46df40 dev:eth0
> IODDR0@0.0: BUG: failure at net/core/skbuff.c:105/skb_panic()!
> IODDR0@0.0: Kernel panic - not syncing: BUG!
> IODDR0@0.0:
> IODDR0@0.0: Process swapper/0 (pid: 0, threadinfo=81728000, task=8173cc00 
> ,cpu: 0)
> IODDR0@0.0: SP = <815a1c0c>
> IODDR0@0.0: Stack:  0001
> IODDR0@0.0: b2d89800 815e33ac
> IODDR0@0.0: ea73c040 0001
> IODDR0@0.0: 60040003 fa0a
> IODDR0@0.0: 0002
> IODDR0@0.0:
> IODDR0@0.0: 804540c0 815a1c70
> IODDR0@0.0: b2744000 602ac070
> IODDR0@0.0: 815a1c44 b2d89800
> IODDR0@0.0: 8173cc00 815a1c08
> IODDR0@0.0:
> IODDR0@0.0: 0006
> IODDR0@0.0: 815a1b50 
> IODDR0@0.0: 80079434 0001
> IODDR0@0.0: ab46df40 b2744000
> IODDR0@0.0: b2d89800
> IODDR0@0.0:
> IODDR0@0.0: fa0a 8045745c
> IODDR0@0.0: 815a1c88 fa0a
> IODDR0@0.0: 80407b20 b2789f80
> IODDR0@0.0: 0005 80407b20
> IODDR0@0.0:
> IODDR0@0.0:
> IODDR0@0.0: Call Trace:
> IODDR0@0.0: [<804540bc>] skb_panic+0xa4/0xa8
> IODDR0@0.0: [<80079430>] console_unlock+0x2f8/0x6d0
> IODDR0@0.0: [<80457458>] skb_put+0xa0/0xc0
> IODDR0@0.0: [<80407b1c>] e1000_clean_rx_irq+0x2dc/0x3e8
> IODDR0@0.0: [<80407b1c>] e1000_clean_rx_irq+0x2dc/0x3e8
> IODDR0@0.0: [<804079c8>] e1000_clean_rx_irq+0x188/0x3e8
> IODDR0@0.0: [<80407b1c>] e1000_clean_rx_irq+0x2dc/0x3e8
> IODDR0@0.0: [<80468b48>] __dev_kfree_skb_any+0x88/0xa8
> IODDR0@0.0: [<804101ac>] e1000e_poll+0x94/0x288
> IODDR0@0.0: [<8046e9d4>] net_rx_action+0x19c/0x4e8
> IODDR0@0.0:   ...
> IODDR0@0.0: Maximum depth to print reached. Use 
> kstack= To specify a custom value (where 0 means to 
> display the full backtrace)
> IODDR0@0.0: ---[ end Kernel panic - not syncing: BUG!

Interesting, this dates back from the driver's initial commit, I am
surprised that not more people did not have that problem, maybe the RX
ring usually goes through at least one filing cycle?

Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver (currently
for ICH9 devices only)")
-- 
Florian

Re: [RFC PATCH 05/10] net: dsa: mv88e6xxx: add support for GPIO configuration

[Florian Fainelli]

On 02/03/2018 01:40 PM, Andrew Lunn wrote:
> From: Brandon Streiff 
> 
> MV88E6352 and later switches support GPIO control through the "Scratch
> & Misc" global2 register. (Older switches do too, though with a slightly
> different register interface. Only the 6352-style is implemented here.)
> 
> Add a new file, global2_scratch.c, for operations in the Scratch & Misc
> space. Additionally, add a GPIO operations structure to present an
> abstract view over GPIO manipulation.
> 
> Reverse Christmas tree and unsigned has been replaced with unsigned
> int by Andrew Lunn.

I thought one of the comments made on Brian's original submission was to
expose GPIO pins as a proper gpiochip which incidentally might help with
GPIOs on the switch being used for other purposes (e.g; LEDs, etc.), is
that an option here?
-- 
Florian

Re: [PATCH v1] r8169: switch to device-managed functions in probe (part 2)

[Andy Shevchenko]

On Sun, 2018-02-04 at 21:29 +0200, Andy Shevchenko wrote:
> This is a follow up to the commit
> 
>   4c45d24a759d ("r8169: switch to device-managed functions in probe")
> 
> to move towards managed resources even more.
> 

Oops, sorry, it's not ready-yet version.


> Cc: Heiner Kallweit 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/net/ethernet/realtek/r8169.c | 16 
>  1 file changed, 4 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/net/ethernet/realtek/r8169.c
> b/drivers/net/ethernet/realtek/r8169.c
> index 0bf7d1759250..88aa3728d674 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -8397,7 +8397,6 @@ static int rtl_init_one(struct pci_dev *pdev,
> const struct pci_device_id *ent)
>   struct rtl8169_private *tp;
>   struct mii_if_info *mii;
>   struct net_device *dev;
> - void __iomem *ioaddr;
>   int chipset, i;
>   int rc;
>  
> @@ -8455,20 +8454,13 @@ static int rtl_init_one(struct pci_dev *pdev,
> const struct pci_device_id *ent)
>   return -ENODEV;
>   }
>  
> - rc = pci_request_regions(pdev, MODULENAME);
> + rc = pcim_iomap_regions(pdev, BIT(region), MODULENAME);
>   if (rc < 0) {
> - netif_err(tp, probe, dev, "could not request
> regions\n");
> + netif_err(tp, probe, dev, "cannot remap MMIO,
> aborting\n");
>   return rc;
>   }
>  
> - /* ioremap MMIO region */
> - ioaddr = devm_ioremap(>dev, pci_resource_start(pdev,
> region),
> -   R8169_REGS_SIZE);
> - if (!ioaddr) {
> - netif_err(tp, probe, dev, "cannot remap MMIO,
> aborting\n");
> - return -EIO;
> - }
> - tp->mmio_addr = ioaddr;
> + tp->mmio_addr = pcim_iomap_table(pdev)[region];
>  
>   if (!pci_is_pcie(pdev))
>   netif_info(tp, probe, dev, "not PCI Express\n");
> @@ -8667,7 +8659,7 @@ static int rtl_init_one(struct pci_dev *pdev,
> const struct pci_device_id *ent)
>   pci_set_drvdata(pdev, dev);
>  
>   netif_info(tp, probe, dev, "%s at 0x%p, %pM, XID %08x IRQ
> %d\n",
> -rtl_chip_infos[chipset].name, ioaddr, dev-
> >dev_addr,
> +rtl_chip_infos[chipset].name, tp->mmio_addr, dev-
> >dev_addr,
>  (u32)(RTL_R32(TxConfig) & 0x9cf0f8ff), pdev->irq);
>   if (rtl_chip_infos[chipset].jumbo_max != JUMBO_1K) {
>   netif_info(tp, probe, dev, "jumbo features [frames:
> %d bytes, "

-- 
Andy Shevchenko 
Intel Finland Oy

[PATCH v1] r8169: switch to device-managed functions in probe (part 2)

[Andy Shevchenko]

This is a follow up to the commit

  4c45d24a759d ("r8169: switch to device-managed functions in probe")

to move towards managed resources even more.

Cc: Heiner Kallweit 
Signed-off-by: Andy Shevchenko 
---
 drivers/net/ethernet/realtek/r8169.c | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/realtek/r8169.c 
b/drivers/net/ethernet/realtek/r8169.c
index 0bf7d1759250..88aa3728d674 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -8397,7 +8397,6 @@ static int rtl_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
struct rtl8169_private *tp;
struct mii_if_info *mii;
struct net_device *dev;
-   void __iomem *ioaddr;
int chipset, i;
int rc;
 
@@ -8455,20 +8454,13 @@ static int rtl_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
return -ENODEV;
}
 
-   rc = pci_request_regions(pdev, MODULENAME);
+   rc = pcim_iomap_regions(pdev, BIT(region), MODULENAME);
if (rc < 0) {
-   netif_err(tp, probe, dev, "could not request regions\n");
+   netif_err(tp, probe, dev, "cannot remap MMIO, aborting\n");
return rc;
}
 
-   /* ioremap MMIO region */
-   ioaddr = devm_ioremap(>dev, pci_resource_start(pdev, region),
- R8169_REGS_SIZE);
-   if (!ioaddr) {
-   netif_err(tp, probe, dev, "cannot remap MMIO, aborting\n");
-   return -EIO;
-   }
-   tp->mmio_addr = ioaddr;
+   tp->mmio_addr = pcim_iomap_table(pdev)[region];
 
if (!pci_is_pcie(pdev))
netif_info(tp, probe, dev, "not PCI Express\n");
@@ -8667,7 +8659,7 @@ static int rtl_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
pci_set_drvdata(pdev, dev);
 
netif_info(tp, probe, dev, "%s at 0x%p, %pM, XID %08x IRQ %d\n",
-  rtl_chip_infos[chipset].name, ioaddr, dev->dev_addr,
+  rtl_chip_infos[chipset].name, tp->mmio_addr, dev->dev_addr,
   (u32)(RTL_R32(TxConfig) & 0x9cf0f8ff), pdev->irq);
if (rtl_chip_infos[chipset].jumbo_max != JUMBO_1K) {
netif_info(tp, probe, dev, "jumbo features [frames: %d bytes, "
-- 
2.15.1

Re: [PATCH net 1/1 v1] rtnetlink: require unique netns identifier

[David Ahern]

On 2/4/18 5:11 AM, Christian Brauner wrote:
> On Sat, Feb 03, 2018 at 11:17:01AM -0800, Stephen Hemminger wrote:
>> On Sat,  3 Feb 2018 14:29:04 +0100
>> Christian Brauner  wrote:
>>
>>> +static int rtnl_ensure_unique_netns_attr(const struct sock *sk,
>>> +struct nlattr *tb[],
>>> +struct netlink_ext_ack *extack)
>>> +{
>>> +   int ret = -EINVAL;
>>> +   struct net *net = NULL, *unique_net = NULL;
>>> +
>>> +   /* Requests without network namespace ids have been able to specify
>>> +* multiple properties referring to different network namespaces so
>>> +* don't regress them.
>>> +*/
>>> +   if (!tb[IFLA_IF_NETNSID])
>>> +   return 0;
>>> +
>>> +   if (!tb[IFLA_NET_NS_PID] && !tb[IFLA_NET_NS_FD])
>>> +   return 0;
>>
>> Isn't this an error?
> 
> My reasoning was that having no explicit network namespace identifying
> attributes the caller operates on the current network namespace which is
> uniquely identified.

agreed. those are not required attributes.

Re: PA Semi PWRficient Gigabit Ethernet doesn't work anymore since the first networking updates for the kernel 4.16

[Andrew Lunn]

On Sun, Feb 04, 2018 at 05:47:03PM +0100, Christian Zigotzky wrote:
> Hello,
> 
> The PA Semi PWRficient Gigabit Ethernet doesn't work anymore since the first
> networking updates [1] for the kernel 4.16.
> 
> Error messages:
> 
> [    0.634241] libphy: pasemi gpio mdio bus: probed
> [    0.634749] pasemi gpio mdio bus: Cannot register as MDIO bus, err -38

-38 is ENOSYS.

> --- a/drivers/net/phy/mdio_bus.c  2018-02-03 17:34:46.973045321 +0100
> +++ b/drivers/net/phy/mdio_bus.c  2018-02-04 11:03:14.909093360 +0100
> @@ -47,41 +47,11 @@
>  
>  #include "mdio-boardinfo.h"
>  
> -static int mdiobus_register_gpiod(struct mdio_device *mdiodev)
> -{
> - struct gpio_desc *gpiod = NULL;
> -
> - /* Deassert the optional reset signal */
> - if (mdiodev->dev.of_node)
> - gpiod = fwnode_get_named_gpiod(>dev.of_node->fwnode,
> -"reset-gpios", 0, GPIOD_OUT_LOW,
> -"PHY reset");

So i think you don't have GPIOLIB enabled. Hence you are hitting

http://elixir.free-electrons.com/linux/latest/source/include/linux/gpio/consumer.h#L470

static inline
struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
 const char *propname, int index,
 enum gpiod_flags dflags,
 const char *label)
{
return ERR_PTR(-ENOSYS);
}

So rather than just deleting all this code, breaking other platforms
that need this gpio, lets try a real fix. Please try this. If it
works, i will formally submit it.

   Andrew

>From a4210ba306948497d7360927c1e532eb903c58b2 Mon Sep 17 00:00:00 2001
From: Andrew Lunn 
Date: Sun, 4 Feb 2018 11:09:20 -0600
Subject: [PATCH] net: phy: Handle not having GPIO enabled in the kernel

If CONFIG_GPIOLIB is disabled, fwnode_get_named_gpiod() becomes a stub
function, which return -ENOSYS. Handle this in the same way as
-ENOENT, i.e. assume there is no GPIO used to reset the PHYs.

Reported-by: Christian Zigotzky 
Signed-off-by: Andrew Lunn 
---
 drivers/net/phy/mdio_bus.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 88272b3ac2e2..24b5511222c8 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -56,7 +56,8 @@ static int mdiobus_register_gpiod(struct mdio_device *mdiodev)
gpiod = fwnode_get_named_gpiod(>dev.of_node->fwnode,
   "reset-gpios", 0, GPIOD_OUT_LOW,
   "PHY reset");
-   if (PTR_ERR(gpiod) == -ENOENT)
+   if (PTR_ERR(gpiod) == -ENOENT ||
+   PTR_ERR(gpiod) == -ENOSYS)
gpiod = NULL;
else if (IS_ERR(gpiod))
return PTR_ERR(gpiod);
-- 
2.15.1

[no subject]

[Jones]

This is in regards to an inheritance on your surname, reply back using your 
email address, stating your full name for more details. Reply to email for 
info. Email me here ( ger...@dr.com )

PA Semi PWRficient Gigabit Ethernet doesn't work anymore since the first networking updates for the kernel 4.16

[Christian Zigotzky]

Hello,

The PA Semi PWRficient Gigabit Ethernet doesn't work anymore since the 
first networking updates [1] for the kernel 4.16.


Error messages:

[    0.634241] libphy: pasemi gpio mdio bus: probed
[    0.634749] pasemi gpio mdio bus: Cannot register as MDIO bus, err -38
[    2.311496] pasemi_mac :00:14.0: runtime IRQ mapping not provided 
by arch
[    2.311554] pasemi_mac :00:14.1: runtime IRQ mapping not provided 
by arch
[    2.311599] pasemi_mac :00:14.2: runtime IRQ mapping not provided 
by arch
[    2.311641] pasemi_mac :00:14.3: runtime IRQ mapping not provided 
by arch
[    2.312276] pasemi_mac :00:15.0: runtime IRQ mapping not provided 
by arch
[    2.312903] pasemi_mac :00:15.1: runtime IRQ mapping not provided 
by arch
[    3.817420] i2c-pasemi :00:1c.0: runtime IRQ mapping not provided 
by arch
[    3.817616] i2c-pasemi :00:1c.1: runtime IRQ mapping not provided 
by arch
[    3.817809] i2c-pasemi :00:1c.2: runtime IRQ mapping not provided 
by arch
[    4.299984] pasemi_edac :00:04.0: runtime IRQ mapping not 
provided by arch
[    4.300281] pasemi_edac :00:05.0: runtime IRQ mapping not 
provided by arch

[   39.633565] pasemi_mac :00:14.3: PHY init failed: -19.
[   39.633569] pasemi_mac :00:14.3: Defaulting to 1Gbit full duplex

I figured out that the problematic code is in the mdio bus changes of 
the networking updates. [1]


I found the problematic code in the file 'drivers/net/phy/mdio_bus.c'. I 
created a patch which solves the problem with the PA Semi PWRficient 
Gigabit Ethernet. (attached)


Could you please check the changes in the file 'drivers/net/phy/mdio_bus.c'?

Thanks,
Christian

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b2fe5fa68642860e7de76167c3111623aa0d5de1
--- a/drivers/net/phy/mdio_bus.c	2018-02-03 17:34:46.973045321 +0100
+++ b/drivers/net/phy/mdio_bus.c	2018-02-04 11:03:14.909093360 +0100
@@ -47,41 +47,11 @@
 
 #include "mdio-boardinfo.h"
 
-static int mdiobus_register_gpiod(struct mdio_device *mdiodev)
-{
-	struct gpio_desc *gpiod = NULL;
-
-	/* Deassert the optional reset signal */
-	if (mdiodev->dev.of_node)
-		gpiod = fwnode_get_named_gpiod(>dev.of_node->fwnode,
-	   "reset-gpios", 0, GPIOD_OUT_LOW,
-	   "PHY reset");
-	if (PTR_ERR(gpiod) == -ENOENT)
-		gpiod = NULL;
-	else if (IS_ERR(gpiod))
-		return PTR_ERR(gpiod);
-
-	mdiodev->reset = gpiod;
-
-	/* Assert the reset signal again */
-	mdio_device_reset(mdiodev, 1);
-
-	return 0;
-}
-
 int mdiobus_register_device(struct mdio_device *mdiodev)
 {
-	int err;
-
 	if (mdiodev->bus->mdio_map[mdiodev->addr])
 		return -EBUSY;
 
-	if (mdiodev->flags & MDIO_DEVICE_FLAG_PHY) {
-		err = mdiobus_register_gpiod(mdiodev);
-		if (err)
-			return err;
-	}
-
 	mdiodev->bus->mdio_map[mdiodev->addr] = mdiodev;
 
 	return 0;

Re: xfrm, ip tunnel: non released device reference upon device unregistration

[Eyal Birger]

On Sun, 4 Feb 2018 13:21:18 +0200
Eyal Birger  wrote:

> Hi,
> 
> We've encountered a non released device reference upon device
> unregistration which seems to stem from xfrm policy code.
> 
> The setup includes:
> - an underlay device (e.g. eth0) using IPv4
> - an xfrm IPv6 over IPv4 tunnel routed via the underlay device
> - an ipip6 tunnel over the xfrm IPv6 tunnel
> 
> When tearing down the underlay device, after traffic had passed via
> the ipip6 tunnel, log messages of the following form are observed:
> 
> unregister_netdevice: waiting for eth0 to become free. Usage count = 2
> 
> The below synthetic script reproduces this consistently on a fresh
> ubuntu vm running net-next v4.15-6066-ge9522a5:

Minor correction: net-next version v4.15-10442-g617aebe

Eyal.

Re: after adding > 200vlans to mlx nic no traffic

[Gal Pressman]

On 01-Feb-18 10:25, Paweł Staszewski wrote:
> 
> 
> W dniu 31.01.2018 o 13:19, Gal Pressman pisze:
>> On 30-Jan-18 17:57, Paweł Staszewski wrote:
>>>
>>> W dniu 30.01.2018 o 15:57, Gal Pressman pisze:
 On 30-Jan-18 02:29, Paweł Staszewski wrote:
> Weird thing with mellanox mlx5 (connectx-4) kernel 4.15-rc9 - from 
> net-next davem tree
>
>
>
> after:
>
> ip link add link enp175s0f1 name vlan1538 type vlan id 1538
>
> ip link set up dev vlan1538
>
>
> traffic on vlan is working
>
>
> But after
>
> VID="1160 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 
> 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 
> 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 
> 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 150
> 0 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 
> 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 
> 1529 1530 1531 1532 1534 1535 1394 1393 1550 1500 1526 1536 1537 1538 
> 1539 1540 1542 1541 1543 1544 1801 1546 1547 1548 1
> 549 1735 3132 3143 3104 3125 3103 3115 3134 3105 3113 3141 4009 3144 3130 
> 1803 3146 3148 3109 1551 1552 1553 1554 1555 1556 1558 1559 1560 1561 
> 1562 1563 1564 1565 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 
> 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586
>    1587 1588 1589 1591 1592 1593 1594 1595 1596 1597 1598 1599 1557 1545 
> 2001 250 4043 1806 1600 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 
> 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1625 1626 1627 1628 
> 1629 1630 1631 1632 1634 1635 1636 1640 1641 164
> 2 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 
> 1657 1658 1659 1660 1661 1662 1663 1664 1665 1601 1666 1667 1668 1669 
> 1670 1671 1672 1673 1674 1676 1677 1678 1680 1681 1682 1683 1684 1685 
> 1686 1687 1688 1689 1690 1691 1692 1693 1694 1696 1
> 697 1698 1712 1817 1869 1810 1814 1818 1855 1856 1857 1858 1859 1860 1861 
> 1862 1863 1864 1865 1866 1867 1868 1870 1871 1872 1873 1874 1875 1876 
> 1877 1878 1879 1880 1885 1890 1891 1892 1893 1894 1895 1898 1881 2190 
> 2191 2192 2193 2194 2195 2196 2197 2198 2199 2541
>    2542 2543 2544 2545 2546 2547 2548 2549 2550 2290"
> for i in $VID
> do
>   ip link add link enp175s0f1 name vlan$i type vlan id $i
> done
>
>
> And setting vlan 1538 up - there is no received traffic on this vlan.
>
>
>
> So searching for broken things (last time same problem was with ixgbe)
>
> ethtool -K enp175s0f1 rx-vlan-filter off
>
>
> And all vlans attached to this device start working
>
>
>
 Hi Pawel,
 I tried to reproduce the issue in our local setups without success.
 Can you please provide more information? are there any errors in dmesg? 
 did you configure anything else that might be relevant to this issue?
 Do you know if this is a new degradation to 4.15-rc9?
>>> previous kernel used was 4.13.2 - without this problem.
>>>
>>> current kernel is net-next 4.15.0-rc9+
>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
>>>
 Try to send traffic over the vlans and sample the ethtool counters 
 (ethtool -S enp175s0f1) of the receiver mlx5 interface over time,
 this might help us trace where the packets drop.
>>> Yes traffic is going out from interface - bot there is nothing on RX - 
>>> tcpdump shows no packets arriving to interface
>>>
>> I am running 4.15.0-rc9+ from Dave's tree, currently on commit 91e6dd828425 
>> ("ipmr: Fix ptrdiff_t print formatting").
>> Tested with the commands you provided and same configuration, the issue does 
>> not reproduce on our setups.
>>
>> Did you see any errors in dmesg? anything coming from mlx5 driver?
> No errors in dmesg
>> Which firmware version are you using?
> 
>> Please provide your .config file, perhaps it is making the difference.
> Ok maybee I will add also ethtool configuration that is started before ip 
> link vlan is added:
> ifc='enp175s0f0 enp175s0f1'
> for i in $ifc
>     do
>     ip link set up dev $i
>     ethtool -A $i autoneg off rx off tx off
>     ethtool -G $i rx 4096 tx 4096
>     ip link set $i txqueuelen 1000
>     ethtool -L $i combined 28
>     ethtool -N $i rx-flow-hash udp4 sdfn
Note that this is not supported by mlx5.

>     ethtool -C $i adaptive-rx off rx-usecs 256 rx-frames 128
>     done
> 
> There are two interfaces
> enp175s0f0 enp175s0f1
> 
> First one have also some vlans:
> Below full list:
> cat /proc/net/vlan/config
> VLAN Dev name    | VLAN ID
> Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
> vlan1538   | 1538  | enp175s0f1
> vlan1160   | 1160  | enp175s0f1
> vlan1450   | 1450  | enp175s0f1
> vlan1451   | 1451  | enp175s0f1
> vlan1452   | 1452  | 

Re: [bpf-next PATCH 0/5] tools/libbpf improvements and selftests

[Daniel Borkmann]

On 02/04/2018 10:19 AM, Jesper Dangaard Brouer wrote:
> On Thu, 1 Feb 2018 18:56:14 +0100
> Daniel Borkmann  wrote:
> 
>> Don't get me wrong, I'm not at all against such tool or test, I think
>> it's a great idea and needed. I just think that tools/lib/bpf/ is not
>> the right place to put it into lib directory. Right now, as you say,
>> it's a mixture of example code on how to use the lib, and tool at the
>> same time to dump/test load an object file with libbpf.
> 
> Okay, to avoid polluting the directory of the library with test/samples
> programs, bow for your suggestion of moving the file to the selftests
> directory.
> 
> I'm at FOSDEM now, and I cannot send a V2 patch right now... If you
> need this in fast (due merge timing), you can make the change yourself
> and apply it... else I'll send a V2 on Tuesday.

Okay, then lets go with Tuesday since currently bpf pull-request is still
pending, thus this fix would go out with the next one anyway.

Thanks,
Daniel

Re: [PATCH net 1/1 v1] rtnetlink: require unique netns identifier

[Christian Brauner]

On Sat, Feb 03, 2018 at 07:09:55PM -0700, David Ahern wrote:
> On 2/3/18 12:17 PM, Stephen Hemminger wrote:
> > On Sat,  3 Feb 2018 14:29:04 +0100
> > Christian Brauner  wrote:
> > 
> >> +static int rtnl_ensure_unique_netns_attr(const struct sock *sk,
> >> +   struct nlattr *tb[],
> >> +   struct netlink_ext_ack *extack)
> >> +{
> >> +  int ret = -EINVAL;
> >> +  struct net *net = NULL, *unique_net = NULL;
> >> +
> >> +  /* Requests without network namespace ids have been able to specify
> >> +   * multiple properties referring to different network namespaces so
> >> +   * don't regress them.
> >> +   */
> >> +  if (!tb[IFLA_IF_NETNSID])
> >> +  return 0;
> >> +
> >> +  if (!tb[IFLA_NET_NS_PID] && !tb[IFLA_NET_NS_FD])
> >> +  return 0;
> > 
> > Isn't this an error?
> > 
> >> +
> >> +  unique_net = get_net_ns_by_id(sock_net(sk), 
> >> nla_get_s32(tb[IFLA_IF_NETNSID]));
> >> +  if (!unique_net)
> >> +  return -1;
> > 
> > Other paths are returning errno, so why -1 here?
> > 
> 
> extack needs to be filled in too.

Yeah, it should report that an invalid network namespace identifier has
been specified.

Thanks!
Christian

Re: [PATCH net 1/1 v1] rtnetlink: require unique netns identifier

[Christian Brauner]

On Sat, Feb 03, 2018 at 11:17:01AM -0800, Stephen Hemminger wrote:
> On Sat,  3 Feb 2018 14:29:04 +0100
> Christian Brauner  wrote:
> 
> > +static int rtnl_ensure_unique_netns_attr(const struct sock *sk,
> > +struct nlattr *tb[],
> > +struct netlink_ext_ack *extack)
> > +{
> > +   int ret = -EINVAL;
> > +   struct net *net = NULL, *unique_net = NULL;
> > +
> > +   /* Requests without network namespace ids have been able to specify
> > +* multiple properties referring to different network namespaces so
> > +* don't regress them.
> > +*/
> > +   if (!tb[IFLA_IF_NETNSID])
> > +   return 0;
> > +
> > +   if (!tb[IFLA_NET_NS_PID] && !tb[IFLA_NET_NS_FD])
> > +   return 0;
> 
> Isn't this an error?

My reasoning was that having no explicit network namespace identifying
attributes the caller operates on the current network namespace which is
uniquely identified.

> 
> > +
> > +   unique_net = get_net_ns_by_id(sock_net(sk), 
> > nla_get_s32(tb[IFLA_IF_NETNSID]));
> > +   if (!unique_net)
> > +   return -1;
> 
> Other paths are returning errno, so why -1 here?

Yes, this should be -EINVAL as well.

Thanks!
Christian

xfrm, ip tunnel: non released device reference upon device unregistration

[Eyal Birger]

Hi,

We've encountered a non released device reference upon device
unregistration which seems to stem from xfrm policy code.

The setup includes:
- an underlay device (e.g. eth0) using IPv4
- an xfrm IPv6 over IPv4 tunnel routed via the underlay device
- an ipip6 tunnel over the xfrm IPv6 tunnel

When tearing down the underlay device, after traffic had passed via the ipip6
tunnel, log messages of the following form are observed:

unregister_netdevice: waiting for eth0 to become free. Usage count = 2

The below synthetic script reproduces this consistently on a fresh ubuntu vm
running net-next v4.15-6066-ge9522a5:
-
#!/bin/bash

ipsec_underlay_dst=192.168.6.1
ipsec_underlay_src=192.168.5.2
ipv6_pfx=1234
local_ipv6_addr="$ipv6_pfx::1"
remote_ipv6_addr="$ipv6_pfx::2"

# create dummy ipsec underlay
ip l add dev dummy1 type dummy
ip l set dev dummy1 up
ip r add "$ipsec_underlay_dst/32" dev dummy1
ip -6 r add "$ipv6_pfx::/16" dev dummy1

ip a add dev dummy1 "$local_ipv6_addr/128"
ip a add dev dummy1 "$ipsec_underlay_src/24"

# add xfrm policy and state
ip x p add src "$local_ipv6_addr/128" dst "$ipv6_pfx::/16" dir out tmpl src 
"$ipsec_underlay_src" dst "$ipsec_underlay_dst" proto esp reqid 1 mode tunnel
ip x s add src "$ipsec_underlay_src" dst "$ipsec_underlay_dst" proto esp spi 
0xcd440ce6 reqid 1 mode tunnel auth-trunc 'hmac(sha1)' 
0x34a546d309031628962b814ef073aff1a638ad21 96 enc 'cbc(aes)' 
0xf31e14149c328297fe7925ad7448420e encap espinudp 4500 4500 0.0.0.0

# add 4o6 tunnel
ip l add tnl46 type ip6tnl mode ipip6 local "$local_ipv6_addr" remote 
"$remote_ipv6_addr"
ip l set dev tnl46 up
ip r add 10.64.0.0/10 dev tnl46 

# pass traffic so route is cached
ping -w 1 -c 1 10.64.0.1

# remove dummy underlay
ip l del dummy1
-

Analysis:

ip6_tunnel holds a dst_cache which caches its underlay dst objects.
When devices are unregistered, non-xfrm dst objects are invlidated by their
original creators (ipv4/ipv6/...) and thus are wiped from dst_cache.

xfrm created routes otoh are not tracked by xfrm, and are not invalidated upon
device unregistration, thus hold the device upon unregistration.

The following rough sketch patch illustrates an approach overcoming this
issue:
-
From e188dc5295e3500bc59e8780049840afa2eb3e24 Mon Sep 17 00:00:00 2001
From: Eyal Birger 
Date: Sun, 4 Feb 2018 13:08:02 +0200
Subject: [PATCH] net: xfrm_policy: invalidate xfrm_dsts on device
 unregistration

---
 include/net/xfrm.h | 10 ++-
 net/xfrm/xfrm_policy.c | 75 ++
 2 files changed, 78 insertions(+), 7 deletions(-)

diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 7d20776..c1c8493 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -994,6 +994,8 @@ struct xfrm_dst {
u32 child_mtu_cached;
u32 route_cookie;
u32 path_cookie;
+   struct list_head xfrm_dst_gc;
+   struct xfrm_dst_list *xfrm_dst_gc_list;
 };
 
 static inline struct dst_entry *xfrm_dst_path(const struct dst_entry *dst)
@@ -1025,13 +1027,7 @@ static inline void xfrm_dst_set_child(struct xfrm_dst 
*xdst, struct dst_entry *c
xdst->child = child;
 }
 
-static inline void xfrm_dst_destroy(struct xfrm_dst *xdst)
-{
-   xfrm_pols_put(xdst->pols, xdst->num_pols);
-   dst_release(xdst->route);
-   if (likely(xdst->u.dst.xfrm))
-   xfrm_state_put(xdst->u.dst.xfrm);
-}
+void xfrm_dst_destroy(struct xfrm_dst *xdst);
 #endif
 
 void xfrm_dst_ifdown(struct dst_entry *dst, struct net_device *dev);
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 7a23078..d446641 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -94,6 +94,58 @@ __xfrm6_selector_match(const struct xfrm_selector *sel, 
const struct flowi *fl)
(fl6->flowi6_oif == sel->ifindex || !sel->ifindex);
 }
 
+struct xfrm_dst_list {
+   spinlock_t  lock;
+   struct list_headhead;
+};
+
+static DEFINE_PER_CPU_ALIGNED(struct xfrm_dst_list, xfrm_dst_gc_list);
+
+static void xfrm_add_dst_list(struct xfrm_dst *xdst)
+{
+   struct xfrm_dst_list *xl = raw_cpu_ptr(_dst_gc_list);
+
+   xdst->xfrm_dst_gc_list = xl;
+
+   spin_lock_bh(>lock);
+   list_add_tail(>xfrm_dst_gc, >head);
+   spin_unlock_bh(>lock);
+}
+
+void xfrm_dst_destroy(struct xfrm_dst *xdst)
+{
+   xfrm_pols_put(xdst->pols, xdst->num_pols);
+   dst_release(xdst->route);
+   if (likely(xdst->u.dst.xfrm))
+   xfrm_state_put(xdst->u.dst.xfrm);
+   if (!list_empty(>xfrm_dst_gc)) {
+   struct xfrm_dst_list *xl = xdst->xfrm_dst_gc_list;
+
+   spin_lock_bh(>lock);
+   list_del(>xfrm_dst_gc);
+   spin_unlock_bh(>lock);
+   }
+}
+EXPORT_SYMBOL_GPL(xfrm_dst_destroy);
+
+void 

Re: possible deadlock in rtnl_lock (2)

[Dmitry Vyukov]

On Sat, Feb 3, 2018 at 12:25 PM, Xin Long  wrote:
> On Thu, Feb 1, 2018 at 7:58 PM, syzbot
>  wrote:
>> Hello,
>>
>> syzbot hit the following crash on upstream commit
>> 255442c93843f52b6891b21d0b485bf2c97f93c3 (Thu Feb 1 03:25:25 2018 +)
>> Merge tag 'docs-4.16' of git://git.lwn.net/linux
>>
>> So far this crash happened 1587 times on net-next, upstream.
>> C reproducer is attached.
>> syzkaller reproducer is attached.
>> Raw console output is attached.
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached.
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+61e4972c2b1d5e08a...@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>>
>> ==
>> WARNING: possible circular locking dependency detected
>> 4.15.0+ #290 Not tainted
>> --
>> syzkaller681093/4124 is trying to acquire lock:
>>  (rtnl_mutex){+.+.}, at: [] rtnl_lock+0x17/0x20
>> net/core/rtnetlink.c:74
>>
>> but task is already holding lock:
>>  (sk_lock-AF_INET){+.+.}, at: [<51813e83>] lock_sock
>> include/net/sock.h:1461 [inline]
>>  (sk_lock-AF_INET){+.+.}, at: [<51813e83>] ip_setsockopt+0x8c/0xb0
>> net/ipv4/ip_sockglue.c:1259
>>
>> which lock already depends on the new lock.
>>
>>
>> the existing dependency chain (in reverse order) is:
>>
>> -> #1 (sk_lock-AF_INET){+.+.}:
>>lock_sock_nested+0xc2/0x110 net/core/sock.c:2780
>>lock_sock include/net/sock.h:1461 [inline]
>>do_ip_getsockopt+0x1b3/0x2170 net/ipv4/ip_sockglue.c:1335
>>ip_getsockopt+0x90/0x220 net/ipv4/ip_sockglue.c:1566
>>tcp_getsockopt+0x82/0xd0 net/ipv4/tcp.c:3359
>>sock_common_getsockopt+0x95/0xd0 net/core/sock.c:2937
>>SYSC_getsockopt net/socket.c:1880 [inline]
>>SyS_getsockopt+0x178/0x340 net/socket.c:1862
>>entry_SYSCALL_64_fastpath+0x29/0xa0
>>
>> -> #0 (rtnl_mutex){+.+.}:
>>lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3920
>>__mutex_lock_common kernel/locking/mutex.c:756 [inline]
>>__mutex_lock+0x16f/0x1a80 kernel/locking/mutex.c:893
>>mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
>>rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74
>>register_netdevice_notifier+0xad/0x860 net/core/dev.c:1607
>>tee_tg_check+0x1a0/0x280 net/netfilter/xt_TEE.c:106
>>xt_check_target+0x22c/0x7d0 net/netfilter/x_tables.c:845
>>check_target net/ipv4/netfilter/ip_tables.c:513 [inline]
>>find_check_entry.isra.8+0x8c8/0xcb0
>> net/ipv4/netfilter/ip_tables.c:554
>>translate_table+0xed1/0x1610 net/ipv4/netfilter/ip_tables.c:725
>>do_replace net/ipv4/netfilter/ip_tables.c:1141 [inline]
>>do_ipt_set_ctl+0x370/0x5f0 net/ipv4/netfilter/ip_tables.c:1675
>>nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
>>nf_setsockopt+0x67/0xc0 net/netfilter/nf_sockopt.c:115
>>ip_setsockopt+0xa1/0xb0 net/ipv4/ip_sockglue.c:1260
>>sctp_setsockopt+0x2b6/0x61d0 net/sctp/socket.c:4104
>>sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2978
>>SYSC_setsockopt net/socket.c:1849 [inline]
>>SyS_setsockopt+0x189/0x360 net/socket.c:1828
>>entry_SYSCALL_64_fastpath+0x29/0xa0
>>
>> other info that might help us debug this:
>>
>>  Possible unsafe locking scenario:
>>
>>CPU0CPU1
>>
>>   lock(sk_lock-AF_INET);
>>lock(rtnl_mutex);
>>lock(sk_lock-AF_INET);
>>   lock(rtnl_mutex);
>>
>>  *** DEADLOCK ***
>>
>> 1 lock held by syzkaller681093/4124:
>>  #0:  (sk_lock-AF_INET){+.+.}, at: [<51813e83>] lock_sock
>> include/net/sock.h:1461 [inline]
>>  #0:  (sk_lock-AF_INET){+.+.}, at: [<51813e83>]
>> ip_setsockopt+0x8c/0xb0 net/ipv4/ip_sockglue.c:1259
>>
>> stack backtrace:
>> CPU: 0 PID: 4124 Comm: syzkaller681093 Not tainted 4.15.0+ #290
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>>  __dump_stack lib/dump_stack.c:17 [inline]
>>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>>  print_circular_bug.isra.38+0x2cd/0x2dc kernel/locking/lockdep.c:1223
>>  check_prev_add kernel/locking/lockdep.c:1863 [inline]
>>  check_prevs_add kernel/locking/lockdep.c:1976 [inline]
>>  validate_chain kernel/locking/lockdep.c:2417 [inline]
>>  __lock_acquire+0x30a8/0x3e00 kernel/locking/lockdep.c:3431
>>  lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3920
>>  __mutex_lock_common kernel/locking/mutex.c:756 [inline]
>>  __mutex_lock+0x16f/0x1a80 kernel/locking/mutex.c:893
>>  mutex_lock_nested+0x16/0x20 

Re: Help needed!

[Sandra Younes]

Good Day,

Forgive my indignation if this message comes to you as a surprise and may 
offend your personality for contacting you without your prior consent and 
writing through this channel.

I came across your name and contact on the course of my personal searching when 
i was searching for a foreign reliable partner. I was assured of your 
capability and reliability after going true your profile.

I'm (Miss. Sandra) from Benghazi libya, My father of blessed memory by name 
late General Abdel Fattah Younes who was shot death by Islamist-linked militia 
within the anti-Gaddafi forces on 28th July, 2011 and after two days later my 
mother with my two brothers was killed one early morning by the rebels as 
result of civil war that is going on in my country Libya, then after the burial 
of my parents, my uncles conspired and sold my father's properties and left 
nothing for me. On a faithful morning, I opened my father's briefcase and 
discover a document which he has deposited ($6.250M USD) in a bank in a Turkish 
Bank which has a small branch in Canada with my name as the legitimate/next of 
kin. Meanwhile i have located the bank,and have also discussed the possiblity 
of transfering the fund. My father left a clause to the bank that i must 
introduce a trusted foreign partner who would be my trustee to help me invest 
this fund; hence the need for your assistance,i request that you be my tr
 ustee and assist me in th

You will also be responsible for the investment and management of the fund for 
me and also you will help me get a good school where i will further my 
education.
I agreed to give you 40% of the $6.250M once the transfer is done. this is my 
true life story, I will be glad to receive your respond soonest for more 
details to enable us start and champion the transfer less than 14 banking days 
as i was informed by the bank manager.

Thanks for giving me your attention,

Yours sincerely,
Miss. Sandra Younes

Re: [RFC PATCH 01/10] net: ptp: Add stub for ptp_classify_raw()

[Sergei Shtylyov]

Hello!

On 2/4/2018 12:40 AM, Andrew Lunn wrote:


When NET_PTP_CLASSIFY is disabled, a stub function is required in
order that drivers compile.


   s/that/the/?



Signed-off-by: Andrew Lunn 
Acked-by: Richard Cochran 

[...]

MBR, Sergei

Re: [bpf-next PATCH 0/5] tools/libbpf improvements and selftests

[Jesper Dangaard Brouer]

On Thu, 1 Feb 2018 18:56:14 +0100
Daniel Borkmann  wrote:

> Don't get me wrong, I'm not at all against such tool or test, I think
> it's a great idea and needed. I just think that tools/lib/bpf/ is not
> the right place to put it into lib directory. Right now, as you say,
> it's a mixture of example code on how to use the lib, and tool at the
> same time to dump/test load an object file with libbpf.

Okay, to avoid polluting the directory of the library with test/samples
programs, bow for your suggestion of moving the file to the selftests
directory.

I'm at FOSDEM now, and I cannot send a V2 patch right now... If you
need this in fast (due merge timing), you can make the change yourself
and apply it... else I'll send a V2 on Tuesday.

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

[PATCH net] sctp: fix dst reference leak in sctp_v4_get_dst

[Tommi Rantala]

Fix dst reference leak in sctp_v4_get_dst() introduced in commit
410f03831 ("sctp: add routing output fallback"):

When walking the address_list, successive ip_route_output_key() calls
may return the same rt->dst with the reference incremented on each call.

The code would not decrement the dst refcount when the dst pointer was
identical from the previous iteration, causing the dst leak.

Testcase:
  ip netns add TEST
  ip netns exec TEST ip link set lo up
  ip link add dummy0 type dummy
  ip link add dummy1 type dummy
  ip link add dummy2 type dummy
  ip link set dev dummy0 netns TEST
  ip link set dev dummy1 netns TEST
  ip link set dev dummy2 netns TEST
  ip netns exec TEST ip addr add 192.168.1.1/24 dev dummy0
  ip netns exec TEST ip link set dummy0 up
  ip netns exec TEST ip addr add 192.168.1.2/24 dev dummy1
  ip netns exec TEST ip link set dummy1 up
  ip netns exec TEST ip addr add 192.168.1.3/24 dev dummy2
  ip netns exec TEST ip link set dummy2 up
  ip netns exec TEST sctp_test -H 192.168.1.2 -P 20002 -h 192.168.1.1 -p 2 
-s -B 192.168.1.3
  ip netns del TEST

In 4.4 and 4.9 kernels this results to:
  [  354.179591] unregister_netdevice: waiting for lo to become free. Usage 
count = 1
  [  364.419674] unregister_netdevice: waiting for lo to become free. Usage 
count = 1
  [  374.663664] unregister_netdevice: waiting for lo to become free. Usage 
count = 1
  [  384.903717] unregister_netdevice: waiting for lo to become free. Usage 
count = 1
  [  395.143724] unregister_netdevice: waiting for lo to become free. Usage 
count = 1
  [  405.383645] unregister_netdevice: waiting for lo to become free. Usage 
count = 1
  ...

Fixes: 410f03831 ("sctp: add routing output fallback")
Acked-by: Neil Horman 
Cc: Marcelo Ricardo Leitner 
Cc: Alexey Kodanev 
Signed-off-by: Tommi Rantala 
---
 net/sctp/protocol.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index 8b4ff315695e..aadb9e7f60e2 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -508,21 +508,20 @@ static void sctp_v4_get_dst(struct sctp_transport *t, 
union sctp_addr *saddr,
if (IS_ERR(rt))
continue;
 
-   if (!dst)
-   dst = >dst;
-
/* Ensure the src address belongs to the output
 * interface.
 */
odev = __ip_dev_find(sock_net(sk), laddr->a.v4.sin_addr.s_addr,
 false);
if (!odev || odev->ifindex != fl4->flowi4_oif) {
-   if (>dst != dst)
+   if (!dst)
+   dst = >dst;
+   else
dst_release(>dst);
continue;
}
 
-   if (dst != >dst)
+   if (dst && dst != >dst)
dst_release(dst);
dst = >dst;
break;
-- 
2.15.1

Re: sctp netns "unregister_netdevice: waiting for lo to become free. Usage count = 1"

[Tommi Rantala]

On 02.02.2018 14:34, Neil Horman wrote:

Patch looks good, but if you could please submit it with the proper title in a
separate thread so it gets davem's attention properly, I'd appreciate it.
Additional points if you update it to include the ipv6 fixes :)


Thanks, I'll send this patch properly.

I think I will let Alexey post the ipv6 fixes separately, as he's also 
planning another fix to sctp_v6_get_dst.


Tommi

Re: [Intel-wired-lan] [PATCH] e1000e: allocate ring descriptors with dma_zalloc_coherent

[Neftin, Sasha]

On 1/26/2018 12:24, Pierre-Yves Kerbrat wrote:

Descriptor rings were not initialized at zero when allocated
When area contained garbage data, it caused skb_over_panic in
e1000_clean_rx_irq (if data had E1000_RXD_STAT_DD bit set)

This patch makes use of dma_zalloc_coherent to make sure the
ring is memset at 0 to prevent the area from containing garbage.

Following is the signature of the panic:
IODDR0@0.0: skbuff: skb_over_panic: text:80407b20 len:64010 put:64010 
head:ab46d800 data:ab46d842 tail:0xab47d24c end:0xab46df40 dev:eth0
IODDR0@0.0: BUG: failure at net/core/skbuff.c:105/skb_panic()!
IODDR0@0.0: Kernel panic - not syncing: BUG!
IODDR0@0.0:
IODDR0@0.0: Process swapper/0 (pid: 0, threadinfo=81728000, task=8173cc00 ,cpu: 
0)
IODDR0@0.0: SP = <815a1c0c>
IODDR0@0.0: Stack:  0001
IODDR0@0.0: b2d89800 815e33ac
IODDR0@0.0: ea73c040 0001
IODDR0@0.0: 60040003 fa0a
IODDR0@0.0: 0002
IODDR0@0.0:
IODDR0@0.0: 804540c0 815a1c70
IODDR0@0.0: b2744000 602ac070
IODDR0@0.0: 815a1c44 b2d89800
IODDR0@0.0: 8173cc00 815a1c08
IODDR0@0.0:
IODDR0@0.0: 0006
IODDR0@0.0: 815a1b50 
IODDR0@0.0: 80079434 0001
IODDR0@0.0: ab46df40 b2744000
IODDR0@0.0: b2d89800
IODDR0@0.0:
IODDR0@0.0: fa0a 8045745c
IODDR0@0.0: 815a1c88 fa0a
IODDR0@0.0: 80407b20 b2789f80
IODDR0@0.0: 0005 80407b20
IODDR0@0.0:
IODDR0@0.0:
IODDR0@0.0: Call Trace:
IODDR0@0.0: [<804540bc>] skb_panic+0xa4/0xa8
IODDR0@0.0: [<80079430>] console_unlock+0x2f8/0x6d0
IODDR0@0.0: [<80457458>] skb_put+0xa0/0xc0
IODDR0@0.0: [<80407b1c>] e1000_clean_rx_irq+0x2dc/0x3e8
IODDR0@0.0: [<80407b1c>] e1000_clean_rx_irq+0x2dc/0x3e8
IODDR0@0.0: [<804079c8>] e1000_clean_rx_irq+0x188/0x3e8
IODDR0@0.0: [<80407b1c>] e1000_clean_rx_irq+0x2dc/0x3e8
IODDR0@0.0: [<80468b48>] __dev_kfree_skb_any+0x88/0xa8
IODDR0@0.0: [<804101ac>] e1000e_poll+0x94/0x288
IODDR0@0.0: [<8046e9d4>] net_rx_action+0x19c/0x4e8
IODDR0@0.0:   ...
IODDR0@0.0: Maximum depth to print reached. Use kstack= 
To specify a custom value (where 0 means to display the full backtrace)
IODDR0@0.0: ---[ end Kernel panic - not syncing: BUG!

Signed-off-by: Pierre-Yves Kerbrat 
Signed-off-by: Marius Gligor 
---
  drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 1298b69..26121ed 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -2333,7 +2333,7 @@ static int e1000_alloc_ring_dma(struct e1000_adapter 
*adapter,
  {
struct pci_dev *pdev = adapter->pdev;
  
-	ring->desc = dma_alloc_coherent(>dev, ring->size, >dma,

+   ring->desc = dma_zalloc_coherent(>dev, ring->size, >dma,
GFP_KERNEL);
if (!ring->desc)
return -ENOMEM;


Looks good. Prefer get another opinion from somebody else.