* Re: [PATCH 0/2] bpf: context casting for tail call and gtrace prog type
From: Kris Van Hees @ 2019-02-26 6:46 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: Kris Van Hees, netdev, bpf, daniel
In-Reply-To: <20190226061823.f7hfs7yojfuycqmg@ast-mbp.dhcp.thefacebook.com>
On Mon, Feb 25, 2019 at 10:18:25PM -0800, Alexei Starovoitov wrote:
> On Mon, Feb 25, 2019 at 07:54:13AM -0800, Kris Van Hees wrote:
> >
> > The goal is to further extend the BPF_PROG_TYPE_GTRACE implementation to
> > support what tracers commonly need, and I am also looking at ways to further
> > extend this model to allow more tracer-specific features as well without the
> > need for adding a BPF program types for every tracer.
>
> It seems by themselves the patches don't provide any new functionality,
> but instead look like plumbing to call external code.
The patches are definitely not plumbing to call external code, and if I gave
that impression I apologise. I overlooked the information you quote below on
allowing new functionality through modules when I wrote the comment above but
please note that it was a forward-looking comment in terms of what could be
done - not a reason for the patches that I submitted.
The patches accomplish something that is totally independent from that: they
make it possible for existing events that execute BPF programs when triggered
to transfer control to a BPF program with a more rich context. The first
patch makes such a transfer possible (using tail-call combined with converting
the context to the new program type), and the second patch provides one such
program type (generic trace). The new functionality provided by the program
type is direct access to task information that previously could only be
obtained through helper calls. E.g. the new program type allows programs to
access the task state, prio, ppid, euid, and egid. None of those pieces of
information can currently be obtained unless you start poking around in
memory using bpf_probe_read() helper calls.
> This is no-go.
> There were several attempts to do so in the past, so we documented it here:
> Documentation/bpf/bpf_design_QA.rst
> Q: New functionality via kernel modules?
> ----------------------------------------
> Q: Can BPF functionality such as new program or map types, new
> helpers, etc be added out of kernel module code?
>
> A: NO.
>
> The answer is still the same.
Thanks for pointing this out - but again, my reference to modules was merely
musing about the possibilities. This information clearly closes the door on
that train of thought, but that is not directly related to what I am doing
with the patches I submitted.
Kris
^ permalink raw reply
* Re: [PATCH net-next v2 5/7] net: sched: pie: add more cases to auto-tune alpha and beta
From: kbuild test robot @ 2019-02-26 6:48 UTC (permalink / raw)
To: Leslie Monis
Cc: kbuild-all, jhs, netdev, dave, Mohit P. Tahiliani, Dhaval Khandla,
Hrishikesh Hiraskar, Manish Kumar B, Sachin D . Patil,
Leslie Monis
In-Reply-To: <20190225102051.12268-6-lesliemonis@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 851 bytes --]
Hi Mohit,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Leslie-Monis/net-sched-pie-align-PIE-implementation-with-RFC-8033/20190226-041701
config: mips-allmodconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 8.2.0-11) 8.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.2.0 make.cross ARCH=mips
All errors (new ones prefixed by >>):
>> ERROR: "__udivdi3" [net/sched/sch_pie.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 58625 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 5/6] devlink: hold a reference to the netdevice around ethtool compat
From: Jiri Pirko @ 2019-02-26 6:50 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, mkubecek, andrew, f.fainelli, netdev, oss-drivers
In-Reply-To: <20190225103127.4f17f900@cakuba.netronome.com>
Mon, Feb 25, 2019 at 07:31:27PM CET, jakub.kicinski@netronome.com wrote:
>On Sun, 24 Feb 2019 12:00:03 +0100, Jiri Pirko wrote:
>> Fri, Feb 22, 2019 at 11:07:56PM CET, jakub.kicinski@netronome.com wrote:
>> >When ethtool is calling into devlink compat code make sure we have
>> >a reference on the netdevice on which the operation was invoked.
>> >
>> >v3: move the hold/lock logic into devlink_compat_* functions (Florian)
>> >
>> >Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>> >---
>> > net/core/devlink.c | 34 +++++++++++++++++++++++-----------
>> > net/core/ethtool.c | 13 ++-----------
>> > 2 files changed, 25 insertions(+), 22 deletions(-)
>> >
>> >diff --git a/net/core/devlink.c b/net/core/devlink.c
>> >index a13055160be0..78c6ea1870ca 100644
>> >--- a/net/core/devlink.c
>> >+++ b/net/core/devlink.c
>> >@@ -6430,27 +6430,39 @@ void devlink_compat_running_version(struct net_device *dev,
>> > {
>> > struct devlink *devlink;
>> >
>> >+ dev_hold(dev);
>> >+ rtnl_unlock();
>>
>> Ha, I got it now. You rely on dev_hold to make sure the
>> devlink instance does not dissappear. But until this patch, that is not
>> guaranteed (or I'm missing it).
>
>Yup, I think the expectation that drivers should free netdevs before
>unregistering devlink holds today. But it may be a source of bugs :S
Sure.
>
>I can add take devlink_mutex, and check the devlink instance is
>registered. Do you prefer an explicit ->registered field like port has,
>or can I do this:
Yeah, let's add WARN_ON.
>
>diff --git a/net/core/devlink.c b/net/core/devlink.c
>index cefcc0f45d44..be39ad6a4e2e 100644
>--- a/net/core/devlink.c
>+++ b/net/core/devlink.c
>@@ -5275,6 +5275,7 @@ struct devlink *devlink_alloc(const struct devlink_ops *ops, size_t priv_size)
> return NULL;
> devlink->ops = ops;
> devlink_net_set(devlink, &init_net);
>+ INIT_LIST_HEAD(&devlink->list);
> INIT_LIST_HEAD(&devlink->port_list);
> INIT_LIST_HEAD(&devlink->sb_list);
> INIT_LIST_HEAD_RCU(&devlink->dpipe_table_list);
>@@ -5303,6 +5304,11 @@ int devlink_register(struct devlink *devlink, struct device *dev)
> }
> EXPORT_SYMBOL_GPL(devlink_register);
>
>+static bool devlink_is_registered(struct devlink *devlink)
>+{
>+ return list_empty(&devlink->list);
>+}
>+
> /**
> * devlink_unregister - Unregister devlink instance
> *
>@@ -5312,7 +5318,7 @@ void devlink_unregister(struct devlink *devlink)
> {
> mutex_lock(&devlink_mutex);
> devlink_notify(devlink, DEVLINK_CMD_DEL);
>- list_del(&devlink->list);
>+ list_del_init(&devlink->list);
> mutex_unlock(&devlink_mutex);
> }
> EXPORT_SYMBOL_GPL(devlink_unregister);
>
>?
^ permalink raw reply
* Re: [PATCH net-next v3 6/6] devlink: add missing NULL checks for devlink ops
From: Jiri Pirko @ 2019-02-26 6:50 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, mkubecek, andrew, f.fainelli, netdev, oss-drivers
In-Reply-To: <20190225103249.15d26b32@cakuba.netronome.com>
Mon, Feb 25, 2019 at 07:32:49PM CET, jakub.kicinski@netronome.com wrote:
>On Sun, 24 Feb 2019 12:03:19 +0100, Jiri Pirko wrote:
>> Fri, Feb 22, 2019 at 11:07:57PM CET, jakub.kicinski@netronome.com wrote:
>>> Commit 76726ccb7f46 ("devlink: add flash update command") and
>>> commit 2d8dc5bbf4e7 ("devlink: Add support for reload")
>>> access devlink ops without NULL-checking. Add the missing checks.
>>> Note that all drivers currently implementing devlink pass non-NULL
>>> ops, so this is not a problem.
>>
>> Wouldn't it be better to rather put WARN_ON&fail when driver calls
>> devlink_alloc() with NULL ops and avoid these checks in the whole code?
>
>Sounds good! Should I remove the existing ones?
Yes please.
^ permalink raw reply
* [PATCH net] net: phy: phylink: fix uninitialized variable in phy_resolve
From: Heiner Kallweit @ 2019-02-26 7:23 UTC (permalink / raw)
To: Russell King - ARM Linux, David Miller, Andrew Lunn,
Florian Fainelli
Cc: netdev@vger.kernel.org
When debugging an issue I found implausible values in state->pause.
Reason in that state->pause isn't initialized and later only single
bits are changed. Also the struct itself isn't initialized in
phylink_resolve(). So better initialize state->pause.
Fixes: 9525ae83959b ("phylink: add phylink infrastructure")
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phylink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 59d175a5b..a9954c205 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -324,6 +324,7 @@ static int phylink_get_mac_state(struct phylink *pl, struct phylink_link_state *
linkmode_zero(state->lp_advertising);
state->interface = pl->link_config.interface;
state->an_enabled = pl->link_config.an_enabled;
+ state->pause = MLO_PAUSE_NONE;
state->link = 1;
return pl->ops->mac_link_state(ndev, state);
--
2.20.1
^ permalink raw reply related
* [PATCH v2 net] net: phy: phylink: fix uninitialized variable in phylink_get_mac_state
From: Heiner Kallweit @ 2019-02-26 7:25 UTC (permalink / raw)
To: Russell King - ARM Linux, David Miller, Andrew Lunn,
Florian Fainelli
Cc: netdev@vger.kernel.org
When debugging an issue I found implausible values in state->pause.
Reason in that state->pause isn't initialized and later only single
bits are changed. Also the struct itself isn't initialized in
phylink_resolve(). So better initialize state->pause.
v2:
- use right function name in subject
Fixes: 9525ae83959b ("phylink: add phylink infrastructure")
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phylink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 59d175a5b..a9954c205 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -324,6 +324,7 @@ static int phylink_get_mac_state(struct phylink *pl, struct phylink_link_state *
linkmode_zero(state->lp_advertising);
state->interface = pl->link_config.interface;
state->an_enabled = pl->link_config.an_enabled;
+ state->pause = MLO_PAUSE_NONE;
state->link = 1;
return pl->ops->mac_link_state(ndev, state);
--
2.20.1
^ permalink raw reply related
* Re: kernel BUG at include/linux/mm.h:LINE! (2)
From: Eric Biggers @ 2019-02-26 7:27 UTC (permalink / raw)
To: syzbot
Cc: davem, edumazet, kuznet, linux-kernel, netdev, syzkaller-bugs,
yoshfuji
In-Reply-To: <000000000000b5f145056e2121a4@google.com>
On Fri, Jun 08, 2018 at 06:11:02AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 7170e6045a6a strparser: Add __strp_unpause and use it in k..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=114236af800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=a601a80fec461d44
> dashboard link: https://syzkaller.appspot.com/bug?extid=3225ce21c0e9929bb9cf
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=10f44fdf800000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=110f636f800000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+3225ce21c0e9929bb9cf@syzkaller.appspotmail.com
>
> flags: 0x2fffc0000000000()
> raw: 02fffc0000000000 0000000000000000 0000000000000000 00000000ffffff80
> raw: ffffea0006b29220 ffff88021fffac18 0000000000000003 0000000000000000
> page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) <= 0)
> ------------[ cut here ]------------
> kernel BUG at include/linux/mm.h:853!
> invalid opcode: 0000 [#1] SMP KASAN
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 4545 Comm: syz-executor492 Not tainted 4.17.0-rc7+ #82
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:get_page include/linux/mm.h:853 [inline]
> RIP: 0010:do_tcp_sendpages+0x1879/0x1e60 net/ipv4/tcp.c:1002
> RSP: 0018:ffff8801c2a06f88 EFLAGS: 00010203
> RAX: 0000000000000000 RBX: ffff8801d972d580 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: ffffffff81a66c25 RDI: ffffed0038540de0
> RBP: ffff8801c2a071e8 R08: ffff8801b11d2480 R09: 0000000000000006
> R10: ffff8801b11d2480 R11: 0000000000000000 R12: 000000000000301d
> R13: ffffea0006b2621c R14: ffff8801ae5a6040 R15: dffffc0000000000
> FS: 0000000000000000(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020008000 CR3: 0000000008c6a000 CR4: 00000000001406e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> tls_push_sg+0x25b/0x860 net/tls/tls_main.c:126
> tls_push_record+0xae5/0x13e0 net/tls/tls_sw.c:266
> tls_sw_push_pending_record+0x22/0x30 net/tls/tls_sw.c:276
> tls_handle_open_record net/tls/tls_main.c:164 [inline]
> tls_sk_proto_close+0x734/0xad0 net/tls/tls_main.c:264
> inet_release+0x104/0x1f0 net/ipv4/af_inet.c:427
> inet6_release+0x50/0x70 net/ipv6/af_inet6.c:459
> sock_release+0x96/0x1b0 net/socket.c:594
> sock_close+0x16/0x20 net/socket.c:1149
> __fput+0x34d/0x890 fs/file_table.c:209
> ____fput+0x15/0x20 fs/file_table.c:243
> task_work_run+0x1e4/0x290 kernel/task_work.c:113
> exit_task_work include/linux/task_work.h:22 [inline]
> do_exit+0x1aee/0x2730 kernel/exit.c:865
> do_group_exit+0x16f/0x430 kernel/exit.c:968
> __do_sys_exit_group kernel/exit.c:979 [inline]
> __se_sys_exit_group kernel/exit.c:977 [inline]
> __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:977
> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x43f368
> RSP: 002b:00007ffd03500578 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000000000043f368
> RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
> RBP: 00000000004bf448 R08: 00000000000000e7 R09: ffffffffffffffd0
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
> R13: 00000000006d1180 R14: 0000000000000000 R15: 0000000000000000
> Code: ff ff 41 89 86 cc 08 00 00 e8 e4 07 05 00 e9 2c eb ff ff e8 ca 4b 27
> fb 48 8b bd b8 fd ff ff 48 c7 c6 40 0c 54 88 e8 77 72 54 fb <0f> 0b 48 89 85
> b8 fd ff ff e8 a9 4b 27 fb 48 8b 85 b8 fd ff ff
> RIP: get_page include/linux/mm.h:853 [inline] RSP: ffff8801c2a06f88
> RIP: do_tcp_sendpages+0x1879/0x1e60 net/ipv4/tcp.c:1002 RSP:
> ffff8801c2a06f88
> ---[ end trace 500a6e4fab99629c ]---
>
>
> ---
> 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
>
AFAICS this was fixed by this commit:
commit d829e9c4112b52f4f00195900fd4c685f61365ab
Author: Daniel Borkmann <daniel@iogearbox.net>
Date: Sat Oct 13 02:45:59 2018 +0200
tls: convert to generic sk_msg interface
So telling syzbot:
#syz fix: tls: convert to generic sk_msg interface
The issue was that described in this comment in tls_sw_sendmsg():
/* Open records defined only if successfully copied, otherwise
* we would trim the sg but not reset the open record frags.
*/
tls_ctx->pending_open_record_frags = true;
Basically, on sendmsg() to a TLS socket, if the message buffer was partially
unmapped, a TLS record would be marked as pending (and then tried to be sent at
sock_release() time) even though it had actually been discarded.
- Eric
^ permalink raw reply
* Re: KASAN: use-after-free Write in tls_push_record (2)
From: Eric Biggers @ 2019-02-26 7:31 UTC (permalink / raw)
To: Boris Pismenny
Cc: syzbot, aviadye, davejwatson, davem, linux-kernel, netdev,
syzkaller-bugs
In-Reply-To: <bb81a2ef-7908-844d-3161-213973342ddb@mellanox.com>
On Thu, Jul 12, 2018 at 06:44:55AM -0400, Boris Pismenny wrote:
> It seems to me that the crash here is due to write_space being called after
> the close system call. Maybe the correct solution is to move the TX software
> state to be released in sk_destruct. As we already do for the device state
> (see tls_device.c).
>
> Is anyone looking into this one?
>
> On 7/11/2018 8:49 PM, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: 1e09177acae3 Merge tag 'mips_fixes_4.18_3' of
> > git://git.ke..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=128903b2400000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=25856fac4e580aa7
> > dashboard link:
> > https://syzkaller.appspot.com/bug?extid=6c4e6ecbf9a2797be67c
> > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> > syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=12312678400000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13ef76c2400000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+6c4e6ecbf9a2797be67c@syzkaller.appspotmail.com
> >
> > RDX: 00000000fffffdef RSI: 00000000200005c0 RDI: 0000000000000003
> > RBP: 00000000006cb018 R08: 0000000020000000 R09: 000000000000001c
> > R10: 0000000000000040 R11: 0000000000000212 R12: 0000000000000005
> > R13: ffffffffffffffff R14: 0000000000000000 R15: 0000000000000000
> > ==================================================================
> > BUG: KASAN: use-after-free in tls_fill_prepend include/net/tls.h:339
> > [inline]
> > BUG: KASAN: use-after-free in tls_push_record+0x1091/0x1400
> > net/tls/tls_sw.c:239
> > Write of size 1 at addr ffff8801ae430000 by task syz-executor589/4567
> >
> > CPU: 0 PID: 4567 Comm: syz-executor589 Not tainted 4.18.0-rc4+ #141
> > 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+0x1c9/0x2b4 lib/dump_stack.c:113
> > print_address_description+0x6c/0x20b mm/kasan/report.c:256
> > kasan_report_error mm/kasan/report.c:354 [inline]
> > kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
> > __asan_report_store1_noabort+0x17/0x20 mm/kasan/report.c:435
> > tls_fill_prepend include/net/tls.h:339 [inline]
> > tls_push_record+0x1091/0x1400 net/tls/tls_sw.c:239
> > tls_sw_push_pending_record+0x22/0x30 net/tls/tls_sw.c:276
> > tls_handle_open_record net/tls/tls_main.c:164 [inline]
> > tls_sk_proto_close+0x74c/0xae0 net/tls/tls_main.c:264
> > inet_release+0x104/0x1f0 net/ipv4/af_inet.c:427
> > inet6_release+0x50/0x70 net/ipv6/af_inet6.c:459
> > __sock_release+0xd7/0x260 net/socket.c:599
> > sock_close+0x19/0x20 net/socket.c:1150
> > __fput+0x355/0x8b0 fs/file_table.c:209
> > ____fput+0x15/0x20 fs/file_table.c:243
> > task_work_run+0x1ec/0x2a0 kernel/task_work.c:113
> > exit_task_work include/linux/task_work.h:22 [inline]
> > do_exit+0x1b08/0x2750 kernel/exit.c:865
> > do_group_exit+0x177/0x440 kernel/exit.c:968
> > __do_sys_exit_group kernel/exit.c:979 [inline]
> > __se_sys_exit_group kernel/exit.c:977 [inline]
> > __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:977
> > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > RIP: 0033:0x43f358
> > Code: Bad RIP value.
> > RSP: 002b:00007fff51750198 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
> > RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000000000043f358
> > RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
> > RBP: 00000000004bf448 R08: 00000000000000e7 R09: ffffffffffffffd0
> > R10: 0000000000000040 R11: 0000000000000246 R12: 0000000000000001
> > R13: 00000000006d1180 R14: 0000000000000000 R15: 0000000000000000
> >
> > The buggy address belongs to the page:
> > page:ffffea0006b90c00 count:0 mapcount:-128 mapping:0000000000000000
> > index:0x0
> > flags: 0x2fffc0000000000()
> > raw: 02fffc0000000000 ffffea0006b96408 ffff88021fffac18 0000000000000000
> > raw: 0000000000000000 0000000000000003 00000000ffffff7f 0000000000000000
> > page dumped because: kasan: bad access detected
> >
> > Memory state around the buggy address:
> > ffff8801ae42ff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ffff8801ae42ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > > ffff8801ae430000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > ^
> > ffff8801ae430080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > ffff8801ae430100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > ==================================================================
> >
> >
> > ---
> > 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
>
AFAICS this was fixed by this commit:
commit d829e9c4112b52f4f00195900fd4c685f61365ab
Author: Daniel Borkmann <daniel@iogearbox.net>
Date: Sat Oct 13 02:45:59 2018 +0200
tls: convert to generic sk_msg interface
So telling syzbot:
#syz fix: tls: convert to generic sk_msg interface
The issue was that described in this comment in tls_sw_sendmsg():
/* Open records defined only if successfully copied, otherwise
* we would trim the sg but not reset the open record frags.
*/
tls_ctx->pending_open_record_frags = true;
Basically, on sendmsg() to a TLS socket, if the message buffer was partially
unmapped, a TLS record would be marked as pending (and then tried to be sent at
sock_release() time) even though it had actually been discarded.
- Eric
^ permalink raw reply
* Re: [RFC] net: dsa: qca8k: CPU port broken with commit 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")
From: Heiner Kallweit @ 2019-02-26 7:33 UTC (permalink / raw)
To: Michal Vokáč, Andrew Lunn, Vinod Koul
Cc: David S. Miller, Florian Fainelli, netdev
In-Reply-To: <d127618b-873e-e4aa-ea75-f747da5574ee@ysoft.com>
On 20.02.2019 16:02, Michal Vokáč wrote:
> Hi,
>
> Another issue in a row with networking on imx6dl-yapp4 platform [1]
> that uses QCA8334 Ethernet switch.
>
> Very recently, with Vinod and Andrew, we solved an issue with
> RGMII_ID mode by patch[2][3]. I tested those with next-20190215
> and it worked just fine.
>
> The patch[2] was merged into next-20190220 so I tested the latest version.
> Now the cpu port does not work again. I tracked it down to this commit
> 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in
> genphy_read_status") [4]
>
> If I revert the offending commit, cpu port works fine. I suspect the
> problem is on the qca8k driver side but I am not really sure.
> AFAICT autonegotiation is not available on the QCA833x cpu port (MAC0).
>
> Any ideas what may be the root cause of the problem?
>
Hi Michal,
I faced the same issue on a system with Marvell switch.
Should be fixed with 0f3b1cf23f0e ("net: phy: fix reading fixed phy status").
This patch is in net-next currently and should show up in linux-next today.
> Thank you,
> Michal
>
Heiner
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=87489ec3a77f3e01bcf0d46e353ae7112ec8c4f0
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a968b5e9d5879f9535d6099505f9e14abcafb623
> [3] https://lore.kernel.org/patchwork/patch/1043817/
> [4] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=5502b218e001
>
^ permalink raw reply
* Re: general protection fault in tls_push_sg
From: Eric Biggers @ 2019-02-26 7:40 UTC (permalink / raw)
To: syzbot
Cc: aviadye, borisp, davejwatson, davem, linux-kernel, netdev,
syzkaller-bugs
In-Reply-To: <0000000000006a3ec5056f0c25cb@google.com>
On Tue, Jun 19, 2018 at 10:34:01PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: ba4dbdedd3ed Merge tag 'jfs-4.18' of git://github.com/klei..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=112e9ce4400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=f390986c4f7cd566
> dashboard link: https://syzkaller.appspot.com/bug?extid=54bcc120da8da091d609
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+54bcc120da8da091d609@syzkaller.appspotmail.com
>
> netlink: 8 bytes leftover after parsing attributes in process
> `syz-executor0'.
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] SMP KASAN
> CPU: 1 PID: 27979 Comm: syz-executor6 Not tainted 4.18.0-rc1+ #109
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline]
> RIP: 0010:compound_head include/linux/page-flags.h:142 [inline]
> RIP: 0010:put_page include/linux/mm.h:911 [inline]
> RIP: 0010:tls_push_sg+0x2a3/0x880 net/tls/tls_main.c:142
> Code: fa 4d 39 e5 75 a2 e8 bc 50 f1 fa 48 8b 85 08 ff ff ff 49 8d 7f 08 48
> b9 00 00 00 00 00 fc ff df c6 00 00 48 89 f8 48 c1 e8 03 <80> 3c 08 00 0f 85
> 50 05 00 00 48 8b 85 08 ff ff ff 49 8b 5f 08 80
> RSP: 0018:ffff8801c5776d90 EFLAGS: 00010202
> RAX: 0000000000000001 RBX: 0000000000000000 RCX: dffffc0000000000
> RDX: 0000000000000000 RSI: ffffffff868a59e4 RDI: 0000000000000008
> RBP: ffff8801c5776eb0 R08: ffff88018e4fc6c0 R09: ffff8801c5776668
> R10: 0000000000000003 R11: 0000000000000002 R12: 0000000000000000
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> FS: 00007f2d08c17700(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000000001ffffcc0 CR3: 0000000188ce8000 CR4: 00000000001406e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> tls_push_record+0xaec/0x1400 net/tls/tls_sw.c:264
> tls_sw_push_pending_record+0x22/0x30 net/tls/tls_sw.c:276
> tls_handle_open_record net/tls/tls_main.c:164 [inline]
> tls_sk_proto_close+0x74c/0xae0 net/tls/tls_main.c:264
> inet_release+0x104/0x1f0 net/ipv4/af_inet.c:427
> inet6_release+0x50/0x70 net/ipv6/af_inet6.c:459
> __sock_release+0xd7/0x260 net/socket.c:603
> sock_close+0x19/0x20 net/socket.c:1186
> __fput+0x35b/0x8b0 fs/file_table.c:209
> ____fput+0x15/0x20 fs/file_table.c:243
> task_work_run+0x1ec/0x2a0 kernel/task_work.c:113
> exit_task_work include/linux/task_work.h:22 [inline]
> do_exit+0x1b08/0x2750 kernel/exit.c:865
> do_group_exit+0x177/0x440 kernel/exit.c:968
> get_signal+0x88e/0x1970 kernel/signal.c:2468
> do_signal+0x9c/0x21c0 arch/x86/kernel/signal.c:816
> exit_to_usermode_loop+0x2de/0x370 arch/x86/entry/common.c:162
> 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
> RIP: 0033:0x455b29
> Code: 1d ba fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 eb b9 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007f2d08c16ce8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
> RAX: fffffffffffffe00 RBX: 000000000072bec8 RCX: 0000000000455b29
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000072bec8
> RBP: 000000000072bec8 R08: 0000000000000033 R09: 000000000072bea0
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 0000000000a3e81f R14: 00007f2d08c179c0 R15: 0000000000000000
> Modules linked in:
> Dumping ftrace buffer:
> (ftrace buffer empty)
> ---[ end trace d9dfd7279b1a9c99 ]---
> RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline]
> RIP: 0010:compound_head include/linux/page-flags.h:142 [inline]
> RIP: 0010:put_page include/linux/mm.h:911 [inline]
> RIP: 0010:tls_push_sg+0x2a3/0x880 net/tls/tls_main.c:142
>
>
> ---
> 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.
>
(As with the other reports of this...)
AFAICS this was fixed by this commit:
commit d829e9c4112b52f4f00195900fd4c685f61365ab
Author: Daniel Borkmann <daniel@iogearbox.net>
Date: Sat Oct 13 02:45:59 2018 +0200
tls: convert to generic sk_msg interface
So telling syzbot:
#syz fix: tls: convert to generic sk_msg interface
The issue was that described in this comment in tls_sw_sendmsg():
/* Open records defined only if successfully copied, otherwise
* we would trim the sg but not reset the open record frags.
*/
tls_ctx->pending_open_record_frags = true;
Basically, on sendmsg() to a TLS socket, if the message buffer was partially
unmapped, a TLS record would be marked as pending (and then tried to be sent at
sock_release() time) even though it had actually been discarded.
- Eric
^ permalink raw reply
* Re: [PATCH] net: dsa: read mac address from DT for slave device
From: xiaofeis @ 2019-02-26 7:45 UTC (permalink / raw)
To: Florian Fainelli
Cc: Vinod Koul, David S. Miller, linux-arm-msm, Bjorn Andersson,
Andrew Lunn, Vivien Didelot, Niklas Cassel, netdev
In-Reply-To: <d741691d-cc04-442f-8027-9466a331a529@gmail.com>
On 2019-02-26 01:27, Florian Fainelli wrote:
> On 2/25/19 5:28 AM, xiaofeis@codeaurora.org wrote:
>> Hi Florian
>>
>> We have two slave DSA interfaces, wan0 and lan0, one is for wan port,
>> and the other is for lan port. Customer has it's mac address pool,
>> they
>> want
>> to assign the mac address from the pool on wan0, lan0, and other
>> interfaces like
>> wifi, bt. Coreboot/uboot will populate it to the DTS node, so the
>> driver
>> can
>> get it from it's node. For DSA slave interface, it already has it's
>> own
>> DTS node, it's
>> easy to just add one porperty "local-mac-address" there for the usage
>> in
>> DSA driver.
>>
>> If not use DSA framework, normally we will use eth0.x and eth0.y for
>> wan
>> and lan.
>> On this case, customer usually also assign the MAC address on these
>> logical interface
>> from it's pool.
>
> OK, but this is not necessary per my previous explanation: the CPU <=>
> WAN pipe is a separate broadcast domain (otherwise it is a security
> hole
> since you exposing LAN machines to the outside world), and so there is
> no need for a separate MAC address. It might be convenient to have one,
> especially for the provider, if they run a management software (e.g.:
> TR69), but it is not required per-se.
>
> Let me ask a secondary question here, how many Ethernet MACs connect to
> the switch in this configuration? Is there one that is supposed to be
> assigned all LAN traffic and one that is supposed to be assigned all
> WAN
> traffic? If so, then what you are doing makes even less
>
Only one MAC connected to switch cpu port, both lan0 and wan0 are on the
top of
same interface(eth0).
>>
>> On 2019-02-22 23:43, Florian Fainelli wrote:
>>> On 2/22/19 4:58 AM, Vinod Koul wrote:
>>>> From: Xiaofei Shen <xiaofeis@codeaurora.org>
>>>>
>>>> Before creating a slave netdevice, get the mac address from DTS and
>>>> apply in case it is valid.
>>>
>>> Can you explain your use case in details?
>>>
>>> Assigning a MAC address to a network device that represents a switch
>>> port does not quite make sense in general. The switch port is really
>>> representing one end of a pipe, so one side you have stations and on
>>> the
>>> other side, you have the CPU/management Ethernet MAC controller's MAC
>>> address which constitutes a station as well. The DSA slave network
>>> devices are just software constructs meant to steer traffic towards
>>> specific ports of the switch, but they are all from the perpsective
>>> of
>>> traffic reaching the CPU Port in the first place, therefore traffic
>>> that
>>> is generally a known unicast Ethernet frame with the CPU's MAC
>>> address
>>> as MAC DA (and of course all types of unknown MC, management traffic
>>> etc.)
>>>
>>> By default, DSA switch need to come up in a configuration where all
>>> ports (except CPU/management) must be strictly separate from every
>>> other
>>> port such that we can achieve what a standalone Ethernet NIC would
>>> do.
>>> This works because all ports are isolated from one another, so there
>>> is
>>> no cross talk and so having the same MAC address (the one from the
>>> CPU)
>>> on the DSA slave network devices just works, each port is a separate
>>> broadcast domain.
>>>
>>> Once you start bridging one or ore ports, the bridge root port will
>>> have
>>> a MAC address, most likely the one the CPU/management Ethernet MAC,
>>> but
>>> similarly, this is not an issue and that's exactly how a software
>>> bridge
>>> would work as well.
>>>
>>>>
>>>> Signed-off-by: Xiaofei Shen <xiaofeis@codeaurora.org>
>>>> Signed-off-by: Vinod Koul <vkoul@kernel.org>
>>>> ---
>>>> include/net/dsa.h | 1 +
>>>> net/dsa/dsa2.c | 1 +
>>>> net/dsa/slave.c | 5 ++++-
>>>> 3 files changed, 6 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/include/net/dsa.h b/include/net/dsa.h
>>>> index b3eefe8e18fd..aa24ce756679 100644
>>>> --- a/include/net/dsa.h
>>>> +++ b/include/net/dsa.h
>>>> @@ -198,6 +198,7 @@ struct dsa_port {
>>>> unsigned int index;
>>>> const char *name;
>>>> const struct dsa_port *cpu_dp;
>>>> + const char *mac;
>>>> struct device_node *dn;
>>>> unsigned int ageing_time;
>>>> u8 stp_state;
>>>> diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
>>>> index a1917025e155..afb7d9fa42f6 100644
>>>> --- a/net/dsa/dsa2.c
>>>> +++ b/net/dsa/dsa2.c
>>>> @@ -261,6 +261,7 @@ static int dsa_port_setup(struct dsa_port *dp)
>>>> int err = 0;
>>>>
>>>> memset(&dp->devlink_port, 0, sizeof(dp->devlink_port));
>>>> + dp->mac = of_get_mac_address(dp->dn);
>>>>
>>>> if (dp->type != DSA_PORT_TYPE_UNUSED)
>>>> err = devlink_port_register(ds->devlink, &dp->devlink_port,
>>>> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
>>>> index a3fcc1d01615..8e64c4e947c6 100644
>>>> --- a/net/dsa/slave.c
>>>> +++ b/net/dsa/slave.c
>>>> @@ -1308,7 +1308,10 @@ int dsa_slave_create(struct dsa_port *port)
>>>> slave_dev->features = master->vlan_features | NETIF_F_HW_TC;
>>>> slave_dev->hw_features |= NETIF_F_HW_TC;
>>>> slave_dev->ethtool_ops = &dsa_slave_ethtool_ops;
>>>> - eth_hw_addr_inherit(slave_dev, master);
>>>> + if (port->mac && is_valid_ether_addr(port->mac))
>>>> + ether_addr_copy(slave_dev->dev_addr, port->mac);
>>>> + else
>>>> + eth_hw_addr_inherit(slave_dev, master);
>>>> slave_dev->priv_flags |= IFF_NO_QUEUE;
>>>> slave_dev->netdev_ops = &dsa_slave_netdev_ops;
>>>> slave_dev->switchdev_ops = &dsa_slave_switchdev_ops;
>>>>
^ permalink raw reply
* Re: [PATCH net-next] can: kvaser_usb: Use struct_size() in alloc_candev()
From: Marc Kleine-Budde @ 2019-02-26 7:52 UTC (permalink / raw)
To: Gustavo A. R. Silva, Wolfgang Grandegger, David S. Miller
Cc: linux-can, netdev, linux-kernel
In-Reply-To: <20190208031035.GA2665@embeddedor>
On 2/8/19 4:10 AM, Gustavo A. R. Silva wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> void *entry[];
> };
>
> instance = alloc(sizeof(struct foo) + count * sizeof(void *));
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = alloc(struct_size(instance, entry, count));
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied to linux-can-next.
Tnx,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
^ permalink raw reply
* Re: KASAN: use-after-free Read in tls_tx_records
From: Eric Biggers @ 2019-02-26 7:55 UTC (permalink / raw)
To: syzbot
Cc: aviadye, borisp, davejwatson, davem, linux-kernel, netdev,
syzkaller-bugs
In-Reply-To: <000000000000dfb5720576ee2873@google.com>
On Fri, Sep 28, 2018 at 06:09:03AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 1042caa79e93 net-ipv4: remove 2 always zero parameters fro..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=13fff711400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=6da69433212d7e87
> dashboard link: https://syzkaller.appspot.com/bug?extid=c45f79b4e5e940da28a9
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+c45f79b4e5e940da28a9@syzkaller.appspotmail.com
>
> EXT4-fs (sda1): resizing filesystem from 524032 to 6 blocks
> EXT4-fs warning (device sda1): ext4_resize_fs:1930: can't shrink FS - resize
> aborted
> EXT4-fs (sda1): resizing filesystem from 524032 to 6 blocks
> EXT4-fs warning (device sda1): ext4_resize_fs:1930: can't shrink FS - resize
> aborted
> ==================================================================
> BUG: KASAN: use-after-free in tls_tx_records+0x8b0/0x980
> net/tls/tls_sw.c:365
> Read of size 8 at addr ffff8801ce46e040 by task syz-executor3/28575
>
> CPU: 0 PID: 28575 Comm: syz-executor3 Not tainted 4.19.0-rc5+ #235
> 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+0x1c4/0x2b4 lib/dump_stack.c:113
> print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> tls_tx_records+0x8b0/0x980 net/tls/tls_sw.c:365
> tls_sw_free_resources_tx+0x1ec/0xd20 net/tls/tls_sw.c:1552
> tls_sk_proto_close+0x605/0x750 net/tls/tls_main.c:278
> inet_release+0x104/0x1f0 net/ipv4/af_inet.c:428
> inet6_release+0x50/0x70 net/ipv6/af_inet6.c:458
> __sock_release+0xd7/0x250 net/socket.c:579
> sock_close+0x19/0x20 net/socket.c:1141
> __fput+0x385/0xa30 fs/file_table.c:278
> ____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:193 [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
> RIP: 0033:0x457579
> Code: 1d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007f2ccaa3bc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
> RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000457579
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
> RBP: 000000000072bf00 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f2ccaa3c6d4
> R13: 00000000004ef912 R14: 00000000004cc460 R15: 00000000ffffffff
>
> Allocated by task 28575:
> 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
> __do_kmalloc mm/slab.c:3718 [inline]
> __kmalloc+0x14e/0x760 mm/slab.c:3727
> kmalloc include/linux/slab.h:518 [inline]
> kzalloc include/linux/slab.h:707 [inline]
> get_rec+0x147/0x630 net/tls/tls_sw.c:653
> tls_sw_sendmsg+0x47e/0x17a0 net/tls/tls_sw.c:727
> 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 23411:
> 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
> tls_encrypt_done+0x221/0x610 net/tls/tls_sw.c:417
> aead_request_complete include/crypto/internal/aead.h:75 [inline]
> pcrypt_aead_serial+0x7b/0xb0 crypto/pcrypt.c:123
> padata_serial_worker+0x4c6/0x760 kernel/padata.c:349
> process_one_work+0xc90/0x1b90 kernel/workqueue.c:2153
> worker_thread+0x17f/0x1390 kernel/workqueue.c:2296
> kthread+0x35a/0x420 kernel/kthread.c:246
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:413
>
> The buggy address belongs to the object at ffff8801ce46e040
> which belongs to the cache kmalloc-2048 of size 2048
> The buggy address is located 0 bytes inside of
> 2048-byte region [ffff8801ce46e040, ffff8801ce46e840)
> The buggy address belongs to the page:
> page:ffffea0007391b80 count:1 mapcount:0 mapping:ffff8801da800c40 index:0x0
> compound_mapcount: 0
> flags: 0x2fffc0000008100(slab|head)
> raw: 02fffc0000008100 ffffea00071b4f88 ffffea0007344f88 ffff8801da800c40
> raw: 0000000000000000 ffff8801ce46e040 0000000100000003 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801ce46df00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801ce46df80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ffff8801ce46e000: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
> ^
> ffff8801ce46e080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801ce46e100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
>
>
> ---
> 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.
>
(As with the other reports of this...)
AFAICS this was fixed by this commit:
commit d829e9c4112b52f4f00195900fd4c685f61365ab
Author: Daniel Borkmann <daniel@iogearbox.net>
Date: Sat Oct 13 02:45:59 2018 +0200
tls: convert to generic sk_msg interface
So telling syzbot:
#syz fix: tls: convert to generic sk_msg interface
The issue was that described in this comment in tls_sw_sendmsg():
/* Open records defined only if successfully copied, otherwise
* we would trim the sg but not reset the open record frags.
*/
tls_ctx->pending_open_record_frags = true;
Basically, on sendmsg() to a TLS socket, if the message buffer was partially
unmapped, a TLS record would be marked as pending (and then tried to be sent at
sock_release() time) even though it had actually been discarded.
- Eric
^ permalink raw reply
* Re: KASAN: out-of-bounds Write in tls_push_record
From: Eric Biggers @ 2019-02-26 7:59 UTC (permalink / raw)
To: syzbot
Cc: aviadye, borisp, davejwatson, davem, linux-kernel, netdev,
syzkaller-bugs
In-Reply-To: <0000000000007567f0057072d2e7@google.com>
On Sat, Jul 07, 2018 at 06:29:03PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 526674536360 Add linux-next specific files for 20180706
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=17e63968400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=c8d1cfc0cb798e48
> dashboard link: https://syzkaller.appspot.com/bug?extid=43358359519ad16cf05e
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=15790594400000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12b53f48400000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+43358359519ad16cf05e@syzkaller.appspotmail.com
>
> RDX: 00000000fffffdef RSI: 00000000200005c0 RDI: 0000000000000004
> RBP: 00000000006cb018 R08: 0000000020000000 R09: 000000000000001c
> R10: 0000000000000040 R11: 0000000000000216 R12: 0000000000000005
> R13: ffffffffffffffff R14: 0000000000000000 R15: 0000000000000000
> ==================================================================
> BUG: KASAN: out-of-bounds in tls_fill_prepend include/net/tls.h:339 [inline]
> BUG: KASAN: out-of-bounds in tls_push_record+0x1091/0x1400
> net/tls/tls_sw.c:239
> Write of size 1 at addr ffff8801c07b8000 by task syz-executor985/4467
>
> CPU: 0 PID: 4467 Comm: syz-executor985 Not tainted 4.18.0-rc3-next-20180706+
> #1
> 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+0x1c9/0x2b4 lib/dump_stack.c:113
> print_address_description+0x6c/0x20b mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.7+0x242/0x30d mm/kasan/report.c:412
> __asan_report_store1_noabort+0x17/0x20 mm/kasan/report.c:435
> tls_fill_prepend include/net/tls.h:339 [inline]
> tls_push_record+0x1091/0x1400 net/tls/tls_sw.c:239
> tls_sw_push_pending_record+0x22/0x30 net/tls/tls_sw.c:276
> tls_handle_open_record net/tls/tls_main.c:164 [inline]
> tls_sk_proto_close+0x74c/0xae0 net/tls/tls_main.c:264
> inet_release+0x104/0x1f0 net/ipv4/af_inet.c:427
> inet6_release+0x50/0x70 net/ipv6/af_inet6.c:459
> __sock_release+0xd7/0x260 net/socket.c:600
> sock_close+0x19/0x20 net/socket.c:1151
> __fput+0x35d/0x930 fs/file_table.c:215
> ____fput+0x15/0x20 fs/file_table.c:251
> task_work_run+0x1ec/0x2a0 kernel/task_work.c:113
> exit_task_work include/linux/task_work.h:22 [inline]
> do_exit+0x1b08/0x2750 kernel/exit.c:869
> do_group_exit+0x177/0x440 kernel/exit.c:972
> __do_sys_exit_group kernel/exit.c:983 [inline]
> __se_sys_exit_group kernel/exit.c:981 [inline]
> __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:981
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x43f358
> Code: Bad RIP value.
> RSP: 002b:00007ffd4c2414b8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000000000043f358
> RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
> RBP: 00000000004bf448 R08: 00000000000000e7 R09: ffffffffffffffd0
> R10: 0000000000000040 R11: 0000000000000246 R12: 0000000000000001
> R13: 00000000006d1180 R14: 0000000000000000 R15: 0000000000000000
>
> The buggy address belongs to the page:
> page:ffffea000701ee00 count:0 mapcount:-128 mapping:0000000000000000
> index:0x0
> flags: 0x2fffc0000000000()
> raw: 02fffc0000000000 ffffea0006b7be08 ffff88021fffac18 0000000000000000
> raw: 0000000000000000 0000000000000003 00000000ffffff7f 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801c07b7f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ffff8801c07b7f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > ffff8801c07b8000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ^
> ffff8801c07b8080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ffff8801c07b8100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ==================================================================
>
>
> ---
> 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
>
(As with the other reports of this...)
AFAICS this was fixed by this commit:
commit d829e9c4112b52f4f00195900fd4c685f61365ab
Author: Daniel Borkmann <daniel@iogearbox.net>
Date: Sat Oct 13 02:45:59 2018 +0200
tls: convert to generic sk_msg interface
So telling syzbot:
#syz fix: tls: convert to generic sk_msg interface
The issue was that described in this comment in tls_sw_sendmsg():
/* Open records defined only if successfully copied, otherwise
* we would trim the sg but not reset the open record frags.
*/
tls_ctx->pending_open_record_frags = true;
Basically, on sendmsg() to a TLS socket, if the message buffer was partially
unmapped, a TLS record would be marked as pending (and then tried to be sent at
sock_release() time) even though it had actually been discarded.
- Eric
^ permalink raw reply
* Re: [PATCH] can: mark expected switch fall-throughs
From: Marc Kleine-Budde @ 2019-02-26 8:02 UTC (permalink / raw)
To: Gustavo A. R. Silva, Wolfgang Grandegger, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Ludovic Desroches
Cc: linux-can, netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <20190129180612.GA28650@embeddedor>
On 1/29/19 7:06 PM, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> This patch fixes the following warnings:
>
> drivers/net/can/peak_canfd/peak_pciefd_main.c:668:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
> drivers/net/can/spi/mcp251x.c:875:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
> drivers/net/can/usb/peak_usb/pcan_usb.c:422:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
> drivers/net/can/at91_can.c:895:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
> drivers/net/can/at91_can.c:953:15: warning: this statement may fall through [-Wimplicit-fallthrough=]
> drivers/net/can/usb/peak_usb/pcan_usb.c: In function ‘pcan_usb_decode_error’:
> drivers/net/can/usb/peak_usb/pcan_usb.c:422:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
> if (n & PCAN_USB_ERROR_BUS_LIGHT) {
> ^
> drivers/net/can/usb/peak_usb/pcan_usb.c:428:2: note: here
> case CAN_STATE_ERROR_WARNING:
> ^~~~
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> This patch is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough.
>
> Notice that in some cases spelling mistakes were fixed.
> In other cases, the /* fall through */ comment is placed
> at the bottom of the case statement, which is what GCC
> is expecting to find.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Added to linux-can-next.
Tnx
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
^ permalink raw reply
* [PATCH] net: phy: Micrel KSZ8061: link failure after cable connect
From: Rajasingh Thavamani @ 2019-02-26 8:15 UTC (permalink / raw)
Cc: t.rajasingh, Rajasingh Thavamani, Andrew Lunn, Florian Fainelli,
Heiner Kallweit, David S. Miller, netdev, linux-kernel
With Micrel KSZ8061 PHY, the link may occasionally not come up after
Ethernet cable connect. The vendor's (Microchip, former Micrel) errata
sheet 80000688A.pdf descripes the problem and possible workarounds in
detail, see below.
The batch implements workaround 1, which permanently fixes the issue.
DESCRIPTION
Link-up may not occur properly when the Ethernet cable is initially
connected. This issue occurs more commonly when the cable is connected
slowly, but it may occur any time a cable is connected. This issue occurs
in the auto-negotiation circuit, and will not occur if auto-negotiation
is disabled (which requires that the two link partners be set to the
same speed and duplex).
END USER IMPLICATIONS
When this issue occurs, link is not established. Subsequent cable
plug/unplaug cycle will not correct the issue.
WORk AROUND
There are four approaches to work around this issue:
1. This issue can be prevented by setting bit 15 in MMD device address 1,
register 2, prior to connecting the cable or prior to setting the
Restart Auto-negotiation bit in register 0h. The MMD registers are
accessed via the indirect access registers Dh and Eh, or via the Micrel
EthUtil utility as shown here:
. if using the EthUtil utility (usually with a Micrel KSZ8061
Evaluation Board), type the following commands:
> address 1
> mmd 1
> iw 2 b61a
. Alternatively, write the following registers to write to the
indirect MMD register:
Write register Dh, data 0001h
Write register Eh, data 0002h
Write register Dh, data 4001h
Write register Eh, data B61Ah
2. The issue can be avoided by disabling auto-negotiation in the KSZ8061,
either by the strapping option, or by clearing bit 12 in register 0h.
Care must be taken to ensure that the KSZ8061 and the link partner
will link with the same speed and duplex. Note that the KSZ8061
defaults to full-duplex when auto-negotiation is off, but other
devices may default to half-duplex in the event of failed
auto-negotiation.
3. The issue can be avoided by connecting the cable prior to powering-up
or resetting the KSZ8061, and leaving it plugged in thereafter.
4. If the above measures are not taken and the problem occurs, link can
be recovered by setting the Restart Auto-Negotiation bit in
register 0h, or by resetting or power cycling the device. Reset may
be either hardware reset or software reset (register 0h, bit 15).
PLAN
This errata will not be corrected in the future revision.
Signed-off-by: Rajasingh Thavamani <T.Rajasingh@landisgyr.com>
---
drivers/net/phy/micrel.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index b1f959935f50..b7df0295a3ca 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -344,6 +344,17 @@ static int ksz8041_config_aneg(struct phy_device *phydev)
return genphy_config_aneg(phydev);
}
+static int ksz8061_config_init(struct phy_device *phydev)
+{
+ int ret;
+
+ ret = phy_write_mmd(phydev, MDIO_MMD_PMAPMD, MDIO_DEVID1, 0xB61A);
+ if (ret)
+ return ret;
+
+ return kszphy_config_init(phydev);
+}
+
static int ksz9021_load_values_from_of(struct phy_device *phydev,
const struct device_node *of_node,
u16 reg,
@@ -1040,7 +1051,7 @@ static struct phy_driver ksphy_driver[] = {
.name = "Micrel KSZ8061",
.phy_id_mask = MICREL_PHY_ID_MASK,
.features = PHY_BASIC_FEATURES,
- .config_init = kszphy_config_init,
+ .config_init = ksz8061_config_init,
.ack_interrupt = kszphy_ack_interrupt,
.config_intr = kszphy_config_intr,
.suspend = genphy_suspend,
--
2.17.1
^ permalink raw reply related
* Re: [PATCH ethtool V2] ethtool: Add support for 200Gbps (50Gbps per lane) link mode
From: Michal Kubecek @ 2019-02-26 8:16 UTC (permalink / raw)
To: Tariq Toukan
Cc: John W. Linville, netdev, Eran Ben Elisha, alaa, Andrew Lunn,
Aya Levin
In-Reply-To: <1551109474-12838-1-git-send-email-tariqt@mellanox.com>
On Mon, Feb 25, 2019 at 05:44:34PM +0200, Tariq Toukan wrote:
> From: Aya Levin <ayal@mellanox.com>
>
> Introduce 50Gbps per lane link modes and 200Gbps speed, update print
> functions and initialization functions accordingly.
> In addition, update related man page accordingly.
>
> Signed-off-by: Aya Levin <ayal@mellanox.com>
> Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
> ---
> ethtool-copy.h | 18 +++++++++++++++++-
> ethtool.8.in | 15 +++++++++++++++
> ethtool.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 77 insertions(+), 1 deletion(-)
>
> V2:
> - Removed wrong and unneeded initialization of adv_bit.
> - Removed an addition in ethtool-copy.h that does not exist in kernel.
Reviewed-by: Michal Kubecek <mkubecek@suse.cz>
However, as these link modes are defined only in net-next tree at the
moment and won't get into mainline until the 5.1-rc1 merge window, maybe
this should be applied after ethtool 5.0 release (if there is one).
Michal
^ permalink raw reply
* Re: [PATCH net-next v3 0/7] net: sched: pie: align PIE implementation with RFC 8033
From: Leslie Monis @ 2019-02-26 8:20 UTC (permalink / raw)
To: Stephen Hemminger
Cc: davem, netdev, Mohit P . Tahiliani, Dave Taht, Jamal Hadi Salim
In-Reply-To: <20190225163811.4a6b477b@shemminger-XPS-13-9360>
On Mon, Feb 25, 2019 at 04:38:11PM -0800, Stephen Hemminger wrote:
> On Tue, 26 Feb 2019 00:39:54 +0530
> Leslie Monis <lesliemonis@gmail.com> wrote:
>
> > The current implementation of the PIE queuing discipline is according to the
> > IETF draft [http://tools.ietf.org/html/draft-pan-aqm-pie-00] and the paper
> > [PIE: A Lightweight Control Scheme to Address the Bufferbloat Problem].
> > However, a lot of necessary modifications and enhancements have been proposed
> > in RFC 8033, which have not yet been incorporated in the source code of Linux.
> > This patch series helps in achieving the same.
> >
> > Performance tests carried out using Flent [https://flent.org/]
> >
> > Changes from v2 to v3:
> > - Used div_u64() instead of direct division after explicit type casting as
> > recommended by David
> >
> > Changes from v1 to v2:
> > - Excluded the patch setting PIE dynamically active/inactive as the test
> > results were unsatisfactory
> > - Fixed a scaling issue when adding more auto-tuning cases which caused
> > local variables to underflow
> > - Changed the long if/else chain to a loop as suggested by Stephen
> > - Changed the position of the accu_prob variable in the pie_vars
> > structure as recommended by Stephen
> >
> > Mohit P. Tahiliani (7):
> > net: sched: pie: change value of QUEUE_THRESHOLD
> > net: sched: pie: change default value of pie_params->target
> > net: sched: pie: change default value of pie_params->tupdate
> > net: sched: pie: change initial value of pie_vars->burst_time
> > net: sched: pie: add more cases to auto-tune alpha and beta
> > net: sched: pie: add derandomization mechanism
> > net: sched: pie: update references
> >
> > include/uapi/linux/pkt_sched.h | 2 +-
> > net/sched/sch_pie.c | 107 ++++++++++++++++++++-------------
> > 2 files changed, 66 insertions(+), 43 deletions(-)
>
> Are you concerned at all that changes to default values might change
> expected behavior of existing users?
Hi Stephen,
As Dave mentioned, the changes which we have made do not really change the
behaviour of the aqm drastically. Our performance tests show that these changes
improve performance without any side-effects. So existing users (if there are
any) should not be negatively affected in any way.
Leslie
^ permalink raw reply
* [PATCH] tcp: fix __tcp_transmit_skb's comment text
From: Geliang Tang @ 2019-02-26 8:41 UTC (permalink / raw)
To: Eric Dumazet, David S. Miller, Alexey Kuznetsov,
Hideaki YOSHIFUJI
Cc: Geliang Tang, netdev, linux-kernel
The function name tcp_do_sendmsg has been renamed. But it still
appears in __tcp_transmit_skb's comment text. This patch changes
it to tcp_sendmsg_locked.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
---
net/ipv4/tcp_output.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index e72aa0ff5785..67a43b966b8a 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1003,7 +1003,7 @@ static void tcp_update_skb_after_send(struct sock *sk, struct sk_buff *skb,
}
/* This routine actually transmits TCP packets queued in by
- * tcp_do_sendmsg(). This is used by both the initial
+ * tcp_sendmsg_locked(). This is used by both the initial
* transmission and possible later retransmissions.
* All SKB's seen here are completely headerless. It is our
* job to build the TCP header, and pass the packet down to
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 net] net: phy: phylink: fix uninitialized variable in phylink_get_mac_state
From: Russell King - ARM Linux admin @ 2019-02-26 8:43 UTC (permalink / raw)
To: Heiner Kallweit
Cc: David Miller, Andrew Lunn, Florian Fainelli,
netdev@vger.kernel.org
In-Reply-To: <6c710eec-a299-5239-dde1-097209e8868d@gmail.com>
On Tue, Feb 26, 2019 at 08:25:41AM +0100, Heiner Kallweit wrote:
> When debugging an issue I found implausible values in state->pause.
> Reason in that state->pause isn't initialized and later only single
> bits are changed. Also the struct itself isn't initialized in
> phylink_resolve(). So better initialize state->pause.
mac_link_state() is expected to always set this, but this is safer.
Maybe also set state->speed to SPEED_UNKNOWN, state->duplex to
DUPLEX_UNKNOWN and state->an_complete to zero?
>
> v2:
> - use right function name in subject
>
> Fixes: 9525ae83959b ("phylink: add phylink infrastructure")
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
> drivers/net/phy/phylink.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index 59d175a5b..a9954c205 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
> @@ -324,6 +324,7 @@ static int phylink_get_mac_state(struct phylink *pl, struct phylink_link_state *
> linkmode_zero(state->lp_advertising);
> state->interface = pl->link_config.interface;
> state->an_enabled = pl->link_config.an_enabled;
> + state->pause = MLO_PAUSE_NONE;
> state->link = 1;
>
> return pl->ops->mac_link_state(ndev, state);
> --
> 2.20.1
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH][next] Bluetooth: mgmt: Use struct_size() helper
From: Marcel Holtmann @ 2019-02-26 8:48 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Johan Hedberg, David S. Miller, open list:BLUETOOTH DRIVERS,
netdev, linux-kernel
In-Reply-To: <20190225191137.GA24383@embeddedor>
Hi Gustavo,
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes, in particular in the
> context in which this code is being used.
>
> So, change the following form:
>
> sizeof(*rp) + (sizeof(rp->entry[0]) * count);
>
> to :
>
> struct_size(rp, entry, count)
>
> Notice that, in this case, variable rp_len is not necessary, hence
> it is removed.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> ---
> net/bluetooth/mgmt.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH net-next] mlxsw: spectrum: acl: Use struct_size() in kzalloc()
From: Jiri Pirko @ 2019-02-26 8:54 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Jiri Pirko, Ido Schimmel, David S. Miller, netdev, linux-kernel
In-Reply-To: <20190225190132.GA23478@embeddedor>
Mon, Feb 25, 2019 at 08:01:32PM CET, gustavo@embeddedor.com wrote:
>One of the more common cases of allocation size calculations is finding
>the size of a structure that has a zero-sized array at the end, along
>with memory for some number of elements for that array. For example:
>
>struct foo {
> int stuff;
> struct boo entry[];
>};
>
>size = sizeof(struct foo) + count * sizeof(struct boo);
>instance = kzalloc(size, GFP_KERNEL)
>
>Instead of leaving these open-coded and prone to type mistakes, we can
>now use the new struct_size() helper:
>
>instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL)
>
>Notice that, in this case, variable alloc_size is not necessary, hence
>it is removed.
>
>This code was detected with the help of Coccinelle.
>
>Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next v4 2/6] devlink: create a special NDO for getting the devlink instance
From: Jiri Pirko @ 2019-02-26 8:56 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, mkubecek, andrew, f.fainelli, netdev, oss-drivers
In-Reply-To: <20190226033407.32625-3-jakub.kicinski@netronome.com>
Tue, Feb 26, 2019 at 04:34:03AM CET, jakub.kicinski@netronome.com wrote:
>Instead of iterating over all devlink ports add a NDO which
>will return the devlink instance from the driver.
>
>v2: add the netdev_to_devlink() helper (Michal)
>v3: check that devlink has ops (Florian)
>v4: hold devlink_mutex (Jiri)
>
>Suggested-by: Jiri Pirko <jiri@resnulli.us>
>Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net] ipv4: Add ICMPv6 support when parse route ipproto
From: Sabrina Dubroca @ 2019-02-26 9:06 UTC (permalink / raw)
To: Hangbin Liu; +Cc: David Ahern, netdev, Roopa Prabhu, David S . Miller
In-Reply-To: <20190226034854.GT10051@dhcp-12-139.nay.redhat.com>
2019-02-26, 11:48:54 +0800, Hangbin Liu wrote:
> Hi David,
> On Mon, Feb 25, 2019 at 07:23:33PM -0700, David Ahern wrote:
> > On 2/25/19 7:17 PM, Hangbin Liu wrote:
> > > I also thought about this issue. Currently we didn't check the ipproto in both
> > > IPv4 and IPv6. You can set icmp in ip6 rules or icmpv6 in ipv4 rules.
> > > This looks don't make any serious problem. It's just a user mis-configuration,
> > > the kernel check the proto number and won't match normal IP/IPv6 headers.
> > >
> > > But yes, we should make it more strict, do you think if I should add a new
> > > rtm_getroute_parse_ip6_proto() function, or just add a family parameter
> > > in previous function?
> >
> > I see now. rtm_getroute_parse_ip_proto is used for ipv4 and ipv6. For v4
> > IPPROTO_ICMPV6 should not be allowed and for v6 IPPROTO_ICMP should
> > fail. You could a version argument to rtm_getroute_parse_ip_proto and
> > fail as needed.
>
> Sorry I didn't get here. Do you mean add an IPv6 version of
> rtm_getroute_parse_ip_proto?
Add an argument to rtm_getroute_parse_ip_proto that tells what IP
version to use, and then handle IPPROTO_ICMP/IPPROTO_ICMPV6 depending
on that.
For example:
int rtm_getroute_parse_ip_proto(struct nlattr *attr, u8 *ip_proto,
bool ipv6, struct netlink_ext_ack *extack)
And pass false from ipv4/true from ipv6.
--
Sabrina
^ permalink raw reply
* Re: [PATCH net-next v4 5/6] devlink: hold a reference to the netdevice around ethtool compat
From: Jiri Pirko @ 2019-02-26 8:57 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, mkubecek, andrew, f.fainelli, netdev, oss-drivers
In-Reply-To: <20190226033407.32625-6-jakub.kicinski@netronome.com>
Tue, Feb 26, 2019 at 04:34:06AM CET, jakub.kicinski@netronome.com wrote:
>When ethtool is calling into devlink compat code make sure we have
>a reference on the netdevice on which the operation was invoked.
>
>v3: move the hold/lock logic into devlink_compat_* functions (Florian)
>
>Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ 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