* pull request: bluetooth 2018-05-07
From: Johan Hedberg @ 2018-05-07 15:05 UTC (permalink / raw)
To: davem; +Cc: linux-bluetooth, netdev
[-- Attachment #1: Type: text/plain, Size: 1189 bytes --]
Hi Dave,
Here are a few more Bluetooth fixes for the 4.17 kernel, all for the
btusb driver. Two relate to the needs_reset_resume table, and one is a
revert of a patch for Atheros 1525/QCA6174 which caused a regression for
some people.
Please let me know if there are any issues pulling. Thanks.
Johan
---
The following changes since commit 2cb5fb1454ef4990f44f3070226ee29201bd5c87:
MAINTAINERS: add myself as SCTP co-maintainer (2018-04-29 22:49:45 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git for-upstream
for you to fetch changes up to 596b07a9a22656493726edf1739569102bd3e136:
Bluetooth: btusb: Add Dell XPS 13 9360 to btusb_needs_reset_resume_table (2018-04-30 10:56:04 +0200)
----------------------------------------------------------------
Hans de Goede (3):
Revert "Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174"
Bluetooth: btusb: Only check needs_reset_resume DMI table for QCA rome chipsets
Bluetooth: btusb: Add Dell XPS 13 9360 to btusb_needs_reset_resume_table
drivers/bluetooth/btusb.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH v2] net: dsa: drop some VLAs in switch.c
From: Salvatore Mesoraca @ 2018-05-07 15:23 UTC (permalink / raw)
To: Andrew Lunn
Cc: linux-kernel, kernel-hardening, netdev, David S. Miller,
Florian Fainelli, Kees Cook, Salvatore Mesoraca, Vivien Didelot,
David Laight
We avoid 2 VLAs by using a pre-allocated field in dsa_switch.
We also try to avoid dynamic allocation whenever possible.
Link: http://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
Link: http://lkml.kernel.org/r/20180505185145.GB32630@lunn.ch
Signed-off-by: Salvatore Mesoraca <s.mesoraca16@gmail.com>
---
include/net/dsa.h | 3 +++
net/dsa/dsa2.c | 14 ++++++++++++++
net/dsa/switch.c | 22 ++++++++++------------
3 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 60fb4ec..576791d 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -256,6 +256,9 @@ struct dsa_switch {
/* Number of switch port queues */
unsigned int num_tx_queues;
+ unsigned long *bitmap;
+ unsigned long _bitmap;
+
/* Dynamically allocated ports, keep last */
size_t num_ports;
struct dsa_port ports[];
diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index adf50fb..cebf35f0 100644
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -748,6 +748,20 @@ struct dsa_switch *dsa_switch_alloc(struct device *dev, size_t n)
if (!ds)
return NULL;
+ /* We avoid allocating memory outside dsa_switch
+ * if it is not needed.
+ */
+ if (n <= sizeof(ds->_bitmap) * 8) {
+ ds->bitmap = &ds->_bitmap;
+ } else {
+ ds->bitmap = devm_kzalloc(dev,
+ BITS_TO_LONGS(n) *
+ sizeof(unsigned long),
+ GFP_KERNEL);
+ if (unlikely(!ds->bitmap))
+ return NULL;
+ }
+
ds->dev = dev;
ds->num_ports = n;
diff --git a/net/dsa/switch.c b/net/dsa/switch.c
index b935117..142b294 100644
--- a/net/dsa/switch.c
+++ b/net/dsa/switch.c
@@ -136,21 +136,20 @@ static int dsa_switch_mdb_add(struct dsa_switch *ds,
{
const struct switchdev_obj_port_mdb *mdb = info->mdb;
struct switchdev_trans *trans = info->trans;
- DECLARE_BITMAP(group, ds->num_ports);
int port;
/* Build a mask of Multicast group members */
- bitmap_zero(group, ds->num_ports);
+ bitmap_zero(ds->bitmap, ds->num_ports);
if (ds->index == info->sw_index)
- set_bit(info->port, group);
+ set_bit(info->port, ds->bitmap);
for (port = 0; port < ds->num_ports; port++)
if (dsa_is_dsa_port(ds, port))
- set_bit(port, group);
+ set_bit(port, ds->bitmap);
if (switchdev_trans_ph_prepare(trans))
- return dsa_switch_mdb_prepare_bitmap(ds, mdb, group);
+ return dsa_switch_mdb_prepare_bitmap(ds, mdb, ds->bitmap);
- dsa_switch_mdb_add_bitmap(ds, mdb, group);
+ dsa_switch_mdb_add_bitmap(ds, mdb, ds->bitmap);
return 0;
}
@@ -204,21 +203,20 @@ static int dsa_switch_vlan_add(struct dsa_switch *ds,
{
const struct switchdev_obj_port_vlan *vlan = info->vlan;
struct switchdev_trans *trans = info->trans;
- DECLARE_BITMAP(members, ds->num_ports);
int port;
/* Build a mask of VLAN members */
- bitmap_zero(members, ds->num_ports);
+ bitmap_zero(ds->bitmap, ds->num_ports);
if (ds->index == info->sw_index)
- set_bit(info->port, members);
+ set_bit(info->port, ds->bitmap);
for (port = 0; port < ds->num_ports; port++)
if (dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port))
- set_bit(port, members);
+ set_bit(port, ds->bitmap);
if (switchdev_trans_ph_prepare(trans))
- return dsa_switch_vlan_prepare_bitmap(ds, vlan, members);
+ return dsa_switch_vlan_prepare_bitmap(ds, vlan, ds->bitmap);
- dsa_switch_vlan_add_bitmap(ds, vlan, members);
+ dsa_switch_vlan_add_bitmap(ds, vlan, ds->bitmap);
return 0;
}
--
1.9.1
^ permalink raw reply related
* Re: The SO_BINDTODEVICE was set to the desired interface, but packets are received from all interfaces.
From: David Ahern @ 2018-05-07 15:23 UTC (permalink / raw)
To: Paolo Abeni, Damir Mansurov, netdev
Cc: Konstantin Ushakov, Alexandra N. Kossovsky, Andrey Dmitrov
In-Reply-To: <1525696890.2587.24.camel@redhat.com>
On 5/7/18 6:41 AM, Paolo Abeni wrote:
> Hi,
> On Mon, 2018-05-07 at 13:19 +0300, Damir Mansurov wrote:
>> After successful call of the setsockopt(SO_BINDTODEVICE) function to set
>> data reception from only one interface, the data is still received from
>> all interfaces. Function setsockopt() returns 0 but then recv() receives
>> data from all available network interfaces.
>>
>> The problem is reproducible on linux kernels 4.14 - 4.16, but it does
>> not on linux kernels 4.4, 4.13.
>
> I think that the cause is commit:
>
> commit fb74c27735f0a34e76dbf1972084e984ad2ea145
> Author: David Ahern <dsahern@gmail.com>
> Date: Mon Aug 7 08:44:16 2017 -0700
>
> net: ipv4: add second dif to udp socket lookups
>
> Something like the following should fix, but I'm unsure it preserves
> the intended semathics for 'sdif'. David, can you please have a look?
> Thanks!
>
> Paolo
> ---
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index dd3102a37ef9..0d593d5c33cf 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -401,9 +401,9 @@ static int compute_score(struct sock *sk, struct net *net,
> bool dev_match = (sk->sk_bound_dev_if == dif ||
> sk->sk_bound_dev_if == sdif);
>
> - if (exact_dif && !dev_match)
> + if (!dev_match)
> return -1;
> - if (sk->sk_bound_dev_if && dev_match)
> + if (sk->sk_bound_dev_if)
> score += 4;
> }
>
>
yes, that does look like a mistake -- no match on sk_bound_dev_if should
fail the lookup.
Let me apply the diff and run my vrf tests to make sure they still work.
^ permalink raw reply
* Re: [PATCH v2 net-next 2/4] net: add skeleton of bpfilter kernel module
From: Harald Welte @ 2018-05-07 15:24 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: davem, daniel, torvalds, gregkh, luto, netdev, linux-kernel,
kernel-team
In-Reply-To: <20180503043604.1604587-3-ast@kernel.org>
Hi Alexei + netdev list,
On Wed, May 02, 2018 at 09:36:02PM -0700, Alexei Starovoitov wrote:
> Later bpfilter_process_sockopt() will be called from bpfilter hooks
> in get/setsockopt() to pass iptable commands into umh via bpfilter.ko
This is a part I'm quite heavily opposed to - at least at this point.
Unless bpfilter offered something that is semantically compatible to
what netfilter/iptables is currently implementing, I don't think
bpfilter should be [allowed to] overriding the iptables
{get,set}sockopt() calls.
I appreciate that people are working on a different architecture packet
filter than what we used to. I also understand that there is a need
for backwards compatibility. I still think it's wrong to offer that
compatibility on the {set,get}sockopt level, rather than on the
"iptables command line utility replacement" level. But nevermind, you
guys have a different opinion on that, on which we can agree to
disagree.
However, no matter what you do, the most important part from the user
point of view is to make sure you don't break semantics.
netfilter/iptables semantics have an intricate notion abut when which
chain of which table is executed, in which order, at what particular
point of the packet traversal during the network stack. The packet
filtering rulesets that people have created over more than 18 years
are based on those semantics. If you offer the same interface, but not
that very same semantics, the packet filtering policies can an will
break - and they will break so in a hidden way. To the user, it appears
as if the ruleset is loaded with the assumed semantics, but in reality
it isn't.
Unless you can replicate those semantics 1:1, I think it is not only
wrong to override the iptables sockopt interface, but it's outright
dangerous.
Having less matches/targets implemented than original iptables is
something that I believe is acceptable (and inevitable, at least in the
beginning). If somebody tries to load a related ruleset with bpfilter
active, it will fail gracefully and the user can chose to not use that
match/target in his ruleset, or to not use bpfilter.
But if the ruleset loads but behaves different than before (because e.g.
it's executed from a completely different place in the stack), that's
IMHO an absolute no-go that must be avoided at all cost. If that's the
case, you are actively breaking network security, rather than creating
it.
So I think there's only two ways to go:
a) replicate the exact semantics/order of the filter/mangle/raw/...
tables and their chains, both among themselves as well as in terms of
ordering with other parts of the network stack, or
b) not use the existing tables/chains with their pre-defined semantics
but rather start new 'tables' which can then have different semantics
as defined at the time of their implementation.
My apologies if I misunderstood something about bpfilter. Feel free to
correct me where I'm wrong. Thanks.
Regards,
Harald
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
^ permalink raw reply
* Re: [bpf-next v2 8/9] bpf: Provide helper to do forwarding lookups in kernel FIB table
From: David Miller @ 2018-05-07 15:36 UTC (permalink / raw)
To: dsahern
Cc: daniel, brouer, netdev, borkmann, ast, shm, roopa, toke,
john.fastabend
In-Reply-To: <4f3037fb-cf76-784f-bc7c-55e6e69104e9@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Mon, 7 May 2018 08:26:47 -0600
> On 5/7/18 8:10 AM, Daniel Borkmann wrote:
>> On 05/07/2018 03:35 PM, Jesper Dangaard Brouer wrote:
>>> On Thu, 3 May 2018 19:54:31 -0700 David Ahern <dsahern@gmail.com> wrote:
>>>
>>>> diff --git a/net/core/filter.c b/net/core/filter.c
>>>> index 6877426c23a6..cf0d27acf1d1 100644
>>>> --- a/net/core/filter.c
>>>> +++ b/net/core/filter.c
>>> [...]
>>>> +static const struct bpf_func_proto bpf_xdp_fib_lookup_proto = {
>>>> + .func = bpf_xdp_fib_lookup,
>>>> + .gpl_only = true,
>>>
>>> Is it a deliberate choice to require BPF-progs using this helper to be
>>> GPL licensed?
>>>
>>> Asking as this seems to be the first network related helper with this
>>> requirement, while this is typical for tracing related helpers.
>>
>> Good point, we should remove that. In networking it's only the perf event
>> output helpers tying into tracing bits. After all, if you do a route lookup
>> via netlink from user space there's no such restriction at all.
>>
>
> Networking symbols are typically exported GPL for modules. The person
> writing the code and exporting GPL is specifying a desire that only GPL
> licensed modules can link to the symbol.
>
> Given the common analogy of modules and bpf programs, why can't a writer
> of a bpf helper specify a preference that only GPL licensed programs
> leverage a BPF helper?
I also think that for this particular set of helpers GPL is appropriate.
Yes, via netlink the same lookup can happen, but not with the same level
of performance and microsecond tuning we've done over the years on this
sophisticated trie lookup code.
Therefore, I think David's choice is very appropriate.
^ permalink raw reply
* INFO: task hung in flush_work
From: syzbot @ 2018-05-07 15:47 UTC (permalink / raw)
To: davem, linux-kernel, linux-s390, netdev, syzkaller-bugs, ubraun
Hello,
syzbot found the following crash on:
HEAD commit: 8fb11a9a8d51 net/ipv6: rename rt6_next to fib6_next
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12ca275b800000
kernel config: https://syzkaller.appspot.com/x/.config?x=c416c61f3cd96be
dashboard link: https://syzkaller.appspot.com/bug?extid=2e7b6af5956e05e5cff7
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2e7b6af5956e05e5cff7@syzkaller.appspotmail.com
netlink: 4 bytes leftover after parsing attributes in process
`syz-executor7'.
netlink: 4 bytes leftover after parsing attributes in process
`syz-executor7'.
INFO: task syz-executor4:17145 blocked for more than 120 seconds.
Not tainted 4.17.0-rc3+ #33
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor4 D21736 17145 4542 0x80000002
Call Trace:
context_switch kernel/sched/core.c:2848 [inline]
__schedule+0x801/0x1e30 kernel/sched/core.c:3490
schedule+0xef/0x430 kernel/sched/core.c:3549
schedule_timeout+0x1b5/0x240 kernel/time/timer.c:1777
do_wait_for_common kernel/sched/completion.c:83 [inline]
__wait_for_common kernel/sched/completion.c:104 [inline]
wait_for_common kernel/sched/completion.c:115 [inline]
wait_for_completion+0x3e7/0x870 kernel/sched/completion.c:136
flush_work+0x531/0x900 kernel/workqueue.c:2903
smc_close_active+0x618/0x9c0 net/smc/smc_close.c:189
smc_release+0x46b/0x610 net/smc/af_smc.c:141
sock_release+0x96/0x1b0 net/socket.c:594
sock_close+0x16/0x20 net/socket.c:1149
__fput+0x34d/0x890 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:243
task_work_run+0x1e4/0x290 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x1aee/0x2730 kernel/exit.c:865
do_group_exit+0x16f/0x430 kernel/exit.c:968
get_signal+0x886/0x1960 kernel/signal.c:2469
do_signal+0x98/0x2040 arch/x86/kernel/signal.c:810
exit_to_usermode_loop+0x28a/0x310 arch/x86/entry/common.c:162
prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
do_syscall_64+0x6ac/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x455979
RSP: 002b:00007f4181b74ce8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: fffffffffffffe00 RBX: 000000000072bf78 RCX: 0000000000455979
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000072bf78
RBP: 000000000072bf78 R08: 0000000000000000 R09: 000000000072bf50
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000a3e81f R14: 00007f4181b759c0 R15: 0000000000000001
Showing all locks held in the system:
2 locks held by khungtaskd/894:
#0: 000000002a4a1b2a (rcu_read_lock){....}, at:
check_hung_uninterruptible_tasks kernel/hung_task.c:175 [inline]
#0: 000000002a4a1b2a (rcu_read_lock){....}, at: watchdog+0x1ff/0xf60
kernel/hung_task.c:249
#1: 00000000472c3276 (tasklist_lock){.+.+}, at:
debug_show_all_locks+0xde/0x34a kernel/locking/lockdep.c:4470
2 locks held by getty/4468:
#0: 0000000065ad3d93 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 00000000bfe7ad12 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4469:
#0: 000000006f6b456f (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 00000000d44cbfd2 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4470:
#0: 0000000039a0b4b8 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 00000000422d9092 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4471:
#0: 0000000049ab501c (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 00000000b1883d82 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4472:
#0: 00000000e473e0f9 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 00000000d6a5f6ee (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4473:
#0: 00000000af39adc0 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 000000005b852d11 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4474:
#0: 00000000b68f2084 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 0000000034e0241f (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by kworker/0:3/4924:
#0: 0000000053ed24fb ((wq_completion)"events"){+.+.}, at:
__write_once_size include/linux/compiler.h:215 [inline]
#0: 0000000053ed24fb ((wq_completion)"events"){+.+.}, at:
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
#0: 0000000053ed24fb ((wq_completion)"events"){+.+.}, at: atomic64_set
include/asm-generic/atomic-instrumented.h:40 [inline]
#0: 0000000053ed24fb ((wq_completion)"events"){+.+.}, at: atomic_long_set
include/asm-generic/atomic-long.h:57 [inline]
#0: 0000000053ed24fb ((wq_completion)"events"){+.+.}, at: set_work_data
kernel/workqueue.c:617 [inline]
#0: 0000000053ed24fb ((wq_completion)"events"){+.+.}, at:
set_work_pool_and_clear_pending kernel/workqueue.c:644 [inline]
#0: 0000000053ed24fb ((wq_completion)"events"){+.+.}, at:
process_one_work+0xaef/0x1b50 kernel/workqueue.c:2116
#1: 000000008a2387f6 ((work_completion)(&smc->tcp_listen_work)){+.+.}, at:
process_one_work+0xb46/0x1b50 kernel/workqueue.c:2120
2 locks held by kworker/1:5/15372:
#0: 0000000053ed24fb ((wq_completion)"events"){+.+.}, at:
__write_once_size include/linux/compiler.h:215 [inline]
#0: 0000000053ed24fb ((wq_completion)"events"){+.+.}, at:
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
#0: 0000000053ed24fb ((wq_completion)"events"){+.+.}, at: atomic64_set
include/asm-generic/atomic-instrumented.h:40 [inline]
#0: 0000000053ed24fb ((wq_completion)"events"){+.+.}, at: atomic_long_set
include/asm-generic/atomic-long.h:57 [inline]
#0: 0000000053ed24fb ((wq_completion)"events"){+.+.}, at: set_work_data
kernel/workqueue.c:617 [inline]
#0: 0000000053ed24fb ((wq_completion)"events"){+.+.}, at:
set_work_pool_and_clear_pending kernel/workqueue.c:644 [inline]
#0: 0000000053ed24fb ((wq_completion)"events"){+.+.}, at:
process_one_work+0xaef/0x1b50 kernel/workqueue.c:2116
#1: 00000000c29cd536 ((work_completion)(&smc->tcp_listen_work)){+.+.}, at:
process_one_work+0xb46/0x1b50 kernel/workqueue.c:2120
1 lock held by syz-executor5/18174:
#0: 00000000fe93fbb2 (sk_lock-AF_INET6){+.+.}, at: lock_sock
include/net/sock.h:1474 [inline]
#0: 00000000fe93fbb2 (sk_lock-AF_INET6){+.+.}, at:
tls_sw_sendmsg+0x1b9/0x12b0 net/tls/tls_sw.c:384
=============================================
NMI backtrace for cpu 1
CPU: 1 PID: 894 Comm: khungtaskd Not tainted 4.17.0-rc3+ #33
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+0x1b9/0x294 lib/dump_stack.c:113
nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103
nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62
arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
trigger_all_cpu_backtrace include/linux/nmi.h:138 [inline]
check_hung_task kernel/hung_task.c:132 [inline]
check_hung_uninterruptible_tasks kernel/hung_task.c:190 [inline]
watchdog+0xc10/0xf60 kernel/hung_task.c:249
kthread+0x345/0x410 kernel/kthread.c:238
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.17.0-rc3+ #33
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:activate_task+0x0/0x2e0 kernel/sched/core.c:704
RSP: 0018:ffff8801dae07570 EFLAGS: 00000007
RAX: 0000000000000000 RBX: ffff8801d9a9e240 RCX: ffff8801dae07728
RDX: 0000000000000009 RSI: ffff8801d9a9e240 RDI: ffff8801dae2c680
RBP: ffff8801dae07598 R08: ffff88021fff8018 R09: 0000000000000000
R10: ffffed0043fff001 R11: ffff88021fff8017 R12: ffff8801dae2c680
R13: 0000000000000000 R14: ffff8801dae07728 R15: ffff8801dae07728
FS: 0000000000000000(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffff600400 CR3: 00000001b5403000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<IRQ>
ttwu_queue kernel/sched/core.c:1840 [inline]
try_to_wake_up+0x870/0x1190 kernel/sched/core.c:2053
wake_up_process+0x10/0x20 kernel/sched/core.c:2126
process_timeout+0x31/0x40 kernel/time/timer.c:1730
call_timer_fn+0x230/0x940 kernel/time/timer.c:1326
expire_timers kernel/time/timer.c:1363 [inline]
__run_timers+0x79e/0xc50 kernel/time/timer.c:1666
run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692
__do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
invoke_softirq kernel/softirq.c:365 [inline]
irq_exit+0x1d1/0x200 kernel/softirq.c:405
exiting_irq arch/x86/include/asm/apic.h:525 [inline]
smp_apic_timer_interrupt+0x17e/0x710 arch/x86/kernel/apic/apic.c:1052
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
</IRQ>
RIP: 0010:native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:54
RSP: 0018:ffffffff88c07bc0 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff13
RAX: dffffc0000000000 RBX: 1ffffffff1180f7b RCX: 0000000000000000
RDX: 1ffffffff11a3170 RSI: 0000000000000001 RDI: ffffffff88d18b80
RBP: ffffffff88c07bc0 R08: ffffed003b5c46c3 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffffffff88c07c78 R14: ffffffff897c2260 R15: 0000000000000000
arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
default_idle+0xc2/0x440 arch/x86/kernel/process.c:354
arch_cpu_idle+0x10/0x20 arch/x86/kernel/process.c:345
default_idle_call+0x6d/0x90 kernel/sched/idle.c:93
cpuidle_idle_call kernel/sched/idle.c:153 [inline]
do_idle+0x395/0x560 kernel/sched/idle.c:262
cpu_startup_entry+0x104/0x120 kernel/sched/idle.c:368
rest_init+0xe1/0xe4 init/main.c:441
start_kernel+0x906/0x92d init/main.c:737
x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:445
x86_64_start_kernel+0x76/0x79 arch/x86/kernel/head64.c:426
secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:242
Code: 89 45 d0 e8 33 d1 63 00 48 8b 4d c8 4c 8b 45 d0 e9 2f ff ff ff 66 0f
1f 44 00 00 55 48 89 e5 e8 a7 51 ff ff 5d c3 0f 1f 44 00 00 <48> b8 00 00
00 00 00 fc ff df 55 48 89 e5 41 56 41 55 4c 8d 6e
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* Re: [PATCH v2 net-next 2/4] net: add skeleton of bpfilter kernel module
From: David Miller @ 2018-05-07 15:50 UTC (permalink / raw)
To: laforge
Cc: ast, daniel, torvalds, gregkh, luto, netdev, linux-kernel,
kernel-team
In-Reply-To: <20180507152435.GE19042@nataraja>
From: Harald Welte <laforge@gnumonks.org>
Date: Mon, 7 May 2018 17:24:35 +0200
> But if the ruleset loads but behaves different than before (because e.g.
> it's executed from a completely different place in the stack), that's
> IMHO an absolute no-go that must be avoided at all cost.
That's not what we are doing nor proposing. I'm sorry if you are
confused on this matter.
The base implementation we strive for will execute the BPF programs
from the existing netfilter hook points.
However, if semantically the effect is equal if we execute the BPF
program from XDP, we will allow that to happen as an optimization.
The BPF exection is where it is in these patches for the purposes of
bootstrapping the bpfilter project and easy testing/benchmarking/hacking.
I hope this clears up your confusion.
If you would like to become involved in hacking on bpfilter to help us
ensure more accurate compatability between existing iptables and what
bpfilter will execute for the same rule sets, we very much look
forward to your contributions and expertiece.
Thank you.
^ permalink raw reply
* [PATCH v3 0/1] multi-threading device shutdown
From: Pavel Tatashin @ 2018-05-07 15:54 UTC (permalink / raw)
To: pasha.tatashin, steven.sistare, daniel.m.jordan, linux-kernel,
jeffrey.t.kirsher, intel-wired-lan, netdev, gregkh,
alexander.duyck, tobin
Changelog
v2 - v3
- Fixed warning from kbuild test.
- Moved device_lock/device_unlock inside device_shutdown_tree().
v1 - v2
- It turns out we cannot lock more than MAX_LOCK_DEPTH by a single
thread. (By default this value is 48), and is used to detect
deadlocks. So, I re-wrote the code to only lock one devices per
thread instead of pre-locking all devices by the main thread.
- Addressed comments from Tobin C. Harding.
- As suggested by Alexander Duyck removed ixgbe changes. It can be
done as a separate work scaling RTNL mutex.
Do a faster shutdown by calling dev->*->shutdown(dev) in parallel.
device_shutdown() calls these functions for every single device but
only using one thread.
Since, nothing else is running on the machine by the device_shutdown()
s called, there is no reason not to utilize all the available CPU
resources.
Pavel Tatashin (1):
drivers core: multi-threading device shutdown
drivers/base/core.c | 275 ++++++++++++++++++++++++++++++++++++--------
1 file changed, 225 insertions(+), 50 deletions(-)
--
2.17.0
^ permalink raw reply
* [PATCH v3 1/1] drivers core: multi-threading device shutdown
From: Pavel Tatashin @ 2018-05-07 15:54 UTC (permalink / raw)
To: pasha.tatashin, steven.sistare, daniel.m.jordan, linux-kernel,
jeffrey.t.kirsher, intel-wired-lan, netdev, gregkh,
alexander.duyck, tobin
In-Reply-To: <20180507155402.10086-1-pasha.tatashin@oracle.com>
When system is rebooted, halted or kexeced device_shutdown() is
called.
This function shuts down every single device by calling either:
dev->bus->shutdown(dev)
dev->driver->shutdown(dev)
Even on a machine with just a moderate amount of devices, device_shutdown()
may take multiple seconds to complete. This is because many devices require
a specific delays to perform this operation.
Here is a sample analysis of time it takes to call device_shutdown() on a
two socket Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz machine.
device_shutdown 2.95s
-----------------------------
mlx4_shutdown 1.14s
megasas_shutdown 0.24s
ixgbe_shutdown 0.37s x 4 (four ixgbe devices on this machine).
the rest 0.09s
In mlx4 we spent the most time, but that is because there is a 1 second
sleep, which is defined by hardware specifications:
mlx4_shutdown
mlx4_unload_one
mlx4_free_ownership
msleep(1000)
With megasas we spend a quarter of a second, but sometimes longer (up-to
0.5s) in this path:
megasas_shutdown
megasas_flush_cache
megasas_issue_blocked_cmd
wait_event_timeout
Finally, with ixgbe_shutdown() it takes 0.37 for each device, but that time
is spread all over the place, with bigger offenders:
ixgbe_shutdown
__ixgbe_shutdown
ixgbe_close_suspend
ixgbe_down
ixgbe_init_hw_generic
ixgbe_reset_hw_X540
msleep(100); 0.104483472
ixgbe_get_san_mac_addr_generic 0.048414851
ixgbe_get_wwn_prefix_generic 0.048409893
ixgbe_start_hw_X540
ixgbe_start_hw_generic
ixgbe_clear_hw_cntrs_generic 0.048581502
ixgbe_setup_fc_generic 0.024225800
All the ixgbe_*generic functions end-up calling:
ixgbe_read_eerd_X540()
ixgbe_acquire_swfw_sync_X540
usleep_range(5000, 6000);
ixgbe_release_swfw_sync_X540
usleep_range(5000, 6000);
While these are short sleeps, they end-up calling them over 24 times!
24 * 0.0055s = 0.132s. Adding-up to 0.528s for four devices. Also we have
four msleep(100). Totaling to: 0.928s
While we should keep optimizing the individual device drivers, in some
cases this is simply a hardware property that forces a specific delay, and
we must wait.
So, the solution for this problem is to shutdown devices in parallel.
However, we must shutdown children before shutting down parents, so parent
device must wait for its children to finish.
With this patch, on the same machine devices_shutdown() takes 1.142s, and
without mlx4 one second delay only 0.38s
Signed-off-by: Pavel Tatashin <pasha.tatashin@oracle.com>
---
drivers/base/core.c | 275 ++++++++++++++++++++++++++++++++++++--------
1 file changed, 225 insertions(+), 50 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index b610816eb887..1f9fda42a968 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -25,6 +25,7 @@
#include <linux/netdevice.h>
#include <linux/sched/signal.h>
#include <linux/sysfs.h>
+#include <linux/kthread.h>
#include "base.h"
#include "power/power.h"
@@ -2102,6 +2103,59 @@ const char *device_get_devnode(struct device *dev,
return *tmp = s;
}
+/**
+ * device_children_count - device children count
+ * @parent: parent struct device.
+ *
+ * Returns number of children for this device or 0 if none.
+ */
+static int device_children_count(struct device *parent)
+{
+ struct klist_iter i;
+ int children = 0;
+
+ if (!parent->p)
+ return 0;
+
+ klist_iter_init(&parent->p->klist_children, &i);
+ while (next_device(&i))
+ children++;
+ klist_iter_exit(&i);
+
+ return children;
+}
+
+/**
+ * device_get_child_by_index - Return child using the provided index.
+ * @parent: parent struct device.
+ * @index: Index of the child, where 0 is the first child in the children list,
+ * and so on.
+ *
+ * Returns child or NULL if child with this index is not present.
+ */
+static struct device *
+device_get_child_by_index(struct device *parent, int index)
+{
+ struct klist_iter i;
+ struct device *dev = NULL, *d;
+ int child_index = 0;
+
+ if (!parent->p || index < 0)
+ return NULL;
+
+ klist_iter_init(&parent->p->klist_children, &i);
+ while ((d = next_device(&i))) {
+ if (child_index == index) {
+ dev = d;
+ break;
+ }
+ child_index++;
+ }
+ klist_iter_exit(&i);
+
+ return dev;
+}
+
/**
* device_for_each_child - device child iterator.
* @parent: parent struct device.
@@ -2765,71 +2819,192 @@ int device_move(struct device *dev, struct device *new_parent,
}
EXPORT_SYMBOL_GPL(device_move);
+/*
+ * device_shutdown_one - call ->shutdown() for the device passed as
+ * argument.
+ */
+static void device_shutdown_one(struct device *dev)
+{
+ /* Don't allow any more runtime suspends */
+ pm_runtime_get_noresume(dev);
+ pm_runtime_barrier(dev);
+
+ if (dev->class && dev->class->shutdown_pre) {
+ if (initcall_debug)
+ dev_info(dev, "shutdown_pre\n");
+ dev->class->shutdown_pre(dev);
+ }
+ if (dev->bus && dev->bus->shutdown) {
+ if (initcall_debug)
+ dev_info(dev, "shutdown\n");
+ dev->bus->shutdown(dev);
+ } else if (dev->driver && dev->driver->shutdown) {
+ if (initcall_debug)
+ dev_info(dev, "shutdown\n");
+ dev->driver->shutdown(dev);
+ }
+
+ /* decrement the reference counter */
+ put_device(dev);
+}
+
+/**
+ * Passed as an argument to device_shutdown_child_task().
+ * child_next_index the next available child index.
+ * tasks_running number of tasks still running. Each tasks decrements it
+ * when job is finished and the last task signals that the
+ * job is complete.
+ * complete Used to signal job competition.
+ * parent Parent device.
+ */
+struct device_shutdown_task_data {
+ atomic_t child_next_index;
+ atomic_t tasks_running;
+ struct completion complete;
+ struct device *parent;
+};
+
+static int device_shutdown_child_task(void *data);
+
+/**
+ * These globals are used by tasks that are started for root devices.
+ * device_root_tasks_finished Number of root devices finished shutting down.
+ * device_root_tasks_started Total number of root devices tasks started.
+ * device_root_tasks_done The completion signal to the main thread.
+ */
+static atomic_t device_root_tasks_finished;
+static atomic_t device_root_tasks_started;
+static struct completion device_root_tasks_done;
+
+/**
+ * Shutdown device tree with root started in dev. If dev has no children
+ * simply shutdown only this device. If dev has children recursively shutdown
+ * children first, and only then the parent. For performance reasons children
+ * are shutdown in parallel using kernel threads. because we lock dev its
+ * children cannot be removed while this functions is running.
+ */
+static void device_shutdown_tree(struct device *dev)
+{
+ int children_count;
+
+ device_lock(dev);
+ children_count = device_children_count(dev);
+
+ if (children_count) {
+ struct device_shutdown_task_data tdata;
+ int i;
+
+ init_completion(&tdata.complete);
+ atomic_set(&tdata.child_next_index, 0);
+ atomic_set(&tdata.tasks_running, children_count);
+ tdata.parent = dev;
+
+ for (i = 0; i < children_count; i++) {
+ kthread_run(device_shutdown_child_task,
+ &tdata, "device_shutdown.%s",
+ dev_name(dev));
+ }
+ wait_for_completion(&tdata.complete);
+ }
+ device_shutdown_one(dev);
+ device_unlock(dev);
+}
+
+/**
+ * Only devices with parent are going through this function. The parent is
+ * locked and waits for all of its children to finish shutting down before
+ * calling shutdown function for itself.
+ */
+static int device_shutdown_child_task(void *data)
+{
+ struct device_shutdown_task_data *tdata = data;
+ int cidx = atomic_inc_return(&tdata->child_next_index) - 1;
+ struct device *dev = device_get_child_by_index(tdata->parent, cidx);
+
+ /* ref. counter is going to be decremented in device_shutdown_one() */
+ get_device(dev);
+ device_shutdown_tree(dev);
+
+ /* If we are the last to exit, signal the completion */
+ if (atomic_dec_return(&tdata->tasks_running) == 0)
+ complete(&tdata->complete);
+ return 0;
+}
+
+/**
+ * On shutdown each root device (the one that does not have a parent) goes
+ * through this function.
+ */
+static int device_shutdown_root_task(void *data)
+{
+ struct device *dev = (struct device *)data;
+ int root_devices;
+
+ device_shutdown_tree(dev);
+
+ /* If we are the last to exit, signal the completion */
+ root_devices = atomic_inc_return(&device_root_tasks_finished);
+ if (root_devices == atomic_read(&device_root_tasks_started))
+ complete(&device_root_tasks_done);
+ return 0;
+}
+
/**
* device_shutdown - call ->shutdown() on each device to shutdown.
*/
void device_shutdown(void)
{
- struct device *dev, *parent;
+ int root_devices = 0;
+ struct device *dev;
- spin_lock(&devices_kset->list_lock);
- /*
- * Walk the devices list backward, shutting down each in turn.
- * Beware that device unplug events may also start pulling
- * devices offline, even as the system is shutting down.
+ atomic_set(&device_root_tasks_finished, 0);
+ atomic_set(&device_root_tasks_started, 0);
+ init_completion(&device_root_tasks_done);
+
+ /* Shutdown the root devices in parallel. The children are going to be
+ * shutdown first in device_shutdown_tree().
*/
+ spin_lock(&devices_kset->list_lock);
while (!list_empty(&devices_kset->list)) {
- dev = list_entry(devices_kset->list.prev, struct device,
- kobj.entry);
+ dev = list_entry(devices_kset->list.next, struct device,
+ kobj.entry);
- /*
- * hold reference count of device's parent to
- * prevent it from being freed because parent's
- * lock is to be held
- */
- parent = get_device(dev->parent);
- get_device(dev);
- /*
- * Make sure the device is off the kset list, in the
- * event that dev->*->shutdown() doesn't remove it.
+ /* Make sure the device is off the kset list, in the event that
+ * dev->*->shutdown() doesn't remove it.
*/
list_del_init(&dev->kobj.entry);
- spin_unlock(&devices_kset->list_lock);
-
- /* hold lock to avoid race with probe/release */
- if (parent)
- device_lock(parent);
- device_lock(dev);
-
- /* Don't allow any more runtime suspends */
- pm_runtime_get_noresume(dev);
- pm_runtime_barrier(dev);
- if (dev->class && dev->class->shutdown_pre) {
- if (initcall_debug)
- dev_info(dev, "shutdown_pre\n");
- dev->class->shutdown_pre(dev);
+ /* Here we start tasks for root devices only */
+ if (!dev->parent) {
+ /* Prevents devices from being freed. The counter is
+ * going to be decremented in device_shutdown_one() once
+ * this root device is shutdown.
+ */
+ get_device(dev);
+
+ /* We unlock list for performance reasons,
+ * dev->*->shutdown(), may try to take this lock to
+ * remove us from kset list. To avoid unlocking this
+ * list we could replace spin lock in:
+ * dev->kobj.kset->list_lock with a dummy one once
+ * device is locked in device_shutdown_root_task() and
+ * in device_shutdown_child_task().
+ */
+ spin_unlock(&devices_kset->list_lock);
+
+ root_devices++;
+ kthread_run(device_shutdown_root_task,
+ dev, "device_root_shutdown.%s",
+ dev_name(dev));
+ spin_lock(&devices_kset->list_lock);
}
- if (dev->bus && dev->bus->shutdown) {
- if (initcall_debug)
- dev_info(dev, "shutdown\n");
- dev->bus->shutdown(dev);
- } else if (dev->driver && dev->driver->shutdown) {
- if (initcall_debug)
- dev_info(dev, "shutdown\n");
- dev->driver->shutdown(dev);
- }
-
- device_unlock(dev);
- if (parent)
- device_unlock(parent);
-
- put_device(dev);
- put_device(parent);
-
- spin_lock(&devices_kset->list_lock);
}
spin_unlock(&devices_kset->list_lock);
+
+ /* Set number of root tasks started, and waits for completion */
+ atomic_set(&device_root_tasks_started, root_devices);
+ if (root_devices != atomic_read(&device_root_tasks_finished))
+ wait_for_completion(&device_root_tasks_done);
}
/*
--
2.17.0
^ permalink raw reply related
* Re: pull request: bluetooth 2018-05-07
From: David Miller @ 2018-05-07 15:56 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth, netdev
In-Reply-To: <20180507150533.GA2927@x1c.home>
From: Johan Hedberg <johan.hedberg@gmail.com>
Date: Mon, 7 May 2018 18:05:33 +0300
> Here are a few more Bluetooth fixes for the 4.17 kernel, all for the
> btusb driver. Two relate to the needs_reset_resume table, and one is a
> revert of a patch for Atheros 1525/QCA6174 which caused a regression for
> some people.
>
> Please let me know if there are any issues pulling. Thanks.
Pulled, thanks Johan.
^ permalink raw reply
* [PATCH net] llc: better deal with too small mtu
From: Eric Dumazet @ 2018-05-07 16:02 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet
syzbot loves to set very small mtu on devices, since it brings joy.
We must make llc_ui_sendmsg() fool proof.
usercopy: Kernel memory overwrite attempt detected to wrapped address (offset 0, size 18446612139802320068)!
kernel BUG at mm/usercopy.c:100!
invalid opcode: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 17464 Comm: syz-executor1 Not tainted 4.17.0-rc3+ #36
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:usercopy_abort+0xbb/0xbd mm/usercopy.c:88
RSP: 0018:ffff8801868bf800 EFLAGS: 00010282
RAX: 000000000000006c RBX: ffffffff87d2fb00 RCX: 0000000000000000
RDX: 000000000000006c RSI: ffffffff81610731 RDI: ffffed0030d17ef6
RBP: ffff8801868bf858 R08: ffff88018daa4200 R09: ffffed003b5c4fb0
R10: ffffed003b5c4fb0 R11: ffff8801dae27d87 R12: ffffffff87d2f8e0
R13: ffffffff87d2f7a0 R14: ffffffff87d2f7a0 R15: ffffffff87d2f7a0
FS: 00007f56a14ac700(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2bc21000 CR3: 00000001abeb1000 CR4: 00000000001426f0
DR0: 0000000020000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000030602
Call Trace:
check_bogus_address mm/usercopy.c:153 [inline]
__check_object_size+0x5d9/0x5d9 mm/usercopy.c:256
check_object_size include/linux/thread_info.h:108 [inline]
check_copy_size include/linux/thread_info.h:139 [inline]
copy_from_iter_full include/linux/uio.h:121 [inline]
memcpy_from_msg include/linux/skbuff.h:3305 [inline]
llc_ui_sendmsg+0x4b1/0x1530 net/llc/af_llc.c:941
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:639
__sys_sendto+0x3d7/0x670 net/socket.c:1789
__do_sys_sendto net/socket.c:1801 [inline]
__se_sys_sendto net/socket.c:1797 [inline]
__x64_sys_sendto+0xe1/0x1a0 net/socket.c:1797
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x455979
RSP: 002b:00007f56a14abc68 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00007f56a14ac6d4 RCX: 0000000000455979
RDX: 0000000000000000 RSI: 0000000020000000 RDI: 0000000000000018
RBP: 000000000072bea0 R08: 00000000200012c0 R09: 0000000000000010
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000000548 R14: 00000000006fbf60 R15: 0000000000000000
Code: 55 c0 e8 c0 55 bb ff ff 75 c8 48 8b 55 c0 4d 89 f9 ff 75 d0 4d 89 e8 48 89 d9 4c 89 e6 41 56 48 c7 c7 80 fa d2 87 e8 a0 0b a3 ff <0f> 0b e8 95 55 bb ff e8 c0 a8 f7 ff 8b 95 14 ff ff ff 4d 89 e8
RIP: usercopy_abort+0xbb/0xbd mm/usercopy.c:88 RSP: ffff8801868bf800
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
---
net/llc/af_llc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/llc/af_llc.c b/net/llc/af_llc.c
index cb80ebb38311e7db1e91881cdec59bc33724d856..1beeea9549fa6ec1f7b0e5f9af8ff3250a316f59 100644
--- a/net/llc/af_llc.c
+++ b/net/llc/af_llc.c
@@ -930,6 +930,9 @@ static int llc_ui_sendmsg(struct socket *sock, struct msghdr *msg, size_t len)
if (size > llc->dev->mtu)
size = llc->dev->mtu;
copied = size - hdrlen;
+ rc = -EINVAL;
+ if (copied < 0)
+ goto release;
release_sock(sk);
skb = sock_alloc_send_skb(sk, size, noblock, &rc);
lock_sock(sk);
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* Re: The SO_BINDTODEVICE was set to the desired interface, but packets are received from all interfaces.
From: Ben Greear @ 2018-05-07 16:14 UTC (permalink / raw)
To: Damir Mansurov, netdev
Cc: Konstantin Ushakov, Alexandra N. Kossovsky, Andrey Dmitrov
In-Reply-To: <5a61e34b-75c2-0452-d6e2-6e4ea77d5ac2@oktetlabs.ru>
On 05/07/2018 03:19 AM, Damir Mansurov wrote:
>
> Greetings,
>
> After successful call of the setsockopt(SO_BINDTODEVICE) function to set data reception from only one interface, the data is still received from all interfaces.
> Function setsockopt() returns 0 but then recv() receives data from all available network interfaces.
>
> The problem is reproducible on linux kernels 4.14 - 4.16, but it does not on linux kernels 4.4, 4.13.
>
> I have written C-code to reproduce this issue (see attached files b2d_send.c and b2d_recv.c). See below explanation of tested configuration.
Hello,
I am not sure if this is your problem or not, but if you are using VRF, then you need
to call SO_BINDTODEVICE before you do the 'normal' bind() call.
Thanks,
Ben
>
>
> PC-1 PC-2
> ------------------- -------------------
> | b2d_send | | b2d_recv |
> | | | |
> | ------| |------ |
> | | eth0 |---------------| eth0 | |
> | ------| |------ |
> | | | |
> | ------| |------ |
> | | eth1 |---------------| eth1 | |
> | ------| |------ |
> | | | |
> ------------------- -------------------
>
> Steps:
> 1. Copy b2d_recv.c to PC-2, compile it ("gcc -o b2d_recv b2d_recv.c") and run "./b2d_recv eth0 23777" to get derived data only from eth0 interface. Port number
> in this example is 23777 only for sample.
>
> 2. Copy b2d_send.c to PC-1, compile it ("gcc -o b2d_send b2d_send.c") and run "./b2d_send ip1 ip2 23777" where ip1 and ip2 are ip addresses of interfaces eth0
> and eth1 of PC-2.
>
> 3. Result:
> - b2d_recv prints out data from eth0 and eth1 on linux kernels from 4.14 up to 4.16.
> - b2d_recv prints out data from only eth0 on linux kernels below 4.14.
>
>
> ******************
> Thanks,
> Damir Mansurov
> dnman@oktetlabs.ru
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: linux-next: Tree for May 7 (net/xdp)
From: Randy Dunlap @ 2018-05-07 16:17 UTC (permalink / raw)
To: Stephen Rothwell, Linux-Next Mailing List
Cc: Linux Kernel Mailing List, netdev@vger.kernel.org,
Björn Töpel, Magnus Karlsson
In-Reply-To: <20180507153147.166ee38a@canb.auug.org.au>
On 05/06/2018 10:31 PM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20180504:
>
on i386:
net/xdp/xdp_umem.o: In function `xdp_umem_reg':
xdp_umem.c:(.text+0x47e): undefined reference to `__udivdi3'
--
~Randy
^ permalink raw reply
* Re: [PATCH RFC net-next] net: ipvs: Adjust gso_size for IPPROTO_TCP
From: Martin KaFai Lau @ 2018-05-07 16:22 UTC (permalink / raw)
To: Julian Anastasov
Cc: netdev, David Ahern, Tom Herbert, Eric Dumazet, Nikita Shirokov,
kernel-team, lvs-devel
In-Reply-To: <alpine.LFD.2.20.1805051515450.1895@ja.home.ssi.bg>
On Sat, May 05, 2018 at 03:58:25PM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Thu, 3 May 2018, Martin KaFai Lau wrote:
>
> > > - when exactly we start to use the new PMTU, eg. what happens
> > > in case socket caches the route, whether route is killed via
> > > dst->obsolete. Or may be while the PMTU expiration is handled
> > > per-packet, the PMTU change is noticed only on ICMP...
> > Before sk can reuse its dst cache, the sk will notice
> > its dst cache is no longer valid by calling dst_check().
> > dst_check() should return NULL which is one of the side
> > effect of the earlier update_pmtu(). This dst_check()
> > is usually only called when the sk needs to do output,
> > so the new PMTU route (i.e. the RTF_CACHE IPv6 route)
> > only have effect to the later packets.
>
> I checked again the code and it looks like sockets
> are forced to use new exceptional route (RTF_CACHE/fnhe) via
> dst_check only when the PMTU update should move them away
> from old non-exceptional routes. Later, if PMTU is
> reduced/updated this is noticed for every packet via dst_mtu,
> as in the case with TCP.
>
> So, except the RTF_LOCAL check in __ip6_rt_update_pmtu
> we should have no other issues. Only one minor bit is strange to me,
> why rt6_insert_exception warns for RTF_PCPU if rt6_cache_allowed_for_pmtu
> allows it when returning true...
hmm...I am not sure I follow this bits. Where is the warn?
Note that "nrt6" and "from" are passed to rt6_insert_exception()
instead of "rt6".
>
> Also, commit 0d3f6d297bfb allows rt6_do_update_pmtu() for
> routes without RTF_CACHE, RTF_PCPU and rt6i_node. Should we
> restrict rt6_do_update_pmtu only to RTF_CACHE routes?
>
> if (!rt6_cache_allowed_for_pmtu(rt6)) {
> - rt6_do_update_pmtu(rt6, mtu);
The existing rt6_do_update_pmtu() looks correct.
The mtu of the dst created by icmp6_dst_alloc()
needs to be udpated and this dst does not have
the RTF_CACHE.
> - /* update rt6_ex->stamp for cache */
> - if (rt6->rt6i_flags & RTF_CACHE)
> + if (rt6->rt6i_flags & RTF_CACHE) {
> + rt6_do_update_pmtu(rt6, mtu);
> + /* update rt6_ex->stamp for cache */
> rt6_update_exception_stamp_rt(rt6);
> + }
> } else if (daddr) {
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* 3c59x: Transmit timeouts
From: tedheadster @ 2018-05-07 16:26 UTC (permalink / raw)
To: klassert, netdev
Steffen,
I am getting mostly transmit errors on a 3c597 Fast Ethernet card.
It is EISA, not PCI. Here is some of the logs with verbosity turned up
a bit:
eth3: using default media 100baseTX
[372] eth3: Initial media type 100baseTX.
eth3: setting half-duplex.
[372] eth3: vortex_up() irq 9 media status 8882.
<intr> eth3: Media 100baseTX has link beat, 8882.
eth3: transmit timed out, tx_status 00 status 8000.
diagnostics: net 0c80 media 8882 dma ffffffff fifo 0000
eth3: transmit timed out, tx_status 00 status 8000.
diagnostics: net 0c80 media 8882 dma ffffffff fifo 0000
eth3: transmit timed out, tx_status 00 status 8000.
diagnostics: net 0c80 media 8882 dma ffffffff fifo 0000
eth3: transmit timed out, tx_status 00 status 8000.
diagnostics: net 0c80 media 8882 dma ffffffff fifo 0000
[378] eth3: vortex_close() status 8000, Tx status 00.
[378] eth3: vortex close stats: rx_nocopy 0 rx_copy 0 tx_queued 0 Rx
pre-checksummed 0.
Here is what I got from the registers:
NetworkDiagnostic (net): txEnabled, rxEnabled, statisticsEnabled
MediaStatus (media): auiDisable, linkBeatDetect, linkBeatEnable, crcStripDisable
IntStatus (status): register window 4 selected
I am seeing /proc/interrupts incrementing, so at least some interrupts
are getting to the card.
'tc -s qdisc' reports 4 requeues on 13 packets sent.
'ifconfig' reports 13 tx packets, 11 tx errors, 11 tx dropped (no
overrun, carrier, or collision errors).
I can do the legwork on debugging this. What should I investigate next?
- Matthew
^ permalink raw reply
* [iproute2-next 1/1] tipc: fixed node and name table listings
From: Jon Maloy @ 2018-05-07 16:32 UTC (permalink / raw)
To: stephen, netdev
Cc: mohan.krishna.ghanta.krishnamurthy, tung.q.nguyen, hoang.h.le,
jon.maloy, canh.d.luu, ying.xue, tipc-discussion
We make it easier for users to correlate between 128-bit node
identities and 32-bit node hash by extending the 'node list'
command to also show the hash value.
We also improve the 'nametable show' command to show the node identity
instead of the node hash value. Since the former potentially is much
longer than the latter, we make room for it by eliminating the (to the
user) irrelevant publication key. We also reorder some of the columns
so that the node id comes last, since this looks nicer and more logical.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
tipc/misc.c | 18 ++++++++++++++++++
tipc/misc.h | 1 +
tipc/nametable.c | 18 ++++++++++--------
tipc/node.c | 19 ++++++++-----------
tipc/peer.c | 4 ++++
5 files changed, 41 insertions(+), 19 deletions(-)
diff --git a/tipc/misc.c b/tipc/misc.c
index 16849f1..13dbaad 100644
--- a/tipc/misc.c
+++ b/tipc/misc.c
@@ -13,6 +13,9 @@
#include <stdint.h>
#include <linux/tipc.h>
#include <string.h>
+#include <sys/ioctl.h>
+#include <sys/socket.h>
+#include <errno.h>
#include "misc.h"
#define IN_RANGE(val, low, high) ((val) <= (high) && (val) >= (low))
@@ -109,3 +112,18 @@ void nodeid2str(uint8_t *id, char *str)
for (i = 31; str[i] == '0'; i--)
str[i] = 0;
}
+
+void hash2nodestr(uint32_t hash, char *str)
+{
+ struct tipc_sioc_nodeid_req nr = {};
+ int sd;
+
+ sd = socket(AF_TIPC, SOCK_RDM, 0);
+ if (sd < 0) {
+ fprintf(stderr, "opening TIPC socket: %s\n", strerror(errno));
+ return;
+ }
+ nr.peer = hash;
+ if (!ioctl(sd, SIOCGETNODEID, &nr))
+ nodeid2str(nr.node_id, str);
+}
diff --git a/tipc/misc.h b/tipc/misc.h
index 6e8afdd..ff2f31f 100644
--- a/tipc/misc.h
+++ b/tipc/misc.h
@@ -17,5 +17,6 @@
uint32_t str2addr(char *str);
int str2nodeid(char *str, uint8_t *id);
void nodeid2str(uint8_t *id, char *str);
+void hash2nodestr(uint32_t hash, char *str);
#endif
diff --git a/tipc/nametable.c b/tipc/nametable.c
index 2578940..ae73dfa 100644
--- a/tipc/nametable.c
+++ b/tipc/nametable.c
@@ -20,6 +20,7 @@
#include "cmdl.h"
#include "msg.h"
#include "nametable.h"
+#include "misc.h"
#define PORTID_STR_LEN 45 /* Four u32 and five delimiter chars */
@@ -31,6 +32,7 @@ static int nametable_show_cb(const struct nlmsghdr *nlh, void *data)
struct nlattr *attrs[TIPC_NLA_NAME_TABLE_MAX + 1] = {};
struct nlattr *publ[TIPC_NLA_PUBL_MAX + 1] = {};
const char *scope[] = { "", "zone", "cluster", "node" };
+ char str[33] = {0,};
mnl_attr_parse(nlh, sizeof(*genl), parse_attrs, info);
if (!info[TIPC_NLA_NAME_TABLE])
@@ -45,20 +47,20 @@ static int nametable_show_cb(const struct nlmsghdr *nlh, void *data)
return MNL_CB_ERROR;
if (!*iteration)
- printf("%-10s %-10s %-10s %-10s %-10s %-10s\n",
- "Type", "Lower", "Upper", "Node", "Port",
- "Publication Scope");
+ printf("%-10s %-10s %-10s %-8s %-10s %-33s\n",
+ "Type", "Lower", "Upper", "Scope", "Port",
+ "Node");
(*iteration)++;
- printf("%-10u %-10u %-10u %-10x %-10u %-12u",
+ hash2nodestr(mnl_attr_get_u32(publ[TIPC_NLA_PUBL_NODE]), str);
+
+ printf("%-10u %-10u %-10u %-8s %-10u %s\n",
mnl_attr_get_u32(publ[TIPC_NLA_PUBL_TYPE]),
mnl_attr_get_u32(publ[TIPC_NLA_PUBL_LOWER]),
mnl_attr_get_u32(publ[TIPC_NLA_PUBL_UPPER]),
- mnl_attr_get_u32(publ[TIPC_NLA_PUBL_NODE]),
+ scope[mnl_attr_get_u32(publ[TIPC_NLA_PUBL_SCOPE])],
mnl_attr_get_u32(publ[TIPC_NLA_PUBL_REF]),
- mnl_attr_get_u32(publ[TIPC_NLA_PUBL_KEY]));
-
- printf("%s\n", scope[mnl_attr_get_u32(publ[TIPC_NLA_PUBL_SCOPE])]);
+ str);
return MNL_CB_OK;
}
diff --git a/tipc/node.c b/tipc/node.c
index b73b644..0fa1064 100644
--- a/tipc/node.c
+++ b/tipc/node.c
@@ -26,10 +26,11 @@
static int node_list_cb(const struct nlmsghdr *nlh, void *data)
{
- uint32_t addr;
struct genlmsghdr *genl = mnl_nlmsg_get_payload(nlh);
struct nlattr *info[TIPC_NLA_MAX + 1] = {};
struct nlattr *attrs[TIPC_NLA_NODE_MAX + 1] = {};
+ char str[33] = {};
+ uint32_t addr;
mnl_attr_parse(nlh, sizeof(*genl), parse_attrs, info);
if (!info[TIPC_NLA_NODE])
@@ -40,13 +41,12 @@ static int node_list_cb(const struct nlmsghdr *nlh, void *data)
return MNL_CB_ERROR;
addr = mnl_attr_get_u32(attrs[TIPC_NLA_NODE_ADDR]);
- printf("%x: ", addr);
-
+ hash2nodestr(addr, str);
+ printf("%-32s %08x ", str, addr);
if (attrs[TIPC_NLA_NODE_UP])
printf("up\n");
else
printf("down\n");
-
return MNL_CB_OK;
}
@@ -64,7 +64,7 @@ static int cmd_node_list(struct nlmsghdr *nlh, const struct cmd *cmd,
fprintf(stderr, "error, message initialisation failed\n");
return -1;
}
-
+ printf("Node Identity Hash State\n");
return msg_dumpit(nlh, node_list_cb, NULL);
}
@@ -120,7 +120,7 @@ static int cmd_node_get_addr(struct nlmsghdr *nlh, const struct cmd *cmd,
}
close(sk);
- printf("%x\n", addr.addr.id.node);
+ printf("%08x\n", addr.addr.id.node);
return 0;
}
@@ -167,7 +167,6 @@ static int nodeid_get_cb(const struct nlmsghdr *nlh, void *data)
uint8_t id[16] = {0,};
uint64_t *w0 = (uint64_t *) &id[0];
uint64_t *w1 = (uint64_t *) &id[8];
- int i;
mnl_attr_parse(nlh, sizeof(*genl), parse_attrs, info);
if (!info[TIPC_NLA_NET])
@@ -180,10 +179,8 @@ static int nodeid_get_cb(const struct nlmsghdr *nlh, void *data)
*w0 = mnl_attr_get_u64(attrs[TIPC_NLA_NET_NODEID]);
*w1 = mnl_attr_get_u64(attrs[TIPC_NLA_NET_NODEID_W1]);
nodeid2str(id, str);
- printf("Node Identity Hash\n");
- printf("%s", str);
- for (i = strlen(str); i <= 33; i++)
- printf(" ");
+ printf("Node Identity Hash\n");
+ printf("%-33s", str);
cmd_node_get_addr(NULL, NULL, NULL, NULL);
return MNL_CB_OK;
}
diff --git a/tipc/peer.c b/tipc/peer.c
index de0c73c..f638077 100644
--- a/tipc/peer.c
+++ b/tipc/peer.c
@@ -39,8 +39,12 @@ static int cmd_peer_rm_addr(struct nlmsghdr *nlh, const struct cmd *cmd,
}
str = shift_cmdl(cmdl);
+
+ /* First try legacy Z.C.N format, then integer format */
addr = str2addr(str);
if (!addr)
+ addr = atoi(str);
+ if (!addr)
return -1;
if (!(nlh = msg_init(buf, TIPC_NL_PEER_REMOVE))) {
--
2.1.4
^ permalink raw reply related
* Re: [PATCH V2 8/8] dt-bindings: stm32: add compatible for syscon
From: Rob Herring @ 2018-05-07 16:35 UTC (permalink / raw)
To: Christophe Roullier
Cc: mark.rutland, mcoquelin.stm32, alexandre.torgue, peppe.cavallaro,
devicetree, andrew, linux-arm-kernel, netdev
In-Reply-To: <1525270723-18241-9-git-send-email-christophe.roullier@st.com>
On Wed, May 02, 2018 at 04:18:43PM +0200, Christophe Roullier wrote:
> This patch describes syscon DT bindings.
>
> Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
> ---
> Documentation/devicetree/bindings/arm/stm32.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/stm32.txt b/Documentation/devicetree/bindings/arm/stm32.txt
> index 6808ed9..06e3834 100644
> --- a/Documentation/devicetree/bindings/arm/stm32.txt
> +++ b/Documentation/devicetree/bindings/arm/stm32.txt
> @@ -8,3 +8,7 @@ using one of the following compatible strings:
> st,stm32f746
> st,stm32h743
> st,stm32mp157
> +
> +Required nodes:
> +- syscon: the soc bus node must have a system controller node pointing to the
> + global control registers, with the compatible string "syscon";
You misunderstood my prior comment. 'syscon' alone is not valid. You
need SoC specific compatible string for it and 'stm32' is not SoC
specific. IOW, the compatible property for a syscon should imply every
single register field in the block.
Rob
^ permalink raw reply
* Re: [PATCH net-next v8 1/7] sched: Add Common Applications Kept Enhanced (cake) qdisc
From: Cong Wang @ 2018-05-07 16:35 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Linux Kernel Network Developers, Cake List
In-Reply-To: <87in831bl2.fsf@toke.dk>
On Fri, May 4, 2018 at 12:10 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Thank you for the review! A few comments below, I'll fix the rest.
>
>> [...]
>>
>> So sch_cake doesn't accept normal tc filters? Is this intentional?
>> If so, why?
>
> For two reasons:
>
> - The two-level scheduling used in CAKE (tins / diffserv classes, and
> flow hashing) does not map in an obvious way to the classification
> index of tc filters.
Sounds like you need to extend struct tcf_result?
>
> - No one has asked for it. We have done our best to accommodate the
> features people want in a home router qdisc directly in CAKE, and the
> ability to integrate tc filters has never been requested.
It is not hard to integrate, basically you need to call tcf_classify().
Although it is not mandatory, it is odd to merge a qdisc doesn't work
with existing tc filters (and actions too).
>>> +static int cake_init(struct Qdisc *sch, struct nlattr *opt,
>>> + struct netlink_ext_ack *extack)
>>> +{
>>> + struct cake_sched_data *q = qdisc_priv(sch);
>>> + int i, j;
>>> +
>>> + sch->limit = 10240;
>>> + q->tin_mode = CAKE_DIFFSERV_BESTEFFORT;
>>> + q->flow_mode = CAKE_FLOW_TRIPLE;
>>> +
>>> + q->rate_bps = 0; /* unlimited by default */
>>> +
>>> + q->interval = 100000; /* 100ms default */
>>> + q->target = 5000; /* 5ms: codel RFC argues
>>> + * for 5 to 10% of interval
>>> + */
>>> +
>>> + q->cur_tin = 0;
>>> + q->cur_flow = 0;
>>> +
>>> + if (opt) {
>>> + int err = cake_change(sch, opt, extack);
>>> +
>>> + if (err)
>>> + return err;
>>
>>
>> Not sure if you really want to reallocate q->tines below for this
>> case.
>
> I'm not sure what you mean here? If there's an error we return it and
> the qdisc is not created. If there's not, we allocate and on subsequent
> changes cake_change() will be called directly, or? Can the init function
> ever be called again during the lifetime of the qdisc?
>
In non-error case, you call cake_change() first and then allocate ->tins
with kvzalloc() below. For me it looks like you don't need to allocate it
again when ->tins!=NULL.
^ permalink raw reply
* Re: [PATCH V2 4/8] ARM: dts: stm32: Add syscfg on stm32mp1
From: Rob Herring @ 2018-05-07 16:36 UTC (permalink / raw)
To: Christophe Roullier
Cc: mark.rutland, mcoquelin.stm32, alexandre.torgue, peppe.cavallaro,
devicetree, andrew, linux-arm-kernel, netdev
In-Reply-To: <1525270723-18241-5-git-send-email-christophe.roullier@st.com>
On Wed, May 02, 2018 at 04:18:39PM +0200, Christophe Roullier wrote:
> System configuration controller is mainly used to manage
> the compensation cell and other IOs and system related
> settings.
>
> Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
> ---
> arch/arm/boot/dts/stm32mp157c.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi
> index bc3eddc..86421ba 100644
> --- a/arch/arm/boot/dts/stm32mp157c.dtsi
> +++ b/arch/arm/boot/dts/stm32mp157c.dtsi
> @@ -167,6 +167,11 @@
> #reset-cells = <1>;
> };
>
> + syscfg: system-config@50020000 {
> + compatible = "syscon";
> + reg = <0x50020000 0x400>;
> + };
NAK as explained in the documentation patch.
Rob
^ permalink raw reply
* Re: [PATCH V2 2/8] dt-bindings: stm32-dwmac: add support of MPU families
From: Rob Herring @ 2018-05-07 16:37 UTC (permalink / raw)
To: Christophe Roullier
Cc: mark.rutland, mcoquelin.stm32, alexandre.torgue, peppe.cavallaro,
devicetree, linux-arm-kernel, netdev, andrew
In-Reply-To: <1525270723-18241-3-git-send-email-christophe.roullier@st.com>
On Wed, May 02, 2018 at 04:18:37PM +0200, Christophe Roullier wrote:
> Add description for Ethernet MPU families fields
>
> Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
> ---
> Documentation/devicetree/bindings/net/stm32-dwmac.txt | 18 ++++++++++++++++--
> 1 file changed, 16 insertions(+), 2 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH RFC net-next] net: ipvs: Adjust gso_size for IPPROTO_TCP
From: Julian Anastasov @ 2018-05-07 17:00 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: netdev, David Ahern, Tom Herbert, Eric Dumazet, Nikita Shirokov,
kernel-team, lvs-devel
In-Reply-To: <20180507162229.5ndsjremhfdtbeqj@kafai-mbp.dhcp.thefacebook.com>
Hello,
On Mon, 7 May 2018, Martin KaFai Lau wrote:
> On Sat, May 05, 2018 at 03:58:25PM +0300, Julian Anastasov wrote:
> >
> > So, except the RTF_LOCAL check in __ip6_rt_update_pmtu
> > we should have no other issues. Only one minor bit is strange to me,
> > why rt6_insert_exception warns for RTF_PCPU if rt6_cache_allowed_for_pmtu
> > allows it when returning true...
> hmm...I am not sure I follow this bits. Where is the warn?
if (ort->rt6i_flags & (RTF_CACHE | RTF_PCPU))
ort = ort->from;
Sorry, my fault, I missed above re-assignment...
WARN_ON_ONCE(ort->rt6i_flags & (RTF_CACHE | RTF_PCPU));
> Note that "nrt6" and "from" are passed to rt6_insert_exception()
> instead of "rt6".
>
> >
> > Also, commit 0d3f6d297bfb allows rt6_do_update_pmtu() for
> > routes without RTF_CACHE, RTF_PCPU and rt6i_node. Should we
> > restrict rt6_do_update_pmtu only to RTF_CACHE routes?
> >
> > if (!rt6_cache_allowed_for_pmtu(rt6)) {
> > - rt6_do_update_pmtu(rt6, mtu);
> The existing rt6_do_update_pmtu() looks correct.
> The mtu of the dst created by icmp6_dst_alloc()
> needs to be udpated and this dst does not have
> the RTF_CACHE.
Aha, ok. I thought, only RTF_CACHE routes can
hold PMTU.
Regards
^ permalink raw reply
* Re: [PATCH v2 net 0/2] IB/ipoib: ip link support
From: Or Gerlitz @ 2018-05-07 17:29 UTC (permalink / raw)
To: Alex Vesker, Denis Drozdov
Cc: David Miller, Doug Ledford, RDMA mailing list, Linux Netdev List,
Jason Gunthorpe, Don Dutile, Honggang Li, Noa Spanier
In-Reply-To: <20180118042549.GA11171@ziepe.ca>
On Thu, Jan 18, 2018 at 7:25 AM, Jason Gunthorpe <jgg@mellanox.com> wrote:
> On Mon, Jan 15, 2018 at 01:13:09PM -0500, David Miller wrote:
>> From: Denis Drozdov <denisd@mellanox.com>
>> Date: Tue, 9 Jan 2018 23:42:45 +0200
>>
>> > IP link was broken due to the changes in IPoIB for the rdma_netdev
>> > support after commit cd565b4b51e5
>> > ("IB/IPoIB: Support acceleration options callbacks").
>> >
>> > This patchset restores IPoIB pkey creation and removal using rtnetlink.
>> > The first patch introduces changes in the rtnetlink code in order to allow
>> > IPOIB allocate and free the netdevice.
>> >
>> > The second patch establishes appropriate rtnetlink callbacks for IPoIB
>> > device and restores IPoIB netlink support
>> >
>> > Changes since v1:
>> > - Fixed double free_netdev calls in ops->free_link in netdev_run_todo
>> > - Removed priv_size from ipoib_link_ops as not required anymore.
>>
>> Please fix your control flow so that the existing netlink op can do
>> the right thing.
>
> Okay. Since this bug has been outstanding in RDMA for so long, I've
> looked pretty carefully at this..
>
> This patch does go too far, but ipoib does appear to legitimately need
> something special here and no amount of 'control flow fixing' in ipoib
> will solve it.
>
> The fundamental issue is that ipoib no longer has a generic software
> netdev for the child interface. Instead the child interface is bound
> directly to one of several *full* hardware drivers. ie the child and
> the master are basically exactly the same HW dependent code.
>
> Since the child is a full hardware netdev, it has its own HW driven
> needs for priv_size, txqs, rxqs, etc. There is no 'one size fits all'
> value like for all the other software based newlink users. It depends
> on the HW device installed in the system (eg mlx4, mlx5, hfi1)
>
> The only problem with rtnl newlink is that it wants to use priv_size,
> txqs, and rxqs values from a singleton static global structure (eg
> ipoib_link_ops) which cannot know in advance which ipoib HW driver is
> in use by the specific parent the child is being created for.
>
> This is what needs to be fixed. ipoib simply needs to have
> parent-dependent inputs to the alloc_netdev_mqs in rtnl_create_link.
>
> The patch proposes
>
> struct net_device *(*alloc_link)(struct net *src_net,
> const char *dev_name,
> struct nlattr *tb[]);
>
> To let ipoib allocate the netdev, and then obviosly figure out the
> right parameters internally.
>
> This patch also adds some free related stuff, but that seems to be
> going too far. ipoib can use the normal free paths. The above is all
> that is necessary.
>
> An alternative would be something like:
>
> struct rtnl_alloc_params {
> size_t priv_size;
> int txqs;
> int rxqs;
> };
> void (*get_alloc_parameters)(struct net_device *net,
> struct rtnl_alloc_params *parms);
>
> To let ipoib tell rtnl_create_link what parameters to use based on
> 'net' instead of taking them from the global singleton.
>
> Do you see another choice?
>
> Can you accept one of these options?
>
> Thanks,
> Jason
> (BTW, Doug & I are now co-maintaining RDMA, so I say the above with my
> maintainer hat on. This is a serious userspace visible regression bug
> on our side, and I really want to see it fixed.)
Guys,
This is broken upstream for a long time, and now in few distributions
that picked
the patches that introduce the breakage, what is the plan?
Or.
^ permalink raw reply
* Fw: [Bug 199643] New: UBSAN: Undefined behaviour in ./include/net/route.h:240:2
From: Stephen Hemminger @ 2018-05-07 17:34 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Mon, 07 May 2018 16:36:49 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 199643] New: UBSAN: Undefined behaviour in ./include/net/route.h:240:2
https://bugzilla.kernel.org/show_bug.cgi?id=199643
Bug ID: 199643
Summary: UBSAN: Undefined behaviour in
./include/net/route.h:240:2
Product: Networking
Version: 2.5
Kernel Version: 4.16.7-CUSTOM
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: stephen@networkplumber.org
Reporter: combuster@archlinux.us
Regression: No
After recompiling the 4.16.7 kernel with gcc 8.1, UBSAN reports the following:
[ 26.312176]
================================================================================
[ 26.312179] UBSAN: Undefined behaviour in ./include/net/route.h:240:2
[ 26.312180] member access within null pointer of type 'struct rtable'
[ 26.312183] CPU: 2 PID: 311 Comm: sd-resolve Not tainted 4.16.7-CUSTOM #1
[ 26.312185] Hardware name: Gigabyte Technology Co., Ltd.
H67MA-UD2H-B3/H67MA-UD2H-B3, BIOS F8 03/27/2012
[ 26.312186] Call Trace:
[ 26.312188] <IRQ>
[ 26.312194] dump_stack+0x62/0x9f
[ 26.312199] ubsan_epilogue+0x9/0x35
[ 26.312201] handle_null_ptr_deref+0x80/0x90
[ 26.312204] __ubsan_handle_type_mismatch_v1+0x6a/0x80
[ 26.312208] icmp_send+0xbb0/0xd90
[ 26.312218] __udp4_lib_rcv+0x760/0x1440
[ 26.312223] ? lock_acquire+0x69/0x100
[ 26.312226] ? ip_local_deliver_finish+0x62/0x4a0
[ 26.312229] ip_local_deliver_finish+0xf3/0x4a0
[ 26.312233] ip_local_deliver+0xa6/0x240
[ 26.312237] ip_rcv+0x33e/0x660
[ 26.312241] ? ip_local_deliver+0x240/0x240
[ 26.312246] __netif_receive_skb_core+0xaef/0x1bb0
[ 26.312254] ? process_backlog+0xcd/0x370
[ 26.312256] ? process_backlog+0xfd/0x370
[ 26.312258] process_backlog+0xfd/0x370
[ 26.312260] ? process_backlog+0xcd/0x370
[ 26.312264] net_rx_action+0x3cb/0xe40
[ 26.312270] ? __do_softirq+0x119/0x376
[ 26.312275] ? do_softirq_own_stack+0x2a/0x40
[ 26.312276] </IRQ>
[ 26.312280] ? do_softirq.part.1+0x21/0x30
[ 26.312282] ? __local_bh_enable_ip+0x4f/0x60
[ 26.312284] ? ip_finish_output2+0x3af/0x720
[ 26.312288] ? ip_output+0xdc/0x270
[ 26.312290] ? ip_output+0xdc/0x270
[ 26.312295] ? ip_send_skb+0x1c/0x80
[ 26.312297] ? udp_send_skb+0x1bf/0x480
[ 26.312301] ? udp_sendmsg+0xbb7/0x1020
[ 26.312304] ? ip_reply_glue_bits+0x60/0x60
[ 26.312308] ? rw_copy_check_uvector+0x5d/0x210
[ 26.312316] ? sock_sendmsg+0x49/0xb0
[ 26.312319] ? ___sys_sendmsg+0x194/0x3b0
[ 26.312323] ? __fget+0x125/0x290
[ 26.312330] ? __sys_sendmmsg+0xdd/0x180
[ 26.312337] ? SyS_sendmmsg+0x5/0x10
[ 26.312340] ? do_syscall_64+0xad/0x5cc
[ 26.312345] ? entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 26.312349]
================================================================================
[ 26.312358]
================================================================================
[ 26.312359] UBSAN: Undefined behaviour in ./include/net/route.h:240:2
[ 26.312360] member access within null pointer of type 'struct rtable'
[ 26.312362] CPU: 2 PID: 311 Comm: sd-resolve Not tainted 4.16.7-CUSTOM #1
[ 26.312363] Hardware name: Gigabyte Technology Co., Ltd.
H67MA-UD2H-B3/H67MA-UD2H-B3, BIOS F8 03/27/2012
[ 26.312364] Call Trace:
[ 26.312367] dump_stack+0x62/0x9f
[ 26.312370] ubsan_epilogue+0x9/0x35
[ 26.312372] handle_null_ptr_deref+0x80/0x90
[ 26.312375] __ubsan_handle_type_mismatch_v1+0x6a/0x80
[ 26.312378] udp_sendmsg+0xc37/0x1020
[ 26.312382] ? ip_reply_glue_bits+0x60/0x60
[ 26.312384] ? rw_copy_check_uvector+0x5d/0x210
[ 26.312391] sock_sendmsg+0x49/0xb0
[ 26.312394] ___sys_sendmsg+0x194/0x3b0
[ 26.312398] ? __fget+0x125/0x290
[ 26.312405] __sys_sendmmsg+0xdd/0x180
[ 26.312413] SyS_sendmmsg+0x5/0x10
[ 26.312415] do_syscall_64+0xad/0x5cc
[ 26.312420] ? entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 26.312424]
================================================================================
[ 206.391361]
================================================================================
[ 206.391370] UBSAN: Undefined behaviour in ./include/net/route.h:240:2
[ 206.391372] member access within null pointer of type 'struct rtable'
[ 206.391376] CPU: 0 PID: 624 Comm: CompositorTileW Not tainted 4.16.7-CUSTOM
#1
[ 206.391378] Hardware name: Gigabyte Technology Co., Ltd.
H67MA-UD2H-B3/H67MA-UD2H-B3, BIOS F8 03/27/2012
[ 206.391381] Call Trace:
[ 206.391386] <IRQ>
[ 206.391398] dump_stack+0x62/0x9f
[ 206.391405] ubsan_epilogue+0x9/0x35
[ 206.391409] handle_null_ptr_deref+0x80/0x90
[ 206.391412] __ubsan_handle_type_mismatch_v1+0x6a/0x80
[ 206.391419] ip_send_unicast_reply+0x626/0x691
[ 206.391429] tcp_v4_send_reset+0x50f/0x990
[ 206.391433] ? inet_csk_destroy_sock+0xbe/0x180
[ 206.391439] ? tcp_v4_do_rcv+0x21a/0x2d0
[ 206.391442] tcp_v4_do_rcv+0x21a/0x2d0
[ 206.391447] ? _raw_spin_lock_nested+0x37/0x60
[ 206.391450] tcp_v4_rcv+0xd2f/0x1420
[ 206.391457] ? lock_acquire+0x69/0x100
[ 206.391460] ? ip_local_deliver_finish+0x62/0x4a0
[ 206.391464] ? ip_local_deliver_finish+0xf3/0x4a0
[ 206.391468] ? ip_local_deliver+0xa6/0x240
[ 206.391472] ? inet_add_protocol.cold.0+0x23/0x23
[ 206.391475] ? ip_rcv+0x33e/0x660
[ 206.391479] ? __local_bh_enable_ip+0x2e/0x60
[ 206.391482] ? ip_local_deliver_finish+0x4a0/0x4a0
[ 206.391485] ? ip_local_deliver+0x240/0x240
[ 206.391492] ? __netif_receive_skb_core+0xaef/0x1bb0
[ 206.391495] ? match_held_lock+0x1f0/0x280
[ 206.391502] ? netif_receive_skb_internal+0x7b/0x2b0
[ 206.391505] ? netif_receive_skb_internal+0x7b/0x2b0
[ 206.391509] ? napi_gro_receive+0x5d/0xe0
[ 206.391519] ? rtl8169_poll+0x224/0x880 [r8169]
[ 206.391524] ? net_rx_action+0x3cb/0xe40
[ 206.391530] ? __do_softirq+0x119/0x376
[ 206.391535] ? handle_irq+0x17e/0x31e
[ 206.391538] ? irq_exit+0x81/0xb0
[ 206.391541] ? do_IRQ+0x9f/0x140
[ 206.391545] ? common_interrupt+0xf/0xf
[ 206.391547] </IRQ>
[ 206.391551]
================================================================================
UBSAN reported nothing when the same kernel was compiled with gcc 7.3.1 from
Arch Linux repositories.
I saw the comment about dst_release but, if this is the intended behaviour, how
can we stop UBSAN from kicking in?
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Fw: [Bug 199637] New: UBSAN: Undefined behaviour in net/ipv4/fib_trie.c:503:6
From: Stephen Hemminger @ 2018-05-07 17:33 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Mon, 07 May 2018 16:07:24 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 199637] New: UBSAN: Undefined behaviour in net/ipv4/fib_trie.c:503:6
https://bugzilla.kernel.org/show_bug.cgi?id=199637
Bug ID: 199637
Summary: UBSAN: Undefined behaviour in
net/ipv4/fib_trie.c:503:6
Product: Networking
Version: 2.5
Kernel Version: 4.16.7
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
Assignee: stephen@networkplumber.org
Reporter: combuster@archlinux.us
Regression: No
After recompiling the 4.16.7 kernel with gcc 8.1, UBSAN reports the following:
[ 25.427424]
================================================================================
[ 25.429680] UBSAN: Undefined behaviour in net/ipv4/fib_trie.c:503:6
[ 25.431920] member access within null pointer of type 'struct tnode'
[ 25.434153] CPU: 3 PID: 1 Comm: systemd Not tainted 4.16.7-CUSTOM #1
[ 25.436384] Hardware name: Gigabyte Technology Co., Ltd.
H67MA-UD2H-B3/H67MA-UD2H-B3, BIOS F8 03/27/2012
[ 25.438647] Call Trace:
[ 25.440889] dump_stack+0x62/0x9f
[ 25.443104] ubsan_epilogue+0x9/0x35
[ 25.445293] handle_null_ptr_deref+0x80/0x90
[ 25.447464] __ubsan_handle_type_mismatch_v1+0x6a/0x80
[ 25.449628] tnode_free+0xce/0x120
[ 25.451749] ? replace+0xa0/0x1f0
[ 25.453833] ? resize+0x4e2/0xb70
[ 25.455916] ? __kmalloc+0x1fe/0x2d0
[ 25.457997] ? tnode_new+0x66/0x160
[ 25.460072] ? fib_insert_alias+0x4a8/0x9e0
[ 25.462145] ? fib_table_insert+0x208/0x690
[ 25.464214] ? fib_magic+0x20c/0x310
[ 25.466280] ? fib_netdev_event+0x81/0x200
[ 25.468339] ? notifier_call_chain+0x63/0x110
[ 25.470407] ? __dev_notify_flags+0xa8/0x170
[ 25.472472] ? dev_change_flags+0x56/0x80
[ 25.474538] ? do_setlink+0x3c2/0x1a00
[ 25.476603] ? fib_magic+0x20c/0x310
[ 25.478666] ? rtnl_setlink+0x129/0x1e0
[ 25.480728] ? rtnetlink_rcv_msg+0x2a4/0x7d0
[ 25.482765] ? rtnetlink_rcv+0x10/0x10
[ 25.484757] ? netlink_rcv_skb+0x6f/0x170
[ 25.486741] ? netlink_unicast+0x1c0/0x2d0
[ 25.488716] ? netlink_sendmsg+0x2c1/0x630
[ 25.490661] ? sock_sendmsg+0x49/0xb0
[ 25.492564] ? SyS_sendto+0x12b/0x1d0
[ 25.494449] ? do_syscall_64+0xad/0x5cc
[ 25.496305] ? page_fault+0x2f/0x50
[ 25.498140] ? entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 25.499974]
================================================================================
UBSAN reported nothing when the same kernel was compiled with gcc 7.3.1 from
Arch Linux repositories.
I have three more similar reports to make, if I continue to c/p in each I'm
gonna feel like a fuzzbot...
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [PATCH bpf-next] xsk: fix 64-bit division
From: Björn Töpel @ 2018-05-07 17:43 UTC (permalink / raw)
To: ast, daniel, netdev
Cc: Björn Töpel, Randy Dunlap, Stephen Rothwell,
magnus.karlsson, linux-next, linux-kernel
In-Reply-To: <e9890e95-16b4-4540-301b-43f17a824808@infradead.org>
From: Björn Töpel <bjorn.topel@intel.com>
i386 builds report:
net/xdp/xdp_umem.o: In function `xdp_umem_reg':
xdp_umem.c:(.text+0x47e): undefined reference to `__udivdi3'
This fix uses div_u64 instead of the GCC built-in.
Fixes: c0c77d8fb787 ("xsk: add user memory registration support sockopt")
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
---
net/xdp/xdp_umem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
index 881dfdefe235..2b47a1dd7c6c 100644
--- a/net/xdp/xdp_umem.c
+++ b/net/xdp/xdp_umem.c
@@ -209,7 +209,7 @@ int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr)
if ((addr + size) < addr)
return -EINVAL;
- nframes = size / frame_size;
+ nframes = (unsigned int)div_u64(size, frame_size);
if (nframes == 0 || nframes > UINT_MAX)
return -EINVAL;
--
2.14.1
^ 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