* Re: [PATCH v2] net: dsa: b53: Add BCM5389 support
From: David Miller @ 2018-06-01 15:16 UTC (permalink / raw)
To: damien.thebault; +Cc: vivien.didelot, f.fainelli, andrew, netdev
In-Reply-To: <1ce940f7dc9c2d57c53e93341629e1981755689a.camel@vitec.com>
From: Damien Thébault <damien.thebault@vitec.com>
Date: Thu, 31 May 2018 07:04:01 +0000
> This patch adds support for the BCM5389 switch connected through MDIO.
>
> Signed-off-by: Damien Thébault <damien.thebault@vitec.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next v2] net: sched: split tc_ctl_tfilter into three handlers
From: David Miller @ 2018-06-01 15:14 UTC (permalink / raw)
To: vladbu; +Cc: jiri, netdev, jhs, xiyou.wangcong
In-Reply-To: <1527749573-18654-1-git-send-email-vladbu@mellanox.com>
From: Vlad Buslov <vladbu@mellanox.com>
Date: Thu, 31 May 2018 09:52:53 +0300
> tc_ctl_tfilter handles three netlink message types: RTM_NEWTFILTER,
> RTM_DELTFILTER, RTM_GETTFILTER. However, implementation of this function
> involves a lot of branching on specific message type because most of the
> code is message-specific. This significantly complicates adding new
> functionality and doesn't provide much benefit of code reuse.
>
> Split tc_ctl_tfilter to three standalone functions that handle filter new,
> delete and get requests.
>
> The only truly protocol independent part of tc_ctl_tfilter is code that
> looks up queue, class, and block. Refactor this code to standalone
> tcf_block_find function that is used by all three new handlers.
>
> Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
> ---
> Changes V1 -> V2:
> - Rebase on current net-next
Applied, thank you.
^ permalink raw reply
* Re: [PATCH V2 mlx5-next 0/2] Mellanox, mlx5 new device events
From: Doug Ledford @ 2018-06-01 15:08 UTC (permalink / raw)
To: David Miller, saeedm; +Cc: netdev, linux-rdma, leonro, jgg
In-Reply-To: <20180531.153603.45475041396194381.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]
On Thu, 2018-05-31 at 15:36 -0400, David Miller wrote:
> From: Saeed Mahameed <saeedm@mellanox.com>
> Date: Wed, 30 May 2018 10:59:48 -0700
>
> > The following series is for mlx5-next tree [1], it adds the support of two
> > new device events, from Ilan Tayari:
> >
> > 1. High temperature warnings.
> > 2. FPGA QP error event.
> >
> > In case of no objection this series will be applied to mlx5-next tree
> > and will be sent later as a pull request to both rdma and net trees.
> >
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git/log/?h=mlx5-next
> >
> > v1->v2:
> > - improve commit message of the FPGA QP error event patch.
>
> Series applied, thanks.
Hi Dave,
Although in this case it doesn't really matter and we can work around
it, this was supposed to be a case of the new methodology that Saeed and
Jason had worked out with you. Specifically, when Saeed says in the
cover letter:
> In case of no objection this series will be applied to mlx5-next tree>
> and will be sent later as a pull request to both rdma and net trees.
then it is intended for you to ack the original patch series, not apply
it, and when acks from both the net and rdma side have been received,
then we will get a pull request of just that series.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH iproute2] ip: IFLA_NEW_NETNSID/IFLA_NEW_IFINDEX support
From: Nicolas Dichtel @ 2018-06-01 15:02 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <d6326980-bce3-5e73-11d0-f053e0511c77@6wind.com>
Le 31/05/2018 à 17:51, Nicolas Dichtel a écrit :
> Le 31/05/2018 à 17:46, Stephen Hemminger a écrit :
>> On Thu, 31 May 2018 16:28:48 +0200
> [snip]
>> This makes sense. All of linkinfo that is present should be displayed.
>>
>> Both netns and ifindex are really unsigned values. Use __u32 and print_uint.
> Ok.
I replied a bit quickly, both are signed values:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/core/rtnetlink.c#n1621
Regards,
Nicolas
^ permalink raw reply
* [PATCH net-next 1/1] net/smc: remove duplicate check in smc_setsockopt
From: Ursula Braun @ 2018-06-01 14:58 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl, ubraun
From: Ursula Braun <ubraun@linux.ibm.com>
smc_setsockopt contains a check for the length specified on the
setsockopt socket call. If checked, it is supposed to return with
EINVAL. But the equivalent check is already contained in the preceding
setsockopt call on the internal TCP socket. That means, the extra
check can be removed.
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
Fixes: 01d2f7e2cdd3 ("net/smc: sockopts TCP_NODELAY and TCP_CORK")
Reported-by: Wei Yongjun <weiyongjun1@huawei.com>
---
net/smc/af_smc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 2c369d4bb1c1..dec3f09f6327 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -1419,8 +1419,6 @@ static int smc_setsockopt(struct socket *sock, int level, int optname,
if (rc)
return rc;
- if (optlen < sizeof(int))
- return rc;
get_user(val, (int __user *)optval);
lock_sock(sk);
--
2.16.3
^ permalink raw reply related
* Re: [PATCH iproute2] devlink: don't enforce NETLINK_{CAP,EXT}_ACK sock opts
From: Jiri Pirko @ 2018-06-01 14:54 UTC (permalink / raw)
To: Ivan Vecera; +Cc: netdev, Arkadi Sharshevsky, Stephen Hemminger
In-Reply-To: <20180601081849.3929-1-ivecera@redhat.com>
Fri, Jun 01, 2018 at 10:18:49AM CEST, ivecera@redhat.com wrote:
>Since commit 049c58539f5d ("devlink: mnlg: Add support for extended ack")
>devlink requires NETLINK_{CAP,EXT}_ACK. This prevents devlink from
>working with older kernels that don't support these features.
>
>host # ./devlink/devlink
>Failed to connect to devlink Netlink
>
>Fixes: 049c58539f5d ("devlink: mnlg: Add support for extended ack")
Acked-by: Jiri Pirko <jiri@mellanox.com>
Thanks!
^ permalink raw reply
* Re: [PATCH net] ipv4: igmp: hold wakelock to prevent delayed reports
From: Florian Fainelli @ 2018-06-01 14:45 UTC (permalink / raw)
To: Tejaswi Tanikella, netdev; +Cc: Andrew Lunn
In-Reply-To: <20180601140532.GA13253@tejaswit-linux.qualcomm.com>
On 06/01/2018 07:05 AM, Tejaswi Tanikella wrote:
> On receiving a IGMPv2/v3 query, based on max_delay set in the header a
> timer is started to send out a response after a random time within
> max_delay. If the system then moves into suspend state, Report is
> delayed until system wakes up.
>
> In one reported scenario, on arm64 devices, max_delay was set to 10s,
> Reports were consistantly delayed if the timer is scheduled after 5 plus
> seconds.
>
> Hold wakelock while starting the timer to prevent moving into suspend
> state.
I suppose this looks fine, but are not you going to be playing
whack-a-mole through the network stack wherever there are similar
patterns? Is not a better solution to move this to
in_dev_get()/in_dev_put() where you could create a proper wakelock per
network device? For instance, I could imagine ARP suffering from the
same short comings...
There is one thing that needs fixing though, see below.
>
> Signed-off-by: Tejaswi Tanikella <tejaswit@codeaurora.org>
> ---
> include/linux/igmp.h | 1 +b
> net/ipv4/igmp.c | 20 ++++++++++++++++++--
> 2 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/igmp.h b/include/linux/igmp.h
> index f823185..9be1c58 100644
> --- a/include/linux/igmp.h
> +++ b/include/linux/igmp.h
> @@ -84,6 +84,7 @@ struct ip_mc_list {
> };
> struct ip_mc_list __rcu *next_hash;
> struct timer_list timer;
> + struct wakeup_source *wakeup_src;
Since you are using this only when CONFIG_IP_MULTICAST is defined, you
might was well save a few bytes by making this enclosed within an ifdef
CONFIG_IP_MULTICAST here as well?
[snip]
> @@ -1415,6 +1429,8 @@ void ip_mc_inc_group(struct in_device *in_dev, __be32 addr)
> #ifdef CONFIG_IP_MULTICAST
> timer_setup(&im->timer, igmp_timer_expire, 0);
> im->unsolicit_count = net->ipv4.sysctl_igmp_qrv;
> + im->wakeup_src = wakeup_source_create("igmp_wakeup_source");
Missing error checking, wakeup_source_create() can return NULL here.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next] rtnetlink: Fix null-ptr-deref in rtnl_newlink
From: David Miller @ 2018-06-01 14:39 UTC (permalink / raw)
To: bhole_prashant_q7; +Cc: edumazet, daniel, ast, ktkhai, fw, netdev
In-Reply-To: <20180601081658.6968-1-bhole_prashant_q7@lab.ntt.co.jp>
From: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
Date: Fri, 1 Jun 2018 17:16:58 +0900
> In rtnl_newlink(), NULL check is performed on m_ops however member of
> ops is accessed. Fixed by accessing member of m_ops instead of ops.
>
> [ 345.432629] BUG: KASAN: null-ptr-deref in rtnl_newlink+0x400/0x1110
> [ 345.432629] Read of size 4 at addr 0000000000000088 by task ip/986
> [ 345.432629]
> [ 345.432629] CPU: 1 PID: 986 Comm: ip Not tainted 4.17.0-rc6+ #9
> [ 345.432629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
> [ 345.432629] Call Trace:
> [ 345.432629] dump_stack+0xc6/0x150
> [ 345.432629] ? dump_stack_print_info.cold.0+0x1b/0x1b
> [ 345.432629] ? kasan_report+0xb4/0x410
> [ 345.432629] kasan_report.cold.4+0x8f/0x91
> [ 345.432629] ? rtnl_newlink+0x400/0x1110
> [ 345.432629] rtnl_newlink+0x400/0x1110
> [...]
>
> Fixes: ccf8dbcd062a ("rtnetlink: Remove VLA usage")
> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] kcm: Fix use-after-free caused by clonned sockets
From: David Miller @ 2018-06-01 14:28 UTC (permalink / raw)
To: ktkhai; +Cc: ebiggers, linux-kernel, netdev, syzkaller-bugs, tom, viro,
edumazet
In-Reply-To: <c1d76abc-5d6f-bd0a-9c84-1c5ed8119e8f@virtuozzo.com>
From: Kirill Tkhai <ktkhai@virtuozzo.com>
Date: Fri, 1 Jun 2018 14:30:38 +0300
> (resend for properly queueing in patchwork)
>
> kcm_clone() creates kernel socket, which does not take net counter.
> Thus, the net may die before the socket is completely destructed,
> i.e. kcm_exit_net() is executed before kcm_done().
>
> Reported-by: syzbot+5f1a04e374a635efc426@syzkaller.appspotmail.com
> Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] qtnfmac: fix NULL pointer dereference
From: Gustavo A. R. Silva @ 2018-06-01 14:22 UTC (permalink / raw)
To: Igor Mitsyanko, Avinash Patil, Sergey Matyukevich, Kalle Valo,
David S. Miller, linux-wireless, netdev, linux-kernel,
kernel-janitors
In-Reply-To: <20180601140848.czb4ws5nixuk4tjb@bars>
Hi Sergey,
On 06/01/2018 09:08 AM, Sergey Matyukevich wrote:
> Hello Gustavo,
>
>> diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
>> index 220e2b7..ae0ca80 100644
>> --- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
>> +++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
>> @@ -654,8 +654,7 @@ qtnf_disconnect(struct wiphy *wiphy, struct net_device *dev,
>> vif = qtnf_mac_get_base_vif(mac);
>> if (!vif) {
>> pr_err("MAC%u: primary VIF is not configured\n", mac->macid);
>> - ret = -EFAULT;
>> - goto out;
>> + return -EFAULT;
>> }
>>
>> if (vif->wdev.iftype != NL80211_IFTYPE_STATION) {
>
> That was my fault. Thanks for the fix!
>
Glad to help. :)
> Reviewed-by: Sergey Matyukevich <sergey.matyukevich.os@quanenna.com>
>
Thanks
^ permalink raw reply
* Re: [PATCH bpf-next v4 3/5] selftests/bpf: test_sockmap, timing improvements
From: John Fastabend @ 2018-06-01 14:11 UTC (permalink / raw)
To: Prashant Bhole, Alexei Starovoitov, Daniel Borkmann
Cc: David S . Miller, Shuah Khan, netdev, linux-kselftest
In-Reply-To: <20180531044240.796-4-bhole_prashant_q7@lab.ntt.co.jp>
On 05/30/2018 09:42 PM, Prashant Bhole wrote:
> Currently 10us delay is too low for many tests to succeed. It needs to
> be increased. Also, many corked tests are expected to hit rx timeout
> irrespective of timeout value.
>
> - This patch sets 1000usec timeout value for corked tests because less
> than that causes broken-pipe error in tx thread. Also sets 1 second
> timeout for all other tests because less than that results in RX
> timeout
> - tests with apply=1 and higher number of iterations were taking lot
> of time. This patch reduces test run time by reducing iterations.
>
> real 0m12.968s
> user 0m0.219s
> sys 0m14.337s
>
> Fixes: a18fda1a62c3 ("bpf: reduce runtime of test_sockmap tests")
> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
> ---
OK seems more reasonable to me. We could probably even go lower
on some of the 'rate' values here if needed (512->128).
Acked-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply
* Re: [PATCH] qtnfmac: fix NULL pointer dereference
From: Sergey Matyukevich @ 2018-06-01 14:08 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Igor Mitsyanko, Avinash Patil, Sergey Matyukevich, Kalle Valo,
David S. Miller, linux-wireless, netdev, linux-kernel,
kernel-janitors
In-Reply-To: <20180601132408.GA2572@embeddedor.com>
Hello Gustavo,
> diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
> index 220e2b7..ae0ca80 100644
> --- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
> +++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
> @@ -654,8 +654,7 @@ qtnf_disconnect(struct wiphy *wiphy, struct net_device *dev,
> vif = qtnf_mac_get_base_vif(mac);
> if (!vif) {
> pr_err("MAC%u: primary VIF is not configured\n", mac->macid);
> - ret = -EFAULT;
> - goto out;
> + return -EFAULT;
> }
>
> if (vif->wdev.iftype != NL80211_IFTYPE_STATION) {
That was my fault. Thanks for the fix!
Reviewed-by: Sergey Matyukevich <sergey.matyukevich.os@quanenna.com>
Regards,
Sergey
^ permalink raw reply
* [PATCH net] ipv4: igmp: hold wakelock to prevent delayed reports
From: Tejaswi Tanikella @ 2018-06-01 14:05 UTC (permalink / raw)
To: netdev
On receiving a IGMPv2/v3 query, based on max_delay set in the header a
timer is started to send out a response after a random time within
max_delay. If the system then moves into suspend state, Report is
delayed until system wakes up.
In one reported scenario, on arm64 devices, max_delay was set to 10s,
Reports were consistantly delayed if the timer is scheduled after 5 plus
seconds.
Hold wakelock while starting the timer to prevent moving into suspend
state.
Signed-off-by: Tejaswi Tanikella <tejaswit@codeaurora.org>
---
include/linux/igmp.h | 1 +
net/ipv4/igmp.c | 20 ++++++++++++++++++--
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/include/linux/igmp.h b/include/linux/igmp.h
index f823185..9be1c58 100644
--- a/include/linux/igmp.h
+++ b/include/linux/igmp.h
@@ -84,6 +84,7 @@ struct ip_mc_list {
};
struct ip_mc_list __rcu *next_hash;
struct timer_list timer;
+ struct wakeup_source *wakeup_src;
int users;
refcount_t refcnt;
spinlock_t lock;
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index b26a81a..c695e2c 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -107,6 +107,9 @@
#include <linux/proc_fs.h>
#include <linux/seq_file.h>
#endif
+#ifdef CONFIG_IP_MULTICAST
+#include <linux/pm_wakeup.h>
+#endif
#ifdef CONFIG_IP_MULTICAST
/* Parameter names and values are taken from igmp-v2-06 draft */
@@ -174,7 +177,13 @@ static int ip_mc_add_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
static void ip_ma_put(struct ip_mc_list *im)
{
+#ifdef CONFIG_IP_MULTICAST
+ __pm_relax(im->wakeup_src);
+#endif
if (refcount_dec_and_test(&im->refcnt)) {
+#ifdef CONFIG_IP_MULTICAST
+ wakeup_source_unregister(im->wakeup_src);
+#endif
in_dev_put(im->interface);
kfree_rcu(im, rcu);
}
@@ -199,8 +208,10 @@ static void ip_ma_put(struct ip_mc_list *im)
static void igmp_stop_timer(struct ip_mc_list *im)
{
spin_lock_bh(&im->lock);
- if (del_timer(&im->timer))
+ if (del_timer(&im->timer)) {
+ __pm_relax(im->wakeup_src);
refcount_dec(&im->refcnt);
+ }
im->tm_running = 0;
im->reporter = 0;
im->unsolicit_count = 0;
@@ -213,8 +224,10 @@ static void igmp_start_timer(struct ip_mc_list *im, int max_delay)
int tv = prandom_u32() % max_delay;
im->tm_running = 1;
- if (!mod_timer(&im->timer, jiffies+tv+2))
+ if (!mod_timer(&im->timer, jiffies+tv+2)) {
refcount_inc(&im->refcnt);
+ __pm_stay_awake(im->wakeup_src);
+ }
}
static void igmp_gq_start_timer(struct in_device *in_dev)
@@ -250,6 +263,7 @@ static void igmp_mod_timer(struct ip_mc_list *im, int max_delay)
spin_unlock_bh(&im->lock);
return;
}
+ __pm_relax(im->wakeup_src);
refcount_dec(&im->refcnt);
}
igmp_start_timer(im, max_delay);
@@ -1415,6 +1429,8 @@ void ip_mc_inc_group(struct in_device *in_dev, __be32 addr)
#ifdef CONFIG_IP_MULTICAST
timer_setup(&im->timer, igmp_timer_expire, 0);
im->unsolicit_count = net->ipv4.sysctl_igmp_qrv;
+ im->wakeup_src = wakeup_source_create("igmp_wakeup_source");
+ wakeup_source_add(im->wakeup_src);
#endif
im->next_rcu = in_dev->mc_list;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH bpf-next v4 1/5] selftests/bpf: test_sockmap, check test failure
From: John Fastabend @ 2018-06-01 14:04 UTC (permalink / raw)
To: Prashant Bhole, Alexei Starovoitov, Daniel Borkmann
Cc: David S . Miller, Shuah Khan, netdev, linux-kselftest
In-Reply-To: <20180531044240.796-2-bhole_prashant_q7@lab.ntt.co.jp>
On 05/30/2018 09:42 PM, Prashant Bhole wrote:
> Test failures are not identified because exit code of RX/TX threads
> is not checked. Also threads are not returning correct exit code.
>
> - Return exit code from threads depending on test execution status
> - In main thread, check the exit code of RX/TX threads
> - Skip error checking for corked tests as they are expected to timeout
>
> Fixes: 16962b2404ac ("bpf: sockmap, add selftests")
> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
> ---
Acked-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply
* Re: [PATCH bpf v3 3/5] selftests/bpf: test_sockmap, fix test timeout
From: John Fastabend @ 2018-06-01 14:03 UTC (permalink / raw)
To: Prashant Bhole, Alexei Starovoitov
Cc: Alexei Starovoitov, Daniel Borkmann, David S . Miller, Shuah Khan,
netdev, linux-kselftest
In-Reply-To: <634dc36e-f299-631d-f501-d12453fa0b98@lab.ntt.co.jp>
On 05/30/2018 09:13 PM, Prashant Bhole wrote:
>
>
> On 5/31/2018 4:59 AM, John Fastabend wrote:
>> On 05/30/2018 12:29 PM, Alexei Starovoitov wrote:
>>> On Wed, May 30, 2018 at 02:56:09PM +0900, Prashant Bhole wrote:
>>>> In order to reduce runtime of tests, recently timout for select() call
>>>> was reduced from 1sec to 10usec. This was causing many tests failures.
>>>> It was caught with failure handling commits in this series.
>>>>
>>>> Restoring the timeout from 10usec to 1sec
>>>>
>>>> Fixes: a18fda1a62c3 ("bpf: reduce runtime of test_sockmap tests")
>>>> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
>>>> ---
>>>> tools/testing/selftests/bpf/test_sockmap.c | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/tools/testing/selftests/bpf/test_sockmap.c
>>>> b/tools/testing/selftests/bpf/test_sockmap.c
>>>> index 64f9e25c451f..9d01f5c2abe2 100644
>>>> --- a/tools/testing/selftests/bpf/test_sockmap.c
>>>> +++ b/tools/testing/selftests/bpf/test_sockmap.c
>>>> @@ -345,8 +345,8 @@ static int msg_loop(int fd, int iov_count, int
>>>> iov_length, int cnt,
>>>> if (err < 0)
>>>> perror("recv start time: ");
>>>> while (s->bytes_recvd < total_bytes) {
>>>> - timeout.tv_sec = 0;
>>>> - timeout.tv_usec = 10;
>>>> + timeout.tv_sec = 1;
>>>> + timeout.tv_usec = 0;
>>>
>>> I've applied the set, but had to revert it, since it takes too long.
>>>
>>> real 1m40.124s
>>> user 0m0.375s
>>> sys 0m14.521s
>>>
>>
>> Dang, I thought it would be a bit longer but not minutes.
>>
>>> Myself and Daniel run the test semi-manually when we apply patches.>
>>> Adding 2 extra minutes of wait time is unnecessary.
>>
>> Yep.
>>
>>> Especially since most of it is idle time.
>>> Please find a way to fix tests differently.
>>> btw I don't see any failures today. Not sure what is being fixed
>>> by incresing a timeout.
>>>
>>
>> Calling these fixes is a bit much, they are primarily improvements.
>>
>> The background is, when I originally wrote the tests my goal was to
>> exercise the kernel code paths. Because of this I didn't really care if
>> the tests actually sent/recv all bytes in the test. (I have long
>> running tests using netperf/wrk/apached/etc. for that) But, the manual
>> tests do have an option to verify the data if specified. The 'verify'
>> option is a bit fragile in that with the right tests (e.g. drop)
>> or the certain options (e.g. cork) it can fail which is expected.
>>
>> What Prashant added was support to actually verify the data correctly.
>> And also fix a few cgroup handling and some pretty printing as well.
>> He noticed the low timeout causing issue in these cases though so
>> increased it.
>>
>> @Prashant, how about increasing this less dramatically because now
>> all cork tests are going to stall for 1s unless perfectly aligned.
>> How about 100us? Or even better we can conditionally set it based
>> on if tx_cork is set. If tx_cork is set use 1us otherwise use 200us
>> or something. (1s is really to high in any cases for lo)
>>
>> Also capturing some of the above in the cover letter would help
>> folks understand the context a bit better.
>>
>
> I did trial and error for timeout values. Currently 1000us for corked
> tests and 1 sec for other tests works fine. I observed broken-pipe error
> at tx side when timeout was < 1000us.
>
> Also tests with apply=1 and higher number of iterations were taking
> time, so reducing iterations reduces the test run time drastically.
>
Yep, sending 1B at a time is slow.
> real 0m12.968s
> user 0m0.219s
> sys 0m14.337s
>
> Also I will try to explain background in the cover letter of next series.
>
Seems more reasonable to me now. Thanks.
> -Prashant
>
>
^ permalink raw reply
* [PATCH] qtnfmac: fix NULL pointer dereference
From: Gustavo A. R. Silva @ 2018-06-01 13:24 UTC (permalink / raw)
To: Igor Mitsyanko, Avinash Patil, Sergey Matyukevich, Kalle Valo,
David S. Miller
Cc: linux-wireless, netdev, linux-kernel, Gustavo A. R. Silva,
kernel-janitors
In case *vif* is NULL at 655: if (!vif), the execution path jumps to
label out, where *vif* is dereferenced at 679:
if (vif->sta_state == QTNF_STA_CONNECTING)
Fix this by immediately returning when *vif* is NULL instead of
jumping to label out.
Addresses-Coverity-ID: 1469567 ("Dereference after null check")
Fixes: 480daa9cb62c ("qtnfmac: fix invalid STA state on EAPOL failure")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
index 220e2b7..ae0ca80 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
@@ -654,8 +654,7 @@ qtnf_disconnect(struct wiphy *wiphy, struct net_device *dev,
vif = qtnf_mac_get_base_vif(mac);
if (!vif) {
pr_err("MAC%u: primary VIF is not configured\n", mac->macid);
- ret = -EFAULT;
- goto out;
+ return -EFAULT;
}
if (vif->wdev.iftype != NL80211_IFTYPE_STATION) {
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next] rtnetlink: Fix null-ptr-deref in rtnl_newlink
From: Ido Schimmel @ 2018-06-01 13:03 UTC (permalink / raw)
To: Prashant Bhole
Cc: David S . Miller, Eric Dumazet, Daniel Borkmann,
Alexei Starovoitov, Kirill Tkhai, Florian Westphal, netdev
In-Reply-To: <20180601081658.6968-1-bhole_prashant_q7@lab.ntt.co.jp>
On Fri, Jun 01, 2018 at 05:16:58PM +0900, Prashant Bhole wrote:
> In rtnl_newlink(), NULL check is performed on m_ops however member of
> ops is accessed. Fixed by accessing member of m_ops instead of ops.
>
> [ 345.432629] BUG: KASAN: null-ptr-deref in rtnl_newlink+0x400/0x1110
> [ 345.432629] Read of size 4 at addr 0000000000000088 by task ip/986
> [ 345.432629]
> [ 345.432629] CPU: 1 PID: 986 Comm: ip Not tainted 4.17.0-rc6+ #9
> [ 345.432629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
> [ 345.432629] Call Trace:
> [ 345.432629] dump_stack+0xc6/0x150
> [ 345.432629] ? dump_stack_print_info.cold.0+0x1b/0x1b
> [ 345.432629] ? kasan_report+0xb4/0x410
> [ 345.432629] kasan_report.cold.4+0x8f/0x91
> [ 345.432629] ? rtnl_newlink+0x400/0x1110
> [ 345.432629] rtnl_newlink+0x400/0x1110
> [...]
>
> Fixes: ccf8dbcd062a ("rtnetlink: Remove VLA usage")
> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
My machine crashed while running regression tests. Thanks for fixing!
Tested-by: Ido Schimmel <idosch@mellanox.com>
^ permalink raw reply
* Re: [PATCH net] ipv6: omit traffic class when calculating flow hash
From: Nicolas Dichtel @ 2018-06-01 12:25 UTC (permalink / raw)
To: Michal Kubecek, David S. Miller
Cc: netdev, linux-kernel, Tom Herbert, David Ahern
In-Reply-To: <20180601112948.93BE7A0C48@unicorn.suse.cz>
Le 01/06/2018 à 12:34, Michal Kubecek a écrit :
> Some of the code paths calculating flow hash for IPv6 use flowlabel member
> of struct flowi6 which, despite its name, encodes both flow label and
> traffic class. If traffic class changes within a TCP connection (as e.g.
> ssh does), ECMP route can switch between path. It's also incosistent with
nit: s/incosistent/inconsistent
> other code paths where ip6_flowlabel() (returning only flow label) is used
> to feed the key.
>
> Use only flow label everywhere, including one place where hash key is set
> using ip6_flowinfo().
>
> Fixes: 51ebd3181572 ("ipv6: add support of equal cost multipath (ECMP)")
> Fixes: f70ea018da06 ("net: Add functions to get skb->hash based on flow structures")
> Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
^ permalink raw reply
* Re: [PATCH net-next v4 00/11] Modify action API for implementing lockless actions
From: Jamal Hadi Salim @ 2018-06-01 12:24 UTC (permalink / raw)
To: Vlad Buslov
Cc: netdev, davem, xiyou.wangcong, jiri, pablo, kadlec, fw, ast,
daniel, edumazet, keescook, marcelo.leitner, kliteyn
In-Reply-To: <vbfmuwgf19e.fsf@reg-r-vrt-018-180.mtr.labs.mlnx>
On 31/05/18 08:38 AM, Vlad Buslov wrote:
> Hi Jamal,
>
> On current net-next I still have action with single reference after last
> step:
> ~$ sudo $TC -s actions ls action skbedit
> total acts 1
>
> action order 0: skbedit mark 1 pipe
> index 1 ref 2 bind 1 installed 47 sec used 47 sec
> Action statistics:
> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> ~$ sudo $TC filter del dev lo parent ffff: protocol ip prio 1 \
>> u32 match ip dst 127.0.0.1/32 flowid 1:1
> ~$ sudo $TC -s actions ls action skbedit
> total acts 1
>
> action order 0: skbedit mark 1 pipe
> index 1 ref 1 bind 0 installed 80 sec used 80 sec
> Action statistics:
> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
>
> Which branch are you testing on?
You are correct - this is how it works now (I was thinking of a
very old version before Cong made some changes a while back).
Just vet this continues to work as above.
cheers,
jamal
^ permalink raw reply
* [PATCH net] kcm: Fix use-after-free caused by clonned sockets
From: Kirill Tkhai @ 2018-06-01 11:30 UTC (permalink / raw)
To: David S. Miller, ebiggers, linux-kernel, netdev, syzkaller-bugs,
tom, viro, Eric Dumazet
In-Reply-To: <9f485659-6d6f-9047-b9ad-b0e4084be88d@virtuozzo.com>
(resend for properly queueing in patchwork)
kcm_clone() creates kernel socket, which does not take net counter.
Thus, the net may die before the socket is completely destructed,
i.e. kcm_exit_net() is executed before kcm_done().
Reported-by: syzbot+5f1a04e374a635efc426@syzkaller.appspotmail.com
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
---
diff --git a/net/kcm/kcmsock.c b/net/kcm/kcmsock.c
index d67734c99027..84b7d5c6fec8 100644
--- a/net/kcm/kcmsock.c
+++ b/net/kcm/kcmsock.c
@@ -1671,7 +1671,7 @@ static struct file *kcm_clone(struct socket *osock)
__module_get(newsock->ops->owner);
newsk = sk_alloc(sock_net(osock->sk), PF_KCM, GFP_KERNEL,
- &kcm_proto, true);
+ &kcm_proto, false);
if (!newsk) {
sock_release(newsock);
return ERR_PTR(-ENOMEM);
^ permalink raw reply related
* [PATCH v2] ath10k: fix incorrect size of dma_free_coherent in ath10k_ce_alloc_src_ring_64
From: YueHaibing @ 2018-06-01 11:25 UTC (permalink / raw)
To: davem, kvalo; +Cc: netdev, linux-kernel, ath10k, linux-wireless, YueHaibing
sizeof(struct ce_desc) should be a copy-paste mistake
just use sizeof(struct ce_desc_64) to avoid mem leak
Fixes: b7ba83f7c414 ("ath10k: add support for shadow register for WNC3990")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/ath/ath10k/ce.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/ce.c b/drivers/net/wireless/ath/ath10k/ce.c
index 3b96a43..35dec2a 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -1512,7 +1512,7 @@ ath10k_ce_alloc_src_ring_64(struct ath10k *ar, unsigned int ce_id,
ret = ath10k_ce_alloc_shadow_base(ar, src_ring, nentries);
if (ret) {
dma_free_coherent(ar->dev,
- (nentries * sizeof(struct ce_desc) +
+ (nentries * sizeof(struct ce_desc_64) +
CE_DESC_RING_ALIGN),
src_ring->base_addr_owner_space_unaligned,
base_addr);
--
2.7.0
^ permalink raw reply related
* Re: [PATCH] ath10k: fix incorrect size of dma_free_coherent in ath10k_ce_alloc_src_ring_64
From: YueHaibing @ 2018-06-01 11:23 UTC (permalink / raw)
To: davem, kvalo; +Cc: netdev, linux-kernel, ath10k, linux-wireless
In-Reply-To: <20180601111602.24108-1-yuehaibing@huawei.com>
On 2018/6/1 19:16, YueHaibing wrote:
> sizeof(struct ce_desc) should be a copy-paste mistake
> just use sizeof(struct ce_desc_64) to avoid mem leak
>
> Fixes: b7ba83f7c414 ("ath10k: add support for shadow register for WNC3990")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/wireless/ath/ath10k/ce.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/ce.c b/drivers/net/wireless/ath/ath10k/ce.c
> index 3b96a43..35dec2a 100644
> --- a/drivers/net/wireless/ath/ath10k/ce.c
> +++ b/drivers/net/wireless/ath/ath10k/ce.c
> @@ -1512,7 +1512,7 @@ ath10k_ce_alloc_src_ring_64(struct ath10k *ar, unsigned int ce_id,
> ret = ath10k_ce_alloc_shadow_base(ar, src_ring, nentries);
> if (ret) {
> dma_free_coherent(ar->dev,
> - (nentries * sizeof(struct ce_desc) +
> + (nentries * sizeof(struct ce_desc64) +
sorry ,I post the wrong patch,will send V2
> CE_DESC_RING_ALIGN),
> src_ring->base_addr_owner_space_unaligned,
> base_addr);
>
^ permalink raw reply
* [PATCH] ath10k: fix incorrect size of dma_free_coherent in ath10k_ce_alloc_src_ring_64
From: YueHaibing @ 2018-06-01 11:16 UTC (permalink / raw)
To: davem, kvalo; +Cc: netdev, linux-kernel, ath10k, linux-wireless, YueHaibing
sizeof(struct ce_desc) should be a copy-paste mistake
just use sizeof(struct ce_desc_64) to avoid mem leak
Fixes: b7ba83f7c414 ("ath10k: add support for shadow register for WNC3990")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/ath/ath10k/ce.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/ce.c b/drivers/net/wireless/ath/ath10k/ce.c
index 3b96a43..35dec2a 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -1512,7 +1512,7 @@ ath10k_ce_alloc_src_ring_64(struct ath10k *ar, unsigned int ce_id,
ret = ath10k_ce_alloc_shadow_base(ar, src_ring, nentries);
if (ret) {
dma_free_coherent(ar->dev,
- (nentries * sizeof(struct ce_desc) +
+ (nentries * sizeof(struct ce_desc64) +
CE_DESC_RING_ALIGN),
src_ring->base_addr_owner_space_unaligned,
base_addr);
--
2.7.0
^ permalink raw reply related
* Re: [PATCH bpf 1/2] bpf: fix alignment of netns_dev/netns_ino fields in bpf_{map,prog}_info
From: Dmitry V. Levin @ 2018-06-01 11:12 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Linus Torvalds, Eugene Syromiatnikov, netdev, linux-kernel,
Martin KaFai Lau, Daniel Borkmann, Alexei Starovoitov,
David S. Miller, Jiri Olsa, Ingo Molnar, Lawrence Brakmo,
Andrey Ignatov, Jakub Kicinski, John Fastabend
In-Reply-To: <20180601084114.xgvtg7nmihdavnnd@ast-mbp>
[-- Attachment #1: Type: text/plain, Size: 5859 bytes --]
On Fri, Jun 01, 2018 at 04:41:16AM -0400, Alexei Starovoitov wrote:
> On Fri, Jun 01, 2018 at 06:12:10AM +0300, Dmitry V. Levin wrote:
> > Hi,
> >
> > Looks like the ABI bug in bpf_map_info and bpf_prog info introduced
> > in 4.16 is going to slip into 4.17, causing extra pain to 32-bit
> > userspace. I'm adding Linus to this thread in hope it might help
> > to get a fix applied before 4.17 is released.
>
> The issue identified in patch 1 is valid.
> These two fields won't be properly accessible by 32-bit user space
> on 64-bit kernel.
Yes, and currently there is no way to build a 32-bit userspace that would
work properly both with 32-bit and 64-bit kernels.
> But the fix in patch 1 is wrong.
Please elaborate.
> The patch 2 is completely unnecessary.
The patch 2 doesn't have to be backported to 4.16, but if it was
implemented in 4.16, there would be no bug to discuss. That is,
the patch 2 is a good policy that would help to avoid this class of bugs
in the future.
Alexei, looks like your Acked-by on the buggy commit
52775b33bb5072fbc07b02c0cf4fe8da1f7ee7cd affects your judgement.
If this is the case, please refer patch 2 to other people who are less biased.
> Everyone can also see that the patches are still marked as 'new' in patchworks
> meaning that we didn't process them.
> At the moment many networking folks are traveling to netconf
> and we only had a chance to discuss this set last night.
> We'll try to send a fix in coming days.
> But regardless whether 4.17 is realesed this sunday or not
> we're not going to rush wrong patch in without proper code review
> and discussion.
> That future patch either will land in 4.17 (if it's dealyed into next sunday)
> or it will be sent to stable.
Note that the fix was submitted to netdev on 2018-05-27.
One week is surely enough to make this bug fixed, isn't it?
> To speed up the situation next time please report the issue that you find
> to public netdev mailing list instead of using proprietary distro emails.
Please explain to me and to the public what do you mean by making this
statement.
I do believe strace developers are free to discuss among themselves
using whatever means of communication they find appropriate.
I do believe the issue was properly reported to netdev, see
https://lkml.kernel.org/r/20180527112835.GA9118@asgard.redhat.com
https://lkml.kernel.org/r/20180527112842.GA18204@asgard.redhat.com
I'd like to use this opportunity to thank Eugene for submitting the fix
the same day the issue was identified as a kernel bug.
Alexei, please do not exclude my email address from this discussion.
Thanks.
> > On Wed, May 30, 2018 at 09:18:58PM +0300, Dmitry V. Levin wrote:
> > > On Sun, May 27, 2018 at 01:28:42PM +0200, Eugene Syromiatnikov wrote:
> > > > Recent introduction of netns_dev/netns_ino to bpf_map_info/bpf_prog info
> > > > has broken compat, as offsets of these fields are different in 32-bit
> > > > and 64-bit ABIs. One fix (other than implementing compat support in
> > > > syscall in order to handle this discrepancy) is to use __aligned_u64
> > > > instead of __u64 for these fields.
> > > >
> > > > Reported-by: Dmitry V. Levin <ldv@altlinux.org>
> > > > Fixes: 52775b33bb507 ("bpf: offload: report device information about
> > > > offloaded maps")
> > > > Fixes: 675fc275a3a2d ("bpf: offload: report device information for
> > > > offloaded programs")
> > > >
> > > > Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
> > >
> > > Reviewed-by: "Dmitry V. Levin" <ldv@altlinux.org>
> > > Cc: <stable@vger.kernel.org> # v4.16+
> > >
> > > Thanks,
> > >
> > > > ---
> > > > include/uapi/linux/bpf.h | 8 ++++----
> > > > tools/include/uapi/linux/bpf.h | 8 ++++----
> > > > 2 files changed, 8 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > > > index c5ec897..903010a 100644
> > > > --- a/include/uapi/linux/bpf.h
> > > > +++ b/include/uapi/linux/bpf.h
> > > > @@ -1017,8 +1017,8 @@ struct bpf_prog_info {
> > > > __aligned_u64 map_ids;
> > > > char name[BPF_OBJ_NAME_LEN];
> > > > __u32 ifindex;
> > > > - __u64 netns_dev;
> > > > - __u64 netns_ino;
> > > > + __aligned_u64 netns_dev;
> > > > + __aligned_u64 netns_ino;
> > > > } __attribute__((aligned(8)));
> > > >
> > > > struct bpf_map_info {
> > > > @@ -1030,8 +1030,8 @@ struct bpf_map_info {
> > > > __u32 map_flags;
> > > > char name[BPF_OBJ_NAME_LEN];
> > > > __u32 ifindex;
> > > > - __u64 netns_dev;
> > > > - __u64 netns_ino;
> > > > + __aligned_u64 netns_dev;
> > > > + __aligned_u64 netns_ino;
> > > > } __attribute__((aligned(8)));
> > > >
> > > > /* User bpf_sock_addr struct to access socket fields and sockaddr struct passed
> > > > diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
> > > > index c5ec897..903010a 100644
> > > > --- a/tools/include/uapi/linux/bpf.h
> > > > +++ b/tools/include/uapi/linux/bpf.h
> > > > @@ -1017,8 +1017,8 @@ struct bpf_prog_info {
> > > > __aligned_u64 map_ids;
> > > > char name[BPF_OBJ_NAME_LEN];
> > > > __u32 ifindex;
> > > > - __u64 netns_dev;
> > > > - __u64 netns_ino;
> > > > + __aligned_u64 netns_dev;
> > > > + __aligned_u64 netns_ino;
> > > > } __attribute__((aligned(8)));
> > > >
> > > > struct bpf_map_info {
> > > > @@ -1030,8 +1030,8 @@ struct bpf_map_info {
> > > > __u32 map_flags;
> > > > char name[BPF_OBJ_NAME_LEN];
> > > > __u32 ifindex;
> > > > - __u64 netns_dev;
> > > > - __u64 netns_ino;
> > > > + __aligned_u64 netns_dev;
> > > > + __aligned_u64 netns_ino;
> > > > } __attribute__((aligned(8)));
> > > >
> > > > /* User bpf_sock_addr struct to access socket fields and sockaddr struct passed
--
ldv
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: WARNING in kcm_exit_net (3)
From: Kirill Tkhai @ 2018-06-01 11:10 UTC (permalink / raw)
To: syzbot, davem, ebiggers, edumazet, linux-kernel, netdev,
syzkaller-bugs, tom, viro
In-Reply-To: <00000000000000dca5056d7c1442@google.com>
On 31.05.2018 11:16, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: d60d61f36b8f Merge branch 'for-linus' of git://git.kernel...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=101bb52f800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=968b0b23c7854c0b
> dashboard link: https://syzkaller.appspot.com/bug?extid=5f1a04e374a635efc426
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=13b9ed2f800000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+5f1a04e374a635efc426@syzkaller.appspotmail.com
>
> IPVS: ftp: loaded support on port[0] = 21
> IPVS: ftp: loaded support on port[0] = 21
> IPVS: ftp: loaded support on port[0] = 21
> IPVS: ftp: loaded support on port[0] = 21
> IPVS: ftp: loaded support on port[0] = 21
> WARNING: CPU: 0 PID: 6 at net/kcm/kcmsock.c:2023 kcm_exit_net+0x392/0x3e0 net/kcm/kcmsock.c:2023
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 4.17.0-rc7+ #75
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Workqueue: netns cleanup_net
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1b9/0x294 lib/dump_stack.c:113
> panic+0x22f/0x4de kernel/panic.c:184
> __warn.cold.8+0x163/0x1b3 kernel/panic.c:536
> report_bug+0x252/0x2d0 lib/bug.c:186
> fixup_bug arch/x86/kernel/traps.c:178 [inline]
> do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
> invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
> RIP: 0010:kcm_exit_net+0x392/0x3e0 net/kcm/kcmsock.c:2023
> RSP: 0018:ffff8801d9a97430 EFLAGS: 00010293
> RAX: ffff8801d9a88180 RBX: 1ffff1003b352e86 RCX: 1ffff1003b351135
> RDX: 0000000000000000 RSI: ffffffff86d56942 RDI: 0000000000000286
> RBP: ffff8801d9a974f8 R08: 1ffff1003b352e67 R09: ffffed003b5c46d2
> R10: 0000000000000003 R11: 0000000000000003 R12: 1ffff1003b352e8a
> R13: ffff8801d9a974d0 R14: ffff8801d96763d0 R15: ffff8801c51d0e00
> ops_exit_list.isra.7+0xb0/0x160 net/core/net_namespace.c:152
> cleanup_net+0x51d/0xb20 net/core/net_namespace.c:523
> process_one_work+0xc1e/0x1b50 kernel/workqueue.c:2145
> worker_thread+0x1cc/0x1440 kernel/workqueue.c:2279
> kthread+0x345/0x410 kernel/kthread.c:240
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
How about this?
[PATCH]kcm: Fix use-after-free caused by clonned sockets
kcm_clone() creates kernel socket, which does not take net counter.
Thus, the net may die before the socket is completely destructed,
i.e. kcm_exit_net() is executed before kcm_done().
Reported-by: syzbot+5f1a04e374a635efc426@syzkaller.appspotmail.com
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
---
diff --git a/net/kcm/kcmsock.c b/net/kcm/kcmsock.c
index d67734c99027..84b7d5c6fec8 100644
--- a/net/kcm/kcmsock.c
+++ b/net/kcm/kcmsock.c
@@ -1671,7 +1671,7 @@ static struct file *kcm_clone(struct socket *osock)
__module_get(newsock->ops->owner);
newsk = sk_alloc(sock_net(osock->sk), PF_KCM, GFP_KERNEL,
- &kcm_proto, true);
+ &kcm_proto, false);
if (!newsk) {
sock_release(newsock);
return ERR_PTR(-ENOMEM);
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox