* Re: kernel 4.18.5 Realtek 8111G network adapter stops responding under high system load
From: Ortwin Glück @ 2018-09-27 15:48 UTC (permalink / raw)
To: Heiner Kallweit, David Arendt, Maciej S. Szmigiero, Gabriel C
Cc: linux-kernel, nic_swsd, netdev
In-Reply-To: <968f03ee-a271-242b-d90a-5c70ea72ce3b@gmail.com>
On 25.09.18 23:03, Heiner Kallweit wrote:
> It seems that all chip versions from 34 (= RTL8168E-VL) with the
> exception of version 39 (= RTL8106E, first sub-version) need
> bit TXCFG_AUTO_FIFO.
>
> And indeed, due to reordering of calls this bit is overwritten.
> Following patch moves setting the bit from the chip-specific
> hw_start function to rtl_set_tx_config_registers().
>
> Whoever is hit by the issue and has the option to build a kernel,
> could you please test whether the patch fixes the issue for you?
Hi,
Looks good so far! No problems for almost 24 hours. This is on a router/firewall that links various
sites via IPSec and other VPNs and has >10 network interfaces, 5 of which are Realtek ones.
Thanks,
Ortwin
# uname -a
Linux lofw 4.18.10+ #72 SMP PREEMPT Wed Sep 26 17:07:07 CEST 2018 x86_64 Intel(R) Core(TM) i5-7500
CPU @ 3.40GHz GenuineIntel GNU/Linux
# uptime
17:42:37 up 22:54, 1 user, load average: 0.48, 0.38, 0.30
# ifconfig wan
wan: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 81.7.230.226 netmask 255.255.255.248 broadcast 81.7.230.231
inet6 fe80::529a:4cff:fe2e:92be prefixlen 64 scopeid 0x20<link>
ether 50:9a:4c:2e:92:be txqueuelen 100 (Ethernet)
RX packets 56342905 bytes 40589502599 (37.8 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 54032328 bytes 44607761646 (41.5 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
# ifconfig lan
lan: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.11.1.1 netmask 255.255.255.0 broadcast 10.11.1.255
inet6 fe80::20a:cdff:fe31:6022 prefixlen 64 scopeid 0x20<link>
ether 00:0a:cd:31:60:22 txqueuelen 100 (Ethernet)
RX packets 54799469 bytes 43111097607 (40.1 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 55158558 bytes 35746992802 (33.2 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
^ permalink raw reply
* Re: [PATCH can-next] can: ucan: remove duplicated include from ucan.c
From: YueHaibing @ 2018-09-27 9:38 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde, David S. Miller,
Martin Elshuber, Jakob Unterwurzacher, Philipp Tomsich
Cc: linux-can, netdev, kernel-janitors
In-Reply-To: <1535505945-143347-1-git-send-email-yuehaibing@huawei.com>
ping.
On 2018/8/29 9:25, YueHaibing wrote:
> Remove duplicated include.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/can/usb/ucan.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/net/can/usb/ucan.c b/drivers/net/can/usb/ucan.c
> index 0678a38..c6f4b41 100644
> --- a/drivers/net/can/usb/ucan.c
> +++ b/drivers/net/can/usb/ucan.c
> @@ -35,10 +35,6 @@
> #include <linux/slab.h>
> #include <linux/usb.h>
>
> -#include <linux/can.h>
> -#include <linux/can/dev.h>
> -#include <linux/can/error.h>
> -
> #define UCAN_DRIVER_NAME "ucan"
> #define UCAN_MAX_RX_URBS 8
> /* the CAN controller needs a while to enable/disable the bus */
>
>
> .
>
^ permalink raw reply
* Re: [PATCH can-next] can: ucan: remove set but not used variable 'udev'
From: YueHaibing @ 2018-09-27 9:38 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde, David S. Miller,
Martin Elshuber, Jakob Unterwurzacher, Philipp Tomsich
Cc: linux-can, netdev, kernel-janitors
In-Reply-To: <1535507214-145191-1-git-send-email-yuehaibing@huawei.com>
ping.
On 2018/8/29 9:46, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/can/usb/ucan.c: In function 'ucan_disconnect':
> drivers/net/can/usb/ucan.c:1578:21: warning:
> variable 'udev' set but not used [-Wunused-but-set-variable]
> struct usb_device *udev;
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/can/usb/ucan.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/net/can/usb/ucan.c b/drivers/net/can/usb/ucan.c
> index 0678a38..c9fd83e 100644
> --- a/drivers/net/can/usb/ucan.c
> +++ b/drivers/net/can/usb/ucan.c
> @@ -1575,11 +1575,8 @@ static int ucan_probe(struct usb_interface *intf,
> /* disconnect the device */
> static void ucan_disconnect(struct usb_interface *intf)
> {
> - struct usb_device *udev;
> struct ucan_priv *up = usb_get_intfdata(intf);
>
> - udev = interface_to_usbdev(intf);
> -
> usb_set_intfdata(intf, NULL);
>
> if (up) {
>
>
> .
>
^ permalink raw reply
* CAN YOU HELP ME FIND A HOME I CAN BUY??
From: MRS.MUBARAK SUZANNE @ 2018-09-27 9:40 UTC (permalink / raw)
I am Mrs.Suzanne Mubarak.Please can you help me look for house I can
buy?I will send you money to pay if you can help me get the house.My
price range is between $500,000 to $4,500,000.Pls reply to my
alternative email: mubaraksuzanne1914@gmail.com
^ permalink raw reply
* CAN YOU HELP ME FIND A HOME I CAN BUY??
From: MRS.MUBARAK SUZANNE @ 2018-09-27 9:40 UTC (permalink / raw)
I am Mrs.Suzanne Mubarak.Please can you help me look for house I can
buy?I will send you money to pay if you can help me get the house.My
price range is between $500,000 to $4,500,000.Pls reply to my
alternative email: mubaraksuzanne1914@gmail.com
^ permalink raw reply
* Re: [PATCH net] vhost-vsock: fix use after free
From: Sergei Shtylyov @ 2018-09-27 9:52 UTC (permalink / raw)
To: Jason Wang, stefanha, mst; +Cc: kvm, virtualization, netdev, linux-kernel
In-Reply-To: <20180927084301.573-1-jasowang@redhat.com>
Hello!
On 9/27/2018 11:43 AM, Jason Wang wrote:
Just a couple of typos...
> The access of vsock is not protected by vhost_vsock_lock. This may
> lead use after free since vhost_vsock_dev_release() may free the
Lead to use.
> pointer at the same time.
>
> Fix this by holding the lock during the acess.
Access.
> Reported-by: syzbot+e3e074963495f92a89ed@syzkaller.appspotmail.com
> Fixes: 16320f363ae1 ("vhost-vsock: add pkt cancel capability")
> Fixes: 433fc58e6bf2 ("VSOCK: Introduce vhost_vsock.ko")
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH] b43: fix spelling mistake "hw_registred" -> "hw_registered"
From: Colin King @ 2018-09-27 16:11 UTC (permalink / raw)
To: Kalle Valo, David S . Miller, Philippe Ombredanne, linux-wireless,
b43-dev, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake struct field name, rename it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/broadcom/b43/b43.h | 2 +-
drivers/net/wireless/broadcom/b43/main.c | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/broadcom/b43/b43.h b/drivers/net/wireless/broadcom/b43/b43.h
index b77d1a904f7e..9fc7c088a539 100644
--- a/drivers/net/wireless/broadcom/b43/b43.h
+++ b/drivers/net/wireless/broadcom/b43/b43.h
@@ -909,7 +909,7 @@ struct b43_wl {
/* Set this if we call ieee80211_register_hw() and check if we call
* ieee80211_unregister_hw(). */
- bool hw_registred;
+ bool hw_registered;
/* We can only have one operating interface (802.11 core)
* at a time. General information about this interface follows.
diff --git a/drivers/net/wireless/broadcom/b43/main.c b/drivers/net/wireless/broadcom/b43/main.c
index b37e7391f55d..4daa1ce8cba3 100644
--- a/drivers/net/wireless/broadcom/b43/main.c
+++ b/drivers/net/wireless/broadcom/b43/main.c
@@ -2611,7 +2611,7 @@ static void b43_request_firmware(struct work_struct *work)
err = ieee80211_register_hw(wl->hw);
if (err)
goto err_one_core_detach;
- wl->hw_registred = true;
+ wl->hw_registered = true;
b43_leds_register(wl->current_dev);
/* Register HW RNG driver */
@@ -5610,7 +5610,7 @@ static struct b43_wl *b43_wireless_init(struct b43_bus_dev *dev)
wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_CQM_RSSI_LIST);
- wl->hw_registred = false;
+ wl->hw_registered = false;
hw->max_rates = 2;
SET_IEEE80211_DEV(hw, dev->dev);
if (is_valid_ether_addr(sprom->et1mac))
@@ -5693,7 +5693,7 @@ static void b43_bcma_remove(struct bcma_device *core)
B43_WARN_ON(!wl);
if (!wldev->fw.ucode.data)
return; /* NULL if firmware never loaded */
- if (wl->current_dev == wldev && wl->hw_registred) {
+ if (wl->current_dev == wldev && wl->hw_registered) {
b43_leds_stop(wldev);
ieee80211_unregister_hw(wl->hw);
}
@@ -5776,7 +5776,7 @@ static void b43_ssb_remove(struct ssb_device *sdev)
B43_WARN_ON(!wl);
if (!wldev->fw.ucode.data)
return; /* NULL if firmware never loaded */
- if (wl->current_dev == wldev && wl->hw_registred) {
+ if (wl->current_dev == wldev && wl->hw_registered) {
b43_leds_stop(wldev);
ieee80211_unregister_hw(wl->hw);
}
--
2.17.1
^ permalink raw reply related
* Re: [RFC] net;sched: Try to find idle cpu for RPS to handle packets
From: Willem de Bruijn @ 2018-09-27 16:17 UTC (permalink / raw)
To: ktkhai
Cc: Eric Dumazet, peterz, David Miller, Daniel Borkmann, Tom Herbert,
Network Development, LKML
In-Reply-To: <84d38f11-2133-9d34-e468-d2ef16715f49@virtuozzo.com>
On Wed, Sep 19, 2018 at 12:02 PM Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
>
> On 19.09.2018 18:49, Eric Dumazet wrote:
> > On Wed, Sep 19, 2018 at 8:41 AM Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
> >>
> >> On 19.09.2018 17:55, Eric Dumazet wrote:
> >>> On Wed, Sep 19, 2018 at 5:29 AM Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
> >>>>
> >>>> Many workloads have polling mode of work. The application
> >>>> checks for incomming packets from time to time, but it also
> >>>> has a work to do, when there is no packets. This RFC
> >>>> tries to develop an idea to queue RPS packets on idle
> >>>> CPU in the the L3 domain of the consumer, so backlog
> >>>> processing of the packets and the application can execute
> >>>> in parallel.
> >>>>
> >>>> We require this in case of network cards does not
> >>>> have enough RX queues to cover all online CPUs (this seems
> >>>> to be the most cards), and get_rps_cpu() actually chooses
> >>>> remote cpu, and SMP interrupt is sent. Here we may try
> >>>> our best, and to find idle CPU nearly the consumer's CPU.
> >>>> Note, that in case of consumer works in poll mode and it
> >>>> does not waits for incomming packets, its CPU will be not
> >>>> idle, while CPU of a sleeping consumer may be idle. So,
> >>>> not polling consumers will still be able to have skb
> >>>> handled on its CPU.
> >>>>
> >>>> In case of network card has many queues, the device
> >>>> interrupts will come on consumer's CPU, and this patch
> >>>> won't try to find idle cpu for them.
> >>>>
> >>>> I've tried simple netperf test for this:
> >>>> netserver -p 1234
> >>>> netperf -L 127.0.0.1 -p 1234 -l 100
> >>>>
> >>>> Before:
> >>>> 87380 16384 16384 100.00 60323.56
> >>>> 87380 16384 16384 100.00 60388.46
> >>>> 87380 16384 16384 100.00 60217.68
> >>>> 87380 16384 16384 100.00 57995.41
> >>>> 87380 16384 16384 100.00 60659.00
> >>>>
> >>>> After:
> >>>> 87380 16384 16384 100.00 64569.09
> >>>> 87380 16384 16384 100.00 64569.25
> >>>> 87380 16384 16384 100.00 64691.63
> >>>> 87380 16384 16384 100.00 64930.14
> >>>> 87380 16384 16384 100.00 62670.15
> >>>>
> >>>> The difference between best runs is +7%,
> >>>> the worst runs differ +8%.
> >>>>
> >>>> What do you think about following somehow in this way?
> >>>
> >>> Hi Kirill
> >>>
> >>> In my experience, scheduler has a poor view of softirq processing
> >>> happening on various cpus.
> >>> A cpu spending 90% of its cycles processing IRQ might be considered 'idle'
> >>
> >> Yes, in case of there is softirq on top of irq_exit(), the cpu is not
> >> considered as busy. But after MAX_SOFTIRQ_TIME (=2ms), ksoftirqd are
> >> waken up to execute the work in process context, and the processor is
> >> considered as !idle. 2ms is 2 timer ticks in case of HZ=1000. So, we
> >> don't restart softirq in case of it was executed for more then 2ms.
> >>
> >
> > That's the theory, but reality is very different unfortunately.
> >
> > If RFS/RPS is setup properly, we really do not hit MAX_SOFTIRQ_TIME condition
> > unless in some synthetic benchmarks maybe.
> >
> >> The similar way, single net_rx_action() can't be executed longer
> >> than 2ms.
> >>
> >> Having 90% load in softirq (called on top of irq_exit()) should be
> >> very unlikely situation, when there are too many interrupts with small
> >> amount of work, which related softirq calls are doing for each of them.
> >> I think it had be a problem even in plain napi case, since it would
> >> worked not like expected.
> >>
> >> But anyway. You worry, that during handling of next portion of skbs,
> >> we find that previous portion of skbs already woken ksoftirqd, and
> >> we don't see this cpu as idle? Yeah, then we'll try to change cpu,
> >> and this is not what we want. We want to continue use the cpu, where
> >> previous portion was handler. Hm, not so fast I'll answer, but certainly,
> >> this may be handled somehow in more creative way.
> >>
> >>> So please run a real workload (it is _very_ uncommon anyone set up RPS
> >>> on lo interface !)
> >>>
> >>> Like 400 or more concurrent netperf -t TCP_RR on a 10Gbit NIC.
> >>
> >> Yeah, it's just a simulation of a single irq nic. I'll try on something
> >> more real hardware.
> >
> > Also my concern is that you might have results that are tied to a particular
> > version of process scheduling, platform, workload...
> >
> > One month later, a small change in process scheduler,
> > and very different results.
>
> Maybe, but especially that function logic has not changed for a long time.
> 10 years at least. The only change is Peter adds idle core searching
> functionality recently.
>
> > This is why I believe this new feature must be controllable, via a new
> > tunable (like RPS/RFS are controllable per rx queue)
Agreed. For RFS we can have different heuristics, but they
should be configurable.
Please also make clear in your patch that this changes RFS, not
RPS.
For RPS, selection should not silently change to select a CPU
outside the configured rps_cpus set. I don't think that that should
ever be relaxed, even with a new knob, as it makes reasoning
about RPS configuration that much harder.
RFS already ignores rps_cpus, so using a different heuristic there
is easier.
I have thought about experimenting with biasing towards a core affine
with the numa node of the rx softirq cpu. In other words, ignoring
RFS if the request is remote. With the assumption (correct or not)
that wake affinity would pull the thread to the same node, load
permitting. But I have zero data for that.
^ permalink raw reply
* Re: bpf: Massive skbuff_head_cache memory leak?
From: Dmitry Vyukov @ 2018-09-27 10:24 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Alexei Starovoitov, Daniel Borkmann, Network Development,
David S. Miller, Andrew Morton, Michal Hocko, John Johansen
In-Reply-To: <c33e8c78-6112-7c0d-c816-98aab90575cc@I-love.SAKURA.ne.jp>
On Wed, Sep 26, 2018 at 11:09 PM, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> Hello, Alexei and Daniel.
>
> Can you show us how to run testcases you are testing?
>
> On 2018/09/22 22:25, Tetsuo Handa wrote:
>> Hello.
>>
>> syzbot is reporting many lockup problems on bpf.git / bpf-next.git / net.git / net-next.git trees.
>>
>> INFO: rcu detected stall in br_multicast_port_group_expired (2)
>> https://syzkaller.appspot.com/bug?id=15c7ad8cf35a07059e8a697a22527e11d294bc94
>>
>> INFO: rcu detected stall in tun_chr_close
>> https://syzkaller.appspot.com/bug?id=6c50618bde03e5a2eefdd0269cf9739c5ebb8270
>>
>> INFO: rcu detected stall in discover_timer
>> https://syzkaller.appspot.com/bug?id=55da031ddb910e58ab9c6853a5784efd94f03b54
>>
>> INFO: rcu detected stall in ret_from_fork (2)
>> https://syzkaller.appspot.com/bug?id=c83129a6683b44b39f5b8864a1325893c9218363
>>
>> INFO: rcu detected stall in addrconf_rs_timer
>> https://syzkaller.appspot.com/bug?id=21c029af65f81488edbc07a10ed20792444711b6
>>
>> INFO: rcu detected stall in kthread (2)
>> https://syzkaller.appspot.com/bug?id=6accd1ed11c31110fed1982f6ad38cc9676477d2
>>
>> INFO: rcu detected stall in ext4_filemap_fault
>> https://syzkaller.appspot.com/bug?id=817e38d20e9ee53390ac361bf0fd2007eaf188af
>>
>> INFO: rcu detected stall in run_timer_softirq (2)
>> https://syzkaller.appspot.com/bug?id=f5a230a3ff7822f8d39fddf8485931bd06ae47fe
>>
>> INFO: rcu detected stall in bpf_prog_ADDR
>> https://syzkaller.appspot.com/bug?id=fb4911fd0e861171cc55124e209f810a0dd68744
>>
>> INFO: rcu detected stall in __run_timers (2)
>> https://syzkaller.appspot.com/bug?id=65416569ddc8d2feb8f19066aa761f5a47f7451a
>>
>> The cause of lockup seems to be flood of printk() messages from memory allocation
>> failures, and one of out_of_memory() messages indicates that skbuff_head_cache
>> usage is huge enough to suspect in-kernel memory leaks.
>>
>> [ 1554.547011] skbuff_head_cache 1847887KB 1847887KB
>>
>> Unfortunately, we cannot find from logs what syzbot is trying to do
>> because constant printk() messages is flooding away syzkaller messages.
>> Can you try running your testcases with kmemleak enabled?
>>
>
> On 2018/09/27 2:35, Dmitry Vyukov wrote:
>> I also started suspecting Apparmor. We switched to Apparmor on Aug 30:
>> https://groups.google.com/d/msg/syzkaller-bugs/o73lO4KGh0w/j9pcH2tSBAAJ
>> Now the instances that use SELinux and Smack explicitly contain that
>> in the name, but the rest are Apparmor.
>> Aug 30 roughly matches these assorted "task hung" reports. Perhaps
>> some Apparmor hook leaks a reference to skbs?
>
> Maybe. They have CONFIG_DEFAULT_SECURITY="apparmor". But I'm wondering why
> this problem is not occurring on linux-next.git when this problem is occurring
> on bpf.git / bpf-next.git / net.git / net-next.git trees. Is syzbot running
> different testcases depending on which git tree is targeted?
Yes, this is strange. Net/bpf instances run _subset_ of tests. That
is, they are more concentrated on the corresponding subsystems, but
other instances can run all these tests too, just with lower
probability.
Bpf instances are restricted to this set of syscalls:
"enable_syscalls": [
"bpf", "mkdir", "mount$bpf", "unlink", "close",
"perf_event_open", "ioctl$PERF*", "getpid", "gettid",
"socketpair", "sendmsg", "recvmsg", "setsockopt$sock_attach_bpf",
"socket$kcm", "ioctl$sock_kcm*",
"mkdirat$cgroup*", "openat$cgroup*", "write$cgroup*",
"openat$tun", "write$tun", "ioctl$TUN*", "ioctl$SIOCSIFHWADDR"
]
Net instances to this:
"enable_syscalls": [
"accept", "accept4", "bind", "close", "connect", "epoll_create",
"epoll_create1", "epoll_ctl", "epoll_pwait", "epoll_wait",
"getpeername", "getsockname", "getsockopt", "ioctl", "listen",
"mmap", "poll", "ppoll", "pread64", "preadv", "pselect6",
"pwrite64", "pwritev", "read", "readv", "recvfrom", "recvmmsg",
"recvmsg", "select", "sendfile", "sendmmsg", "sendmsg", "sendto",
"setsockopt", "shutdown", "socket", "socketpair", "splice",
"vmsplice", "write", "writev", "tee", "bpf", "getpid",
"getgid", "getuid", "gettid", "unshare", "pipe",
"syz_emit_ethernet", "syz_extract_tcp_res",
"syz_genetlink_get_family_id", "syz_init_net_socket",
"mkdirat$cgroup*", "openat$cgroup*", "write$cgroup*",
"clock_gettime", "bpf"
]
^ permalink raw reply
* Re: bpf: Massive skbuff_head_cache memory leak?
From: Dmitry Vyukov @ 2018-09-27 10:27 UTC (permalink / raw)
To: John Johansen
Cc: Daniel Borkmann, Tetsuo Handa, Alexei Starovoitov,
Network Development, David S. Miller, Andrew Morton, Michal Hocko
In-Reply-To: <af79013b-d496-f29f-5e57-da11658310aa@canonical.com>
On Thu, Sep 27, 2018 at 1:35 AM, John Johansen
<john.johansen@canonical.com> wrote:
> On 09/26/2018 02:22 PM, Daniel Borkmann wrote:
>> On 09/26/2018 11:09 PM, Tetsuo Handa wrote:
>>> Hello, Alexei and Daniel.
>>>
>>> Can you show us how to run testcases you are testing?
>>
>> Sorry for the delay; currently quite backlogged but will definitely take a look
>> at these reports. Regarding your question: majority of test cases are in the
>> kernel tree under selftests, see tools/testing/selftests/bpf/ .
>>
>
> Its unlikely to be apparmor. I went through the reports and saw nothing that
> would indicate apparmor involvement, but the primary reason is what is being tested
> in upstream apparmor atm.
>
> The current upstream code does nothing directly with skbuffs. Its
> possible that the audit code paths (kernel audit does grab skbuffs)
> could, but there are only a couple cases that would be triggered in
> the current fuzzing so this seems to be an unlikely source for such a
> large leak.
Ack. There is no direct evidence against apparmor, I am just trying to
get at least some hooks re the root cause.
>From all the weak indirect evidence, I leaning towards skb allocation
in an infinite loop (or a timer with infinite rate).
>>> On 2018/09/22 22:25, Tetsuo Handa wrote:
>>>> Hello.
>>>>
>>>> syzbot is reporting many lockup problems on bpf.git / bpf-next.git / net.git / net-next.git trees.
>>>>
>>>> INFO: rcu detected stall in br_multicast_port_group_expired (2)
>>>> https://syzkaller.appspot.com/bug?id=15c7ad8cf35a07059e8a697a22527e11d294bc94
>>>>
>>>> INFO: rcu detected stall in tun_chr_close
>>>> https://syzkaller.appspot.com/bug?id=6c50618bde03e5a2eefdd0269cf9739c5ebb8270
>>>>
>>>> INFO: rcu detected stall in discover_timer
>>>> https://syzkaller.appspot.com/bug?id=55da031ddb910e58ab9c6853a5784efd94f03b54
>>>>
>>>> INFO: rcu detected stall in ret_from_fork (2)
>>>> https://syzkaller.appspot.com/bug?id=c83129a6683b44b39f5b8864a1325893c9218363
>>>>
>>>> INFO: rcu detected stall in addrconf_rs_timer
>>>> https://syzkaller.appspot.com/bug?id=21c029af65f81488edbc07a10ed20792444711b6
>>>>
>>>> INFO: rcu detected stall in kthread (2)
>>>> https://syzkaller.appspot.com/bug?id=6accd1ed11c31110fed1982f6ad38cc9676477d2
>>>>
>>>> INFO: rcu detected stall in ext4_filemap_fault
>>>> https://syzkaller.appspot.com/bug?id=817e38d20e9ee53390ac361bf0fd2007eaf188af
>>>>
>>>> INFO: rcu detected stall in run_timer_softirq (2)
>>>> https://syzkaller.appspot.com/bug?id=f5a230a3ff7822f8d39fddf8485931bd06ae47fe
>>>>
>>>> INFO: rcu detected stall in bpf_prog_ADDR
>>>> https://syzkaller.appspot.com/bug?id=fb4911fd0e861171cc55124e209f810a0dd68744
>>>>
>>>> INFO: rcu detected stall in __run_timers (2)
>>>> https://syzkaller.appspot.com/bug?id=65416569ddc8d2feb8f19066aa761f5a47f7451a
>>>>
>>>> The cause of lockup seems to be flood of printk() messages from memory allocation
>>>> failures, and one of out_of_memory() messages indicates that skbuff_head_cache
>>>> usage is huge enough to suspect in-kernel memory leaks.
>>>>
>>>> [ 1554.547011] skbuff_head_cache 1847887KB 1847887KB
>>>>
>>>> Unfortunately, we cannot find from logs what syzbot is trying to do
>>>> because constant printk() messages is flooding away syzkaller messages.
>>>> Can you try running your testcases with kmemleak enabled?
>>>>
>>>
>>> On 2018/09/27 2:35, Dmitry Vyukov wrote:
>>>> I also started suspecting Apparmor. We switched to Apparmor on Aug 30:
>>>> https://groups.google.com/d/msg/syzkaller-bugs/o73lO4KGh0w/j9pcH2tSBAAJ
>>>> Now the instances that use SELinux and Smack explicitly contain that
>>>> in the name, but the rest are Apparmor.
>>>> Aug 30 roughly matches these assorted "task hung" reports. Perhaps
>>>> some Apparmor hook leaks a reference to skbs?
>>>
>>> Maybe. They have CONFIG_DEFAULT_SECURITY="apparmor". But I'm wondering why
>>> this problem is not occurring on linux-next.git when this problem is occurring
>>> on bpf.git / bpf-next.git / net.git / net-next.git trees. Is syzbot running
>>> different testcases depending on which git tree is targeted?
>>>
>>
>
> this is another reason that it is doubtful that its apparmor.
>
^ permalink raw reply
* Re: [PATCH can-next] can: ucan: remove set but not used variable 'udev'
From: Marc Kleine-Budde @ 2018-09-27 10:37 UTC (permalink / raw)
To: YueHaibing, Wolfgang Grandegger, David S. Miller, Martin Elshuber,
Jakob Unterwurzacher, Philipp Tomsich
Cc: linux-can, netdev, kernel-janitors
In-Reply-To: <1535507214-145191-1-git-send-email-yuehaibing@huawei.com>
[-- Attachment #1.1: Type: text/plain, Size: 675 bytes --]
On 08/29/2018 03:46 AM, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/can/usb/ucan.c: In function 'ucan_disconnect':
> drivers/net/can/usb/ucan.c:1578:21: warning:
> variable 'udev' set but not used [-Wunused-but-set-variable]
> struct usb_device *udev;
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied to linux-can.
tnx.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH can-next] can: ucan: remove duplicated include from ucan.c
From: Marc Kleine-Budde @ 2018-09-27 10:39 UTC (permalink / raw)
To: YueHaibing, Wolfgang Grandegger, David S. Miller, Martin Elshuber,
Jakob Unterwurzacher, Philipp Tomsich
Cc: linux-can, netdev, kernel-janitors
In-Reply-To: <1535505945-143347-1-git-send-email-yuehaibing@huawei.com>
[-- Attachment #1.1: Type: text/plain, Size: 446 bytes --]
On 08/29/2018 03:25 AM, YueHaibing wrote:
> Remove duplicated include.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied to linux-can.
Tnx,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 net-next] dt-bindings: can: rcar_can: document r8a77965 support
From: Marc Kleine-Budde @ 2018-09-27 10:46 UTC (permalink / raw)
To: Eugeniu Rosca
Cc: Simon Horman, Kieran Bingham, Sergei Shtylyov,
Wolfgang Grandegger, David S . Miller, Rob Herring, Mark Rutland,
linux-can, netdev, devicetree, Magnus Damm, linux-renesas-soc,
Eugeniu Rosca
In-Reply-To: <20180921194833.GA28500@vmlxhi-102.adit-jv.com>
[-- Attachment #1.1: Type: text/plain, Size: 1287 bytes --]
On 09/21/2018 09:48 PM, Eugeniu Rosca wrote:
> Hi Marc,
>
> On Mon, Aug 27, 2018 at 12:08:48PM +0200, Marc Kleine-Budde wrote:
>> On 08/20/2018 04:49 PM, Eugeniu Rosca wrote:
>>> From: Eugeniu Rosca <rosca.eugeniu@gmail.com>
>>>
>>> Document the support for rcar_can on R8A77965 SoC devices.
>>> Add R8A77965 to the list of SoCs which require the "assigned-clocks" and
>>> "assigned-clock-rates" properties (thanks, Sergei).
>>>
>>> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
>>> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
>>> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
>>
>> Added to linux-can.
>
> I can't find the patch in below repositories:
> - https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git
> - https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git
>
> Could you please let me know what "linux-can" means?
I haven't pushed it yet, it will be in the testing branch of linux-can.git
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net V2] vhost-vsock: fix use after free
From: Michael S. Tsirkin @ 2018-09-27 17:04 UTC (permalink / raw)
To: Jason Wang
Cc: stefanha, kvm, virtualization, netdev, linux-kernel,
sergei.shtylyov
In-Reply-To: <20180927122204.4188-1-jasowang@redhat.com>
On Thu, Sep 27, 2018 at 08:22:04PM +0800, Jason Wang wrote:
> The access of vsock is not protected by vhost_vsock_lock. This may
> lead to use after free since vhost_vsock_dev_release() may free the
> pointer at the same time.
>
> Fix this by holding the lock during the access.
>
> Reported-by: syzbot+e3e074963495f92a89ed@syzkaller.appspotmail.com
> Fixes: 16320f363ae1 ("vhost-vsock: add pkt cancel capability")
> Fixes: 433fc58e6bf2 ("VSOCK: Introduce vhost_vsock.ko")
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Wow is that really the best we can do? A global lock on a data path
operation? Granted use after free is nasty but Stefan said he sees
a way to fix it using a per socket refcount. He's on vacation
until Oct 4 though ...
> ---
> - V2: fix typos
> - The patch is needed for -stable.
> ---
> drivers/vhost/vsock.c | 26 +++++++++++++++++++-------
> 1 file changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
> index 34bc3ab40c6d..7d0b292867fd 100644
> --- a/drivers/vhost/vsock.c
> +++ b/drivers/vhost/vsock.c
> @@ -210,21 +210,27 @@ vhost_transport_send_pkt(struct virtio_vsock_pkt *pkt)
> struct vhost_vsock *vsock;
> int len = pkt->len;
>
> + spin_lock_bh(&vhost_vsock_lock);
> +
> /* Find the vhost_vsock according to guest context id */
> - vsock = vhost_vsock_get(le64_to_cpu(pkt->hdr.dst_cid));
> + vsock = __vhost_vsock_get(le64_to_cpu(pkt->hdr.dst_cid));
> if (!vsock) {
> virtio_transport_free_pkt(pkt);
> + spin_unlock_bh(&vhost_vsock_lock);
> return -ENODEV;
> }
>
> if (pkt->reply)
> atomic_inc(&vsock->queued_replies);
>
> - spin_lock_bh(&vsock->send_pkt_list_lock);
> + spin_lock(&vsock->send_pkt_list_lock);
> list_add_tail(&pkt->list, &vsock->send_pkt_list);
> - spin_unlock_bh(&vsock->send_pkt_list_lock);
> + spin_unlock(&vsock->send_pkt_list_lock);
>
> vhost_work_queue(&vsock->dev, &vsock->send_pkt_work);
> +
> + spin_unlock_bh(&vhost_vsock_lock);
> +
> return len;
> }
>
> @@ -236,18 +242,22 @@ vhost_transport_cancel_pkt(struct vsock_sock *vsk)
> int cnt = 0;
> LIST_HEAD(freeme);
>
> + spin_lock_bh(&vhost_vsock_lock);
> +
> /* Find the vhost_vsock according to guest context id */
> - vsock = vhost_vsock_get(vsk->remote_addr.svm_cid);
> - if (!vsock)
> + vsock = __vhost_vsock_get(vsk->remote_addr.svm_cid);
> + if (!vsock) {
> + spin_unlock_bh(&vhost_vsock_lock);
> return -ENODEV;
> + }
>
> - spin_lock_bh(&vsock->send_pkt_list_lock);
> + spin_lock(&vsock->send_pkt_list_lock);
> list_for_each_entry_safe(pkt, n, &vsock->send_pkt_list, list) {
> if (pkt->vsk != vsk)
> continue;
> list_move(&pkt->list, &freeme);
> }
> - spin_unlock_bh(&vsock->send_pkt_list_lock);
> + spin_unlock(&vsock->send_pkt_list_lock);
>
> list_for_each_entry_safe(pkt, n, &freeme, list) {
> if (pkt->reply)
> @@ -265,6 +275,8 @@ vhost_transport_cancel_pkt(struct vsock_sock *vsk)
> vhost_poll_queue(&tx_vq->poll);
> }
>
> + spin_unlock_bh(&vhost_vsock_lock);
> +
> return 0;
> }
>
> --
> 2.17.1
^ permalink raw reply
* Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations
From: Jason A. Donenfeld @ 2018-09-27 17:06 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Thomas Gleixner, Peter Zijlstra, Ard Biesheuvel, LKML, Netdev,
Linux Crypto Mailing List, David Miller, Greg Kroah-Hartman,
Samuel Neves, Andrew Lutomirski, Jean-Philippe Aumasson,
Russell King - ARM Linux, linux-arm-kernel
In-Reply-To: <BB2CD8D5-E7FF-4D25-8C83-F64960253248@amacapital.net>
On Thu, Sep 27, 2018 at 6:27 PM Andy Lutomirski <luto@amacapital.net> wrote:
> I would add another consideration: if you can get better latency with negligible overhead (0.1%? 0.05%), then that might make sense too. For example, it seems plausible that checking need_resched() every few blocks adds basically no overhead, and the SIMD helpers could do this themselves or perhaps only ever do a block at a time.
>
> need_resched() costs a cacheline access, but it’s usually a hot cacheline, and the actual check is just whether a certain bit in memory is set.
Yes you're right, I do plan to check quite often, rather than seldom,
for this reason. I've been toying with the idea of instead processing
65k (maximum size of a UDP packet) at a time before checking
need_resched(), but armed with the 20µs figure, this isn't remotely
possible on most hardware. So I'll stick with the original
conservative plan of checking very often, and not making things
different from the aspects worked out by the present crypto API in
this regard.
^ permalink raw reply
* [PATCH 1/2] net: dpaa2: move DPAA2 PTP driver out of staging/
From: Yangbo Lu @ 2018-09-27 11:12 UTC (permalink / raw)
To: linux-kernel, devel, netdev, Richard Cochran, David S . Miller,
Ioana Radulescu, Greg Kroah-Hartman
Cc: Yangbo Lu
This patch is to move DPAA2 PTP driver out of staging/
since the dpaa2-eth had been moved out.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
---
drivers/net/ethernet/freescale/Kconfig | 9 +--------
drivers/net/ethernet/freescale/dpaa2/Kconfig | 15 +++++++++++++++
drivers/net/ethernet/freescale/dpaa2/Makefile | 6 ++++--
.../ethernet/freescale/dpaa2}/dprtc-cmd.h | 0
.../rtc => net/ethernet/freescale/dpaa2}/dprtc.c | 0
.../rtc => net/ethernet/freescale/dpaa2}/dprtc.h | 0
.../rtc => net/ethernet/freescale/dpaa2}/rtc.c | 0
.../rtc => net/ethernet/freescale/dpaa2}/rtc.h | 0
drivers/staging/fsl-dpaa2/Kconfig | 8 --------
drivers/staging/fsl-dpaa2/Makefile | 1 -
drivers/staging/fsl-dpaa2/rtc/Makefile | 7 -------
11 files changed, 20 insertions(+), 26 deletions(-)
create mode 100644 drivers/net/ethernet/freescale/dpaa2/Kconfig
rename drivers/{staging/fsl-dpaa2/rtc => net/ethernet/freescale/dpaa2}/dprtc-cmd.h (100%)
rename drivers/{staging/fsl-dpaa2/rtc => net/ethernet/freescale/dpaa2}/dprtc.c (100%)
rename drivers/{staging/fsl-dpaa2/rtc => net/ethernet/freescale/dpaa2}/dprtc.h (100%)
rename drivers/{staging/fsl-dpaa2/rtc => net/ethernet/freescale/dpaa2}/rtc.c (100%)
rename drivers/{staging/fsl-dpaa2/rtc => net/ethernet/freescale/dpaa2}/rtc.h (100%)
delete mode 100644 drivers/staging/fsl-dpaa2/rtc/Makefile
diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
index 7a30276..d3a62bc 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -96,13 +96,6 @@ config GIANFAR
on the 8540.
source "drivers/net/ethernet/freescale/dpaa/Kconfig"
-
-config FSL_DPAA2_ETH
- tristate "Freescale DPAA2 Ethernet"
- depends on FSL_MC_BUS && FSL_MC_DPIO
- depends on NETDEVICES && ETHERNET
- ---help---
- Ethernet driver for Freescale DPAA2 SoCs, using the
- Freescale MC bus driver
+source "drivers/net/ethernet/freescale/dpaa2/Kconfig"
endif # NET_VENDOR_FREESCALE
diff --git a/drivers/net/ethernet/freescale/dpaa2/Kconfig b/drivers/net/ethernet/freescale/dpaa2/Kconfig
new file mode 100644
index 0000000..44c5c3a
--- /dev/null
+++ b/drivers/net/ethernet/freescale/dpaa2/Kconfig
@@ -0,0 +1,15 @@
+config FSL_DPAA2_ETH
+ tristate "Freescale DPAA2 Ethernet"
+ depends on FSL_MC_BUS && FSL_MC_DPIO
+ depends on NETDEVICES && ETHERNET
+ help
+ Ethernet driver for Freescale DPAA2 SoCs, using the
+ Freescale MC bus driver
+
+config FSL_DPAA2_PTP_CLOCK
+ tristate "Freescale DPAA2 PTP Clock"
+ depends on FSL_DPAA2_ETH && POSIX_TIMERS
+ select PTP_1588_CLOCK
+ help
+ This driver adds support for using the DPAA2 1588 timer module
+ as a PTP clock.
diff --git a/drivers/net/ethernet/freescale/dpaa2/Makefile b/drivers/net/ethernet/freescale/dpaa2/Makefile
index 9315ecd..312e37f 100644
--- a/drivers/net/ethernet/freescale/dpaa2/Makefile
+++ b/drivers/net/ethernet/freescale/dpaa2/Makefile
@@ -3,9 +3,11 @@
# Makefile for the Freescale DPAA2 Ethernet controller
#
-obj-$(CONFIG_FSL_DPAA2_ETH) += fsl-dpaa2-eth.o
+obj-$(CONFIG_FSL_DPAA2_ETH) += fsl-dpaa2-eth.o
+obj-$(CONFIG_FSL_DPAA2_PTP_CLOCK) += fsl-dpaa2-rtc.o
-fsl-dpaa2-eth-objs := dpaa2-eth.o dpaa2-ethtool.o dpni.o
+fsl-dpaa2-eth-objs := dpaa2-eth.o dpaa2-ethtool.o dpni.o
+fsl-dpaa2-rtc-objs := rtc.o dprtc.o
# Needed by the tracing framework
CFLAGS_dpaa2-eth.o := -I$(src)
diff --git a/drivers/staging/fsl-dpaa2/rtc/dprtc-cmd.h b/drivers/net/ethernet/freescale/dpaa2/dprtc-cmd.h
similarity index 100%
rename from drivers/staging/fsl-dpaa2/rtc/dprtc-cmd.h
rename to drivers/net/ethernet/freescale/dpaa2/dprtc-cmd.h
diff --git a/drivers/staging/fsl-dpaa2/rtc/dprtc.c b/drivers/net/ethernet/freescale/dpaa2/dprtc.c
similarity index 100%
rename from drivers/staging/fsl-dpaa2/rtc/dprtc.c
rename to drivers/net/ethernet/freescale/dpaa2/dprtc.c
diff --git a/drivers/staging/fsl-dpaa2/rtc/dprtc.h b/drivers/net/ethernet/freescale/dpaa2/dprtc.h
similarity index 100%
rename from drivers/staging/fsl-dpaa2/rtc/dprtc.h
rename to drivers/net/ethernet/freescale/dpaa2/dprtc.h
diff --git a/drivers/staging/fsl-dpaa2/rtc/rtc.c b/drivers/net/ethernet/freescale/dpaa2/rtc.c
similarity index 100%
rename from drivers/staging/fsl-dpaa2/rtc/rtc.c
rename to drivers/net/ethernet/freescale/dpaa2/rtc.c
diff --git a/drivers/staging/fsl-dpaa2/rtc/rtc.h b/drivers/net/ethernet/freescale/dpaa2/rtc.h
similarity index 100%
rename from drivers/staging/fsl-dpaa2/rtc/rtc.h
rename to drivers/net/ethernet/freescale/dpaa2/rtc.h
diff --git a/drivers/staging/fsl-dpaa2/Kconfig b/drivers/staging/fsl-dpaa2/Kconfig
index 59aaae7..991e154 100644
--- a/drivers/staging/fsl-dpaa2/Kconfig
+++ b/drivers/staging/fsl-dpaa2/Kconfig
@@ -16,11 +16,3 @@ config FSL_DPAA2_ETHSW
---help---
Driver for Freescale DPAA2 Ethernet Switch. Select
BRIDGE to have support for bridge tools.
-
-config FSL_DPAA2_PTP_CLOCK
- tristate "Freescale DPAA2 PTP Clock"
- depends on FSL_DPAA2_ETH && POSIX_TIMERS
- select PTP_1588_CLOCK
- help
- This driver adds support for using the DPAA2 1588 timer module
- as a PTP clock.
diff --git a/drivers/staging/fsl-dpaa2/Makefile b/drivers/staging/fsl-dpaa2/Makefile
index 464f242..c92ab98 100644
--- a/drivers/staging/fsl-dpaa2/Makefile
+++ b/drivers/staging/fsl-dpaa2/Makefile
@@ -3,4 +3,3 @@
#
obj-$(CONFIG_FSL_DPAA2_ETHSW) += ethsw/
-obj-$(CONFIG_FSL_DPAA2_PTP_CLOCK) += rtc/
diff --git a/drivers/staging/fsl-dpaa2/rtc/Makefile b/drivers/staging/fsl-dpaa2/rtc/Makefile
deleted file mode 100644
index 5468da0..0000000
--- a/drivers/staging/fsl-dpaa2/rtc/Makefile
+++ /dev/null
@@ -1,7 +0,0 @@
-#
-# Makefile for the Freescale DPAA2 PTP clock
-#
-
-obj-$(CONFIG_FSL_DPAA2_PTP_CLOCK) += dpaa2-rtc.o
-
-dpaa2-rtc-objs := rtc.o dprtc.o
--
1.7.1
^ permalink raw reply related
* [PATCH net 1/1] qed: Fix shmem structure inconsistency between driver and the mfw.
From: Sudarsana Reddy Kalluru @ 2018-09-27 11:12 UTC (permalink / raw)
To: davem; +Cc: netdev, Michal.Kalderon
The structure shared between driver and the management FW (mfw) differ in
sizes. This would lead to issues when driver try to access the structure
members which are not-aligned with the mfw copy e.g., data_ptr usage in the
case of mfw_tlv request.
Align the driver structure with mfw copy, add reserved field(s) to driver
structure for the members not used by the driver.
Fixes: dd006921d ("qed: Add MFW interfaces for TLV request support.)
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Michal Kalderon <Michal.Kalderon@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_hsi.h b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
index 9b3ef00e..a713826 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_hsi.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
@@ -11987,6 +11987,7 @@ struct public_global {
u32 running_bundle_id;
s32 external_temperature;
u32 mdump_reason;
+ u64 reserved;
u32 data_ptr;
u32 data_size;
};
--
1.8.3.1
^ permalink raw reply related
* pull-request: mac80211 2018-09-27
From: Johannes Berg @ 2018-09-27 11:18 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Here's another - unfortunately pretty large - set of fixes
for the current cycle. The changes are pretty simple or even
trivial though.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 28619527b8a712590c93d0a9e24b4425b9376a8c:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-09-04 12:45:11 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2018-09-27
for you to fetch changes up to 1222a16014888ed9733c11e221730d4a8196222b:
nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds (2018-09-27 11:44:44 +0200)
----------------------------------------------------------------
More patches than I'd like perhaps, but each seems reasonable:
* two new spectre-v1 mitigations in nl80211
* TX status fix in general, and mesh in particular
* powersave vs. offchannel fix
* regulatory initialization fix
* fix for a queue hang due to a bad return value
* allocate TXQs for active monitor interfaces, fixing my
earlier patch to avoid unnecessary allocations where I
missed this case needed them
* fix TDLS data frames priority assignment
* fix scan results processing to take into account duplicate
channel numbers (over different operating classes, but we
don't necessarily know the operating class)
* various hwsim fixes for radio destruction and new radio
announcement messages
* remove an extraneous kernel-doc line
----------------------------------------------------------------
Andrei Otcheretianski (3):
mac80211: Always report TX status
mac80211: Don't wake up from PS for offchannel TX
cfg80211: reg: Init wiphy_idx in regulatory_hint_core()
Bob Copeland (1):
mac80211: fix pending queue hang due to TX_DROP
Felix Fietkau (1):
mac80211: allocate TXQs for active monitor interfaces
Johannes Berg (1):
mac80211: TDLS: fix skb queue/priority assignment
Jouni Malinen (1):
cfg80211: Address some corner cases in scan result channel updating
Martin Willi (3):
mac80211_hwsim: fix locking when iterating radios during ns exit
mac80211_hwsim: fix race in radio destruction from netlink notifier
mac80211_hwsim: do not omit multicast announce of first added radio
Masashi Honma (2):
nl80211: Fix possible Spectre-v1 for NL80211_TXRATE_HT
nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds
Randy Dunlap (1):
cfg80211: fix reg_query_regdb_wmm kernel-doc
Yuan-Chi Pang (1):
mac80211: fix TX status reporting for ieee80211s
drivers/net/wireless/mac80211_hwsim.c | 36 ++++++++++------------
include/net/cfg80211.h | 2 --
net/mac80211/iface.c | 3 +-
net/mac80211/mesh.h | 3 +-
net/mac80211/mesh_hwmp.c | 9 ++----
net/mac80211/status.c | 11 +++----
net/mac80211/tdls.c | 8 ++---
net/mac80211/tx.c | 6 +++-
net/wireless/nl80211.c | 20 +++++++++---
net/wireless/reg.c | 1 +
net/wireless/scan.c | 58 +++++++++++++++++++++++++++++------
11 files changed, 103 insertions(+), 54 deletions(-)
^ permalink raw reply
* Re: KMSAN: uninit-value in memcmp (2)
From: Dmitry Vyukov @ 2018-09-27 11:20 UTC (permalink / raw)
To: Vladis Dronov; +Cc: syzbot, syzkaller-bugs, LKML, Networking
In-Reply-To: <1439650590.16502818.1538047050900.JavaMail.zimbra@redhat.com>
On Thu, Sep 27, 2018 at 1:17 PM, Vladis Dronov <vdronov@redhat.com> wrote:
> Hello, Dmirty,
>
> Thank you for the explanation of how syzkaller/syzbot works in this and
> other emails. I understand that is it a complicated task to determine
> and categorize bugs based on just crash dump and messages, and syzkaller
> does a great job of doing so.
Thanks.
>> Re __hw_addr_add_ex bug, as Alex noted the crash was detected _after_
>> the fixing commit went in. So it's something new and different and
>> can't be fixed by the older commit.
>
> Indeed, you're right, there is another issue with tun/tap devices which
> leads to this bug. I've posted a patch (https://lkml.org/lkml/2018/9/26/416)
> to fix it.
>
> I hope I did not do much damage, reporting previous fix as a fix for this bug,
> as syzkaller will probably create another "KMSAN: uninit-value in <...>"
> report.
No, it did not do any damage.
This is in fact already re-reported as "KMSAN: uninit-value in __dev_mc_add":
https://syzkaller.appspot.com/bug?id=0766d38c656abeace60621896d705743aeefed51
> ----- Original Message -----
>> From: "Dmitry Vyukov" <dvyukov@google.com>
>> To: "Alexander Potapenko" <glider@google.com>
>> Cc: "Vladis Dronov" <vdronov@redhat.com>, "syzbot" <syzbot+d3402c47f680ff24b29c@syzkaller.appspotmail.com>,
>> "syzkaller-bugs" <syzkaller-bugs@googlegroups.com>, "David Miller" <davem@davemloft.net>, "Eric Dumazet"
>> <edumazet@google.com>, "LKML" <linux-kernel@vger.kernel.org>, "Networking" <netdev@vger.kernel.org>, "sunlianwen"
>> <sunlw.fnst@cn.fujitsu.com>
>> Sent: Monday, September 24, 2018 11:39:08 AM
>> Subject: Re: KMSAN: uninit-value in memcmp (2)
>>
>> On Mon, Sep 24, 2018 at 8:53 AM, Alexander Potapenko <glider@google.com>
>> wrote:
>> > On Mon, Sep 24, 2018 at 12:09 AM Vladis Dronov <vdronov@redhat.com> wrote:
>> >>
>> >> Hello, Dmirty,
>> >>
>> >> Thank you for the reply. Can we please, discuss this further?
>> > Hi Vladis,
>> >> > You can see on dashboard that the last crash
>> >> > for the second version (2) happened just few days ago. So this is a
>> >> > different bug.
>> > FWIW I've just double-checked that the reproducer provided by
>> > syzkaller in the original message still triggers the report from the
>> > original message in the latest KMSAN tree (which already contains the
>> > __hw_addr_add_ex() fix from April).
>> >> Well... yes and no. When I was looking at this bug (bug?id=088efeac32fd) I
>> >> was looking
>> >> at the report at "2018/05/09 18:55"
>> >> (https://syzkaller.appspot.com/text?tag=CrashReport&x=141b707b800000),
>> >> since it was the only report with a reproducer. This was my error.
>> >>
>> >> The error and the call trace in this report are:
>> >>
>> >> >>>
>> >> BUG: KMSAN: uninit-value in memcmp+0x119/0x180 lib/string.c:861
>> >> CPU: 0 PID: 38 Comm: kworker/0:1 Not tainted 4.17.0-rc3+ #88
>> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> >> Google 01/01/2011
>> >> Workqueue: ipv6_addrconf addrconf_dad_work
>> >> Call Trace:
>> >> __dump_stack lib/dump_stack.c:77 [inline]
>> >> dump_stack+0x185/0x1d0 lib/dump_stack.c:113
>> >> kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
>> >> __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
>> >> memcmp+0x119/0x180 lib/string.c:861
>> >> __hw_addr_add_ex net/core/dev_addr_lists.c:61 [inline]
>> >> __dev_mc_add+0x1fc/0x900 net/core/dev_addr_lists.c:670
>> >> dev_mc_add+0x6d/0x80 net/core/dev_addr_lists.c:687
>> >> igmp6_group_added+0x2db/0xa00 net/ipv6/mcast.c:662
>> >> ipv6_dev_mc_inc+0xe9e/0x1130 net/ipv6/mcast.c:914
>> >> addrconf_join_solict net/ipv6/addrconf.c:2103 [inline]
>> >> addrconf_dad_begin net/ipv6/addrconf.c:3853 [inline]
>> >> addrconf_dad_work+0x462/0x2a20 net/ipv6/addrconf.c:3979
>> >> process_one_work+0x12c6/0x1f60 kernel/workqueue.c:2145
>> >> worker_thread+0x113c/0x24f0 kernel/workqueue.c:2279
>> >> kthread+0x539/0x720 kernel/kthread.c:239
>> >> ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:412
>> >>
>> >> Local variable description: ----buf@igmp6_group_added
>> >> Variable was created at:
>> >> igmp6_group_added+0x4a/0xa00 net/ipv6/mcast.c:650
>> >> ipv6_dev_mc_inc+0xe9e/0x1130 net/ipv6/mcast.c:914
>> >> <<<
>> >>
>> >> It is the same like in bug?id=3887c0d99aecb27d085180c5222d245d08a30806
>> >> which, after some more test, made me believe these bugs are duplicate
>> >> and are fixed by the same commit.
>> >>
>> >> But let's look at another report at "2018/09/12 21:00"
>> >> (https://syzkaller.appspot.com/text?tag=CrashReport&x=14f99b71400000)
>> >> at the bug (bug?id=088efeac32fd), the one you've mentioned as
>> >> "the last crash for the second version (2) happened just few days ago".
>> >>
>> >> Its error and the call trace are completely different:
>> >>
>> >> >>>
>> >> BUG: KMSAN: uninit-value in memcmp+0x11d/0x180 lib/string.c:863
>> >> CPU: 0 PID: 6107 Comm: syz-executor4 Not tainted 4.19.0-rc3+ #45
>> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> >> Google 01/01/2011
>> >> Call Trace:
>> >> __dump_stack lib/dump_stack.c:77 [inline]
>> >> dump_stack+0x14b/0x190 lib/dump_stack.c:113
>> >> kmsan_report+0x183/0x2b0 mm/kmsan/kmsan.c:956
>> >> __msan_warning+0x70/0xc0 mm/kmsan/kmsan_instr.c:645
>> >> memcmp+0x11d/0x180 lib/string.c:863
>> >> dev_uc_add_excl+0x165/0x7b0 net/core/dev_addr_lists.c:464
>> >> ndo_dflt_fdb_add net/core/rtnetlink.c:3463 [inline]
>> >> rtnl_fdb_add+0x1081/0x1270 net/core/rtnetlink.c:3558
>> >> rtnetlink_rcv_msg+0xa0b/0x1530 net/core/rtnetlink.c:4715
>> >> netlink_rcv_skb+0x36e/0x5f0 net/netlink/af_netlink.c:2454
>> >> rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4733
>> >> netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
>> >> netlink_unicast+0x1638/0x1720 net/netlink/af_netlink.c:1343
>> >> netlink_sendmsg+0x1205/0x1290 net/netlink/af_netlink.c:1908
>> >> sock_sendmsg_nosec net/socket.c:621 [inline]
>> >> sock_sendmsg net/socket.c:631 [inline]
>> >> ...
>> >> Uninit was created at:
>> >> ...
>> >> slab_post_alloc_hook mm/slab.h:446 [inline]
>> >> slab_alloc_node mm/slub.c:2718 [inline]
>> >> __kmalloc_node_track_caller+0x9e7/0x1160 mm/slub.c:4351
>> >> __kmalloc_reserve net/core/skbuff.c:138 [inline]
>> >> __alloc_skb+0x2f5/0x9e0 net/core/skbuff.c:206
>> >> alloc_skb include/linux/skbuff.h:996 [inline]
>> >> netlink_alloc_large_skb net/netlink/af_netlink.c:1189 [inline]
>> >> netlink_sendmsg+0xb49/0x1290 net/netlink/af_netlink.c:1883
>> >> sock_sendmsg_nosec net/socket.c:621 [inline]
>> >> sock_sendmsg net/socket.c:631 [inline]
>> >> ___sys_sendmsg+0xe70/0x1290 net/socket.c:2114
>> >> <<<
>> >>
>> >> This is a different bug. How come these 2 different reports for 2
>> >> different
>> >> bugs have ended in the same syzkaller report (bug?id=088efeac32fd) ?
>> >
>> > I suspect this is because syzbot used the top stack frame as the
>> > report signature.
>> > There's a mechanism to ignore frames like memcmp() in the reports, not
>> > sure why didn't it work in this case (maybe it just wasn't in place at
>> > the time the report happened).
>> >> One bug is fixed by the "net: fix uninit-value in __hw_addr_add_ex()"
>> >> commit,
>> >> the second one is not, but they are still in the same syzkaller report.
>> >>
>> >> This was the reason of my confusion. I'm not sure how to fix this. If it
>> >> is possible,
>> >> probably we need to cancel/revoke "#syz fix: net: fix uninit-value in
>> >> __hw_addr_add_ex()"
>> >> for this syzkaller report (bug?id=088efeac32fd). And then "split" it into
>> >> 2 or
>> >> more different reports, but I'm not sure if this is possible.
>> >>
>> >> Probably, syzkaller needs to look deeper into the KMSAN reports to
>> >> differentiate
>> >> KMSAN errors happening because of different reasons.
>> >>
>> >> > On Sun, Sep 23, 2018 at 6:02 PM, Vladis Dronov <vdronov@redhat.com>
>> >> > wrote:
>> >> > > #syz fix: net: fix uninit-value in __hw_addr_add_ex()
>> >> >
>> >> > Hi Vladis,
>> >> >
>> >> > This can be fixed with "net: fix uninit-value in __hw_addr_add_ex()".
>> >> > That commit landed in April, syzbot waited till the commit reached all
>> >> > tested trees, and then closed the bug.
>> >> > But the similar bug continued to happen, so syzbot created second
>> >> > version of this bug (2). You can see on dashboard that the last crash
>> >> > for the second version (2) happened just few days ago. So this is a
>> >> > different bug.
>>
>>
>> Precisely discriminating bugs (root causes) bases on crash text is
>> generally undecidable problem, even for humans. We even can have
>> literally equal crash texts, which are still different bugs. And we
>> can have significantly differently looking crash texts, which are
>> actually caused by the same root cause. syzbot extracts some
>> "identity" string for each crash and than uses that string to
>> discriminate crashes and sort them into bins. This identity string is
>> what you see in email subject and bug title on dashboard. This method
>> can have both false positives and false negatives, but works
>> reasonably well in most cases and looks like the best practical
>> option.
>>
>> For this exact instance (memcmp) we actually improved the analysis
>> logic recently:
>> https://github.com/google/syzkaller/commit/0e29942f77715486995d996f80f82742812d75a2#diff-abe1515f011fad2659ff218f9eea9ae1
>> But this crash was analyzed and reported before the change. So if this
>> crash happens again it should be reported as "in __hw_addr_add_ex"
>> now.
>>
>> Re __hw_addr_add_ex bug, as Alex noted the crash was detected _after_
>> the fixing commit went in. So it's something new and different and
>> can't be fixed by the older commit.
>>
>> There are no general, single guideline as to what to do when several
>> different bugs glued together into a single bug. Fixing at least one
>> of them (any) in the context of the bug is good, fixing both is good
>> too. When/if a bug is closed, new occurrences of similar crashes (the
>> same identity string) will lead to creation of a new bug. So if we fix
>> only one and close the bug, eventually the second one will lead to a
>> new bug (won't be lost), now dedicated to this second crash.
>>
>> Now syzbot thinks that this bug is fixed/closed:
>> https://syzkaller.appspot.com/bug?extid=d3402c47f680ff24b29c
>> There is specifically no "undo" functionality, because it's inherently
>> racy with creation of a new version of this bugs by new crashes. So if
>> of these crashes will happen again, syzbot will open new bugs (now
>> with better discriminated titles). We can wait for that. Or we can
>> submit new fixes without waiting for new syzbot bugs (adding
>> Reported-by to new commits referencing this bug should not do any
>> harm).
>>
>> Hope this clarifies things a bit.
>>
>> Thanks
^ permalink raw reply
* Re: KASAN: use-after-free Read in tcf_block_find
From: Cong Wang @ 2018-09-27 17:50 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Eric Dumazet, syzbot+37b8770e6d5a8220a039, David Miller,
Jamal Hadi Salim, Jiri Pirko, LKML,
Linux Kernel Network Developers, syzkaller-bugs
In-Reply-To: <CACT4Y+YbQbZ7XTPK1HLvPiR9rmSm7Cz0H2LJAFfYfAta1Y3CiQ@mail.gmail.com>
On Thu, Sep 27, 2018 at 1:11 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> Would a stack trace for call_rcu be helpful here? I have this idea for
> a long time, but never get around to implementing it:
> https://bugzilla.kernel.org/show_bug.cgi?id=198437
Yes. Generally speaking, showing backtrace of call_rcu()
or schedule_work(0 etc. is very helpful, we are more interested
in who calls call_rcu() than what that RCU callback does.
BTW, yesterday I asked syzbot to test this:
https://github.com/congwang/linux/commit/b7815584cf1c0bbb79e8f6fe3e4b66ba10375560
I still don't get any result.
For this specific bug, we should hold a refcnt in dev->qdisc, I don't
even see how call_rcu() could be invoked, unless of course we mess
up with qdisc refcnt.
^ permalink raw reply
* [PATCH net-next 2/7] ipv4: add RTM_GETADDR2
From: Christian Brauner @ 2018-09-27 17:58 UTC (permalink / raw)
To: jbenc, davem, dsahern, stephen, netdev, linux-kernel; +Cc: Christian Brauner
In-Reply-To: <20180927175857.3511-1-christian@brauner.io>
Various userspace programs (e.g. iproute2) have sent RTM_GETADDR
requests with struct ifinfomsg. This is wrong and should have been
struct ifaddrmsg all along as mandated by the manpages. However, dump
requests so far didn't parse the netlink message that was sent and
succeeded even when a wrong struct was passed along.
Currently, the message is parsed under the assumption that the correct
struct ifaddrmsg is sent down. If the parsing fails the kernel will
still fulfill the request to preserve backwards compatability but a
rate-limited message that there were leftover bytes after parsing the
message is recorded in dmesg. It has been argued that this is
unacceptable [1].
But various new features that got and will get added to RTM_GETADDR make
it necessary to definitely know what header was passed along.
This is currently not possible without resorting to (likely unreliable)
hacks such as introducing a nested attribute that ensures that
RTM_GETADDR which pass along properties such as IFA_TARGET_NETNSID
always exceed RTM_GETADDR requests that send down the wrong struct
ifinfomsg [2]. Basically, multiple approaches to solve this have been
shut down. Furthermore, the API expressed via RTM_GETADDR is apparently
frozen [3] so the wiggle room at this point seems very much zero.
The correct solution at this point seems to me to introduce a new
RTM_GETADDR2 request. This way we can parse the message and fail hard if
the struct is not struct ifaddrmsg and can safely extend it in the
future. Userspace tools that rely on the buggy RTM_GETADDR API will
still keep working without even having to see any log messages and new
userspace tools that want to make user of new features can make use of
the new RTM_GETADDR2 requests.
[1]: https://lists.openwall.net/netdev/2018/09/25/59
[2]: https://lists.openwall.net/netdev/2018/09/25/75
[3]: https://lists.openwall.net/netdev/2018/09/26/166
Signed-off-by: Christian Brauner <christian@brauner.io>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Benc <jbenc@redhat.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
---
net/ipv4/devinet.c | 24 +++++++++++++++++++++---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 44d931a3cd50..3ac004ba67b0 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1659,7 +1659,8 @@ static int inet_fill_ifaddr(struct sk_buff *skb, struct in_ifaddr *ifa,
return -EMSGSIZE;
}
-static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
+static int inet_dump_ifaddr_common(struct sk_buff *skb,
+ struct netlink_callback *cb, int rtm_type)
{
struct inet_fill_args fillargs = {
.portid = NETLINK_CB(cb->skb).portid,
@@ -1683,8 +1684,14 @@ static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
s_idx = idx = cb->args[1];
s_ip_idx = ip_idx = cb->args[2];
- if (nlmsg_parse(cb->nlh, sizeof(struct ifaddrmsg), tb, IFA_MAX,
- ifa_ipv4_policy, NULL) >= 0) {
+ if (rtm_type == RTM_GETADDR2) {
+ int err;
+
+ err = nlmsg_parse(cb->nlh, sizeof(struct ifaddrmsg), tb,
+ IFA_MAX, ifa_ipv4_policy, NULL);
+ if (err < 0)
+ return err;
+
if (tb[IFA_TARGET_NETNSID]) {
fillargs.netnsid = nla_get_s32(tb[IFA_TARGET_NETNSID]);
@@ -1736,6 +1743,16 @@ static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
return skb->len;
}
+static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
+{
+ return inet_dump_ifaddr_common(skb, cb, RTM_GETADDR);
+}
+
+static int inet_dump_ifaddr2(struct sk_buff *skb, struct netlink_callback *cb)
+{
+ return inet_dump_ifaddr_common(skb, cb, RTM_GETADDR2);
+}
+
static void rtmsg_ifa(int event, struct in_ifaddr *ifa, struct nlmsghdr *nlh,
u32 portid)
{
@@ -2564,6 +2581,7 @@ void __init devinet_init(void)
rtnl_register(PF_INET, RTM_NEWADDR, inet_rtm_newaddr, NULL, 0);
rtnl_register(PF_INET, RTM_DELADDR, inet_rtm_deladdr, NULL, 0);
rtnl_register(PF_INET, RTM_GETADDR, NULL, inet_dump_ifaddr, 0);
+ rtnl_register(PF_INET, RTM_GETADDR2, NULL, inet_dump_ifaddr2, 0);
rtnl_register(PF_INET, RTM_GETNETCONF, inet_netconf_get_devconf,
inet_netconf_dump_devconf, 0);
}
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 5/7] phonet: add RTM_GETADDR2
From: Christian Brauner @ 2018-09-27 17:58 UTC (permalink / raw)
To: jbenc, davem, dsahern, stephen, netdev, linux-kernel; +Cc: Christian Brauner
In-Reply-To: <20180927175857.3511-1-christian@brauner.io>
Various userspace programs (e.g. iproute2) have sent RTM_GETADDR
requests with struct ifinfomsg. This is wrong and should have been
struct ifaddrmsg all along as mandated by the manpages. However, dump
requests so far didn't parse the netlink message that was sent and
succeeded even when a wrong struct was passed along.
Currently, the message is parsed under the assumption that the correct
struct ifaddrmsg is sent down. If the parsing fails the kernel will
still fulfill the request to preserve backwards compatability but a
rate-limited message that there were leftover bytes after parsing the
message is recorded in dmesg. It has been argued that this is
unacceptable [1].
But various new features that got and will get added to RTM_GETADDR make
it necessary to definitely know what header was passed along.
This is currently not possible without resorting to (likely unreliable)
hacks such as introducing a nested attribute that ensures that
RTM_GETADDR which pass along properties such as IFA_TARGET_NETNSID
always exceed RTM_GETADDR requests that send down the wrong struct
ifinfomsg [2]. Basically, multiple approaches to solve this have been
shut down. Furthermore, the API expressed via RTM_GETADDR is apparently
frozen [3] so the wiggle room at this point seems very much zero.
The correct solution at this point seems to me to introduce a new
RTM_GETADDR2 request. This way we can parse the message and fail hard if
the struct is not struct ifaddrmsg and can safely extend it in the
future. Userspace tools that rely on the buggy RTM_GETADDR API will
still keep working without even having to see any log messages and new
userspace tools that want to make user of new features can make use of
the new RTM_GETADDR2 requests.
[1]: https://lists.openwall.net/netdev/2018/09/25/59
[2]: https://lists.openwall.net/netdev/2018/09/25/75
[3]: https://lists.openwall.net/netdev/2018/09/26/166
Signed-off-by: Christian Brauner <christian@brauner.io>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Benc <jbenc@redhat.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
---
net/phonet/pn_netlink.c | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/net/phonet/pn_netlink.c b/net/phonet/pn_netlink.c
index 871eaf2cb85e..acba4fe9a612 100644
--- a/net/phonet/pn_netlink.c
+++ b/net/phonet/pn_netlink.c
@@ -131,13 +131,22 @@ static int fill_addr(struct sk_buff *skb, struct net_device *dev, u8 addr,
return -EMSGSIZE;
}
-static int getaddr_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
+static int getaddr_dumpit_common(struct sk_buff *skb,
+ struct netlink_callback *cb, int rtm_type)
{
struct phonet_device_list *pndevs;
+ struct nlattr *tb[IFA_MAX+1];
struct phonet_device *pnd;
- int dev_idx = 0, dev_start_idx = cb->args[0];
+ int err, dev_idx = 0, dev_start_idx = cb->args[0];
int addr_idx = 0, addr_start_idx = cb->args[1];
+ if (rtm_type == RTM_GETADDR2) {
+ err = nlmsg_parse(cb->nlh, sizeof(struct ifaddrmsg), tb,
+ IFA_MAX, ifa_phonet_policy, NULL);
+ if (err < 0)
+ return err;
+ }
+
pndevs = phonet_device_list(sock_net(skb->sk));
rcu_read_lock();
list_for_each_entry_rcu(pnd, &pndevs->list, list) {
@@ -168,6 +177,16 @@ static int getaddr_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
return skb->len;
}
+static int getaddr_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
+{
+ return getaddr_dumpit_common(skb, cb, RTM_GETADDR);
+}
+
+static int getaddr_dumpit2(struct sk_buff *skb, struct netlink_callback *cb)
+{
+ return getaddr_dumpit_common(skb, cb, RTM_GETADDR2);
+}
+
/* Routes handling */
static int fill_route(struct sk_buff *skb, struct net_device *dev, u8 dst,
@@ -309,6 +328,8 @@ int __init phonet_netlink_register(void)
addr_doit, NULL, 0);
rtnl_register_module(THIS_MODULE, PF_PHONET, RTM_GETADDR,
NULL, getaddr_dumpit, 0);
+ rtnl_register_module(THIS_MODULE, PF_PHONET, RTM_GETADDR2,
+ NULL, getaddr_dumpit2, 0);
rtnl_register_module(THIS_MODULE, PF_PHONET, RTM_NEWROUTE,
route_doit, NULL, 0);
rtnl_register_module(THIS_MODULE, PF_PHONET, RTM_DELROUTE,
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 7/7] rtnetlink: enable RTM_GETADDR2
From: Christian Brauner @ 2018-09-27 17:58 UTC (permalink / raw)
To: jbenc, davem, dsahern, stephen, netdev, linux-kernel; +Cc: Christian Brauner
In-Reply-To: <20180927175857.3511-1-christian@brauner.io>
Various userspace programs (e.g. iproute2) have sent RTM_GETADDR
requests with struct ifinfomsg. This is wrong and should have been
struct ifaddrmsg all along as mandated by the manpages. However, dump
requests so far didn't parse the netlink message that was sent and
succeeded even when a wrong struct was passed along.
Currently, the message is parsed under the assumption that the correct
struct ifaddrmsg is sent down. If the parsing fails the kernel will
still fulfill the request to preserve backwards compatability but a
rate-limited message that there were leftover bytes after parsing the
message is recorded in dmesg. It has been argued that this is
unacceptable [1].
But various new features that got and will get added to RTM_GETADDR make
it necessary to definitely know what header was passed along.
This is currently not possible without resorting to (likely unreliable)
hacks such as introducing a nested attribute that ensures that
RTM_GETADDR which pass along properties such as IFA_TARGET_NETNSID
always exceed RTM_GETADDR requests that send down the wrong struct
ifinfomsg [2]. Basically, multiple approaches to solve this have been
shut down. Furthermore, the API expressed via RTM_GETADDR is apparently
frozen [3] so the wiggle room at this point seems very much zero.
The correct solution at this point seems to me to introduce a new
RTM_GETADDR2 request. This way we can parse the message and fail hard if
the struct is not struct ifaddrmsg and can safely extend it in the
future. Userspace tools that rely on the buggy RTM_GETADDR API will
still keep working without even having to see any log messages and new
userspace tools that want to make user of new features can make use of
the new RTM_GETADDR2 requests.
[1]: https://lists.openwall.net/netdev/2018/09/25/59
[2]: https://lists.openwall.net/netdev/2018/09/25/75
[3]: https://lists.openwall.net/netdev/2018/09/26/166
Signed-off-by: Christian Brauner <christian@brauner.io>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Benc <jbenc@redhat.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
---
net/core/rtnetlink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 35162e1b06ad..2ec020236053 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -4835,6 +4835,7 @@ void __init rtnetlink_init(void)
rtnl_register(PF_UNSPEC, RTM_DELLINK, rtnl_dellink, NULL, 0);
rtnl_register(PF_UNSPEC, RTM_GETADDR, NULL, rtnl_dump_all, 0);
+ rtnl_register(PF_UNSPEC, RTM_GETADDR2, NULL, rtnl_dump_all, 0);
rtnl_register(PF_UNSPEC, RTM_GETROUTE, NULL, rtnl_dump_all, 0);
rtnl_register(PF_UNSPEC, RTM_GETNETCONF, NULL, rtnl_dump_all, 0);
--
2.17.1
^ permalink raw reply related
* Re: KASAN: use-after-free Read in tcf_block_find
From: Dmitry Vyukov @ 2018-09-27 18:04 UTC (permalink / raw)
To: Cong Wang
Cc: Eric Dumazet, syzbot+37b8770e6d5a8220a039, David Miller,
Jamal Hadi Salim, Jiri Pirko, LKML,
Linux Kernel Network Developers, syzkaller-bugs
In-Reply-To: <CAM_iQpUpe5J30_aOzDUHrxiC7hXyQfH6-R7TM_L==gkj_XTu5w@mail.gmail.com>
On Thu, Sep 27, 2018 at 7:50 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Thu, Sep 27, 2018 at 1:11 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>>
>> Would a stack trace for call_rcu be helpful here? I have this idea for
>> a long time, but never get around to implementing it:
>> https://bugzilla.kernel.org/show_bug.cgi?id=198437
>
> Yes. Generally speaking, showing backtrace of call_rcu()
> or schedule_work(0 etc. is very helpful, we are more interested
> in who calls call_rcu() than what that RCU callback does.
>
> BTW, yesterday I asked syzbot to test this:
> https://github.com/congwang/linux/commit/b7815584cf1c0bbb79e8f6fe3e4b66ba10375560
> I still don't get any result.
I see that test job. It's in some dead loop, now trying to run for 37'th time.
I've just pushed a fix a bug that could have caused it (fuzzing the
fuzzer, we should go deeper!):
https://github.com/google/syzkaller/commit/98b28ead6ceaf22064b9715cc1950848d2bdef0b
If it won't help, I will take a look tomorrow.
> For this specific bug, we should hold a refcnt in dev->qdisc, I don't
> even see how call_rcu() could be invoked, unless of course we mess
> up with qdisc refcnt.
^ permalink raw reply
* [PATCH net-next] net: bridge: explicitly zero is_sticky in fdb_create
From: Nikolay Aleksandrov @ 2018-09-27 12:05 UTC (permalink / raw)
To: netdev; +Cc: roopa, davem, stephen, bridge, Nikolay Aleksandrov
We need to explicitly zero is_sticky when creating a new fdb, otherwise
we might get a stale value for a new entry.
Fixes: 435f2e7cc0b7 ("net: bridge: add support for sticky fdb entries")
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
net/bridge/br_fdb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index a56ed7f2a3a3..74331690a390 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -504,6 +504,7 @@ static struct net_bridge_fdb_entry *fdb_create(struct net_bridge *br,
fdb->added_by_user = 0;
fdb->added_by_external_learn = 0;
fdb->offloaded = 0;
+ fdb->is_sticky = 0;
fdb->updated = fdb->used = jiffies;
if (rhashtable_lookup_insert_fast(&br->fdb_hash_tbl,
&fdb->rhnode,
--
2.11.0
^ 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