* 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 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 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: 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: 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: [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
* [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: [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
* 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 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
* 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: 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
* [PATCH v2 2/2] netlink: add validation function to policy
From: Johannes Berg @ 2018-09-27 9:28 UTC (permalink / raw)
To: linux-wireless, netdev; +Cc: Michal Kubecek, Johannes Berg
In-Reply-To: <20180927092836.6117-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
Add the ability to have an arbitrary validation function attached
to a netlink policy that doesn't already use the validation_data
pointer in another way.
This can be useful to validate for example the content of a binary
attribute, like in nl80211 the "(information) elements", which must
be valid streams of "u8 type, u8 length, u8 value[length]".
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/netlink.h | 24 +++++++++++++++++++++++-
lib/nlattr.c | 7 +++++++
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index d34ceeba82a8..6a106ef5ca56 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -193,13 +193,14 @@ enum nla_policy_validation {
NLA_VALIDATE_RANGE,
NLA_VALIDATE_MIN,
NLA_VALIDATE_MAX,
+ NLA_VALIDATE_FUNCTION,
};
/**
* struct nla_policy - attribute validation policy
* @type: Type of attribute or NLA_UNSPEC
* @validation_type: type of attribute validation done in addition to
- * type-specific validation (e.g. range), see
+ * type-specific validation (e.g. range, function call), see
* &enum nla_policy_validation
* @len: Type specific length of payload
*
@@ -269,6 +270,13 @@ enum nla_policy_validation {
* of s16 - do that as usual in the code instead.
* All other Unused - but note that it's a union
*
+ * Meaning of `validate' field, use via NLA_POLICY_VALIDATE_FN:
+ * NLA_BINARY Validation function called for the attribute,
+ * not compatible with use of the validation_data
+ * as in NLA_BITFIELD32, NLA_REJECT, NLA_NESTED and
+ * NLA_NESTED_ARRAY.
+ * All other Unused - but note that it's a union
+ *
* Example:
* static const struct nla_policy my_policy[ATTR_MAX+1] = {
* [ATTR_FOO] = { .type = NLA_U16 },
@@ -286,6 +294,8 @@ struct nla_policy {
struct {
s16 min, max;
};
+ int (*validate)(const struct nlattr *attr,
+ struct netlink_ext_ack *extack);
};
};
@@ -307,6 +317,11 @@ struct nla_policy {
tp == NLA_S16 || tp == NLA_U16 || \
tp == NLA_S32 || tp == NLA_U32 || \
tp == NLA_S64 || tp == NLA_U64) + tp)
+#define NLA_ENSURE_NO_VALIDATION_PTR(tp) \
+ (__NLA_ENSURE(tp != NLA_BITFIELD32 && \
+ tp != NLA_REJECT && \
+ tp != NLA_NESTED && \
+ tp != NLA_NESTED_ARRAY) + tp)
#define NLA_POLICY_RANGE(tp, _min, _max) { \
.type = NLA_ENSURE_INT_TYPE(tp), \
@@ -327,6 +342,13 @@ struct nla_policy {
.max = _max, \
}
+#define NLA_POLICY_VALIDATE_FN(tp, fn, ...) { \
+ .type = NLA_ENSURE_NO_VALIDATION_PTR(tp), \
+ .validation_type = NLA_VALIDATE_FUNCTION, \
+ .validate = fn, \
+ .len = __VA_ARGS__ + 0, \
+}
+
/**
* struct nl_info - netlink source information
* @nlh: Netlink message header of original request
diff --git a/lib/nlattr.c b/lib/nlattr.c
index 5670e4b7dfef..1e900bb414ef 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -300,6 +300,13 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
if (err)
return err;
break;
+ case NLA_VALIDATE_FUNCTION:
+ if (pt->validate) {
+ err = pt->validate(nla, extack);
+ if (err)
+ return err;
+ }
+ break;
}
return 0;
--
2.14.4
^ permalink raw reply related
* [PATCH v2 1/2] netlink: add attribute range validation to policy
From: Johannes Berg @ 2018-09-27 9:28 UTC (permalink / raw)
To: linux-wireless, netdev; +Cc: Michal Kubecek, Johannes Berg
In-Reply-To: <20180927092836.6117-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
Without further bloating the policy structs, we can overload
the `validation_data' pointer with a struct of s16 min, max
and use those to validate ranges in NLA_{U,S}{8,16,32,64}
attributes.
It may sound strange to validate NLA_U32 with a s16 max, but
in many cases NLA_U32 is used for enums etc. since there's no
size benefit in using a smaller attribute width anyway, due
to netlink attribute alignment; in cases like that it's still
useful, particularly when the attribute really transports an
enum value.
Doing so lets us remove quite a bit of validation code, if we
can be sure that these attributes aren't used by userspace in
places where they're ignored today.
To achieve all this, split the 'type' field and introduce a
new 'validation_type' field which indicates what further
validation (beyond the validation prescribed by the type of
the attribute) is done. This currently allows for no further
validation (the default), as well as min, max and range checks.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/netlink.h | 67 ++++++++++++++++++++++++++++++++++++++++++++---
lib/nlattr.c | 72 +++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 136 insertions(+), 3 deletions(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index 3698ca8ff92c..d34ceeba82a8 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -188,9 +188,19 @@ enum {
#define NLA_TYPE_MAX (__NLA_TYPE_MAX - 1)
+enum nla_policy_validation {
+ NLA_VALIDATE_NONE,
+ NLA_VALIDATE_RANGE,
+ NLA_VALIDATE_MIN,
+ NLA_VALIDATE_MAX,
+};
+
/**
* struct nla_policy - attribute validation policy
* @type: Type of attribute or NLA_UNSPEC
+ * @validation_type: type of attribute validation done in addition to
+ * type-specific validation (e.g. range), see
+ * &enum nla_policy_validation
* @len: Type specific length of payload
*
* Policies are defined as arrays of this struct, the array must be
@@ -238,7 +248,26 @@ enum {
* nested attributes directly inside, while an array has
* the nested attributes at another level down and the
* attributes directly in the nesting don't matter.
- * All other Unused
+ * All other Unused - but note that it's a union
+ *
+ * Meaning of `min' and `max' fields, use via NLA_POLICY_MIN, NLA_POLICY_MAX
+ * and NLA_POLICY_RANGE:
+ * NLA_U8,
+ * NLA_U16,
+ * NLA_U32,
+ * NLA_U64,
+ * NLA_S8,
+ * NLA_S16,
+ * NLA_S32,
+ * NLA_S64 These are used depending on the validation_type
+ * field, if that is min/max/range then the minimum,
+ * maximum and both are used (respectively) to check
+ * the value of the integer attribute.
+ * Note that in the interest of code simplicity and
+ * struct size both limits are s16, so you cannot
+ * enforce a range that doesn't fall within the range
+ * of s16 - do that as usual in the code instead.
+ * All other Unused - but note that it's a union
*
* Example:
* static const struct nla_policy my_policy[ATTR_MAX+1] = {
@@ -249,9 +278,15 @@ enum {
* };
*/
struct nla_policy {
- u16 type;
+ u8 type;
+ u8 validation_type;
u16 len;
- const void *validation_data;
+ union {
+ const void *validation_data;
+ struct {
+ s16 min, max;
+ };
+ };
};
#define NLA_POLICY_EXACT_LEN(_len) { .type = NLA_EXACT_LEN, .len = _len }
@@ -266,6 +301,32 @@ struct nla_policy {
#define NLA_POLICY_NESTED_ARRAY(maxattr, policy) \
{ .type = NLA_NESTED_ARRAY, .validation_data = policy, .len = maxattr }
+#define __NLA_ENSURE(condition) (sizeof(char[1 - 2*!(condition)]) - 1)
+#define NLA_ENSURE_INT_TYPE(tp) \
+ (__NLA_ENSURE(tp == NLA_S8 || tp == NLA_U8 || \
+ tp == NLA_S16 || tp == NLA_U16 || \
+ tp == NLA_S32 || tp == NLA_U32 || \
+ tp == NLA_S64 || tp == NLA_U64) + tp)
+
+#define NLA_POLICY_RANGE(tp, _min, _max) { \
+ .type = NLA_ENSURE_INT_TYPE(tp), \
+ .validation_type = NLA_VALIDATE_RANGE, \
+ .min = _min, \
+ .max = _max \
+}
+
+#define NLA_POLICY_MIN(tp, _min) { \
+ .type = NLA_ENSURE_INT_TYPE(tp), \
+ .validation_type = NLA_VALIDATE_MIN, \
+ .min = _min, \
+}
+
+#define NLA_POLICY_MAX(tp, _max) { \
+ .type = NLA_ENSURE_INT_TYPE(tp), \
+ .validation_type = NLA_VALIDATE_MAX, \
+ .max = _max, \
+}
+
/**
* struct nl_info - netlink source information
* @nlh: Netlink message header of original request
diff --git a/lib/nlattr.c b/lib/nlattr.c
index 2f8feff669a7..5670e4b7dfef 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -95,6 +95,64 @@ static int nla_validate_array(const struct nlattr *head, int len, int maxtype,
return 0;
}
+static int nla_validate_int_range(const struct nla_policy *pt,
+ const struct nlattr *nla,
+ struct netlink_ext_ack *extack)
+{
+ bool validate_min, validate_max;
+ s64 value;
+
+ validate_min = pt->validation_type == NLA_VALIDATE_RANGE ||
+ pt->validation_type == NLA_VALIDATE_MIN;
+ validate_max = pt->validation_type == NLA_VALIDATE_RANGE ||
+ pt->validation_type == NLA_VALIDATE_MAX;
+
+ switch (pt->type) {
+ case NLA_U8:
+ value = nla_get_u8(nla);
+ break;
+ case NLA_U16:
+ value = nla_get_u16(nla);
+ break;
+ case NLA_U32:
+ value = nla_get_u32(nla);
+ break;
+ case NLA_S8:
+ value = nla_get_s8(nla);
+ break;
+ case NLA_S16:
+ value = nla_get_s16(nla);
+ break;
+ case NLA_S32:
+ value = nla_get_s32(nla);
+ break;
+ case NLA_S64:
+ value = nla_get_s64(nla);
+ break;
+ case NLA_U64:
+ /* treat this one specially, since it may not fit into s64 */
+ if ((validate_min && nla_get_u64(nla) < pt->min) ||
+ (validate_max && nla_get_u64(nla) > pt->max)) {
+ NL_SET_ERR_MSG_ATTR(extack, nla,
+ "integer out of range");
+ return -ERANGE;
+ }
+ return 0;
+ default:
+ WARN_ON(1);
+ return -EINVAL;
+ }
+
+ if ((validate_min && value < pt->min) ||
+ (validate_max && value > pt->max)) {
+ NL_SET_ERR_MSG_ATTR(extack, nla,
+ "integer out of range");
+ return -ERANGE;
+ }
+
+ return 0;
+}
+
static int validate_nla(const struct nlattr *nla, int maxtype,
const struct nla_policy *policy,
struct netlink_ext_ack *extack)
@@ -230,6 +288,20 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
goto out_err;
}
+ /* further validation */
+ switch (pt->validation_type) {
+ case NLA_VALIDATE_NONE:
+ /* nothing to do */
+ break;
+ case NLA_VALIDATE_RANGE:
+ case NLA_VALIDATE_MIN:
+ case NLA_VALIDATE_MAX:
+ err = nla_validate_int_range(pt, nla, extack);
+ if (err)
+ return err;
+ break;
+ }
+
return 0;
out_err:
NL_SET_ERR_MSG_ATTR(extack, nla, "Attribute failed policy validation");
--
2.14.4
^ permalink raw reply related
* [PATCH v2 0/2] netlink: extended attribute validation
From: Johannes Berg @ 2018-09-27 9:28 UTC (permalink / raw)
To: linux-wireless, netdev; +Cc: Michal Kubecek
This adds further netlink attribute validation:
* min/max/range validation
* validation through a custom function pointer
This is useful to
* reduce boilerplate code in command handling code, if attributes
are used commonly across different commands
* get more extended ACK error messages/attribute pointers
* ensure attributes are valid even when ignored
(though this might be a problem when converting existing code)
Changes since v1:
* split off validate_type from type and use that for min/max/range
and function; this is better because the range is limited to the
range of s16 and so things like "u16 with minimum value 1" couldn't
be expressed earlier
* add macros for this, e.g. NLA_POLICY_MIN(NLA_U16, 1) for the case
mentioned in the previous bullet
Using this pretty much in all places where applicable in nl80211
reduces the code size there by about 1.8KiB, with just a minimal
code increase in lib/nlattr.o.
johannes
^ permalink raw reply
* Re: [PATCH iproute2] vxlan: show correct ttl inherit info
From: Phil Sutter @ 2018-09-27 9:27 UTC (permalink / raw)
To: Hangbin Liu; +Cc: netdev, Stephen Hemminger, David Ahern
In-Reply-To: <1538033316-32312-1-git-send-email-liuhangbin@gmail.com>
Hi Hangbin,
On Thu, Sep 27, 2018 at 03:28:36PM +0800, Hangbin Liu wrote:
> We should only show ttl inherit when IFLA_VXLAN_TTL_INHERIT supplied.
> Otherwise show the ttl number, or auto when it is 0.
>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
> ---
> ip/iplink_vxlan.c | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/ip/iplink_vxlan.c b/ip/iplink_vxlan.c
> index 831f39a..7fc0e2b 100644
> --- a/ip/iplink_vxlan.c
> +++ b/ip/iplink_vxlan.c
> @@ -145,7 +145,7 @@ static int vxlan_parse_opt(struct link_util *lu, int argc, char **argv,
> NEXT_ARG();
> check_duparg(&attrs, IFLA_VXLAN_TTL, "ttl", *argv);
> if (strcmp(*argv, "inherit") == 0) {
> - addattr_l(n, 1024, IFLA_VXLAN_TTL_INHERIT, NULL, 0);
> + addattr(n, 1024, IFLA_VXLAN_TTL_INHERIT);
So for VXLAN, the attribute is just added but with a zero value. Looking
at respective kernel code, this seems fine. Now I wonder why for Geneve,
you set the value to 1 and when displaying explicitly check whether the
attribute is there *and* non-zero. OK, looks like Geneve driver always
exports IFLA_GENEVE_TTL_INHERIT. Oddly, I can't find where VXLAN driver
in kernel does export the IFLA_VXLAN_TTL_INHERIT attribute. Am I missing
something?
Do you know why handling of the attributes in both drivers differ?
Cheers, Phil
^ permalink raw reply
* Re: [PATCH net V2] vhost-vsock: fix use after free
From: Stefan Hajnoczi @ 2018-09-27 15:33 UTC (permalink / raw)
To: Jason Wang
Cc: kvm, sergei.shtylyov, mst, netdev, linux-kernel, virtualization
In-Reply-To: <20180927122204.4188-1-jasowang@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 838 bytes --]
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>
> ---
> - V2: fix typos
> - The patch is needed for -stable.
> ---
> drivers/vhost/vsock.c | 26 +++++++++++++++++++-------
> 1 file changed, 19 insertions(+), 7 deletions(-)
Thank you, Jason!
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH iproute2-next] geneve: fix ttl inherit behavior
From: Phil Sutter @ 2018-09-27 9:08 UTC (permalink / raw)
To: Hangbin Liu; +Cc: netdev, Stephen Hemminger, David Ahern
In-Reply-To: <1538033257-32244-1-git-send-email-liuhangbin@gmail.com>
On Thu, Sep 27, 2018 at 03:27:37PM +0800, Hangbin Liu wrote:
> Currently when we add geneve with "ttl inherit", we set ttl to 0, which
> is actually use whatever default value instead of inherit the inner
> protocol's ttl value.
>
> To respect compatibility with old behavior and make a difference between
> ttl inherit and ttl == 0, we add an attribute IFLA_GENEVE_TTL_INHERIT in
> kernel commit 52d0d404d39dd ("geneve: add ttl inherit support").
>
> Now let's use "ttl inherit" to inherit the inner protocol's ttl, and use
> "ttl auto" to means "use whatever default value", the same behavior with
> ttl == 0.
>
> Reported-by: Jianlin Shi <jishi@redhat.com>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Acked-by: Phil Sutter <phil@nwl.cc>
^ permalink raw reply
* Re: [PATCH] mt76: fix building without CONFIG_MT76x0U
From: kbuild test robot @ 2018-09-27 15:22 UTC (permalink / raw)
To: Arnd Bergmann
Cc: kbuild-all, Kalle Valo, Stanislaw Gruszka, Felix Fietkau,
Lorenzo Bianconi, Arnd Bergmann, David S. Miller, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20180926125356.2026635-1-arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]
Hi Arnd,
I love your patch! Yet something to improve:
[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on next-20180926]
[cannot apply to v4.19-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Arnd-Bergmann/mt76-fix-building-without-CONFIG_MT76x0U/20180927-101346
base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git master
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> ERROR: "mt76x0_tx_prepare_skb" [drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0u.ko] undefined!
>> ERROR: "mt76x0_cleanup" [drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0u.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 65149 bytes --]
^ permalink raw reply
* Re: [PATCH resend] can: rcar_can: convert to SPDX identifiers
From: Marc Kleine-Budde @ 2018-09-27 9:05 UTC (permalink / raw)
To: Kuninori Morimoto, Wolfgang Grandegger
Cc: Linux-Renesas, Linux-Net, linux-can
In-Reply-To: <874ledyrc6.wl-kuninori.morimoto.gx@renesas.com>
[-- Attachment #1.1: Type: text/plain, Size: 819 bytes --]
On 09/26/2018 03:41 AM, Kuninori Morimoto wrote:
>
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> This patch updates license to use SPDX-License-Identifier
> instead of verbose license text.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Wolfram Sang has already supplied a similar patch, but not for Makefile
and Kconfig. I've applied your patch for Makefile and Kconfig and
adjusted the commit message accordingly.
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-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations
From: Jason A. Donenfeld @ 2018-09-27 15:19 UTC (permalink / raw)
To: Thomas Gleixner, Peter Zijlstra
Cc: 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: <CAHmME9rN3-7Mj5JQqt2EFPauG9vjkN5pQn3tPiJY4fPiwksaDA@mail.gmail.com>
Hey again Thomas,
On Thu, Sep 27, 2018 at 3:26 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Hi Thomas,
>
> I'm trying to optimize this for crypto performance while still taking
> into account preemption concerns. I'm having a bit of trouble figuring
> out a way to determine numerically what the upper bounds for this
> stuff looks like. I'm sure I could pick a pretty sane number that's
> arguably okay -- and way under the limit -- but I still am interested
> in determining what that limit actually is. I was hoping there'd be a
> debugging option called, "warn if preemption is disabled for too
> long", or something, but I couldn't find anything like that. I'm also
> not quite sure what the latency limits are, to just compute this with
> a formula. Essentially what I'm trying to determine is:
>
> preempt_disable();
> asm volatile(".fill N, 1, 0x90;");
> preempt_enable();
>
> What is the maximum value of N for which the above is okay? What
> technique would you generally use in measuring this?
>
> Thanks,
> Jason
>From talking to Peter (now CC'd) on IRC, it sounds like what you're
mostly interested in is clocktime latency on reasonable hardware, with
a goal of around ~20µs as a maximum upper bound? I don't expect to get
anywhere near this value at all, but if you can confirm that's a
decent ballpark, it would make for some interesting calculations.
Regards,
Jason
^ permalink raw reply
* Re: [PATCH] ieee802154: ca8210: remove redundant condition check before debugfs_remove
From: Stefan Schmidt @ 2018-09-27 15:15 UTC (permalink / raw)
To: zhong jiang, h.morris, alex.aring, davem; +Cc: linux-wpan, netdev, linux-kernel
In-Reply-To: <1536901477-28375-1-git-send-email-zhongjiang@huawei.com>
Hello Zhong.
On 14/09/2018 07:04, zhong jiang wrote:
> debugfs_remove has taken the IS_ERR into account. Just
> remove the unnecessary condition.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> ---
> drivers/net/ieee802154/ca8210.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/ieee802154/ca8210.c b/drivers/net/ieee802154/ca8210.c
> index 58299fb..46b4818 100644
> --- a/drivers/net/ieee802154/ca8210.c
> +++ b/drivers/net/ieee802154/ca8210.c
> @@ -3044,8 +3044,7 @@ static void ca8210_test_interface_clear(struct ca8210_priv *priv)
> {
> struct ca8210_test *test = &priv->test;
>
> - if (!IS_ERR(test->ca8210_dfs_spi_int))
> - debugfs_remove(test->ca8210_dfs_spi_int);
> + debugfs_remove(test->ca8210_dfs_spi_int);
> kfifo_free(&test->up_fifo);
> dev_info(&priv->spi->dev, "Test interface removed\n");
> }
>
This patch has been applied to the wpan tree and will be
part of the next pull request to net. Thanks!
regards
Stefan Schmidt
^ permalink raw reply
* Re: [PATCH] netlink: add policy attribute range validation
From: Johannes Berg @ 2018-09-27 8:51 UTC (permalink / raw)
To: Michal Kubecek; +Cc: linux-wireless, netdev
In-Reply-To: <20180927084807.GG30601@unicorn.suse.cz>
On Thu, 2018-09-27 at 10:48 +0200, Michal Kubecek wrote:
> We could still use helper macros so this part could become
>
> DEFINE_NLA_U8_RANGE(retry_range, 1, 255);
>
> or
>
> DEFINE_NLA_RANGE(retry_range, u8, 1, 255);
True.
> > policy[] = {
> > ...
> > [NL80211_ATTR_WIPHY_RETRY_SHORT] = {
> > .type = NLA_U8,
> > .validation_data = &retry_range,
> > },
> > ...
> > };
>
> And this could be also shortened using a macro.
>
> It would still be longer but not that much.
Right. You'd still have to name it, and then we'd probably eventually
want to share some common range definitions, but indeed it would work.
> I didn't mean it as a serious objection, rather a note that the gain may
> not be worth the additional complexity.
Sure, and suggestions are very welcome. I was just trying to explain why
I chose this direction, more than anything else.
> But if you want to follow in the
> direction you indicated later (in particular, allowing different
> interpretations of validation_data for the same type), overloading does
> indeed make more sense.
I'm just working on the patches - give me a few more minutes.
johannes
^ permalink raw reply
* Re: [PATCH net-next] virtio_net: ethtool tx napi configuration
From: Jason Wang @ 2018-09-27 8:50 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Florian Fainelli, Network Development, David Miller, caleb.raitto,
Michael S. Tsirkin, Jon Olson (Google Drive), Willem de Bruijn
In-Reply-To: <CAF=yD-KEcWuYrSofugYBc3kwWvQdFDsv3z_yWx5-JDzyMga1qw@mail.gmail.com>
On 2018年09月14日 12:46, Willem de Bruijn wrote:
>> I'm not sure I get this. If we don't enable tx napi, we tend to delay TX
>> interrupt if we found the ring is about to full to avoid interrupt
>> storm, so we're probably ok in this case.
> I'm only concerned about the transition state when converting from
> napi to no-napi when the queue is stopped and tx interrupt disabled.
>
> With napi mode the interrupt is only disabled if napi is scheduled,
> in which case it will eventually reenable the interrupt. But when
> switching to no-napi mode in this state no progress will be made.
>
> But it seems this cannot happen. When converting to no-napi
> mode, set_coalesce waits for napi to complete in napi_disable.
> So the interrupt should always start enabled when transitioning
> into no-napi mode.
An update, I meet a hang in napi_disalbe(). But it's hard to be
reproduced. I tend to choose a easy way like V1 that only allow the
switching when device is down.
I will post the patch after a vacation. (or you can post if it was
urgent for you).
Thanks
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox