* Re: [Patch V3 net 05/11] net: hns3: remove unnecessary queue reset in the hns3_uninit_all_ring()
From: Sergei Shtylyov @ 2018-10-28 8:09 UTC (permalink / raw)
To: Huazhong Tan, davem
Cc: netdev, linuxarm, salil.mehta, yisen.zhuang, lipeng321,
linyunsheng
In-Reply-To: <1540697651-22993-6-git-send-email-tanhuazhong@huawei.com>
Hello!
On 28.10.2018 6:34, Huazhong Tan wrote:
> It is not necessary to reset the queue in the hns3_uninit_all_ring(),
> since the queue is stopped in the down operation, and will be reset
> in the up operaton. And the judgment of the HCLGE_STATE_RST_HANDLING
Operation.
> flag in the hclge_reset_tqp() is not correct, because we need to reset
> tqp during pf reset, otherwise it may cause queue not be reset to
Not being reset?
> working state problem.
>
> Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH net 0/2] macsec: linkstate fixes
From: Sabrina Dubroca @ 2018-10-28 8:33 UTC (permalink / raw)
To: netdev; +Cc: Sabrina Dubroca, Radu Rendec, Patrick Talbert
This series fixes issues with handling administrative and operstate of
macsec devices.
Radu Rendec proposed another version of the first patch [0] but I'd
rather not follow the behavior of vlan devices, going with macvlan
does instead. Patrick Talbert also reported the same issue to me.
The second patch is a follow-up. The restriction on setting the device
up is a bit unreasonable, and operstate provides the information we
need in this case.
[0] https://patchwork.ozlabs.org/patch/971374/
Sabrina Dubroca (2):
macsec: update operstate when lower device changes
macsec: let the administrator set UP state even if lowerdev is down
drivers/net/macsec.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
--
2.19.1
^ permalink raw reply
* [PATCH net 1/2] macsec: update operstate when lower device changes
From: Sabrina Dubroca @ 2018-10-28 8:33 UTC (permalink / raw)
To: netdev; +Cc: Sabrina Dubroca, Radu Rendec, Patrick Talbert
In-Reply-To: <cover.1540714256.git.sd@queasysnail.net>
Like all other virtual devices (macvlan, vlan), the operstate of a
macsec device should match the state of its lower device. This is done
by calling netif_stacked_transfer_operstate from its netdevice notifier.
We also need to call netif_stacked_transfer_operstate when a new macsec
device is created, so that its operstate is set properly. This is only
relevant when we try to bring the device up directly when we create it.
Radu Rendec proposed a similar patch, inspired from the 802.1q driver,
that included changing the administrative state of the macsec device,
instead of just the operstate. This version is similar to what the
macvlan driver does, and updates only the operstate.
Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
Reported-by: Radu Rendec <radu.rendec@gmail.com>
Reported-by: Patrick Talbert <ptalbert@redhat.com>
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
---
drivers/net/macsec.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
index 4bb90b6867a2..6195b8edafc0 100644
--- a/drivers/net/macsec.c
+++ b/drivers/net/macsec.c
@@ -3306,6 +3306,9 @@ static int macsec_newlink(struct net *net, struct net_device *dev,
if (err < 0)
goto del_dev;
+ netif_stacked_transfer_operstate(real_dev, dev);
+ linkwatch_fire_event(dev);
+
macsec_generation++;
return 0;
@@ -3490,6 +3493,20 @@ static int macsec_notify(struct notifier_block *this, unsigned long event,
return NOTIFY_DONE;
switch (event) {
+ case NETDEV_DOWN:
+ case NETDEV_UP:
+ case NETDEV_CHANGE: {
+ struct macsec_dev *m, *n;
+ struct macsec_rxh_data *rxd;
+
+ rxd = macsec_data_rtnl(real_dev);
+ list_for_each_entry_safe(m, n, &rxd->secys, secys) {
+ struct net_device *dev = m->secy.netdev;
+
+ netif_stacked_transfer_operstate(real_dev, dev);
+ }
+ break;
+ }
case NETDEV_UNREGISTER: {
struct macsec_dev *m, *n;
struct macsec_rxh_data *rxd;
--
2.19.1
^ permalink raw reply related
* [PATCH net 2/2] macsec: let the administrator set UP state even if lowerdev is down
From: Sabrina Dubroca @ 2018-10-28 8:33 UTC (permalink / raw)
To: netdev; +Cc: Sabrina Dubroca, Radu Rendec, Patrick Talbert
In-Reply-To: <cover.1540714256.git.sd@queasysnail.net>
Currently, the kernel doesn't let the administrator set a macsec device
up unless its lower device is currently up. This is inconsistent, as a
macsec device that is up won't automatically go down when its lower
device goes down.
Now that linkstate propagation works, there's really no reason for this
limitation, so let's remove it.
Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
Reported-by: Radu Rendec <radu.rendec@gmail.com>
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
---
drivers/net/macsec.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
index 6195b8edafc0..64a982563d59 100644
--- a/drivers/net/macsec.c
+++ b/drivers/net/macsec.c
@@ -2812,9 +2812,6 @@ static int macsec_dev_open(struct net_device *dev)
struct net_device *real_dev = macsec->real_dev;
int err;
- if (!(real_dev->flags & IFF_UP))
- return -ENETDOWN;
-
err = dev_uc_add(real_dev, dev->dev_addr);
if (err < 0)
return err;
--
2.19.1
^ permalink raw reply related
* Re: [PATCH v2] sctp: socket.c validate sprstat_policy
From: Tomas Bortoli @ 2018-10-28 8:42 UTC (permalink / raw)
To: Xin Long
Cc: Vlad Yasevich, Neil Horman, Marcelo Ricardo Leitner, davem,
linux-sctp, network dev, LKML
In-Reply-To: <CADvbK_dHDq69jtLHh4p9xeonhcLAjSytTZMZ0vN3QzcukP2ajg@mail.gmail.com>
On 10/28/18 5:17 AM, Xin Long wrote:
> On Sun, Oct 28, 2018 at 5:54 AM Tomas Bortoli <tomasbortoli@gmail.com> wrote:
>>
>> It is possible to perform out-of-bound reads on
>> sctp_getsockopt_pr_streamstatus() and on
>> sctp_getsockopt_pr_assocstatus() by passing from userspace a
>> sprstat_policy that overflows the abandoned_sent/abandoned_unsent
>> fixed length arrays. The over-read data are directly copied/leaked
>> to userspace.
>>
>> Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
>> Reported-by: syzbot+5da0d0a72a9e7d791748@syzkaller.appspotmail.com
>> ---
>> net/sctp/socket.c | 8 ++++++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
>> index fc0386e8ff23..14dce5d95817 100644
>> --- a/net/sctp/socket.c
>> +++ b/net/sctp/socket.c
>> @@ -7083,7 +7083,9 @@ static int sctp_getsockopt_pr_assocstatus(struct sock *sk, int len,
>> }
>>
>> policy = params.sprstat_policy;
>> - if (!policy || (policy & ~(SCTP_PR_SCTP_MASK | SCTP_PR_SCTP_ALL)))
>> + if (!policy || (policy & ~(SCTP_PR_SCTP_MASK | SCTP_PR_SCTP_ALL)) ||
>> + __SCTP_PR_INDEX(policy) > SCTP_PR_INDEX(MAX) ||
>> + __SCTP_PR_INDEX(policy) < 0)
>> goto out;
>>
>> asoc = sctp_id2assoc(sk, params.sprstat_assoc_id);
>> @@ -7142,7 +7144,9 @@ static int sctp_getsockopt_pr_streamstatus(struct sock *sk, int len,
>> }
>>
>> policy = params.sprstat_policy;
>> - if (!policy || (policy & ~(SCTP_PR_SCTP_MASK | SCTP_PR_SCTP_ALL)))
>> + if (!policy || (policy & ~(SCTP_PR_SCTP_MASK | SCTP_PR_SCTP_ALL)) ||
>> + __SCTP_PR_INDEX(policy) > SCTP_PR_INDEX(MAX) ||
>> + __SCTP_PR_INDEX(policy) < 0)
>> goto out;
> This is not the correct fix.
> See https://lkml.org/lkml/2018/10/27/136
>
Ack, good to know ty!
^ permalink raw reply
* Re: WARNING in __debug_object_init (3)
From: Eric Dumazet @ 2018-10-28 17:44 UTC (permalink / raw)
To: Dmitry Vyukov, syzbot, Eric Dumazet
Cc: Alexei Starovoitov, Daniel Borkmann, David Miller, LKML, netdev,
syzkaller-bugs
In-Reply-To: <CACT4Y+bxF2gZpdp5JuWSWwyqX=ZumOmei-pOpnGFjALDeaqmQQ@mail.gmail.com>
On 10/28/2018 08:13 AM, Dmitry Vyukov wrote:
> On Sun, Oct 28, 2018 at 3:18 AM, syzbot
> <syzbot+6e682caa546b7c96c859@syzkaller.appspotmail.com> wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: 8c60c36d0b8c Add linux-next specific files for 20181019
>> git tree: linux-next
>> console output: https://syzkaller.appspot.com/x/log.txt?x=100feec5400000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=8b6d7c4c81535e89
>> dashboard link: https://syzkaller.appspot.com/bug?extid=6e682caa546b7c96c859
>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13579abd400000
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13654f6b400000
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+6e682caa546b7c96c859@syzkaller.appspotmail.com
>
> +Eric knows what's wrong here. Something about "bpf: add tests for
> direct packet access from CGROUP_SKB" commit. Was is amended to fix a
> bug?
>
I know little.
It seems that this linux-next tree contains a (buggy) pre-version of
this commit :
commit 2cb494a36c98279c5c6ce8e99cf9776f15449ade
Author: Song Liu <songliubraving@fb.com>
Date: Fri Oct 19 09:57:58 2018 -0700
bpf: add tests for direct packet access from CGROUP_SKB
Tests are added to make sure CGROUP_SKB cannot access:
tc_classid, data_meta, flow_keys
and can read and write:
mark, prority, and cb[0-4]
and can read other fields.
To make selftest with skb->sk work, a dummy sk is added in
bpf_prog_test_run_skb().
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Maybe bpf maintainers chose to pre-submit a buggy patch and rebased their tree.
The buggy patch in linux-next was :
commit 75079847e9d05d4cc1b7e09b29e22cbc8318a6b7
Author: Song Liu <songliubraving@fb.com>
Date: Thu Oct 18 09:06:49 2018 -0700
bpf: add tests for direct packet access from CGROUP_SKB
Tests are added to make sure CGROUP_SKB cannot access:
tc_classid, data_meta, flow_keys
and can read and write:
mark, prority, and cb[0-4]
and can read other fields.
To make selftest with skb->sk work, a dummy sk is added in
bpf_prog_test_run_skb().
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
>
>> ODEBUG: object 0000000015e9012c is on stack 00000000115bcb67, but NOT
>> annotated.
>> WARNING: CPU: 0 PID: 5594 at lib/debugobjects.c:369 debug_object_is_on_stack
>> lib/debugobjects.c:363 [inline]
>> WARNING: CPU: 0 PID: 5594 at lib/debugobjects.c:369
>> __debug_object_init.cold.14+0x51/0xdf lib/debugobjects.c:395
>> Kernel panic - not syncing: panic_on_warn set ...
>> CPU: 0 PID: 5594 Comm: syz-executor740 Not tainted 4.19.0-rc8-next-20181019+
>> #98
>> 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+0x244/0x39d lib/dump_stack.c:113
>> panic+0x2ad/0x55c kernel/panic.c:188
>> __warn.cold.8+0x20/0x45 kernel/panic.c:540
>> report_bug+0x254/0x2d0 lib/bug.c:186
>> fixup_bug arch/x86/kernel/traps.c:178 [inline]
>> do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
>> do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:290
>> invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:969
>> RIP: 0010:debug_object_is_on_stack lib/debugobjects.c:363 [inline]
>> RIP: 0010:__debug_object_init.cold.14+0x51/0xdf lib/debugobjects.c:395
>> Code: ea 03 80 3c 02 00 75 7c 49 8b 54 24 18 48 89 de 48 c7 c7 c0 f1 40 88
>> 4c 89 85 d0 fd ff ff e8 09 8c d1 fd 4c 8b 85 d0 fd ff ff <0f> 0b e9 09 d6 ff
>> ff 41 83 c4 01 b8 ff ff 37 00 44 89 25 b7 4e 66
>> RSP: 0018:ffff8801bb387308 EFLAGS: 00010086
>> RAX: 0000000000000050 RBX: ffff8801bb387af8 RCX: 0000000000000000
>> RDX: 0000000000000000 RSI: ffffffff816585a5 RDI: 0000000000000005
>> RBP: ffff8801bb387560 R08: ffff8801cb208a20 R09: ffffed003b5c5008
>> R10: ffffed003b5c5008 R11: ffff8801dae28047 R12: ffff8801d82ea300
>> R13: 0000000000069700 R14: ffff8801d82ea300 R15: ffff8801cb208a10
>> debug_object_init+0x16/0x20 lib/debugobjects.c:432
>> debug_timer_init kernel/time/timer.c:704 [inline]
>> debug_init kernel/time/timer.c:757 [inline]
>> init_timer_key+0xa9/0x480 kernel/time/timer.c:806
>> sock_init_data+0xe1/0xdc0 net/core/sock.c:2696
>> bpf_prog_test_run_skb+0x255/0xc40 net/bpf/test_run.c:144
>> bpf_prog_test_run+0x130/0x1a0 kernel/bpf/syscall.c:1790
>> __do_sys_bpf kernel/bpf/syscall.c:2427 [inline]
>> __se_sys_bpf kernel/bpf/syscall.c:2371 [inline]
>> __x64_sys_bpf+0x3d8/0x510 kernel/bpf/syscall.c:2371
>> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> RIP: 0033:0x440259
>> Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
>> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff
>> 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
>> RSP: 002b:00007ffc212cf818 EFLAGS: 00000213 ORIG_RAX: 0000000000000141
>> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440259
>> RDX: 0000000000000028 RSI: 0000000020000080 RDI: 000000000000000a
>> RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
>> R10: 0000000000000000 R11: 0000000000000213 R12: 0000000000401ae0
>> R13: 0000000000401b70 R14: 0000000000000000 R15: 0000000000000000
>>
>> ======================================================
>> WARNING: possible circular locking dependency detected
>> 4.19.0-rc8-next-20181019+ #98 Not tainted
>> ------------------------------------------------------
>> syz-executor740/5594 is trying to acquire lock:
>> 00000000688fcc6b ((console_sem).lock){-.-.}, at: down_trylock+0x13/0x70
>> kernel/locking/semaphore.c:136
>>
>> but task is already holding lock:
>> 00000000505ead1b (&obj_hash[i].lock){-.-.}, at:
>> __debug_object_init+0x127/0x1290 lib/debugobjects.c:384
>>
>> which lock already depends on the new lock.
>>
>>
>> the existing dependency chain (in reverse order) is:
>>
>> -> #3 (&obj_hash[i].lock){-.-.}:
>> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
>> _raw_spin_lock_irqsave+0x99/0xd0 kernel/locking/spinlock.c:152
>> __debug_object_init+0x127/0x1290 lib/debugobjects.c:384
>> debug_object_init+0x16/0x20 lib/debugobjects.c:432
>> debug_hrtimer_init kernel/time/hrtimer.c:410 [inline]
>> debug_init kernel/time/hrtimer.c:458 [inline]
>> hrtimer_init+0x97/0x490 kernel/time/hrtimer.c:1308
>> init_dl_task_timer+0x1b/0x50 kernel/sched/deadline.c:1057
>> __sched_fork+0x2ae/0x590 kernel/sched/core.c:2166
>> init_idle+0x75/0x740 kernel/sched/core.c:5382
>> sched_init+0xb33/0xc02 kernel/sched/core.c:6065
>> start_kernel+0x4be/0xa2b init/main.c:608
>> x86_64_start_reservations+0x2e/0x30 arch/x86/kernel/head64.c:472
>> x86_64_start_kernel+0x76/0x79 arch/x86/kernel/head64.c:451
>> secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
>>
>> -> #2 (&rq->lock){-.-.}:
>> __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
>> _raw_spin_lock+0x2d/0x40 kernel/locking/spinlock.c:144
>> rq_lock kernel/sched/sched.h:1127 [inline]
>> task_fork_fair+0xb0/0x6d0 kernel/sched/fair.c:9768
>> sched_fork+0x443/0xba0 kernel/sched/core.c:2359
>> copy_process+0x2585/0x8770 kernel/fork.c:1887
>> _do_fork+0x1cb/0x11c0 kernel/fork.c:2216
>> kernel_thread+0x34/0x40 kernel/fork.c:2275
>> rest_init+0x28/0x372 init/main.c:409
>> arch_call_rest_init+0xe/0x1b
>> start_kernel+0x9f0/0xa2b init/main.c:745
>> x86_64_start_reservations+0x2e/0x30 arch/x86/kernel/head64.c:472
>> x86_64_start_kernel+0x76/0x79 arch/x86/kernel/head64.c:451
>> secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
>>
>> -> #1 (&p->pi_lock){-.-.}:
>> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
>> _raw_spin_lock_irqsave+0x99/0xd0 kernel/locking/spinlock.c:152
>> try_to_wake_up+0xd2/0x12e0 kernel/sched/core.c:1965
>> wake_up_process+0x10/0x20 kernel/sched/core.c:2129
>> __up.isra.1+0x1c0/0x2a0 kernel/locking/semaphore.c:262
>> up+0x13c/0x1c0 kernel/locking/semaphore.c:187
>> __up_console_sem+0xbe/0x1b0 kernel/printk/printk.c:236
>> console_unlock+0x80c/0x1190 kernel/printk/printk.c:2432
>> vprintk_emit+0x391/0x990 kernel/printk/printk.c:1922
>> vprintk_default+0x28/0x30 kernel/printk/printk.c:1964
>> vprintk_func+0x7e/0x181 kernel/printk/printk_safe.c:398
>> printk+0xa7/0xcf kernel/printk/printk.c:1997
>> check_stack_usage kernel/exit.c:755 [inline]
>> do_exit.cold.18+0x57/0x16f kernel/exit.c:916
>> do_group_exit+0x177/0x440 kernel/exit.c:970
>> __do_sys_exit_group kernel/exit.c:981 [inline]
>> __se_sys_exit_group kernel/exit.c:979 [inline]
>> __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:979
>> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>
>> -> #0 ((console_sem).lock){-.-.}:
>> lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844
>> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
>> _raw_spin_lock_irqsave+0x99/0xd0 kernel/locking/spinlock.c:152
>> down_trylock+0x13/0x70 kernel/locking/semaphore.c:136
>> __down_trylock_console_sem+0xae/0x1f0 kernel/printk/printk.c:219
>> console_trylock+0x15/0xa0 kernel/printk/printk.c:2247
>> console_trylock_spinning kernel/printk/printk.c:1653 [inline]
>> vprintk_emit+0x372/0x990 kernel/printk/printk.c:1921
>> vprintk_default+0x28/0x30 kernel/printk/printk.c:1964
>> vprintk_func+0x7e/0x181 kernel/printk/printk_safe.c:398
>> printk+0xa7/0xcf kernel/printk/printk.c:1997
>> debug_object_is_on_stack lib/debugobjects.c:363 [inline]
>> __debug_object_init.cold.14+0x4a/0xdf lib/debugobjects.c:395
>> debug_object_init+0x16/0x20 lib/debugobjects.c:432
>> debug_timer_init kernel/time/timer.c:704 [inline]
>> debug_init kernel/time/timer.c:757 [inline]
>> init_timer_key+0xa9/0x480 kernel/time/timer.c:806
>> sock_init_data+0xe1/0xdc0 net/core/sock.c:2696
>> bpf_prog_test_run_skb+0x255/0xc40 net/bpf/test_run.c:144
>> bpf_prog_test_run+0x130/0x1a0 kernel/bpf/syscall.c:1790
>> __do_sys_bpf kernel/bpf/syscall.c:2427 [inline]
>> __se_sys_bpf kernel/bpf/syscall.c:2371 [inline]
>> __x64_sys_bpf+0x3d8/0x510 kernel/bpf/syscall.c:2371
>> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>
>> other info that might help us debug this:
>>
>> Chain exists of:
>> (console_sem).lock --> &rq->lock --> &obj_hash[i].lock
>>
>> Possible unsafe locking scenario:
>>
>> CPU0 CPU1
>> ---- ----
>> lock(&obj_hash[i].lock);
>> lock(&rq->lock);
>> lock(&obj_hash[i].lock);
>> lock((console_sem).lock);
>>
>> *** DEADLOCK ***
>>
>> 1 lock held by syz-executor740/5594:
>> #0: 00000000505ead1b (&obj_hash[i].lock){-.-.}, at:
>> __debug_object_init+0x127/0x1290 lib/debugobjects.c:384
>>
>> stack backtrace:
>> CPU: 0 PID: 5594 Comm: syz-executor740 Not tainted 4.19.0-rc8-next-20181019+
>> #98
>> 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+0x244/0x39d lib/dump_stack.c:113
>> print_circular_bug.isra.35.cold.54+0x1bd/0x27d
>> kernel/locking/lockdep.c:1221
>> check_prev_add kernel/locking/lockdep.c:1863 [inline]
>> check_prevs_add kernel/locking/lockdep.c:1976 [inline]
>> validate_chain kernel/locking/lockdep.c:2347 [inline]
>> __lock_acquire+0x3399/0x4c20 kernel/locking/lockdep.c:3341
>> lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844
>> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
>> _raw_spin_lock_irqsave+0x99/0xd0 kernel/locking/spinlock.c:152
>> down_trylock+0x13/0x70 kernel/locking/semaphore.c:136
>> __down_trylock_console_sem+0xae/0x1f0 kernel/printk/printk.c:219
>> console_trylock+0x15/0xa0 kernel/printk/printk.c:2247
>> console_trylock_spinning kernel/printk/printk.c:1653 [inline]
>> vprintk_emit+0x372/0x990 kernel/printk/printk.c:1921
>> vprintk_default+0x28/0x30 kernel/printk/printk.c:1964
>> vprintk_func+0x7e/0x181 kernel/printk/printk_safe.c:398
>> printk+0xa7/0xcf kernel/printk/printk.c:1997
>> debug_object_is_on_stack lib/debugobjects.c:363 [inline]
>> __debug_object_init.cold.14+0x4a/0xdf lib/debugobjects.c:395
>> debug_object_init+0x16/0x20 lib/debugobjects.c:432
>> debug_timer_init kernel/time/timer.c:704 [inline]
>> debug_init kernel/time/timer.c:757 [inline]
>> init_timer_key+0xa9/0x480 kernel/time/timer.c:806
>> sock_init_data+0xe1/0xdc0 net/core/sock.c:2696
>> bpf_prog_test_run_skb+0x255/0xc40 net/bpf/test_run.c:144
>> bpf_prog_test_run+0x130/0x1a0 kernel/bpf/syscall.c:1790
>> __do_sys_bpf kernel/bpf/syscall.c:2427 [inline]
>> __se_sys_bpf kernel/bpf/syscall.c:2371 [inline]
>> __x64_sys_bpf+0x3d8/0x510 kernel/bpf/syscall.c:2371
>> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> RIP: 0033:0x440259
>> Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
>> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff
>> 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
>> RSP: 002b:00007ffc212cf818 EFLAGS: 00000213 ORIG_RAX: 0000000000000141
>> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440259
>> RDX: 0000000000000028 RSI: 0000000020000080 RDI: 000000000000000a
>> RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
>> R10: 0000000000000000 R11: 0000000000000213 R12: 0000000000401ae0
>> R13: 0000000000401b70 R14: 0000000000000000 R15: 0000000000000000
>> Kernel Offset: disabled
>> Rebooting in 86400 seconds..
>>
>>
>> ---
>> 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. See:
>> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
>> syzbot.
>> syzbot can test patches for this bug, for details see:
>> https://goo.gl/tpsmEJ#testing-patches
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "syzkaller-bugs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to syzkaller-bugs+unsubscribe@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/syzkaller-bugs/0000000000008db3210579416691%40google.com.
>> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: iproute2: fix build on glibc < 2.21 / uClibc
From: Petr Vorel @ 2018-10-28 10:16 UTC (permalink / raw)
To: netdev
Subject: [iproute] utils.h: provide fallback CLOCK_TAI definition
In-Reply-To: <20181027153102.32302-1-peter@korsgaard.com>
To: Stephen Hemminger <stephen@networkplumber.org>,
Vinicius Costa Gomes <vinicius.gomes@intel.com>
Cc: netdev@vger.kernel.org, Peter Korsgaard <peter@korsgaard.com>
From: Petr Vorel <petr.vorel@gmail.com>
List-Id: <netdev.vger.kernel.org>
> q_{etf,taprio}.c uses CLOCK_TAI, which isn't exposed by glibc < 2.21 or
> uClibc, breaking the build. Provide a fallback definition like it is done
> for IPPROTO_MPLS and others.
>
> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Reviewed-by: Petr Vorel <petr.vorel@gmail.com>
> ---
> include/utils.h | 4 ++++
> 1 file changed, 4 insertions(+)
Kind regards,
Petr
^ permalink raw reply
* Re: [RFC net-next v2 1/8] net: sched: register callbacks for indirect tc block binds
From: Or Gerlitz @ 2018-10-28 11:10 UTC (permalink / raw)
To: John Hurley
Cc: Linux Netdev List, oss-drivers, Jiri Pirko, Oz Shlomo,
Jakub Kicinski, Simon Horman, Aviv Heller
In-Reply-To: <1540470417-14803-2-git-send-email-john.hurley@netronome.com>
On Thu, Oct 25, 2018 at 3:28 PM John Hurley <john.hurley@netronome.com> wrote:
> Currently drivers can register to receive TC block bind/unbind callbacks
> by implementing the setup_tc ndo in any of their given netdevs. However,
> drivers may also be interested in binds to higher level devices (e.g.
> tunnel drivers) to potentially offload filters applied to them.
> Introduce indirect block devs which allows drivers to register callbacks
> for block binds on other devices. The calling driver is expected to
> reference an 'owner' struct that it will pass to all block registrations.
> This is used to track the callbacks from a given driver and free them if
> the driver is removed while the upper level device is still active.
Hi John,
Maybe it would be better to follow the trusted environment model of the kernel
and not protect the core from driver bugs? If the driver does things right they
will unregister before bailing out and if not, they will have to fix..
> Freeing a callback will also trigger an unbind event (if necessary) to
> direct the driver to remove any offloaded rules and unreg any block filter
> callbacks.
> Allow registering an indirect block dev callback for a device that is
> already bound to a block. In this case (if it is an ingress block),
> register and also trigger the callback meaning that any already installed
> rules can be replayed to the calling driver.
not just can be replayed.. they will be replayed, but through an
existing (tc re-offload?)
facility, correct?
Or.
^ permalink raw reply
* [PATCH v2] bonding: fix length of actor system
From: Tobias Jungel @ 2018-10-28 11:54 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Veaceslav Falico, Andy Gospodarek, Eric Dumazet, netdev
In-Reply-To: <386.1540680344@nyx>
The attribute IFLA_BOND_AD_ACTOR_SYSTEM is sent to user space having the
length of sizeof(bond->params.ad_actor_system) which is 8 byte. This
patch aligns the length to ETH_ALEN to have the same MAC address exposed
as using sysfs.
Fixes: f87fda00b6ed2 ("bonding: prevent out of bound accesses")
Signed-off-by: Tobias Jungel <tobias.jungel@gmail.com>
---
Changes in v2:
- correct Fixes line
drivers/net/bonding/bond_netlink.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_netlink.c b/drivers/net/bonding/bond_netlink.c
index 9697977b80f0..6b9ad8673218 100644
--- a/drivers/net/bonding/bond_netlink.c
+++ b/drivers/net/bonding/bond_netlink.c
@@ -638,8 +638,7 @@ static int bond_fill_info(struct sk_buff *skb,
goto nla_put_failure;
if (nla_put(skb, IFLA_BOND_AD_ACTOR_SYSTEM,
- sizeof(bond->params.ad_actor_system),
- &bond->params.ad_actor_system))
+ ETH_ALEN, &bond->params.ad_actor_system))
goto nla_put_failure;
}
if (!bond_3ad_get_active_agg_info(bond, &info)) {
^ permalink raw reply related
* Re: CAKE and r8169 cause panic on upload in v4.19
From: Oleksandr Natalenko @ 2018-10-28 12:22 UTC (permalink / raw)
To: David Miller
Cc: dave.taht, hkallweit1, toke, jhs, xiyou.wangcong, jiri, netdev,
linux-kernel
In-Reply-To: <20181027.214426.537959459795607171.davem@davemloft.net>
Hi.
On 28.10.2018 05:44, David Miller wrote:
> Does this fix it?
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 022ad73d6253..77d43ae2a7bb 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5457,7 +5457,7 @@ static void gro_flush_oldest(struct list_head
> *head)
> /* Do not adjust napi->gro_hash[].count, caller is adding a new
> * SKB to the chain.
> */
> - list_del(&oldest->list);
> + skb_list_del_init(oldest);
> napi_gro_complete(oldest);
> }
Yes, but I had to apply both a8305bff6852 and 992cba7e276d too to get it
compiled. With these 3 patches the panic is not triggered any more while
having GRO enabled.
Thanks!
--
Oleksandr Natalenko (post-factum)
^ permalink raw reply
* Re: [Bridge] [PATCH net] net: bridge: remove ipv6 zero address check in mcast queries
From: Stephen Hemminger @ 2018-10-28 15:20 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: netdev, roopa, bridge, yinxu, liuhangbin, davem
In-Reply-To: <20181027090747.22104-1-nikolay@cumulusnetworks.com>
On Sat, 27 Oct 2018 12:07:47 +0300
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> wrote:
> Recently a check was added which prevents marking of routers with zero
> source address, but for IPv6 that cannot happen as the relevant RFCs
> actually forbid such packets:
> RFC 2710 (MLDv1):
> "To be valid, the Query message MUST
> come from a link-local IPv6 Source Address, be at least 24 octets
> long, and have a correct MLD checksum."
>
> Same goes for RFC 3810.
>
> And also it can be seen as a requirement in ipv6_mc_check_mld_query()
> which is used by the bridge to validate the message before processing
> it. Thus any queries with :: source address won't be processed anyway.
> So just remove the check for zero IPv6 source address from the query
> processing function.
>
> Fixes: 5a2de63fd1a5 ("bridge: do not add port to router list when receives query with source 0.0.0.0")
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
What about a broken/malicious sender? Could an all zero source be used
to poison the multicast table?
^ permalink raw reply
* Re: [PATCH] ptp: drop redundant kasprintf() to create worker name
From: Kees Cook @ 2018-10-28 16:05 UTC (permalink / raw)
To: Rasmus Villemoes; +Cc: Richard Cochran, Network Development, LKML
In-Reply-To: <20181026212300.5827-1-linux@rasmusvillemoes.dk>
On Fri, Oct 26, 2018 at 10:22 PM, Rasmus Villemoes
<linux@rasmusvillemoes.dk> wrote:
> Building with -Wformat-nonliteral, gcc complains
>
> drivers/ptp/ptp_clock.c: In function ‘ptp_clock_register’:
> drivers/ptp/ptp_clock.c:239:26: warning: format not a string literal and no format arguments [-Wformat-nonliteral]
> worker_name : info->name);
>
> kthread_create_worker takes fmt+varargs to set the name of the
> worker, and that happens with a vsnprintf() to a stack buffer (that is
> then copied into task_comm). So there's no reason not to just pass
> "ptp%d", ptp->index to kthread_create_worker() and avoid the
> intermediate worker_name variable.
>
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Reviewed-by: Kees Cook <keescook@chromium.org>
-Kees
> ---
> drivers/ptp/ptp_clock.c | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c
> index 7eacc1c4b3b1..5419a89d300e 100644
> --- a/drivers/ptp/ptp_clock.c
> +++ b/drivers/ptp/ptp_clock.c
> @@ -232,12 +232,8 @@ struct ptp_clock *ptp_clock_register(struct ptp_clock_info *info,
> init_waitqueue_head(&ptp->tsev_wq);
>
> if (ptp->info->do_aux_work) {
> - char *worker_name = kasprintf(GFP_KERNEL, "ptp%d", ptp->index);
> -
> kthread_init_delayed_work(&ptp->aux_work, ptp_aux_kworker);
> - ptp->kworker = kthread_create_worker(0, worker_name ?
> - worker_name : info->name);
> - kfree(worker_name);
> + ptp->kworker = kthread_create_worker(0, "ptp%d", ptp->index);
> if (IS_ERR(ptp->kworker)) {
> err = PTR_ERR(ptp->kworker);
> pr_err("failed to create ptp aux_worker %d\n", err);
> --
> 2.19.1.6.gbde171bbf5
>
--
Kees Cook
^ permalink raw reply
* Re: [Bridge] [PATCH net] net: bridge: remove ipv6 zero address check in mcast queries
From: Nikolay Aleksandrov @ 2018-10-28 16:09 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, roopa, bridge, yinxu, liuhangbin, davem
In-Reply-To: <20181028082023.222fac71@xeon-e3>
On 28/10/2018 17:20, Stephen Hemminger wrote:
> On Sat, 27 Oct 2018 12:07:47 +0300
> Nikolay Aleksandrov <nikolay@cumulusnetworks.com> wrote:
>
>> Recently a check was added which prevents marking of routers with zero
>> source address, but for IPv6 that cannot happen as the relevant RFCs
>> actually forbid such packets:
>> RFC 2710 (MLDv1):
>> "To be valid, the Query message MUST
>> come from a link-local IPv6 Source Address, be at least 24 octets
>> long, and have a correct MLD checksum."
>>
>> Same goes for RFC 3810.
>>
>> And also it can be seen as a requirement in ipv6_mc_check_mld_query()
>> which is used by the bridge to validate the message before processing
>> it. Thus any queries with :: source address won't be processed anyway.
>> So just remove the check for zero IPv6 source address from the query
>> processing function.
>>
>> Fixes: 5a2de63fd1a5 ("bridge: do not add port to router list when receives query with source 0.0.0.0")
>> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>
> What about a broken/malicious sender? Could an all zero source be used
> to poison the multicast table?
>
No, this has nothing to do with the table. This is about marking routers
and we shouldn't consider queries with src 0.0.0.0 (the original fix)
but for IPv6 such query is invalid and in fact doesn't reach that code at all.
As I've written in the commit message, ipv6_mc_check_mld_query() already checks
for that and marks it as invalid thus it isn't processed and we can drop that
check from the bridge mcast code, if you test with such src you can see in
the bridge mcast statistics that the MLD errors are going up showing that these
packets are treated as errors.
Thanks,
Nik
^ permalink raw reply
* [GIT PULL] 9p updates for 4.20
From: Dominique Martinet @ 2018-10-29 1:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: v9fs-developer, linux-kernel, netdev
Hi Linus,
Here is a 9p update for 4.20.
Highlights this time around are the end of Matthew's work to remove the
custom 9p request cache and use a slab directly for requests, with some
extra patches on my end to not degrade performance, but it's a very good
cleanup.
Tomas and I fixed a few more syzkaller bugs (refcount is the big one),
and I had a go at the coverity bugs and at some of the bugzilla reports
we had open for a while.
I'm a bit disappointed that I couldn't get much reviews for a few of my
own patches, but the big ones got some and it's all been soaking in
linux-next for quite a while so I think it should be OK.
Lastly, as said last time, I'm going to be confusing again as I changed
my PGP key - it's signed by the old one - but should keep this one for
the forseeable future now.
Thanks!
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
are available in the Git repository at:
git://github.com/martinetd/linux tags/9p-for-4.20
for you to fetch changes up to fb488fc1f2b4c5128540b032892ddec91edaf8d9:
9p/trans_fd: put worker reqs on destroy (2018-10-10 09:14:34 +0900)
----------------------------------------------------------------
Dan Carpenter (1):
9p: potential NULL dereference
Dinu-Razvan Chis-Serban (1):
9p locks: add mount option for lock retry interval
Dominique Martinet (12):
9p/xen: fix check for xenbus_read error in front_probe
v9fs_dir_readdir: fix double-free on p9stat_read error
9p: clear dangling pointers in p9stat_free
9p: embed fcall in req to round down buffer allocs
9p: add a per-client fcall kmem_cache
9p/rdma: do not disconnect on down_interruptible EAGAIN
9p: acl: fix uninitialized iattr access
9p/rdma: remove useless check in cm_event_handler
9p: p9dirent_read: check network-provided name length
9p locks: fix glock.client_id leak in do_lock
9p/trans_fd: abort p9_read_work if req status changed
9p/trans_fd: put worker reqs on destroy
Gertjan Halkes (1):
9p: do not trust pdu content for stat item size
Gustavo A. R. Silva (1):
9p: fix spelling mistake in fall-through annotation
Matthew Wilcox (2):
9p: Use a slab for allocating requests
9p: Remove p9_idpool
Tomas Bortoli (3):
9p: rename p9_free_req() function
9p: Add refcount to p9_req_t
9p: Rename req to rreq in trans_fd
fs/9p/acl.c | 2 +-
fs/9p/v9fs.c | 21 +++++
fs/9p/v9fs.h | 1 +
fs/9p/vfs_dir.c | 19 +---
fs/9p/vfs_file.c | 24 +++++-
include/net/9p/9p.h | 12 +--
include/net/9p/client.h | 71 ++++++---------
net/9p/Makefile | 1 -
net/9p/client.c | 551 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------------------------------
net/9p/mod.c | 9 +-
net/9p/protocol.c | 20 ++++-
net/9p/trans_fd.c | 64 +++++++++-----
net/9p/trans_rdma.c | 37 ++++----
net/9p/trans_virtio.c | 44 +++++++---
net/9p/trans_xen.c | 17 ++--
net/9p/util.c | 140 ------------------------------
16 files changed, 482 insertions(+), 551 deletions(-)
delete mode 100644 net/9p/util.c
^ permalink raw reply
* Re: bnx2: rx_fw_discards: BCM5716 sporadically drops packets when update to driver version 2.2.6
From: maowenan @ 2018-10-29 2:15 UTC (permalink / raw)
To: rasesh.mody, netdev, f.fainelli, andrew, linux-kernel
In-Reply-To: <1a94796f-1760-f332-46f0-6ab0b5a0aab7@huawei.com>
Could anyone give some clues to address count of rx_fw_discards increasing issue?
On 2018/10/26 11:15, maowenan wrote:
> Hi，
>
> After I update version of bnx2 driver from 2.2.1 to 2.2.6, I find BCM5716 sporadically drops packets, which
> shows in rx_fw_discards.
> C36-141-5:~ # ethtool -S NIC0
>
> NIC statistics:
> rx_ucast_packets: 11902
>
> rx_mcast_packets: 217
>
> rx_bcast_packets: 4954320
>
> rx_filtered_packets: 328793
>
> rx_fw_discards: 2742
>
> C36-141-5:~ #
>
> 5s later:
>
> C36-141-5:~ # ethtool -S NIC0
>
> NIC statistics:
> rx_ucast_packets: 11910
>
> rx_mcast_packets: 217
>
> rx_bcast_packets: 4958117
>
> rx_filtered_packets: 328897
>
> rx_fw_discards: 2750
>
> C36-141-5:~ #
>
> so rx_fw_discards: 2742-----> rx_fw_discards: 2750, lost 8 packets.
>
> the information of bnx2
> C36-141-5:~ # modinfo bnx2
> kernel/drivers/net/ethernet/broadcom/bnx2.ko
>
> firmware: bnx2/bnx2-rv2p-09ax-6.0.17.fw
>
> firmware: bnx2/bnx2-rv2p-09-6.0.17.fw
>
> firmware: bnx2/bnx2-mips-09-6.2.1b.fw
>
> firmware: bnx2/bnx2-rv2p-06-6.0.15.fw
>
> firmware: bnx2/bnx2-mips-06-6.2.3.fw
> version: 2.2.6
>
>
> 1) Firstly, I check the patches from 2.2.1 to 2.2.6, below patch is interesting.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0021850d0417a4dc38ed871d929b651b87e2ead9
> Do not enable filter SORT MODE in chip init routine. This patch addresses an
> issue where BCM5716 sporadically drops packets when changing multicast list.
>
> diff --git a/drivers/net/ethernet/broadcom/bnx2.c b/drivers/net/ethernet/broadcom/bnx2.c
> index 8957eb5f4478..8c9a8b7787d2 100644
> --- a/drivers/net/ethernet/broadcom/bnx2.c
> +++ b/drivers/net/ethernet/broadcom/bnx2.c
> @@ -4984,8 +4984,6 @@ bnx2_init_chip(struct bnx2 *bp)
>
> bp->idle_chk_status_idx = 0xffff;
>
> - bp->rx_mode = BNX2_EMAC_RX_MODE_SORT_MODE;
> -
> /* Set up how to generate a link change interrupt. */
> BNX2_WR(bp, BNX2_EMAC_ATTENTION_ENA, BNX2_EMAC_ATTENTION_ENA_LINK);
>
>
> 2) Secondly, I revert this patch, after verify it, I find rx_fw_discards does not increasing.
> so I think this patch can fix current issue. But I'm not sure the issue of this patch to fix
> will be reproduced?
> I'm not convinced that what factor will trigger rx_fw_discards increasing?
> And how to fix this?
>
> Thanks a lot.
>
>
>
>
>
>
>
>
>
>
>
>
>
> .
>
^ permalink raw reply
* Re: [PATCH net] net: bridge: remove ipv6 zero address check in mcast queries
From: David Miller @ 2018-10-29 2:18 UTC (permalink / raw)
To: nikolay; +Cc: netdev, roopa, bridge, yinxu, liuhangbin
In-Reply-To: <20181027090747.22104-1-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Sat, 27 Oct 2018 12:07:47 +0300
> Recently a check was added which prevents marking of routers with zero
> source address, but for IPv6 that cannot happen as the relevant RFCs
> actually forbid such packets:
> RFC 2710 (MLDv1):
> "To be valid, the Query message MUST
> come from a link-local IPv6 Source Address, be at least 24 octets
> long, and have a correct MLD checksum."
>
> Same goes for RFC 3810.
>
> And also it can be seen as a requirement in ipv6_mc_check_mld_query()
> which is used by the bridge to validate the message before processing
> it. Thus any queries with :: source address won't be processed anyway.
> So just remove the check for zero IPv6 source address from the query
> processing function.
>
> Fixes: 5a2de63fd1a5 ("bridge: do not add port to router list when receives query with source 0.0.0.0")
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ptp: drop redundant kasprintf() to create worker name
From: David Miller @ 2018-10-29 2:20 UTC (permalink / raw)
To: linux; +Cc: richardcochran, keescook, netdev, linux-kernel
In-Reply-To: <20181026212300.5827-1-linux@rasmusvillemoes.dk>
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date: Fri, 26 Oct 2018 23:22:59 +0200
> Building with -Wformat-nonliteral, gcc complains
>
> drivers/ptp/ptp_clock.c: In function ‘ptp_clock_register’:
> drivers/ptp/ptp_clock.c:239:26: warning: format not a string literal and no format arguments [-Wformat-nonliteral]
> worker_name : info->name);
>
> kthread_create_worker takes fmt+varargs to set the name of the
> worker, and that happens with a vsnprintf() to a stack buffer (that is
> then copied into task_comm). So there's no reason not to just pass
> "ptp%d", ptp->index to kthread_create_worker() and avoid the
> intermediate worker_name variable.
>
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Applied.
^ permalink raw reply
* Re: CAKE and r8169 cause panic on upload in v4.19
From: David Miller @ 2018-10-28 17:45 UTC (permalink / raw)
To: oleksandr
Cc: dave.taht, hkallweit1, toke, jhs, xiyou.wangcong, jiri, netdev,
linux-kernel
In-Reply-To: <3d749bf1ec48ee9f4172b23bde84ec4b@natalenko.name>
From: Oleksandr Natalenko <oleksandr@natalenko.name>
Date: Sun, 28 Oct 2018 13:22:09 +0100
> Hi.
>
> On 28.10.2018 05:44, David Miller wrote:
>> Does this fix it?
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 022ad73d6253..77d43ae2a7bb 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -5457,7 +5457,7 @@ static void gro_flush_oldest(struct list_head
>> *head)
>> /* Do not adjust napi->gro_hash[].count, caller is adding a new
>> * SKB to the chain.
>> */
>> - list_del(&oldest->list);
>> + skb_list_del_init(oldest);
>> napi_gro_complete(oldest);
>> }
>
> Yes, but I had to apply both a8305bff6852 and 992cba7e276d too to get
> it compiled. With these 3 patches the panic is not triggered any more
> while having GRO enabled.
>
> Thanks!
Thanks for testing, I'll queue this up for -stable too:
>From ece23711dd956cd5053c9cb03e9fe0668f9c8894 Mon Sep 17 00:00:00 2001
From: "David S. Miller" <davem@davemloft.net>
Date: Sun, 28 Oct 2018 10:35:12 -0700
Subject: [PATCH] net: Properly unlink GRO packets on overflow.
Just like with normal GRO processing, we have to initialize
skb->next to NULL when we unlink overflow packets from the
GRO hash lists.
Fixes: d4546c2509b1 ("net: Convert GRO SKB handling to list_head.")
Reported-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 022ad73d6253..77d43ae2a7bb 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5457,7 +5457,7 @@ static void gro_flush_oldest(struct list_head *head)
/* Do not adjust napi->gro_hash[].count, caller is adding a new
* SKB to the chain.
*/
- list_del(&oldest->list);
+ skb_list_del_init(oldest);
napi_gro_complete(oldest);
}
--
2.17.2
^ permalink raw reply related
* Re: KASAN: slab-out-of-bounds Read in sctp_getsockopt
From: Marcelo Ricardo Leitner @ 2018-10-28 17:53 UTC (permalink / raw)
To: Xin Long
Cc: syzbot+5da0d0a72a9e7d791748, davem, LKML, linux-sctp, network dev,
Neil Horman, syzkaller-bugs, Vlad Yasevich
In-Reply-To: <CADvbK_fK4jyPXA+ZJUtAFOjRcunqX0XdiEC2nZbnLMVxiJCAmw@mail.gmail.com>
On Sat, Oct 27, 2018 at 02:58:33PM +0900, Xin Long wrote:
> On Sat, Oct 27, 2018 at 1:38 AM syzbot
> <syzbot+5da0d0a72a9e7d791748@syzkaller.appspotmail.com> wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: bd6bf7c10484 Merge tag 'pci-v4.20-changes' of git://git.ke..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=16fd6bcb400000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=2dd8629d56664133
> > dashboard link: https://syzkaller.appspot.com/bug?extid=5da0d0a72a9e7d791748
> > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16b3ea33400000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17f9f1bd400000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+5da0d0a72a9e7d791748@syzkaller.appspotmail.com
> >
> > ==================================================================
> > BUG: KASAN: slab-out-of-bounds in sctp_getsockopt_pr_streamstatus
> > net/sctp/socket.c:7174 [inline]
> Forgot to change to use "&" in sctp_getsockopt_pr_streamstatus() in
> "sctp: get pr_assoc and pr_stream all status with SCTP_PR_SCTP_ALL instead"
>
> @@ -7158,7 +7158,7 @@ static int
> sctp_getsockopt_pr_streamstatus(struct sock *sk, int len,
> goto out;
> }
>
> - if (policy == SCTP_PR_SCTP_ALL) {
> + if (policy & SCTP_PR_SCTP_ALL) {
Hmmm. This is trying to avoid the
streamoute->abandoned_unsent[__SCTP_PR_INDEX(policy)]
with possibly large 'policy' as policy may be SCTP_PR_SCTP_ALL | SCTP_PR_SCTP_MASK
That said, I don't think this is a good fix because the input
parameter was bogus and we would be trying to make some sense out of
it. So I suggest something along these lines:
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index fc0386e8ff23..b816956c69f5 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -7144,6 +7144,8 @@ static int sctp_getsockopt_pr_streamstatus(struct sock *sk, int len,
policy = params.sprstat_policy;
if (!policy || (policy & ~(SCTP_PR_SCTP_MASK | SCTP_PR_SCTP_ALL)))
goto out;
+ if (policy & SCTP_PR_SCTP_ALL && policy & ~SCTP_PR_SCTP_ALL)
+ goto out;
asoc = sctp_id2assoc(sk, params.sprstat_assoc_id);
if (!asoc || params.sprstat_sid >= asoc->stream.outcnt)
To bail out if ALL is specificied together with anything else.
(the if condition probably could be optimized somehow)
>
> > BUG: KASAN: slab-out-of-bounds in sctp_getsockopt+0x7516/0x7cc2
> > net/sctp/socket.c:7582
> > Read of size 8 at addr ffff8801d89f0968 by task syz-executor278/5330
> >
> > CPU: 1 PID: 5330 Comm: syz-executor278 Not tainted 4.19.0+ #303
> > 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+0x244/0x39d lib/dump_stack.c:113
> > print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
> > kasan_report_error mm/kasan/report.c:354 [inline]
> > kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412
> > __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> > sctp_getsockopt_pr_streamstatus net/sctp/socket.c:7174 [inline]
> > sctp_getsockopt+0x7516/0x7cc2 net/sctp/socket.c:7582
> > sock_common_getsockopt+0x9a/0xe0 net/core/sock.c:2937
> > __sys_getsockopt+0x1ad/0x390 net/socket.c:1939
> > __do_sys_getsockopt net/socket.c:1950 [inline]
> > __se_sys_getsockopt net/socket.c:1947 [inline]
> > __x64_sys_getsockopt+0xbe/0x150 net/socket.c:1947
> > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > RIP: 0033:0x445789
> > Code: e8 6c b6 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
> > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> > ff 0f 83 2b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00
> > RSP: 002b:00007effdb293db8 EFLAGS: 00000246 ORIG_RAX: 0000000000000037
> > RAX: ffffffffffffffda RBX: 00000000006dac48 RCX: 0000000000445789
> > RDX: 0000000000000074 RSI: 0000000000000084 RDI: 0000000000000003
> > RBP: 00000000006dac40 R08: 0000000020000040 R09: 0000000000000000
> > R10: 0000000020000080 R11: 0000000000000246 R12: 00000000006dac4c
> > R13: 00007ffcfc408c6f R14: 00007effdb2949c0 R15: 00000000006dad2c
> >
> > Allocated by task 5329:
> > save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> > set_track mm/kasan/kasan.c:460 [inline]
> > kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
> > kmem_cache_alloc_trace+0x152/0x750 mm/slab.c:3620
> > kmalloc include/linux/slab.h:513 [inline]
> > kzalloc include/linux/slab.h:707 [inline]
> > sctp_stream_init_ext+0x4f/0xf0 net/sctp/stream.c:237
> > sctp_sendmsg_to_asoc+0x1308/0x1a20 net/sctp/socket.c:1896
> > sctp_sendmsg+0x13c2/0x1da0 net/sctp/socket.c:2113
> > inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
> > sock_sendmsg_nosec net/socket.c:621 [inline]
> > sock_sendmsg+0xd5/0x120 net/socket.c:631
> > __sys_sendto+0x3d7/0x670 net/socket.c:1788
> > __do_sys_sendto net/socket.c:1800 [inline]
> > __se_sys_sendto net/socket.c:1796 [inline]
> > __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1796
> > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > Freed by task 3223:
> > save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> > set_track mm/kasan/kasan.c:460 [inline]
> > __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
> > kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
> > __cache_free mm/slab.c:3498 [inline]
> > kfree+0xcf/0x230 mm/slab.c:3813
> > kzfree+0x28/0x30 mm/slab_common.c:1543
> > aa_free_file_ctx security/apparmor/include/file.h:76 [inline]
> > apparmor_file_free_security+0x133/0x1a0 security/apparmor/lsm.c:448
> > security_file_free+0x4a/0x80 security/security.c:900
> > file_free fs/file_table.c:54 [inline]
> > __fput+0x4e8/0xa30 fs/file_table.c:294
> > ____fput+0x15/0x20 fs/file_table.c:309
> > task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
> > tracehook_notify_resume include/linux/tracehook.h:188 [inline]
> > exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166
> > prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
> > syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
> > do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > The buggy address belongs to the object at ffff8801d89f0900
> > which belongs to the cache kmalloc-96 of size 96
> > The buggy address is located 8 bytes to the right of
> > 96-byte region [ffff8801d89f0900, ffff8801d89f0960)
> > The buggy address belongs to the page:
> > page:ffffea0007627c00 count:1 mapcount:0 mapping:ffff8801da8004c0 index:0x0
> > flags: 0x2fffc0000000100(slab)
> > raw: 02fffc0000000100 ffffea0007646748 ffffea0007613488 ffff8801da8004c0
> > raw: 0000000000000000 ffff8801d89f0000 0000000100000020 0000000000000000
> > page dumped because: kasan: bad access detected
> >
> > Memory state around the buggy address:
> > ffff8801d89f0800: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > ffff8801d89f0880: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > > ffff8801d89f0900: 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc
> > ^
> > ffff8801d89f0980: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > ffff8801d89f0a00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > ==================================================================
> >
> >
> > ---
> > 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. See:
> > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> > syzbot.
> > syzbot can test patches for this bug, for details see:
> > https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply related
* [GIT] Networking
From: David Miller @ 2018-10-29 2:46 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) GRO overflow entries are not unlinked properly, resulting in list poison
pointers being dereferenced.
2) Fix bridge build with ipv6 disabled, from Nikolay Aleksandrov.
3) Direct packet access and other fixes in BPF from Daniel Borkmann.
4) gred_change_table_def() gets passed the wrong pointer, a pointer to
a set of unparsed attributes instead of the attribute itself. From
Jakub Kicinski.
5) Allow macsec device to be brought up even if it's lowerdev is down,
from Sabrina Dubroca.
Please pull, thanks a lot!
The following changes since commit 345671ea0f9258f410eb057b9ced9cefbbe5dc78:
Merge branch 'akpm' (patches from Andrew) (2018-10-26 19:33:41 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 747569b0a7c537d680bc94a988be6caad9960488:
net: diag: document swapped src/dst in udp_dump_one. (2018-10-28 19:27:21 -0700)
----------------------------------------------------------------
Alexei Starovoitov (1):
Merge branch 'pkt-access-fixes'
Daniel Borkmann (9):
bpf: fix test suite to enable all unpriv program types
bpf: disallow direct packet access for unpriv in cg_skb
bpf: fix direct packet access for flow dissector progs
bpf: fix cg_skb types to hint access type in may_access_direct_pkt_data
bpf: fix direct packet write into pop/peek helpers
bpf: fix leaking uninitialized memory on pop/peek helpers
bpf: make direct packet write unclone more robust
bpf: add bpf_jit_limit knob to restrict unpriv allocations
bpf: fix wrong helper enablement in cgroup local storage
David S. Miller (3):
Merge git://git.kernel.org/.../bpf/bpf
net: Properly unlink GRO packets on overflow.
Merge branch 'macsec-fixes'
Jakub Kicinski (1):
net: sched: gred: pass the right attribute to gred_change_table_def()
Lorenzo Colitti (1):
net: diag: document swapped src/dst in udp_dump_one.
Martin Lau (1):
bpf, btf: fix a missing check bug in btf_parse
Naresh Kamboju (1):
selftests/bpf: add config fragments BPF_STREAM_PARSER and XDP_SOCKETS
Nikolay Aleksandrov (1):
net: bridge: remove ipv6 zero address check in mcast queries
Rasmus Villemoes (1):
ptp: drop redundant kasprintf() to create worker name
Sabrina Dubroca (2):
macsec: update operstate when lower device changes
macsec: let the administrator set UP state even if lowerdev is down
Taehee Yoo (1):
bpf: devmap: fix wrong interface selection in notifier_call
Documentation/sysctl/net.txt | 8 ++++++++
drivers/net/macsec.c | 20 +++++++++++++++++---
drivers/ptp/ptp_clock.c | 6 +-----
include/linux/filter.h | 1 +
kernel/bpf/btf.c | 58 +++++++++++++++++++++++++---------------------------------
kernel/bpf/core.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++---
kernel/bpf/devmap.c | 3 +--
kernel/bpf/helpers.c | 2 --
kernel/bpf/queue_stack_maps.c | 2 ++
kernel/bpf/verifier.c | 13 ++++++++++---
net/bridge/br_multicast.c | 3 +--
net/core/dev.c | 2 +-
net/core/filter.c | 21 +++++++++++++++++----
net/core/sysctl_net_core.c | 10 ++++++++--
net/ipv4/udp_diag.c | 1 +
net/sched/sch_gred.c | 2 +-
tools/testing/selftests/bpf/config | 2 ++
tools/testing/selftests/bpf/test_verifier.c | 15 +++++++++++++--
18 files changed, 155 insertions(+), 63 deletions(-)
^ permalink raw reply
* [PATCH 2/2] dt-binding: mediatek-dwmac: add binding document for MediaTek MT2712 DWMAC
From: Biao Huang @ 2018-10-29 3:04 UTC (permalink / raw)
To: davem, robh+dt
Cc: honghui.zhang, yt.shen, liguo.zhang, mark.rutland, sean.wang,
nelson.chang, matthias.bgg, biao.huang, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, joabreu, andrew
In-Reply-To: <1540782294-27721-1-git-send-email-biao.huang@mediatek.com>
The commit adds the device tree binding documentation for the MediaTek DWMAC
found on MediaTek MT2712.
Signed-off-by: Biao Huang <biao.huang@mediatek.com>
---
.../devicetree/bindings/net/mediatek-dwmac.txt | 49 ++++++++++++++++++++
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/mediatek-dwmac.txt
diff --git a/Documentation/devicetree/bindings/net/mediatek-dwmac.txt b/Documentation/devicetree/bindings/net/mediatek-dwmac.txt
new file mode 100644
index 0000000..8baf0e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/mediatek-dwmac.txt
@@ -0,0 +1,49 @@
+MediaTek DWMAC glue layer controller
+
+This file documents platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+The device node has following properties.
+
+Required properties:
+- compatible: Should be "mediatek,mt2712-gmac" for MT2712 SoC
+- reg: Address and length of the register set for the device
+- interrupts: Should contain the MAC interrupts
+- interrupt-names: Should contain a list of interrupt names corresponding to
+ the interrupts in the interrupts property, if available.
+ Should be "macirq" for the main MAC IRQ
+- clocks: Must contain a phandle for each entry in clock-names.
+- clock-names: the name of the clock listed in the clocks property. These are
+ "axi", "apb", "mac_ext", "mac_parent", "ptp_ref", "ptp_parent", "ptp_top"
+ for MT2712 SoC
+- mac-address: See ethernet.txt in the same directory
+- phy-mode: See ethernet.txt in the same directory
+
+Example:
+
+ eth: ethernet@1101c000 {
+ compatible = "mediatek,mt2712-gmac";
+ reg = <0 0x1101c000 0 0x1300>;
+ interrupts = <GIC_SPI 237 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "macirq";
+ phy-mode ="rgmii-id";
+ mac-address = [00 55 7b b5 7d f7];
+ clock-names = "axi",
+ "apb",
+ "mac_ext",
+ "mac_parent",
+ "ptp_ref",
+ "ptp_parent",
+ "ptp_top";
+ clocks = <&pericfg CLK_PERI_GMAC>,
+ <&pericfg CLK_PERI_GMAC_PCLK>,
+ <&topckgen CLK_TOP_ETHER_125M_SEL>,
+ <&topckgen CLK_TOP_ETHERPLL_125M>,
+ <&topckgen CLK_TOP_ETHER_50M_SEL>,
+ <&topckgen CLK_TOP_APLL1_D3>,
+ <&topckgen CLK_TOP_APLL1>;
+ snps,txpbl = <32>;
+ snps,rxpbl = <32>;
+ snps,reset-gpio = <&pio 87 GPIO_ACTIVE_LOW>;
+ snps,reset-active-low;
+ };
--
1.7.9.5
^ permalink raw reply related
* Re: ethernet "bus" number in DTS ?
From: Michal Suchánek @ 2018-10-28 18:25 UTC (permalink / raw)
To: Florian Fainelli
Cc: andrew@lunn.ch, linuxppc-dev@lists.ozlabs.org, robh,
netdev@vger.kernel.org
In-Reply-To: <27720d1a-a002-5090-d4fc-92ea59b5839a@gmail.com>
On Fri, 26 Oct 2018 15:57:15 -0700
Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 10/23/18 11:22 PM, Michal Suchánek wrote:
> > On Tue, 23 Oct 2018 11:20:36 -0700
> > Florian Fainelli <f.fainelli@gmail.com> wrote:
> >
> >> On 10/23/18 11:02 AM, Joakim Tjernlund wrote:
> >>> On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:
> >
> >>>
> >>> I also noted that using status = "disabled" didn't work either to
> >>> create a fix name scheme. Even worse, all the eth I/F after gets
> >>> renumbered. It seems to me there is value in having stability in
> >>> eth I/F naming at boot. Then userspace(udev) can rename if need
> >>> be.
> >>>
> >>> Sure would like to known more about why this feature is not
> >>> wanted ?
> >>>
> >>> I found
> >>> https://patchwork.kernel.org/patch/4122441/
> >>> You quote policy as reason but surely it must be better to
> >>> have something stable, connected to the hardware name, than
> >>> semirandom naming?
> >>
> >> If the Device Tree nodes are ordered by ascending base register
> >> address, my understanding is that you get the same order as far as
> >> platform_device creation goes, this may not be true in the future
> >> if Rob decides to randomize that, but AFAICT this is still true.
> >> This may not work well with status = disabled properties being
> >> inserted here and there, but we have used that here and it has
> >> worked for as far as I can remember doing it.
> >
> > So this is unstable in several respects. First is changing the
> > enabled/disabled status in the deivecetrees provided by the kernel.
> >
> > Second is if you have hardware hotplug mechanism either by firmware
> > or by loading device overlays.
> >
> > Third is the case when the devicetree is not built as part of the
> > kernel but is instead provided by firmware that initializes the
> > low-level hardware details. Then the ordering by address is not
> > guaranteed nor is that the same address will be used to access the
> > same interface every time. There might be multiple ways to
> > configure the hardware depending on firmware configuration and/or
> > version.
> >
> >
> >> Second, you might want to name network devices ethX, but what if I
> >> want to name them ethernetX or fooX or barX? Should we be
> >> accepting a mechanism in the kernel that would allow someone to
> >> name the interfaces the way they want straight from a name being
> >> provided in Device Tree?
> >
> > Clearly if there is text Ethernet1 printed above the Ethernet port
> > we should provide a mechanism to name the port Ethernet1 by
> > default.
>
> Yes, but then have a specific property that is flexible enough to
> retrieve things like "vital product information". For DSA switches, we
> have an optional "label" property which names the network device
> directly like it would be found on the product's case. Ideally this
> should be much more flexible such that it can point to the appropriate
> node/firmware service/whatever to get that name, which is what some
> people have been working on lately, see [1].
>
> [1]: https://lkml.org/lkml/2018/8/14/1039
That's nice for something unique per-device like MAC address. However,
for something per-model like port labels DT properties should suffice.
>
> The point is don't re-purpose the aliases which is something that
> exists within Device Tree to basically provide a shorter path to a
> specific set of nodes for the boot program to mangle and muck with
> instead of having to resolve a full path to a node. At least that is
> how I conceive it.
>
> Now what complicates the matter is that some OSes like Linux tend to
> use it to also generate seemingly stable index for peripherals that
> are numbered by index such as SPI, I2C, etc buses, which is why we are
> having this conversation here, see below for more.
>
> >
> >>
> >> Aliases are fine for providing relative stability within the Device
> >> Tree itself and boot programs that might need to modify the Device
> >> Tree (e.g: inserting MAC addresses) such that you don't have to
> >> encode logic to search for nodes by compatible strings etc. but
> >> outside of that use case, it seems to me that you can resolve every
> >> naming decision in user-space.
> >
> > However, this is pushing platform-specific knowledge to userspace.
> > The way the Ethernet interface is attached and hence the device
> > properties usable for identifying the device uniquely are
> > platform-specific.
>
> There is always going to be some amount of platform specific knowledge
> to user-space, what matters is the level of abstraction that is
> presented to you.
>
> >
> > On the other hand, aliases are universal when provided. If they are
> > good enough to assign a MAC address they are good enough to provide
> > a stable default name.
>
> We are not talking about the same aliases then. The special Device
> Tree node named "aliases" is a way to create shorted Device Tree node
> paths, it is not by any means an equivalent for what I would rather
> call a "label", or "port name" or silk screen annotation on a PCB for
> instance.
However, if the kernel ethN names are deterministic based on something
like aliases it is trivial to translate them to "port name". As it is
they are pretty much random which is the issue aliases *can* solve.
>
> >
> > I think this is indeed forcing the userspace to reinvent several
> > wheels for no good reason.
>
> udev or systemd will come up with some stable names for your network
> device right off the bat.
As has been already pointed out these names are not stable for various
reasons. *Making* them stable is the whole point of this discussion.
> If you are deeply embedded maybe you don't
> want those, but then use something like the full path in /sys to get
> some stable names based on the SoC's topology.
However, it some devices might be disabled depending on the device
configuration generating stable names is not that easy. Also if bus
topology may differ depending on device/firmware configuration you
cannot assign stable names based just on /sys hierarchy. Also it is
said that /sys hierarchy is not an ABI in the kernel docs so you should
not base your stable device names which *are* an ABI on the
unstable /sys hierarchy.
>
> >
> > What is the problem with adding the aliases?
>
> aliases is IMHO the wrong tool for the job because it is too limiting,
> you want it to be used to have Ethernet controller instance N to be
> named "ethN", what if someone tomorrows says, no this is not good, I
> want the aliases to automatically name my network devices
> "ethernet-controllerN" or "blahblahN"? You see where I am getting
> with that?
Then you can write udev rule to translate ethN to blahlbahN and so long
as the ethN is stable the translation is stable as well. Alternatively
you might want to use a different devicetree property if one existed.
>
> And yes, I do realize that Linux has traditionally named Ethernet
> adapters ethN, but also allows people to name interfaces just the way
> they want even from within the drivers themselves.
>
> Now imagine your platform uses ACPI, and there are no aliases there to
> point a node with a shorter name, how we would go about naming your
> Ethernet controller unless there is a specific VPD/label/sticker
> property that can be somehow be retried?
There is biosdevname for that which uses proprietary BIOS extensions to
look up device names in BIOS.
Thanks
Michal
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2018-10-29 3:19 UTC (permalink / raw)
To: David Miller; +Cc: Andrew Morton, netdev, Linux Kernel Mailing List
In-Reply-To: <20181028.194639.720600183842499774.davem@davemloft.net>
On Sun, Oct 28, 2018 at 7:46 PM David Miller <davem@davemloft.net> wrote:
>
> Please pull, thanks a lot!
Pulled,
Linus
^ permalink raw reply
* Re: [v2, PATCH 0/2] add Ethernet driver support for mt2712
From: biao huang @ 2018-10-29 3:32 UTC (permalink / raw)
To: davem
Cc: robh+dt, honghui.zhang, yt.shen, liguo.zhang, mark.rutland,
nelson.chang, matthias.bgg, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, joabreu, andrew
In-Reply-To: <1540782294-27721-1-git-send-email-biao.huang@mediatek.com>
On Mon, 2018-10-29 at 11:04 +0800, Biao Huang wrote:
> The mt2712 Ethernet IP is from Synopsys, so extend stmmac to support mt2712.
>
sorry, I forgot to add detail descriptions for these patches.
changes in v2:
--since STMMAC driver applied to most Synopsys ip Ethernet, I add
dwmac-mediatek.c to support MediaTek mt2712 in v2.
--abandon Ethernet drivers proposed in v1.
--rewrite dt-binding document for v2 driver.
Best Regards!
^ permalink raw reply
* Re: Your Loan Firm
From: EMRAH GLOBAL LOAN FIRM @ 2018-10-28 19:32 UTC (permalink / raw)
To: Recipients
Are you searching for a Genuine Loan? At an affordable interest rate? Get back to us with your Name and Phone Number
Best Regards,
Emrah Global Loan
^ 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