* 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
* Re: [PATCH 1/1] macsec: reflect the master interface state
From: Radu Rendec @ 2018-10-28 21:14 UTC (permalink / raw)
To: Sabrina Dubroca; +Cc: netdev, davem, ptalbert
In-Reply-To: <20181001125240.GA8219@bistromath.localdomain>
On Mon, 2018-10-01 at 14:52 +0200, Sabrina Dubroca wrote:
> 2018-09-19, 12:44:41 -0400, Radu Rendec wrote:
> > Hello,
>
> Gah, sorry, this fell into the "week-end" crack and I forgot to answer :(
No worries. I was on vacation in the meantime, hence my late reply.
> > On Wed, Sep 19, 2018 at 11:24 AM Sabrina Dubroca <sd@queasysnail.net> wrote:
> > > 2018-09-18, 20:16:12 -0400, Radu Rendec wrote:
> > > > This patch makes macsec interfaces reflect the state of the underlying
> > > > interface: if the master interface changes state to up/down, the macsec
> > > > interface changes its state accordingly.
> > >
> > > Yes, that's a bit unfortunate. I was wondering if we should just allow
> > > setting the device up, and let link state handle the rest.
> >
> > Yes, that could work. It would also be consistent with the idea of
> > propagating only the link state.
>
> Do you want to handle it, or should I?
Too late. I saw your patches this morning. Thanks for sending them out
and sorry for not looking into this sooner.
> > > It's missing small parts of link state handling that I have been
> > > testing, mainly when creating a new device.
> >
> > Can you please be more specific? I've just looked at macsec_newlink()
> > and I didn't notice anything related to link state handling.
>
> Yes, that's actually the problem. For example,
> macvlan_common_newlink() does:
>
> netif_stacked_transfer_operstate(lowerdev, dev);
> linkwatch_fire_event(dev);
>
> If you try to create a macsec device UP with its lowerdev UP:
>
> ip link set $lower up
> ip link add link $lower up type macsec
>
>
> You'll get:
>
> macsec0@$lower: <BROADCAST,MULTICAST,UP,LOWER_UP> [...] state UNKNOWN [...]
>
> and you want "state UP".
That makes sense. Thanks for taking the time to explain this!
> > > I don't like that this completely ignores whether the device was done
> > > independently of the lower link. Maybe the administrator actually
> > > wants the macsec device down, regardless of state changes on the lower
> > > device.
> >
> > I thought about that too and I don't like it either. Perhaps the vlan
> > approach of having a "loose binding" flag is worth considering. Then the
> > admin can decice for themselves.
>
> Do you have a use case where you'd want that? If that solves some
> problem for you (a problem that can't be solved just by fixing the
> current bug), then ok, we can consider it. I prefer to avoid adding
> obscure options and more code unless they're necessary.
I do have a use case, but with the current bugs fixed, it can be
implemented at the application level by setting the admin state on both
the underlying interface and the macsec interface at the same time.
There is no need to implement this in the kernel and complicate the
macsec code unnecessarily.
> And sorry for the delay in answering :/
No need to apologize. I had a huge delay myself in getting back.
Best regards,
Radu Rendec
^ permalink raw reply
* Re: [PATCH net] rtnetlink: Disallow FDB configuration for non-Ethernet device
From: David Ahern @ 2018-10-28 21:37 UTC (permalink / raw)
To: Ido Schimmel, netdev@vger.kernel.org; +Cc: davem@davemloft.net, Vlad Yasevich
In-Reply-To: <20181027203819.7333-1-idosch@mellanox.com>
On 10/27/18 2:39 PM, Ido Schimmel wrote:
> When an FDB entry is configured, the address is validated to have the
> length of an Ethernet address, but the device for which the address is
> configured can be of any type.
>
> The above can result in the use of uninitialized memory when the address
> is later compared against existing addresses since 'dev->addr_len' is
> used and it may be greater than ETH_ALEN, as with ip6tnl devices.
>
> Fix this by making sure that FDB entries are only configured for
> Ethernet devices.
...
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index f679c7a7d761..728a97f9f700 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -3600,6 +3600,11 @@ static int rtnl_fdb_add(struct sk_buff *skb, struct nlmsghdr *nlh,
> return -EINVAL;
> }
>
> + if (dev->type != ARPHRD_ETHER) {
> + NL_SET_ERR_MSG(extack, "invalid device type");
If only Ethernet devices are supported, then the error message can be
more specific: "FDB add only support for Ethernet devices"
> + return -EINVAL;
> + }
> +
> addr = nla_data(tb[NDA_LLADDR]);
>
> err = fdb_vid_parse(tb[NDA_VLAN], &vid, extack);
> @@ -3704,6 +3709,11 @@ static int rtnl_fdb_del(struct sk_buff *skb, struct nlmsghdr *nlh,
> return -EINVAL;
> }
>
> + if (dev->type != ARPHRD_ETHER) {
> + NL_SET_ERR_MSG(extack, "invalid device type");
same here.
> + return -EINVAL;
> + }
> +
> addr = nla_data(tb[NDA_LLADDR]);
>
> err = fdb_vid_parse(tb[NDA_VLAN], &vid, extack);
>
^ permalink raw reply
* Re: WARNING in __debug_object_init (3)
From: Song Liu @ 2018-10-29 6:47 UTC (permalink / raw)
To: eric.dumazet
Cc: dvyukov, syzbot+6e682caa546b7c96c859, edumazet,
Alexei Starovoitov, Daniel Borkmann, David S . Miller, open list,
Networking, syzkaller-bugs
In-Reply-To: <64bc75ce-336d-2115-1016-b10bc920539f@gmail.com>
On Sun, Oct 28, 2018 at 10:45 AM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> 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>
>
Thanks Eric.
Yeah, the version in the linux-next tree was a buggy version. The one
in Linus' tree is correct. I confirmed that this issue doesn't repro in Linus'
tree.
Song
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in sctp_getsockopt
From: Xin Long @ 2018-10-29 6:50 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: syzbot+5da0d0a72a9e7d791748, davem, LKML, linux-sctp, network dev,
Neil Horman, syzkaller-bugs, Vlad Yasevich
In-Reply-To: <20181028175325.GQ6634@localhost.localdomain>
On Mon, Oct 29, 2018 at 2:53 AM Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
>
> 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;
sure, will change to:
@@ -7142,7 +7148,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)))
+ if (!policy || (policy & ~(SCTP_PR_SCTP_MASK | SCTP_PR_SCTP_ALL)) ||
+ ((policy & SCTP_PR_SCTP_ALL) && (policy & SCTP_PR_SCTP_MASK)))
goto out;
including the one in sctp_getsockopt_pr_assocstatus(), thanks.
>
> 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
* Re: [PATCH 1/3] i2c: sh_mobile: Remove dummy runtime PM callbacks
From: Wolfram Sang @ 2018-10-28 22:22 UTC (permalink / raw)
To: Jarkko Nikula
Cc: linux-pm, linux-i2c, Wolfram Sang, netdev, David S . Miller,
Sergei Shtylyov, linux-renesas-soc, linux-usb, Yoshihiro Shimoda
In-Reply-To: <20181024135134.28456-2-jarkko.nikula@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 609 bytes --]
On Wed, Oct 24, 2018 at 04:51:32PM +0300, Jarkko Nikula wrote:
> Platform drivers don't need dummy runtime PM callbacks that just return
> success and non-NULL pm pointer in their struct device_driver in order
> to have runtime PM happening. This has changed since following commits:
>
> 05aa55dddb9e ("PM / Runtime: Lenient generic runtime pm callbacks")
> 543f2503a956 ("PM / platform_bus: Allow runtime PM by default")
> 8b313a38ecff ("PM / Platform: Use generic runtime PM callbacks directly")
>
> Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Applied to for-next, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH net] net: diag: document swapped src/dst in udp_dump_one.
From: Lorenzo Colitti @ 2018-10-29 0:15 UTC (permalink / raw)
To: netdev; +Cc: davem, zenczykowski, xemul, dsahern, Lorenzo Colitti
Since its inception, udp_dump_one has had a bug where userspace
needs to swap src and dst addresses and ports in order to find
the socket it wants. This is because it passes the socket source
address to __udp[46]_lib_lookup's saddr argument, but those
functions are intended to find local sockets matching received
packets, so saddr is the remote address, not the local address.
This can no longer be fixed for backwards compatibility reasons,
so add a brief comment explaining that this is the case. This
will avoid confusion and help ensure SOCK_DIAG implementations
of new protocols don't have the same problem.
Fixes: a925aa00a55 ("udp_diag: Implement the get_exact dumping functionality")
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
---
net/ipv4/udp_diag.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/udp_diag.c b/net/ipv4/udp_diag.c
index d9ad986c7b..5cbb9be052 100644
--- a/net/ipv4/udp_diag.c
+++ b/net/ipv4/udp_diag.c
@@ -42,6 +42,7 @@ static int udp_dump_one(struct udp_table *tbl, struct sk_buff *in_skb,
rcu_read_lock();
if (req->sdiag_family == AF_INET)
+ /* src and dst are swapped for historical reasons */
sk = __udp4_lib_lookup(net,
req->id.idiag_src[0], req->id.idiag_sport,
req->id.idiag_dst[0], req->id.idiag_dport,
--
2.19.1.568.g152ad8e336-goog
^ permalink raw reply related
* [PATCH net] Documentation: ip-sysctl.txt: Document tcp_fwmark_accept
From: Lorenzo Colitti @ 2018-10-29 0:30 UTC (permalink / raw)
To: netdev; +Cc: davem, zenczykowski, Lorenzo Colitti
This patch documents the tcp_fwmark_accept sysctl that was
added in 3.15.
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
---
Documentation/networking/ip-sysctl.txt | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 163b5ff107..32b21571ad 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -316,6 +316,17 @@ tcp_frto - INTEGER
By default it's enabled with a non-zero value. 0 disables F-RTO.
+tcp_fwmark_accept - BOOLEAN
+ If set, incoming connections to listening sockets that do not have a
+ socket mark will set the mark of the accepting socket to the fwmark of
+ the incoming SYN packet. This will cause all packets on that connection
+ (starting from the first SYNACK) to be sent with that fwmark. The
+ listening socket's mark is unchanged. Listening sockets that already
+ have a fwmark set via setsockopt(SOL_SOCKET, SO_MARK, ...) are
+ unaffected.
+
+ Default: 0
+
tcp_invalid_ratelimit - INTEGER
Limit the maximal rate for sending duplicate acknowledgments
in response to incoming TCP packets that are for an existing
--
2.19.1.568.g152ad8e336-goog
^ permalink raw reply related
* Re: [Patch V3 net 05/11] net: hns3: remove unnecessary queue reset in the hns3_uninit_all_ring()
From: tanhuazhong @ 2018-10-29 0:54 UTC (permalink / raw)
To: Sergei Shtylyov, davem
Cc: netdev, linuxarm, salil.mehta, yisen.zhuang, lipeng321,
linyunsheng
In-Reply-To: <cd3e9a2a-e6ef-ceb0-6863-85eaf36841ee@cogentembedded.com>
On 2018/10/28 16:09, Sergei Shtylyov wrote:
> 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.
>
yes, sorry for my poor spelling
>> 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?
>
yes, thanks.
>> 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
>
Greeting.
Huazhong
>
^ permalink raw reply
* Re: [PATCH 1/2] net:stmmac: dwmac-mediatek: add support for mt2712
From: Corentin Labbe @ 2018-10-29 10:08 UTC (permalink / raw)
To: Biao Huang
Cc: davem, robh+dt, mark.rutland, devicetree, nelson.chang, andrew,
netdev, sean.wang, liguo.zhang, linux-kernel, matthias.bgg,
joabreu, linux-mediatek, honghui.zhang, yt.shen, linux-arm-kernel
In-Reply-To: <1540782294-27721-2-git-send-email-biao.huang@mediatek.com>
Hello
I have some minor comments below
On Mon, Oct 29, 2018 at 11:04:53AM +0800, Biao Huang wrote:
> Add Ethernet support for MediaTek SoCs from the mt2712 family
>
> Signed-off-by: Biao Huang <biao.huang@mediatek.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/Kconfig | 8 +
> drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
> .../net/ethernet/stmicro/stmmac/dwmac-mediatek.c | 364 ++++++++++++++++++++
> 3 files changed, 373 insertions(+)
> create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> index edf2036..76d779e 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
> +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> @@ -75,6 +75,14 @@ config DWMAC_LPC18XX
> ---help---
> Support for NXP LPC18xx/43xx DWMAC Ethernet.
>
> +config DWMAC_MEDIATEK
> + tristate "MediaTek MT27xx GMAC support"
> + depends on OF
You should add something like && (COMPILE_TEST || ARCH_MEDIATEK)
[...]
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
> new file mode 100644
> index 0000000..9ccf3a5
> --- /dev/null
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
> @@ -0,0 +1,364 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (c) 2018 MediaTek Inc.
Only SPDX can use the // comment style, the rest should use /**/
[...]
> +static int mt2712_set_interface(struct mediatek_dwmac_plat_data *plat)
> +{
> + int rmii_rxc = plat->rmii_rxc ? RMII_CLK_SRC_RXC : 0;
> + u32 intf_val = 0;
> +
> + /* select phy interface in top control domain */
> + switch (plat->phy_mode) {
> + case PHY_INTERFACE_MODE_MII:
> + intf_val |= PHY_INTF_MII_GMII;
> + break;
> + case PHY_INTERFACE_MODE_RMII:
> + intf_val |= PHY_INTF_RMII;
> + intf_val |= rmii_rxc;
> + break;
> + case PHY_INTERFACE_MODE_RGMII:
> + case PHY_INTERFACE_MODE_RGMII_TXID:
> + case PHY_INTERFACE_MODE_RGMII_RXID:
> + case PHY_INTERFACE_MODE_RGMII_ID:
> + intf_val |= PHY_INTF_RGMII;
> + break;
> + default:
> + pr_err("phy interface not support\n");
I think you could use dev_err() instead.
And I think it is better spelled "not supported".
[...]
> +static int mediatek_dwmac_probe(struct platform_device *pdev)
> +{
> + int ret = 0;
> + struct plat_stmmacenet_data *plat_dat;
> + struct stmmac_resources stmmac_res;
> + struct mediatek_dwmac_plat_data *priv_plat;
> +
> + priv_plat = devm_kzalloc(&pdev->dev, sizeof(*priv_plat), GFP_KERNEL);
> + if (!priv_plat)
> + return -ENOMEM;
> +
> + priv_plat->variant = of_device_get_match_data(&pdev->dev);
> + if (!priv_plat->variant) {
> + dev_err(&pdev->dev, "Missing dwmac-mediatek variant\n");
> + return -EINVAL;
> + }
> +
> + priv_plat->dev = &pdev->dev;
> + priv_plat->np = pdev->dev.of_node;
> + priv_plat->phy_mode = of_get_phy_mode(priv_plat->np);
> +
> + ret = mediatek_dwmac_config_dt(priv_plat);
> + if (ret)
> + return ret;
> +
> + ret = stmmac_get_platform_resources(pdev, &stmmac_res);
> + if (ret)
> + return ret;
> +
> + plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
> + if (IS_ERR(plat_dat))
> + return PTR_ERR(plat_dat);
> +
> + plat_dat->interface = priv_plat->phy_mode;
> + /* clk_csr_i = 250-300MHz & MDC = clk_csr_i/124 */
> + plat_dat->clk_csr = 5;
> + plat_dat->has_gmac4 = 1;
> + plat_dat->has_gmac = 0;
> + plat_dat->pmt = 0;
> + plat_dat->maxmtu = 1500;
ETH_DATA_LEN ?
Regards
^ permalink raw reply
* Re: [PATCH net] net: bridge: remove ipv6 zero address check in mcast queries
From: Hangbin Liu @ 2018-10-29 1:33 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: netdev, roopa, davem, yinxu, bridge
In-Reply-To: <20181027090747.22104-1-nikolay@cumulusnetworks.com>
On Sat, Oct 27, 2018 at 12:07:47PM +0300, Nikolay Aleksandrov 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>
Opps.. Sorry for the mistake and thank you for your fix.
Regards
Hangbin
> ---
> net/bridge/br_multicast.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> index 41cdafbf2ebe..6bac0d6b7b94 100644
> --- a/net/bridge/br_multicast.c
> +++ b/net/bridge/br_multicast.c
> @@ -1428,8 +1428,7 @@ static void br_multicast_query_received(struct net_bridge *br,
> * is 0.0.0.0 should not be added to router port list.
> */
> if ((saddr->proto == htons(ETH_P_IP) && saddr->u.ip4) ||
> - (saddr->proto == htons(ETH_P_IPV6) &&
> - !ipv6_addr_any(&saddr->u.ip6)))
> + saddr->proto == htons(ETH_P_IPV6))
> br_multicast_mark_router(br, port);
> }
>
> --
> 2.17.2
>
^ permalink raw reply
* [PATCH] hinic: Fix l4_type parameter in hinic_task_set_tunnel_l4
From: Nathan Chancellor @ 2018-10-29 10:51 UTC (permalink / raw)
To: Aviad Krawczyk, David S. Miller
Cc: netdev, linux-kernel, Nick Desaulniers, Nathan Chancellor
Clang warns:
drivers/net/ethernet/huawei/hinic/hinic_tx.c:392:34: error: implicit
conversion from enumeration type 'enum hinic_l4_tunnel_type' to
different enumeration type 'enum hinic_l4_offload_type'
[-Werror,-Wenum-conversion]
hinic_task_set_tunnel_l4(task, TUNNEL_UDP_NO_CSUM,
~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~~~
1 error generated.
It seems that hinic_task_set_tunnel_l4 was meant to take an enum of type
hinic_l4_tunnel_type, not hinic_l4_offload_type, given both the name of
the functions and the values used.
Fixes: cc18a7543d2f ("net-next/hinic: add checksum offload and TSO support")
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/net/ethernet/huawei/hinic/hinic_hw_qp.c | 2 +-
drivers/net/ethernet/huawei/hinic/hinic_hw_qp.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_qp.c b/drivers/net/ethernet/huawei/hinic/hinic_hw_qp.c
index 967c993d5303..bbf9bdd0ee3e 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_qp.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_qp.c
@@ -532,7 +532,7 @@ void hinic_task_set_inner_l3(struct hinic_sq_task *task,
}
void hinic_task_set_tunnel_l4(struct hinic_sq_task *task,
- enum hinic_l4_offload_type l4_type,
+ enum hinic_l4_tunnel_type l4_type,
u32 tunnel_len)
{
task->pkt_info2 |= HINIC_SQ_TASK_INFO2_SET(l4_type, TUNNEL_L4TYPE) |
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_qp.h b/drivers/net/ethernet/huawei/hinic/hinic_hw_qp.h
index a0dc63a4bfc7..038522e202b6 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_qp.h
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_qp.h
@@ -160,7 +160,7 @@ void hinic_task_set_inner_l3(struct hinic_sq_task *task,
u32 network_len);
void hinic_task_set_tunnel_l4(struct hinic_sq_task *task,
- enum hinic_l4_offload_type l4_type,
+ enum hinic_l4_tunnel_type l4_type,
u32 tunnel_len);
void hinic_set_cs_inner_l4(struct hinic_sq_task *task,
--
2.19.1
^ permalink raw reply related
* Re: [PATCH net] net: sched: gred: pass the right attribute to gred_change_table_def()
From: David Miller @ 2018-10-29 2:24 UTC (permalink / raw)
To: jakub.kicinski; +Cc: tgraf, jhs, xiyou.wangcong, netdev, oss-drivers
In-Reply-To: <20181026225106.5510-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Fri, 26 Oct 2018 15:51:06 -0700
> gred_change_table_def() takes a pointer to TCA_GRED_DPS attribute,
> and expects it will be able to interpret its contents as
> struct tc_gred_sopt. Pass the correct gred attribute, instead of
> TCA_OPTIONS.
>
> This bug meant the table definition could never be changed after
> Qdisc was initialized (unless whatever TCA_OPTIONS contained both
> passed netlink validation and was a valid struct tc_gred_sopt...).
...
> Fixes: f62d6b936df5 ("[PKT_SCHED]: GRED: Use central VQ change procedure")
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Quite an ancient bug :-)
Applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH net 0/2] macsec: linkstate fixes
From: David Miller @ 2018-10-29 2:26 UTC (permalink / raw)
To: sd; +Cc: netdev, radu.rendec, ptalbert
In-Reply-To: <cover.1540714256.git.sd@queasysnail.net>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Sun, 28 Oct 2018 09:33:08 +0100
> 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/
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net] net: diag: document swapped src/dst in udp_dump_one.
From: David Miller @ 2018-10-29 2:27 UTC (permalink / raw)
To: lorenzo; +Cc: netdev, zenczykowski, xemul, dsahern
In-Reply-To: <20181029001522.54391-1-lorenzo@google.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Mon, 29 Oct 2018 09:15:22 +0900
> Since its inception, udp_dump_one has had a bug where userspace
> needs to swap src and dst addresses and ports in order to find
> the socket it wants. This is because it passes the socket source
> address to __udp[46]_lib_lookup's saddr argument, but those
> functions are intended to find local sockets matching received
> packets, so saddr is the remote address, not the local address.
>
> This can no longer be fixed for backwards compatibility reasons,
> so add a brief comment explaining that this is the case. This
> will avoid confusion and help ensure SOCK_DIAG implementations
> of new protocols don't have the same problem.
>
> Fixes: a925aa00a55 ("udp_diag: Implement the get_exact dumping functionality")
> Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Applied, thanks.
^ permalink raw reply
* [PATCH] kselftests/bpf: use ping6 as the default ipv6 ping binary if it exists
From: Li Zhijian @ 2018-10-29 11:14 UTC (permalink / raw)
To: shuah, netdev, linux-kselftest; +Cc: linux-kernel, ast, daniel, Li Zhijian
ping binary on some distros doesn't support "ping -6" anymore.
Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
---
tools/testing/selftests/bpf/test_skb_cgroup_id.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/test_skb_cgroup_id.sh b/tools/testing/selftests/bpf/test_skb_cgroup_id.sh
index 42544a9..a9bc6f8 100755
--- a/tools/testing/selftests/bpf/test_skb_cgroup_id.sh
+++ b/tools/testing/selftests/bpf/test_skb_cgroup_id.sh
@@ -10,7 +10,7 @@ wait_for_ip()
echo -n "Wait for testing link-local IP to become available "
for _i in $(seq ${MAX_PING_TRIES}); do
echo -n "."
- if ping -6 -q -c 1 -W 1 ff02::1%${TEST_IF} >/dev/null 2>&1; then
+ if $PING6 -c 1 -W 1 ff02::1%${TEST_IF} >/dev/null 2>&1; then
echo " OK"
return
fi
@@ -58,5 +58,6 @@ BPF_PROG_OBJ="${DIR}/test_skb_cgroup_id_kern.o"
BPF_PROG_SECTION="cgroup_id_logger"
BPF_PROG_ID=0
PROG="${DIR}/test_skb_cgroup_id_user"
+type ping6 >/dev/null 2>&1 && PING6="ping6" || PING6="ping -6"
main
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 2/2] net: qcom/emac: add phy-handle support for ACPI
From: Wang, Dongsheng @ 2018-10-29 2:39 UTC (permalink / raw)
To: Andrew Lunn
Cc: Timur Tabi, Zheng, Joey, f.fainelli@gmail.com,
netdev@vger.kernel.org, robert.moore@intel.com, rjw@rjwysocki.net,
linux-acpi@vger.kernel.org
In-Reply-To: <20181026131301.GC30093@lunn.ch>
On 2018/10/26 21:12, Andrew Lunn wrote:
> On Fri, Oct 26, 2018 at 03:04:25AM +0000, Wang, Dongsheng wrote:
>> On 2018/10/26 10:37, Timur Tabi wrote:
>>> On 10/25/18 9:18 PM, Wang, Dongsheng wrote:
>>>> But when I was reading Documentation/acpi/DSD-properties-rules.txt, my
>>>> understanding is we should try to conform to DT bindings. So maybe ACPI
>>>> doesn't have such a document, just DT bindings.
>>> There was an attempt to document DSDs, but it was abandoned after a while.
>>>
>>> https://github.com/ahs3/dsd
>>>
>> Yes, here's a database concept, and I asked some Intel guys, the answer
>> I got was there is no such database or document. :(
> Hi Dongsheng
>
> If there is no clear documentation for ACPI, it becomes even more
> important that the xgene code is refactored into a central location,
> and you make use of it. We really need to avoid every ACPI ethernet
> driver doing its own thing.
However, without a document specifying MDIO and phy-handle, it is almost
difficult for us to do this. Because maybe the ACPI device or property
corresponding to each platform is different.
Just like APM looks different to us. APM's MDIO adev doesn't describe
the concept of port, and our platform does. Besides, I cannot get the
ACPI table of APM or other manufacturers.
The table of ACPI cannot be obtained from kernel source as easily as DT.
We can't know without a platform to do ACPI dump. Unless some of the
manufacturers have pushed the table to upstream.
So I think we might have a hard time doing this without a document. And
it's likely that this work involves code modifications by BIOS vendors.
Cheers,
Dongsheng
^ 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