* [PATCH net-next 3/4] e1000e: Fix -Wformat-truncation warnings
From: Florian Fainelli @ 2019-02-22 4:09 UTC (permalink / raw)
To: netdev
Cc: davem, Florian Fainelli, Jeff Kirsher,
moderated list:INTEL ETHERNET DRIVERS, open list
In-Reply-To: <20190222040929.16657-1-f.fainelli@gmail.com>
Provide precision hints to snprintf() since we know the destination
buffer size of the RX/TX ring names are IFNAMSIZ + 5 - 1. This fixes the
following warnings:
drivers/net/ethernet/intel/e1000e/netdev.c: In function
'e1000_request_msix':
drivers/net/ethernet/intel/e1000e/netdev.c:2109:13: warning: 'snprintf'
output may be truncated before the last format character
[-Wformat-truncation=]
"%s-rx-0", netdev->name);
^
drivers/net/ethernet/intel/e1000e/netdev.c:2107:3: note: 'snprintf'
output between 6 and 21 bytes into a destination of size 20
snprintf(adapter->rx_ring->name,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sizeof(adapter->rx_ring->name) - 1,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s-rx-0", netdev->name);
~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/intel/e1000e/netdev.c:2125:13: warning: 'snprintf'
output may be truncated before the last format character
[-Wformat-truncation=]
"%s-tx-0", netdev->name);
^
drivers/net/ethernet/intel/e1000e/netdev.c:2123:3: note: 'snprintf'
output between 6 and 21 bytes into a destination of size 20
snprintf(adapter->tx_ring->name,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sizeof(adapter->tx_ring->name) - 1,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s-tx-0", netdev->name);
~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 736fa51878f8..7acc61e4f645 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -2106,7 +2106,7 @@ static int e1000_request_msix(struct e1000_adapter *adapter)
if (strlen(netdev->name) < (IFNAMSIZ - 5))
snprintf(adapter->rx_ring->name,
sizeof(adapter->rx_ring->name) - 1,
- "%s-rx-0", netdev->name);
+ "%.14s-rx-0", netdev->name);
else
memcpy(adapter->rx_ring->name, netdev->name, IFNAMSIZ);
err = request_irq(adapter->msix_entries[vector].vector,
@@ -2122,7 +2122,7 @@ static int e1000_request_msix(struct e1000_adapter *adapter)
if (strlen(netdev->name) < (IFNAMSIZ - 5))
snprintf(adapter->tx_ring->name,
sizeof(adapter->tx_ring->name) - 1,
- "%s-tx-0", netdev->name);
+ "%.14s-tx-0", netdev->name);
else
memcpy(adapter->tx_ring->name, netdev->name, IFNAMSIZ);
err = request_irq(adapter->msix_entries[vector].vector,
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 4/4] veth: Fix -Wformat-truncation
From: Florian Fainelli @ 2019-02-22 4:09 UTC (permalink / raw)
To: netdev
Cc: davem, Florian Fainelli, Alexei Starovoitov, Daniel Borkmann,
Jakub Kicinski, Jesper Dangaard Brouer, John Fastabend,
Toshiaki Makita, David Ahern, Michael Walle, Li RongQing,
open list, open list:XDP (eXpress Data Path)
In-Reply-To: <20190222040929.16657-1-f.fainelli@gmail.com>
Provide a precision hint to snprintf() in order to eliminate a
-Wformat-truncation warning provided below. A maximum of 11 characters
is allowed to reach a maximum of 32 - 1 characters given a possible
maximum value of queues using up to UINT_MAX which occupies 10
characters. Incidentally 11 is the number of characters for
"xdp_packets" which is the largest string we append.
drivers/net/veth.c: In function 'veth_get_strings':
drivers/net/veth.c:118:47: warning: '%s' directive output may be
truncated writing up to 31 bytes into a region of size between 12 and 21
[-Wformat-truncation=]
snprintf(p, ETH_GSTRING_LEN, "rx_queue_%u_%s",
^~
drivers/net/veth.c:118:5: note: 'snprintf' output between 12 and 52
bytes into a destination of size 32
snprintf(p, ETH_GSTRING_LEN, "rx_queue_%u_%s",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
i, veth_rq_stats_desc[j].desc);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/veth.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index fbf890ebbeae..569e87a51a33 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -115,7 +115,8 @@ static void veth_get_strings(struct net_device *dev, u32 stringset, u8 *buf)
p += sizeof(ethtool_stats_keys);
for (i = 0; i < dev->real_num_rx_queues; i++) {
for (j = 0; j < VETH_RQ_STATS_LEN; j++) {
- snprintf(p, ETH_GSTRING_LEN, "rx_queue_%u_%s",
+ snprintf(p, ETH_GSTRING_LEN,
+ "rx_queue_%u_%.11s",
i, veth_rq_stats_desc[j].desc);
p += ETH_GSTRING_LEN;
}
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 1/4] mlxsw: spectrum: Avoid -Wformat-truncation warnings
From: Florian Fainelli @ 2019-02-22 4:09 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli, Jiri Pirko, Ido Schimmel, open list
In-Reply-To: <20190222040929.16657-1-f.fainelli@gmail.com>
Give precision identifiers to the two snprintf() formatting the priority
and TC strings to avoid producing these two warnings:
drivers/net/ethernet/mellanox/mlxsw/spectrum.c: In function
'mlxsw_sp_port_get_prio_strings':
drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2132:37: warning: '%d'
directive output may be truncated writing between 1 and 3 bytes into a
region of size between 0 and 31 [-Wformat-truncation=]
snprintf(*p, ETH_GSTRING_LEN, "%s_%d",
^~
drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2132:3: note: 'snprintf'
output between 3 and 36 bytes into a destination of size 32
snprintf(*p, ETH_GSTRING_LEN, "%s_%d",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mlxsw_sp_port_hw_prio_stats[i].str, prio);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/mellanox/mlxsw/spectrum.c: In function
'mlxsw_sp_port_get_tc_strings':
drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2143:37: warning: '%d'
directive output may be truncated writing between 1 and 11 bytes into a
region of size between 0 and 31 [-Wformat-truncation=]
snprintf(*p, ETH_GSTRING_LEN, "%s_%d",
^~
drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2143:3: note: 'snprintf'
output between 3 and 44 bytes into a destination of size 32
snprintf(*p, ETH_GSTRING_LEN, "%s_%d",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mlxsw_sp_port_hw_tc_stats[i].str, tc);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index f018b0607dac..5f6962da8877 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -2129,7 +2129,7 @@ static void mlxsw_sp_port_get_prio_strings(u8 **p, int prio)
int i;
for (i = 0; i < MLXSW_SP_PORT_HW_PRIO_STATS_LEN; i++) {
- snprintf(*p, ETH_GSTRING_LEN, "%s_%d",
+ snprintf(*p, ETH_GSTRING_LEN, "%.29s_%.1d",
mlxsw_sp_port_hw_prio_stats[i].str, prio);
*p += ETH_GSTRING_LEN;
}
@@ -2140,7 +2140,7 @@ static void mlxsw_sp_port_get_tc_strings(u8 **p, int tc)
int i;
for (i = 0; i < MLXSW_SP_PORT_HW_TC_STATS_LEN; i++) {
- snprintf(*p, ETH_GSTRING_LEN, "%s_%d",
+ snprintf(*p, ETH_GSTRING_LEN, "%.29s_%.1d",
mlxsw_sp_port_hw_tc_stats[i].str, tc);
*p += ETH_GSTRING_LEN;
}
--
2.19.1
^ permalink raw reply related
* Re: [PATCH net-next v2] ip_tunnel: Add dst_cache management lwtunnel_state of ip tunnel
From: wenxu @ 2019-02-22 4:14 UTC (permalink / raw)
To: David Ahern, davem, netdev
In-Reply-To: <f228c250-ccde-d9e5-8072-8d5bee736f71@gmail.com>
On 2/22/2019 11:39 AM, David Ahern wrote:
> On 2/21/19 10:00 PM, wenxu@ucloud.cn wrote:
>> From: wenxu <wenxu@ucloud.cn>
>>
>> The lwtunnel_state is not init the dst_cache Which make the
>> ip_md_tunnel_xmit can't use the dst_cache. It will lookup
>> route table every packets.
>>
>> Signed-off-by: wenxu <wenxu@ucloud.cn>
>> ---
>> net/ipv4/ip_tunnel_core.c | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/net/ipv4/ip_tunnel_core.c b/net/ipv4/ip_tunnel_core.c
>> index 9a0e67b..f91ef7a 100644
>> --- a/net/ipv4/ip_tunnel_core.c
>> +++ b/net/ipv4/ip_tunnel_core.c
>> @@ -252,6 +252,12 @@ static int ip_tun_build_state(struct nlattr *attr,
>>
>> tun_info = lwt_tun_info(new_state);
>>
>> + err = dst_cache_init(&tun_info->dst_cache, GFP_ATOMIC);
> build_state is called with rtnl held. Unless I am missing something, you
> don't need ATOMIC here.
If set GFP_KERNEL shows following:
Feb 22 07:07:03 A1_V5_02 kernel: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:1301
Feb 22 07:07:03 A1_V5_02 kernel: in_atomic(): 1, irqs_disabled(): 0, pid: 7950, name: ip
Feb 22 07:07:03 A1_V5_02 kernel: CPU: 21 PID: 7950 Comm: ip Kdump: loaded Not tainted 5.0.0-rc6-next-20190215 #14
Feb 22 07:07:03 A1_V5_02 kernel: Hardware name: Inspur SA5112M5/YZMB-00870-101, BIOS 4.0.3 05/22/2018
Feb 22 07:07:03 A1_V5_02 kernel: Call Trace:
Feb 22 07:07:03 A1_V5_02 kernel: dump_stack+0x5a/0x73
Feb 22 07:07:03 A1_V5_02 kernel: ___might_sleep+0xfc/0x120
Feb 22 07:07:03 A1_V5_02 kernel: mutex_lock_killable+0x1c/0x42
Feb 22 07:07:03 A1_V5_02 kernel: pcpu_alloc+0x390/0x6f0
Feb 22 07:07:03 A1_V5_02 kernel: ? __nla_parse+0xf8/0x160
Feb 22 07:07:03 A1_V5_02 kernel: dst_cache_init+0x1d/0x40
Feb 22 07:07:03 A1_V5_02 kernel: ip_tun_build_state+0x75/0x140
Feb 22 07:07:03 A1_V5_02 kernel: lwtunnel_build_state+0x92/0xf0
Feb 22 07:07:03 A1_V5_02 kernel: fib_create_info+0x74e/0x1020
build_state in the rcu_read_lock and disable the preempt
rcu_read_lock();
ops = rcu_dereference(lwtun_encaps[encap_type]);
if (likely(ops && ops->build_state && try_module_get(ops->owner))) {
found = true;
ret = ops->build_state(encap, family, cfg, lws, extack);
if (ret)
module_put(ops->owner);
}
rcu_read_unlock();
^ permalink raw reply
* Re: [RFC] rtnetlink: handle multiple vlan tags in set_vf_vlan
From: Moshe Shemesh @ 2019-02-22 4:58 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev@vger.kernel.org, Stephen Hemminger
In-Reply-To: <20190221175436.10767-1-sthemmin@microsoft.com>
On 2/21/2019 7:54 PM, Stephen Hemminger wrote:
> The netlink API for IFLA_VF_VLAN_LIST allows multiple VLAN tags to
> be passed (and the message was validated) but only the first VLAN
> tag was being passed to the device. Change to iterate over each tag received.
>
> Fixes: 79aab093a0b5 ("net: Update API for VF vlan protocol 802.1ad support")
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> net/core/rtnetlink.c | 19 ++++++++++---------
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index a51cab95ba64..3a9ec988ae21 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -2207,11 +2207,10 @@ static int do_setvfinfo(struct net_device *dev, struct nlattr **tb)
> if (tb[IFLA_VF_VLAN_LIST]) {
> struct ifla_vf_vlan_info *ivvl[MAX_VLAN_LIST_LEN];
> struct nlattr *attr;
> - int rem, len = 0;
> + int i, rem, len = 0;
>
> - err = -EOPNOTSUPP;
> if (!ops->ndo_set_vf_vlan)
> - return err;
> + return -EOPNOTSUPP;
>
> nla_for_each_nested(attr, tb[IFLA_VF_VLAN_LIST], rem) {
> if (nla_type(attr) != IFLA_VF_VLAN_INFO ||
> @@ -2224,13 +2223,15 @@ static int do_setvfinfo(struct net_device *dev, struct nlattr **tb)
>
> len++;
> }
> - if (len == 0)
> - return -EINVAL;
>
> - err = ops->ndo_set_vf_vlan(dev, ivvl[0]->vf, ivvl[0]->vlan,
> - ivvl[0]->qos, ivvl[0]->vlan_proto);
> - if (err < 0)
> - return err;
> + err = -EINVAL; /* empty list error */
> + for (i = 0; i < len; i++) {
> + err = ops->ndo_set_vf_vlan(dev, ivvl[i]->vf,
> + ivvl[i]->vlan, ivvl[i]->qos,
> + ivvl[i]->vlan_proto);
Doing that each vlan will just overwrite the vf vlan configuration set
by its preceding one.
Note #define MAX_VLAN_LIST_LEN 1
The point here was that I had to add the rtnl interface to set vf vlan
with option to set vf vlan protocol. While doing that I was asked to add
option to get a list of vlans from user to support QinQ, so once it will
be needed there won't be a need to add another rtnl interface.
The driver which will support setting double vlan or more per vf will
change MAX_VLAN_LIST_LEN and change the ndo function.
> + if (err < 0)
> + return err;
> + }
> }
>
> if (tb[IFLA_VF_TX_RATE]) {
>
^ permalink raw reply
* Re: [PATCH net-next] rocker: Add missing break for PRE_BRIDGE_FLAGS
From: David Miller @ 2019-02-22 5:29 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, sfr, jiri, linux-kernel
In-Reply-To: <20190222022647.20144-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 21 Feb 2019 18:26:46 -0800
> A missing break keyword should have been added after adding support for
> PRE_BRIDGE_FLAGS.
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Fixes: 93700458ff63 ("rocker: Check Handle PORT_PRE_BRIDGE_FLAGS")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied.
This turned out to be a really rough series for your Florian :-) :-)
^ permalink raw reply
* Re: [PATCH net v2 0/2] ipv6: route: enforce RCU protection for fib6_info->from
From: David Miller @ 2019-02-22 5:32 UTC (permalink / raw)
To: dsahern; +Cc: pabeni, netdev
In-Reply-To: <70d0567e-c01e-2a7d-1b89-a7744fa8ad35@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Thu, 21 Feb 2019 21:45:08 -0500
> On 2/21/19 12:54 PM, David Miller wrote:
>> From: Paolo Abeni <pabeni@redhat.com>
>> Date: Thu, 21 Feb 2019 11:19:40 +0100
>>
>>> This series addresses a couple of RCU left-over dating back to rt6_info->from
>>> conversion to RCU
>>>
>>> v1 -> v2:
>>> - fix a possible race in patch 1
>>
>> Series applied.
>>
>
> and queued for stable? I don't see them in the stable list.
Good catch, queued up.
Thanks David.
^ permalink raw reply
* Re: [PATCH] [V2]r8152: Add support for MAC address pass through on RTL8153-BD
From: David Chen @ 2019-02-22 5:44 UTC (permalink / raw)
To: Jiri Slaby
Cc: linux-usb, netdev, linux-kernel, davem, hayeswang,
mario.limonciello, bigeasy, edumazet, f.fainelli, david.chen7,
kai.heng.feng, zhongjiang
In-Reply-To: <91332458-c2c1-b7c3-5135-ab0741108020@suse.cz>
Hi Jiri,
Thanks for your comments. BND_MASK and BD_MASK are defined separately, and I have tested RTL8153-BD and RTL8153-BND devices, both work as expected.
Thanks and Regards,
-David
> Jiri Slaby <jslaby@suse.cz> 於 2019年2月18日 下午10:22 寫道：
>
>> On 18. 02. 19, 15:00, David Chen wrote:
>> From: David Chen <david.chen7@dell.com>
>>
>> RTL8153-BD is used in Dell DA300 type-C dongle.
>> It should be added to the whitelist of devices to activate MAC address
>> pass through.
>>
>> Per confirming with Realtek all devices containing RTL8153-BD should
>> activate MAC pass through and there won't use pass through bit on efuse
>> like in RTL8153-AD.
>>
>> Signed-off-by: David Chen <david.chen7@dell.com>
>> ---
>> drivers/net/usb/r8152.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
>> index 60dd1ec1665f..86c8c64fbb0f 100644
>> --- a/drivers/net/usb/r8152.c
>> +++ b/drivers/net/usb/r8152.c
>> @@ -557,6 +557,7 @@ enum spd_duplex {
>> /* MAC PASSTHRU */
>> #define AD_MASK 0xfee0
>> #define BND_MASK 0x0004
>> +#define BD_MASK 0x0001
>> #define EFUSE 0xcfdb
>> #define PASS_THRU_MASK 0x1
>>
>> @@ -1176,9 +1177,9 @@ static int vendor_mac_passthru_addr_read(struct r8152 *tp, struct sockaddr *sa)
>> return -ENODEV;
>> }
>> } else {
>> - /* test for RTL8153-BND */
>> + /* test for RTL8153-BND and RTL8153-BD */
>> ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, USB_MISC_1);
>> - if ((ocp_data & BND_MASK) == 0) {
>> + if ((ocp_data & BND_MASK) == 0 && (ocp_data & BD_MASK) == 0) {
>
> Can you ensure that BND won't have the BD's bit set and vice versa? I.e.
> should the check be something like:
> if (isBND() && (ocp_data & BND_MASK) == 0 ||
> isBD() && (ocp_data & BD_MASK) == 0)
> instead?
>
> thanks,
> --
> js
> suse labs
^ permalink raw reply
* Re: [PATCH] bpfilter: re-add header search paths to tools include to fix build error
From: Guenter Roeck @ 2019-02-22 5:54 UTC (permalink / raw)
To: Masahiro Yamada, David S . Miller, netdev
Cc: Song Liu, Alexei Starovoitov, Yonghong Song, linux-kernel,
Martin KaFai Lau, Daniel Borkmann
In-Reply-To: <1550805799-24572-1-git-send-email-yamada.masahiro@socionext.com>
On 2/21/19 7:23 PM, Masahiro Yamada wrote:
> I thought header search paths to tools/include(/uapi) were unneeded,
> but it looks like a build error occurs depending on the compiler.
>
> Commit 303a339f30a9 ("bpfilter: remove extra header search paths for
> bpfilter_umh") reintroduced the build error fixed by commit ae40832e53c3
> ("bpfilter: fix a build err").
>
> Apology for the breakage, and thanks to Guenter for reporting this.
>
> Fixes: 303a339f30a9 ("bpfilter: remove extra header search paths for bpfilter_umh")
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
> ---
>
> Guenter,
>
> Sorry for bothering you, but
> could you please test this with your compiler?
>
> I am also using GCC 7.3, but my compiler cannot
> reproduce the build error.
>
>
> net/bpfilter/Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/bpfilter/Makefile b/net/bpfilter/Makefile
> index 5d6c776..854395f 100644
> --- a/net/bpfilter/Makefile
> +++ b/net/bpfilter/Makefile
> @@ -5,6 +5,7 @@
>
> hostprogs-y := bpfilter_umh
> bpfilter_umh-objs := main.o
> +KBUILD_HOSTCFLAGS += -Itools/include/ -Itools/include/uapi
> HOSTCC := $(CC)
>
> ifeq ($(CONFIG_BPFILTER_UMH), y)
>
^ permalink raw reply
* [PATCH net-next] kcm: Remove unnecessary SLAB_PANIC for kmem_cache_create() in kcm_init
From: Yue Haibing @ 2019-02-22 6:15 UTC (permalink / raw)
To: davem, ktkhai, gregkh, tom, asmadeus; +Cc: linux-kernel, netdev, YueHaibing
From: YueHaibing <yuehaibing@huawei.com>
There has check NULL on kmem_cache_create on failure in kcm_init,
no need use SLAB_PANIC to panic the system.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/kcm/kcmsock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/kcm/kcmsock.c b/net/kcm/kcmsock.c
index 571d824..c5c5ab6 100644
--- a/net/kcm/kcmsock.c
+++ b/net/kcm/kcmsock.c
@@ -2036,13 +2036,13 @@ static int __init kcm_init(void)
kcm_muxp = kmem_cache_create("kcm_mux_cache",
sizeof(struct kcm_mux), 0,
- SLAB_HWCACHE_ALIGN | SLAB_PANIC, NULL);
+ SLAB_HWCACHE_ALIGN, NULL);
if (!kcm_muxp)
goto fail;
kcm_psockp = kmem_cache_create("kcm_psock_cache",
sizeof(struct kcm_psock), 0,
- SLAB_HWCACHE_ALIGN | SLAB_PANIC, NULL);
+ SLAB_HWCACHE_ALIGN, NULL);
if (!kcm_psockp)
goto fail;
--
2.7.0
^ permalink raw reply related
* [PATCH net v3] net: set static variable an initial value in atl2_probe()
From: Mao Wenan @ 2019-02-22 6:57 UTC (permalink / raw)
To: kernel-janitors, chris.snook, jcliburn, dan.carpenter, netdev,
davem
cards_found is a static variable, but when it enters atl2_probe(),
cards_found is set to zero, the value is not consistent with last probe,
so next behavior is not our expect.
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
v1->v2: change the subject from "net: drop pointless static qualifier in atl2_probe()"
to "net: set static variable an initial value in atl2_probe()";
keep 'static' for variable cards_found.
v2->v3: change patch description, and send patch to netdev mail list.
drivers/net/ethernet/atheros/atlx/atl2.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atlx/atl2.c b/drivers/net/ethernet/atheros/atlx/atl2.c
index bb41becb6609..31ff1e0d1baa 100644
--- a/drivers/net/ethernet/atheros/atlx/atl2.c
+++ b/drivers/net/ethernet/atheros/atlx/atl2.c
@@ -1335,13 +1335,11 @@ static int atl2_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
{
struct net_device *netdev;
struct atl2_adapter *adapter;
- static int cards_found;
+ static int cards_found = 0;
unsigned long mmio_start;
int mmio_len;
int err;
- cards_found = 0;
-
err = pci_enable_device(pdev);
if (err)
return err;
--
2.20.1
^ permalink raw reply related
* [PATCH 5/5] net: dsa: fix a leaked reference by adding missing of_node_put
From: Wen Yang @ 2019-02-22 7:15 UTC (permalink / raw)
To: linus.walleij
Cc: andrew, vivien.didelot, f.fainelli, davem, netdev, linux-kernel,
alexandre.belloni, UNGLinuxDriver, nbd, lorenzo.bianconi83, kvalo,
matthias.bgg, linux-wireless, linux-arm-kernel, linux-mediatek,
anirudh, John.Linn, michal.simek, wang.yi59, Wen Yang
In-Reply-To: <1550819742-32155-1-git-send-email-wen.yang99@zte.com.cn>
The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
./net/dsa/port.c:294:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 284, but without a corresponding object release within this function.
./net/dsa/dsa2.c:627:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 618, but without a corresponding object release within this function.
./net/dsa/dsa2.c:630:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 618, but without a corresponding object release within this function.
./net/dsa/dsa2.c:636:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 618, but without a corresponding object release within this function.
./net/dsa/dsa2.c:639:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 618, but without a corresponding object release within this function.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Vivien Didelot <vivien.didelot@gmail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
net/dsa/dsa2.c | 16 ++++++++++------
net/dsa/port.c | 1 +
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index 8c431e0..89823f0 100644
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -613,7 +613,7 @@ static int dsa_switch_parse_ports_of(struct dsa_switch *ds,
struct device_node *ports, *port;
struct dsa_port *dp;
u32 reg;
- int err;
+ int err = 0;
ports = of_get_child_by_name(dn, "ports");
if (!ports) {
@@ -624,19 +624,23 @@ static int dsa_switch_parse_ports_of(struct dsa_switch *ds,
for_each_available_child_of_node(ports, port) {
err = of_property_read_u32(port, "reg", ®);
if (err)
- return err;
+ goto out_put_node;
- if (reg >= ds->num_ports)
- return -EINVAL;
+ if (reg >= ds->num_ports) {
+ err = -EINVAL;
+ goto out_put_node;
+ }
dp = &ds->ports[reg];
err = dsa_port_parse_of(dp, port);
if (err)
- return err;
+ goto out_put_node;
}
- return 0;
+out_put_node:
+ of_node_put(ports);
+ return err;
}
static int dsa_switch_parse_member_of(struct dsa_switch *ds,
diff --git a/net/dsa/port.c b/net/dsa/port.c
index 2d7e01b..a6d9a04 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -291,6 +291,7 @@ static struct phy_device *dsa_port_get_phy_device(struct dsa_port *dp)
return ERR_PTR(-EPROBE_DEFER);
}
+ of_node_put(phy_dn);
return phydev;
}
--
2.9.5
^ permalink raw reply related
* [PATCH 3/5] mt76: fix a leaked reference by adding a missing of_node_put
From: Wen Yang @ 2019-02-22 7:15 UTC (permalink / raw)
To: linus.walleij
Cc: andrew, vivien.didelot, f.fainelli, davem, netdev, linux-kernel,
alexandre.belloni, UNGLinuxDriver, nbd, lorenzo.bianconi83, kvalo,
matthias.bgg, linux-wireless, linux-arm-kernel, linux-mediatek,
anirudh, John.Linn, michal.simek, wang.yi59, Wen Yang
In-Reply-To: <1550819742-32155-1-git-send-email-wen.yang99@zte.com.cn>
The call to of_find_node_by_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
./drivers/net/wireless/mediatek/mt76/eeprom.c:58:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:61:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:67:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:70:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:72:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Cc: Felix Fietkau <nbd@nbd.name>
Cc: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/wireless/mediatek/mt76/eeprom.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/eeprom.c b/drivers/net/wireless/mediatek/mt76/eeprom.c
index 530e559..a1529920d 100644
--- a/drivers/net/wireless/mediatek/mt76/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/eeprom.c
@@ -54,22 +54,30 @@ mt76_get_of_eeprom(struct mt76_dev *dev, int len)
part = np->name;
mtd = get_mtd_device_nm(part);
- if (IS_ERR(mtd))
- return PTR_ERR(mtd);
+ if (IS_ERR(mtd)) {
+ ret = PTR_ERR(mtd);
+ goto out_put_node;
+ }
- if (size <= sizeof(*list))
- return -EINVAL;
+ if (size <= sizeof(*list)) {
+ ret = -EINVAL;
+ goto out_put_node;
+ }
offset = be32_to_cpup(list);
ret = mtd_read(mtd, offset, len, &retlen, dev->eeprom.data);
put_mtd_device(mtd);
if (ret)
- return ret;
+ goto out_put_node;
- if (retlen < len)
- return -EINVAL;
+ if (retlen < len) {
+ ret = -EINVAL;
+ goto out_put_node;
+ }
- return 0;
+out_put_node:
+ of_node_put(np);
+ return ret;
#else
return -ENOENT;
#endif
--
2.9.5
^ permalink raw reply related
* [PATCH 4/5] net: xilinx: fix a leaked reference by adding missing of_node_put
From: Wen Yang @ 2019-02-22 7:15 UTC (permalink / raw)
To: linus.walleij
Cc: andrew, vivien.didelot, f.fainelli, davem, netdev, linux-kernel,
alexandre.belloni, UNGLinuxDriver, nbd, lorenzo.bianconi83, kvalo,
matthias.bgg, linux-wireless, linux-arm-kernel, linux-mediatek,
anirudh, John.Linn, michal.simek, wang.yi59, Wen Yang
In-Reply-To: <1550819742-32155-1-git-send-email-wen.yang99@zte.com.cn>
The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warning:
./drivers/net/ethernet/xilinx/xilinx_axienet_main.c:1624:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 1569, but without a corresponding object release within this function.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Cc: Anirudha Sarangi <anirudh@xilinx.com>
Cc: John Linn <John.Linn@xilinx.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: netdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 0789d8a..8335390 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -1575,11 +1575,13 @@ static int axienet_probe(struct platform_device *pdev)
ret = of_address_to_resource(np, 0, &dmares);
if (ret) {
dev_err(&pdev->dev, "unable to get DMA resource\n");
+ of_node_put(np);
goto free_netdev;
}
lp->dma_regs = devm_ioremap_resource(&pdev->dev, &dmares);
if (IS_ERR(lp->dma_regs)) {
dev_err(&pdev->dev, "could not map DMA regs\n");
+ of_node_put(np);
ret = PTR_ERR(lp->dma_regs);
goto free_netdev;
}
--
2.9.5
^ permalink raw reply related
* [PATCH 2/5] net: mscc: ocelot: fix a leaked reference by adding a missing of_node_put
From: Wen Yang @ 2019-02-22 7:15 UTC (permalink / raw)
To: linus.walleij
Cc: andrew, vivien.didelot, f.fainelli, davem, netdev, linux-kernel,
alexandre.belloni, UNGLinuxDriver, nbd, lorenzo.bianconi83, kvalo,
matthias.bgg, linux-wireless, linux-arm-kernel, linux-mediatek,
anirudh, John.Linn, michal.simek, wang.yi59, Wen Yang
In-Reply-To: <1550819742-32155-1-git-send-email-wen.yang99@zte.com.cn>
The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
./drivers/net/ethernet/mscc/ocelot_board.c:293:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 249, but without a corresponding object release within this function.
./drivers/net/ethernet/mscc/ocelot_board.c:312:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 249, but without a corresponding object release within this function.
./drivers/net/ethernet/mscc/ocelot_board.c:336:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 249, but without a corresponding object release within this function.
./drivers/net/ethernet/mscc/ocelot_board.c:339:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 249, but without a corresponding object release within this function.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/mscc/ocelot_board.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mscc/ocelot_board.c b/drivers/net/ethernet/mscc/ocelot_board.c
index ca3ea2f..f1485a6 100644
--- a/drivers/net/ethernet/mscc/ocelot_board.c
+++ b/drivers/net/ethernet/mscc/ocelot_board.c
@@ -290,7 +290,7 @@ static int mscc_ocelot_probe(struct platform_device *pdev)
err = ocelot_probe_port(ocelot, port, regs, phy);
if (err)
- return err;
+ goto err_probe_ports;
err = of_get_phy_mode(portnp);
if (err < 0)
@@ -309,7 +309,8 @@ static int mscc_ocelot_probe(struct platform_device *pdev)
dev_err(ocelot->dev,
"invalid phy mode for port%d, (Q)SGMII only\n",
port);
- return -EINVAL;
+ err = -EINVAL;
+ goto err_probe_ports;
}
serdes = devm_of_phy_get(ocelot->dev, portnp, NULL);
@@ -328,6 +329,7 @@ static int mscc_ocelot_probe(struct platform_device *pdev)
ocelot->ports[port]->serdes = serdes;
}
+ of_node_put(ports);
register_netdevice_notifier(&ocelot_netdevice_nb);
register_switchdev_blocking_notifier(&ocelot_switchdev_blocking_nb);
@@ -336,6 +338,7 @@ static int mscc_ocelot_probe(struct platform_device *pdev)
return 0;
err_probe_ports:
+ of_node_put(ports);
return err;
}
--
2.9.5
^ permalink raw reply related
* [PATCH 1/5] net: dsa: fix a leaked reference by adding a missing of_node_put
From: Wen Yang @ 2019-02-22 7:15 UTC (permalink / raw)
To: linus.walleij
Cc: andrew, vivien.didelot, f.fainelli, davem, netdev, linux-kernel,
alexandre.belloni, UNGLinuxDriver, nbd, lorenzo.bianconi83, kvalo,
matthias.bgg, linux-wireless, linux-arm-kernel, linux-mediatek,
anirudh, John.Linn, michal.simek, wang.yi59, Wen Yang
The call to of_get_child_by_name returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
./drivers/net/dsa/rtl8366rb.c:510:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 501, but without a corresponding object release within this function.
./drivers/net/dsa/rtl8366rb.c:518:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 501, but without a corresponding object release within this function.
./drivers/net/dsa/rtl8366rb.c:540:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 501, but without a corresponding object release within this function.
./drivers/net/dsa/rtl8366rb.c:548:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 501, but without a corresponding object release within this function.
./drivers/net/dsa/rtl8366rb.c:556:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 501, but without a corresponding object release within this function.
./drivers/net/dsa/rtl8366rb.c:561:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 501, but without a corresponding object release within this function.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Vivien Didelot <vivien.didelot@gmail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/dsa/rtl8366rb.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/dsa/rtl8366rb.c b/drivers/net/dsa/rtl8366rb.c
index a4d5049..f4b14b6 100644
--- a/drivers/net/dsa/rtl8366rb.c
+++ b/drivers/net/dsa/rtl8366rb.c
@@ -507,7 +507,8 @@ static int rtl8366rb_setup_cascaded_irq(struct realtek_smi *smi)
irq = of_irq_get(intc, 0);
if (irq <= 0) {
dev_err(smi->dev, "failed to get parent IRQ\n");
- return irq ? irq : -EINVAL;
+ ret = irq ? irq : -EINVAL;
+ goto out_put_node;
}
/* This clears the IRQ status register */
@@ -515,7 +516,7 @@ static int rtl8366rb_setup_cascaded_irq(struct realtek_smi *smi)
&val);
if (ret) {
dev_err(smi->dev, "can't read interrupt status\n");
- return ret;
+ goto out_put_node;
}
/* Fetch IRQ edge information from the descriptor */
@@ -537,7 +538,7 @@ static int rtl8366rb_setup_cascaded_irq(struct realtek_smi *smi)
val);
if (ret) {
dev_err(smi->dev, "could not configure IRQ polarity\n");
- return ret;
+ goto out_put_node;
}
ret = devm_request_threaded_irq(smi->dev, irq, NULL,
@@ -545,7 +546,7 @@ static int rtl8366rb_setup_cascaded_irq(struct realtek_smi *smi)
"RTL8366RB", smi);
if (ret) {
dev_err(smi->dev, "unable to request irq: %d\n", ret);
- return ret;
+ goto out_put_node;
}
smi->irqdomain = irq_domain_add_linear(intc,
RTL8366RB_NUM_INTERRUPT,
@@ -553,12 +554,15 @@ static int rtl8366rb_setup_cascaded_irq(struct realtek_smi *smi)
smi);
if (!smi->irqdomain) {
dev_err(smi->dev, "failed to create IRQ domain\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto out_put_node;
}
for (i = 0; i < smi->num_ports; i++)
irq_set_parent(irq_create_mapping(smi->irqdomain, i), irq);
- return 0;
+out_put_node:
+ of_node_put(intc);
+ return ret;
}
static int rtl8366rb_set_addr(struct realtek_smi *smi)
--
2.9.5
^ permalink raw reply related
* [PATCH net-next] net: phy: let genphy_c45_read_abilities also check aneg capability
From: Heiner Kallweit @ 2019-02-22 7:23 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller
Cc: netdev@vger.kernel.org, Maxime Chevallier
When using genphy_c45_read_abilities() as get_features callback we
also have to set the autoneg capability in phydev->supported.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy-c45.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/phy/phy-c45.c b/drivers/net/phy/phy-c45.c
index 4835c96cb..f05ef267a 100644
--- a/drivers/net/phy/phy-c45.c
+++ b/drivers/net/phy/phy-c45.c
@@ -336,6 +336,17 @@ int genphy_c45_pma_read_abilities(struct phy_device *phydev)
{
int val;
+ linkmode_clear_bit(ETHTOOL_LINK_MODE_Autoneg_BIT, phydev->supported);
+ if (phydev->c45_ids.devices_in_package & MDIO_DEVS_AN) {
+ val = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_STAT1);
+ if (val < 0)
+ return val;
+
+ if (val & MDIO_AN_STAT1_ABLE)
+ linkmode_set_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
+ phydev->supported);
+ }
+
val = phy_read_mmd(phydev, MDIO_MMD_PMAPMD, MDIO_STAT2);
if (val < 0)
return val;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] x86, retpolines: raise limit for generating indirect calls from switch-case
From: Jesper Dangaard Brouer @ 2019-02-22 7:31 UTC (permalink / raw)
To: Daniel Borkmann
Cc: tglx, linux-kernel, netdev, David S . Miller,
Björn Töpel, Magnus Karlsson, Alexei Starovoitov,
Peter Zijlstra, David Woodhouse, Andy Lutomirski, Borislav Petkov,
Linus Torvalds, brouer
In-Reply-To: <20190221221941.29358-1-daniel@iogearbox.net>
On Thu, 21 Feb 2019 23:19:41 +0100
Daniel Borkmann <daniel@iogearbox.net> wrote:
> Recent work on XDP from Björn and Magnus additionally found that
> manually transforming the XDP return code switch statement with
> more than 5 cases into if-else combination would result in a
> considerable speedup in XDP layer due to avoidance of indirect
> calls in CONFIG_RETPOLINE enabled builds. On i40e driver with
> XDP prog attached, a 20-26% speedup has been observed [0]. Aside
> from XDP, there are many other places later in the networking
> stack's critical path with similar switch-case processing. Rather
> than fixing every XDP-enabled driver and locations in stack by
> hand, it would be good to instead raise the limit where gcc would
> emit expensive indirect calls from the switch under retpolines
I'm very happy to see this. Thanks to Björn for finding, analyzing and
providing hand-coded-if-else code that demonstrated the performance
issue for XDP. But I do think this GCC case-values-threshold param is
a better and more generic solution to the issue we observed and
measured in XDP land. And hopefully other parts of the network stack
and kernel will also benefit.
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
Thanks for following up on this Daniel,
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH] net: nfc: Fix NULL dereference on nfc_llcp_build_tlv fails
From: Yue Haibing @ 2019-02-22 7:37 UTC (permalink / raw)
To: sameo, davem; +Cc: linux-kernel, netdev, linux-wireless, YueHaibing
From: YueHaibing <yuehaibing@huawei.com>
KASAN report this:
BUG: KASAN: null-ptr-deref in nfc_llcp_build_gb+0x37f/0x540 [nfc]
Read of size 3 at addr 0000000000000000 by task syz-executor.0/5401
CPU: 0 PID: 5401 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xfa/0x1ce lib/dump_stack.c:113
kasan_report+0x171/0x18d mm/kasan/report.c:321
memcpy+0x1f/0x50 mm/kasan/common.c:130
nfc_llcp_build_gb+0x37f/0x540 [nfc]
nfc_llcp_register_device+0x6eb/0xb50 [nfc]
nfc_register_device+0x50/0x1d0 [nfc]
nfcsim_device_new+0x394/0x67d [nfcsim]
? 0xffffffffc1080000
nfcsim_init+0x6b/0x1000 [nfcsim]
do_one_initcall+0xfa/0x5ca init/main.c:887
do_init_module+0x204/0x5f6 kernel/module.c:3460
load_module+0x66b2/0x8570 kernel/module.c:3808
__do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x462e99
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f9cb79dcc58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
RDX: 0000000000000000 RSI: 0000000020000280 RDI: 0000000000000003
RBP: 00007f9cb79dcc70 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f9cb79dd6bc
R13: 00000000004bcefb R14: 00000000006f7030 R15: 0000000000000004
nfc_llcp_build_tlv will return NULL on fails, caller should check it,
otherwise will trigger a NULL dereference.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: eda21f16a5ed ("NFC: Set MIU and RW values from CONNECT and CC LLCP frames")
Fixes: d646960f7986 ("NFC: Initial LLCP support")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/nfc/llcp_commands.c | 20 ++++++++++++++++++++
net/nfc/llcp_core.c | 24 ++++++++++++++++++++----
2 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/net/nfc/llcp_commands.c b/net/nfc/llcp_commands.c
index 6a196e4..d1fc019e 100644
--- a/net/nfc/llcp_commands.c
+++ b/net/nfc/llcp_commands.c
@@ -419,6 +419,10 @@ int nfc_llcp_send_connect(struct nfc_llcp_sock *sock)
sock->service_name,
sock->service_name_len,
&service_name_tlv_length);
+ if (!service_name_tlv) {
+ err = -ENOMEM;
+ goto error_tlv;
+ }
size += service_name_tlv_length;
}
@@ -429,9 +433,17 @@ int nfc_llcp_send_connect(struct nfc_llcp_sock *sock)
miux_tlv = nfc_llcp_build_tlv(LLCP_TLV_MIUX, (u8 *)&miux, 0,
&miux_tlv_length);
+ if (!miux_tlv) {
+ err = -ENOMEM;
+ goto error_tlv;
+ }
size += miux_tlv_length;
rw_tlv = nfc_llcp_build_tlv(LLCP_TLV_RW, &rw, 0, &rw_tlv_length);
+ if (!rw_tlv) {
+ err = -ENOMEM;
+ goto error_tlv;
+ }
size += rw_tlv_length;
pr_debug("SKB size %d SN length %zu\n", size, sock->service_name_len);
@@ -484,9 +496,17 @@ int nfc_llcp_send_cc(struct nfc_llcp_sock *sock)
miux_tlv = nfc_llcp_build_tlv(LLCP_TLV_MIUX, (u8 *)&miux, 0,
&miux_tlv_length);
+ if (!miux_tlv) {
+ err = -ENOMEM;
+ goto error_tlv;
+ }
size += miux_tlv_length;
rw_tlv = nfc_llcp_build_tlv(LLCP_TLV_RW, &rw, 0, &rw_tlv_length);
+ if (!rw_tlv) {
+ err = -ENOMEM;
+ goto error_tlv;
+ }
size += rw_tlv_length;
skb = llcp_allocate_pdu(sock, LLCP_PDU_CC, size);
diff --git a/net/nfc/llcp_core.c b/net/nfc/llcp_core.c
index ef4026a..4fa0152 100644
--- a/net/nfc/llcp_core.c
+++ b/net/nfc/llcp_core.c
@@ -532,10 +532,10 @@ static u8 nfc_llcp_reserve_sdp_ssap(struct nfc_llcp_local *local)
static int nfc_llcp_build_gb(struct nfc_llcp_local *local)
{
- u8 *gb_cur, *version_tlv, version, version_length;
- u8 *lto_tlv, lto_length;
- u8 *wks_tlv, wks_length;
- u8 *miux_tlv, miux_length;
+ u8 *gb_cur, version, version_length;
+ u8 lto_length, wks_length, miux_length;
+ u8 *version_tlv = NULL, *lto_tlv = NULL,
+ *wks_tlv = NULL, *miux_tlv = NULL;
__be16 wks = cpu_to_be16(local->local_wks);
u8 gb_len = 0;
int ret = 0;
@@ -543,17 +543,33 @@ static int nfc_llcp_build_gb(struct nfc_llcp_local *local)
version = LLCP_VERSION_11;
version_tlv = nfc_llcp_build_tlv(LLCP_TLV_VERSION, &version,
1, &version_length);
+ if (!version_tlv) {
+ ret = -ENOMEM;
+ goto out;
+ }
gb_len += version_length;
lto_tlv = nfc_llcp_build_tlv(LLCP_TLV_LTO, &local->lto, 1, <o_length);
+ if (!lto_tlv) {
+ ret = -ENOMEM;
+ goto out;
+ }
gb_len += lto_length;
pr_debug("Local wks 0x%lx\n", local->local_wks);
wks_tlv = nfc_llcp_build_tlv(LLCP_TLV_WKS, (u8 *)&wks, 2, &wks_length);
+ if (!wks_tlv) {
+ ret = -ENOMEM;
+ goto out;
+ }
gb_len += wks_length;
miux_tlv = nfc_llcp_build_tlv(LLCP_TLV_MIUX, (u8 *)&local->miux, 0,
&miux_length);
+ if (!miux_tlv) {
+ ret = -ENOMEM;
+ goto out;
+ }
gb_len += miux_length;
gb_len += ARRAY_SIZE(llcp_magic);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next 1/5] net/mlx5e: Return -EOPNOTSUPP when modify header action zero
From: Tonghao Zhang @ 2019-02-22 7:39 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Saeed Mahameed, Linux Netdev List
In-Reply-To: <CAJ3xEMjUc93sYnCKBBmno_uxJ81UtqYDTtmMZzP=yzaGynz0Qg@mail.gmail.com>
On Fri, Feb 22, 2019 at 12:27 AM Or Gerlitz <gerlitz.or@gmail.com> wrote:
>
> On Thu, Feb 21, 2019 at 3:42 PM <xiangxia.m.yue@gmail.com> wrote:
> > else /* namespace is MLX5_FLOW_NAMESPACE_KERNEL - NIC offloading */
> > max_actions = MLX5_CAP_FLOWTABLE_NIC_RX(priv->mdev, max_modify_header_actions);
> >
> > + if (!max_actions) {
> > + NL_SET_ERR_MSG_MOD(extack,
> > + "don't support pedit actions, can't offload");
> > + netdev_warn(priv->netdev, "don't support pedit actions, can't offload\n");
>
> it's not going to work if we keep filling the driver with duplicated
> error messages, stick to extack only
v2 will be sent
> Also, when you respin with comments provided on this submission,
> please send also cover letter
> which is going to be "[PATCH net-next 00/05] ... " use
> --cover-letter for git format-patch and edit it after creation
OK
^ permalink raw reply
* Re: [PATCH v2] iwlwifi: mvm: Use div_s64 instead of do_div in iwl_mvm_debug_range_resp
From: Luciano Coelho @ 2019-02-22 7:45 UTC (permalink / raw)
To: Nick Desaulniers, Nathan Chancellor
Cc: Johannes Berg, Emmanuel Grumbach, Intel Linux Wireless,
Kalle Valo, linux-wireless, netdev, LKML, Arnd Bergmann
In-Reply-To: <CAKwvOdmCeHxiGPkXXzjwnTtgzEDDjYRE1QBdu7BHeuzCE4YtRA@mail.gmail.com>
On Thu, 2019-02-21 at 16:13 -0800, Nick Desaulniers wrote:
> On Thu, Feb 21, 2019 at 12:08 AM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> > Clang warns:
> >
> > drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:465:2:
> > warning:
> > comparison of distinct pointer types ('typeof ((rtt_avg)) *' (aka
> > 'long
> > long *') and 'uint64_t *' (aka 'unsigned long long *'))
> > [-Wcompare-distinct-pointer-types]
> > do_div(rtt_avg, 6666);
> > ^~~~~~~~~~~~~~~~~~~~~
> > include/asm-generic/div64.h:222:28: note: expanded from macro
> > 'do_div'
> > (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
> > ~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~
> > 1 warning generated.
> >
> > do_div expects an unsigned dividend. Use div_s64, which expects a
> > signed
> > dividend.
> >
> > Fixes: 937b10c0de68 ("iwlwifi: mvm: add debug prints for FTM")
> > Link: https://github.com/ClangBuiltLinux/linux/issues/372
> > Suggested-by: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> > ---
> >
> > v1 -> v2:
> >
> > * Fix logic (as the return value of div{,64}_s64 must be used),
> > thanks
> > to Arnd for the review.
>
> oh boy, sorry I missed that in the initial code review, thanks Arnd
> for the sharp eye!
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Thanks, guys, I really didn't pay much attention when I applied the
previous versions either.
I have applied this in our internal tree and will send it out instead
of the previous one as part of our upstreaming process.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH net-next 2/5] net/mlx5e: Make the log friendly when decapsulation offload not supported
From: Tonghao Zhang @ 2019-02-22 7:48 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Saeed Mahameed, Linux Netdev List
In-Reply-To: <CAJ3xEMh_-NTfsELextUZ0Nk0P1n0r5+H3R7hjwxX_TQT+h=3DA@mail.gmail.com>
On Fri, Feb 22, 2019 at 12:32 AM Or Gerlitz <gerlitz.or@gmail.com> wrote:
>
> On Thu, Feb 21, 2019 at 3:42 PM <xiangxia.m.yue@gmail.com> wrote:
> >
> > From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> >
> > If we try to offload decapsulation actions to VFs hw, we get the log [1].
>
> but the switching was on the tunnel type (if (tunnel_type == [...]) -
Yes, but we try to offload tc flow to VF device. For example
the p2p1_0 is VF, but not rep
tc qdisc add dev p2p1_0 ingress
ethtool -K p2p1_0 hw-tc-offload on
tc filter add dev p2p1_0 protocol ip chain 0 parent ffff: prio 1
flower skip_sw dst_mac 00:10:56:fb:64:e8 dst_ip 10.100.3.104 src_ip
10.100.4.0/24 enc_dst_ip 192.168.240.128 enc_key_id 100 enc_dst_port
4789 action tunnel_key unset
> what rules caused you to get here?
> what was the ingress device and what was the egress (mirred) device?
the ingress device is p2p1_0 (VF), and the egress (mirred) device is not used
>
> > It's not friendly, because the kind of net device is null, and we don't
> > know what '0' means.
> >
> > [1] "mlx5_core 0000:05:01.2 vf_0: decapsulation offload is not supported for net device (0)"
^ permalink raw reply
* Re: [PATCH net-next 5/5] net/mlx5e: Support enable/disable VFs link state on switchdev mode
From: Tonghao Zhang @ 2019-02-22 7:49 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Saeed Mahameed, Linux Netdev List
In-Reply-To: <CAJ3xEMgVe7xthCwEUtm0MC_AqoDcZPY06vVkn3woM9jWxQj5+Q@mail.gmail.com>
On Fri, Feb 22, 2019 at 1:03 AM Or Gerlitz <gerlitz.or@gmail.com> wrote:
>
> On Thu, Feb 21, 2019 at 3:42 PM <xiangxia.m.yue@gmail.com> wrote:
> > From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> >
> > This patch allow users to enable/disable VFs link state
> > on switchdev mode.
>
> NAK
>
> We do it with the reps, if you change the administrative link state of a VF rep
> it will effect the operational link state of the VF, see upstream commit
>
> 20a1ea674783 net/mlx5e: Support VF vport link state control for SRIOV
> switchdev mode
Thanks，it is useful for us.
^ permalink raw reply
* Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework)
From: si-wei liu @ 2019-02-22 7:55 UTC (permalink / raw)
To: Samudrala, Sridhar, Michael S. Tsirkin, Siwei Liu
Cc: Jiri Pirko, Stephen Hemminger, David Miller, Netdev,
virtualization, virtio-dev, Brandeburg, Jesse, Alexander Duyck,
Jakub Kicinski, Jason Wang, liran.alon
In-Reply-To: <91d4cbb1-be7a-b53c-6b2a-99bef07e7c53@intel.com>
On 2/21/2019 11:00 PM, Samudrala, Sridhar wrote:
>
>
> On 2/21/2019 7:33 PM, si-wei liu wrote:
>>
>>
>> On 2/21/2019 5:39 PM, Michael S. Tsirkin wrote:
>>> On Thu, Feb 21, 2019 at 05:14:44PM -0800, Siwei Liu wrote:
>>>> Sorry for replying to this ancient thread. There was some remaining
>>>> issue that I don't think the initial net_failover patch got addressed
>>>> cleanly, see:
>>>>
>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815268
>>>>
>>>> The renaming of 'eth0' to 'ens4' fails because the udev userspace was
>>>> not specifically writtten for such kernel automatic enslavement.
>>>> Specifically, if it is a bond or team, the slave would typically get
>>>> renamed *before* virtual device gets created, that's what udev can
>>>> control (without getting netdev opened early by the other part of
>>>> kernel) and other userspace components for e.g. initramfs,
>>>> init-scripts can coordinate well in between. The in-kernel
>>>> auto-enslavement of net_failover breaks this userspace convention,
>>>> which don't provides a solution if user care about consistent naming
>>>> on the slave netdevs specifically.
>>>>
>>>> Previously this issue had been specifically called out when IFF_HIDDEN
>>>> and the 1-netdev was proposed, but no one gives out a solution to this
>>>> problem ever since. Please share your mind how to proceed and solve
>>>> this userspace issue if netdev does not welcome a 1-netdev model.
>>> Above says:
>>>
>>> there's no motivation in the systemd/udevd community at
>>> this point to refactor the rename logic and make it work well with
>>> 3-netdev.
>>>
>>> What would the fix be? Skip slave devices?
>>>
>> There's nothing user can get if just skipping slave devices - the
>> name is still unchanged and unpredictable e.g. eth0, or eth1 the next
>> reboot, while the rest may conform to the naming scheme (ens3 and
>> such). There's no way one can fix this in userspace alone - when the
>> failover is created the enslaved netdev was opened by the kernel
>> earlier than the userspace is made aware of, and there's no
>> negotiation protocol for kernel to know when userspace has done
>> initial renaming of the interface. I would expect netdev list should
>> at least provide the direction in general for how this can be solved...
>>
> Is there an issue if slave device names are not predictable? The user/admin scripts are expected
> to only work with the master failover device.
Where does this expectation come from?
Admin users may have ethtool or tc configurations that need to deal with
predictable interface name. Third-party app which was built upon
specifying certain interface name can't be modified to chase dynamic names.
Specifically, we have pre-canned image that uses ethtool to fine tune VF
offload settings post boot for specific workload. Those images won't
work well if the name is constantly changing just after couple rounds of
live migration.
> Moreover, you were suggesting hiding the lower slave devices anyway. There was some discussion
> about moving them to a hidden network namespace so that they are not visible from the default namespace.
> I looked into this sometime back, but did not find the right kernel api to create a network namespace within
> kernel. If so, we could use this mechanism to simulate a 1-netdev model.
Yes, that's one possible implementation (IMHO the key is to make
1-netdev model as much transparent to a real NIC as possible, while a
hidden netns is just the vehicle). However, I recall there was
resistance around this discussion that even the concept of hiding itself
is a taboo for Linux netdev. I would like to summon potential
alternatives before concluding 1-netdev is the only solution too soon.
Thanks,
-Siwei
>
>> -Siwei
>>
>>
^ permalink raw reply
* Re: [Bridge] [PATCH net] net: bridge: remove ipv6 zero address check in mcast queries
From: Hangbin Liu @ 2019-02-22 7:57 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Linus Lüssing, netdev, roopa, bridge, davem, yinxu,
Sebastian Gottschall
In-Reply-To: <9db055dd-6486-1d6e-7dce-edc511650af9@cumulusnetworks.com>
Hi Nikolay,
On Thu, Feb 21, 2019 at 03:20:14PM +0200, Nikolay Aleksandrov wrote:
> >
> > Yes, I agree. But this "regression" could be fixed by setting up correct
> > switch configuration. See more explains below.
> >
>
> That is irrelevant, if the setup once worked we should not break it unless
> it's in RFC requirement violation and RFC 4541 is only suggestive, not required.
Thanks for your reply. I just noticed the RFC4541 category is informational.
> > "because this would cause the Queries to be seen as coming from a newly
> > elected Querier" means other address could be elected as a Querier but
> > "0.0.0.0" should not.
> >
>
> But this change hasn't been incorporated, has it ? A 0.0.0.0 address currently
> will always win the election and silence all of the rest. Current bridge state
> is simply broken for some cases because of that.
Yes. I agree. I realized linus also said
"""
However, one of the two options seems to be necessary. Either
reverting the patch for the IGMP part, too. Or Ignoring 0.0.0.0
sources for querier eletcion and presence detection.
"""
>
> Removing 0.0.0.0 from the election will effectively disable snooping even if there's
> a configured bridge unless it has an address. You can see that this will end up in
> people having suddenly their multicast flooded with current setups, right ?
Yes
> Any big behaviour change like that should be optional, but I don't think we need
> another option as this is not so big of a deal because we're not breaking any
> required behaviour.
Just a little curious, RFC 3376 said the General Queries are sent from multicast
routers. I think a router *should* has a IP address, isn't it?
RFC 4541 also suggested:
If the switch is not the Querier, it should use the 'all-zeros' IP
Source Address in these proxy queries (even though some hosts may
elect to not process queries with a 0.0.0.0 IP Source Address).
When such proxy queries are received, they must not be included in
the Querier election process.
And what I got is most vendors apply this suggestion.
> In case you decide to follow the option path, please use the new boolopt api to avoid
> adding new fields to the bridge, this should be an on/off thing. I still vote for a
> revert though.
For consistency with other vendors and rfc, I would prefer to remove zero address election.
For compatibility with previous users, I'm also OK to revert it.
Regards
Hangbin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox