* Re: [bpf PATCH v2 2/2] bpf: sockmap only allow ESTABLISHED sock state
From: John Fastabend @ 2018-06-09 21:53 UTC (permalink / raw)
To: daniel, ast; +Cc: edumazet, weiwan, netdev
In-Reply-To: <20180608150644.15153.4135.stgit@john-Precision-Tower-5810>
On 06/08/2018 08:06 AM, John Fastabend wrote:
> Per the note in the TLS ULP (which is actually a generic statement
> regarding ULPs)
>
> /* The TLS ulp is currently supported only for TCP sockets
> * in ESTABLISHED state.
> * Supporting sockets in LISTEN state will require us
> * to modify the accept implementation to clone rather then
> * share the ulp context.
> */
>
> After this patch we only allow socks that are in ESTABLISHED state or
> are being added via a sock_ops event that is transitioning into an
> ESTABLISHED state. By allowing sock_ops events we allow users to
> manage sockmaps directly from sock ops programs. The two supported
> sock_ops ops are BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB and
> BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB.
>
> Also tested with 'netserver -6' and 'netperf -H [IPv6]' as well as
> 'netperf -H [IPv4]'.
>
> Reported-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
> ---
Fixes: 174a79ff9515 ("bpf: sockmap with sk redirect support")
^ permalink raw reply
* Re: [bpf PATCH v2 2/2] bpf: sockmap only allow ESTABLISHED sock state
From: Daniel Borkmann @ 2018-06-09 20:51 UTC (permalink / raw)
To: John Fastabend, edumazet, weiwan, ast; +Cc: netdev
In-Reply-To: <20180608150644.15153.4135.stgit@john-Precision-Tower-5810>
Hi John,
On 06/08/2018 05:06 PM, John Fastabend wrote:
> Per the note in the TLS ULP (which is actually a generic statement
> regarding ULPs)
>
> /* The TLS ulp is currently supported only for TCP sockets
> * in ESTABLISHED state.
> * Supporting sockets in LISTEN state will require us
> * to modify the accept implementation to clone rather then
> * share the ulp context.
> */
>
> After this patch we only allow socks that are in ESTABLISHED state or
> are being added via a sock_ops event that is transitioning into an
> ESTABLISHED state. By allowing sock_ops events we allow users to
> manage sockmaps directly from sock ops programs. The two supported
> sock_ops ops are BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB and
> BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB.
>
> Also tested with 'netserver -6' and 'netperf -H [IPv6]' as well as
> 'netperf -H [IPv4]'.
>
> Reported-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Please also add a Fixes tag to this one. Ok to just reply with one.
Thanks,
Daniel
^ permalink raw reply
* Re: WARNING in do_dentry_open
From: Daniel Borkmann @ 2018-06-09 20:41 UTC (permalink / raw)
To: Dmitry Vyukov, syzbot, Alexei Starovoitov, netdev
Cc: linux-fsdevel, LKML, syzkaller-bugs, Al Viro
In-Reply-To: <92b8621b-cf57-5fe9-23d1-e06b83ee0c78@iogearbox.net>
On 06/08/2018 03:47 PM, Daniel Borkmann wrote:
> On 06/08/2018 03:34 PM, Dmitry Vyukov wrote:
>> On Fri, Jun 8, 2018 at 3:11 PM, syzbot
>> <syzbot+2e7fcab0f56fdbb330b8@syzkaller.appspotmail.com> wrote:
>>> Hello,
>>>
>>> syzbot found the following crash on:
>>>
>>> HEAD commit: 68abbe729567 Merge branch 'akpm' (patches from Andrew)
>>> git tree: upstream
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=130146af800000
>>> kernel config: https://syzkaller.appspot.com/x/.config?x=e5a4673d4582131c
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=2e7fcab0f56fdbb330b8
>>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>>> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1591756f800000
>>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=152236af800000
>>
>> Looking at the reproducer this seems to be related to bpf.
>> +bpf maintainers
>
> Indeed, thanks! Already working on a fix right now.
#syz fix: bpf: implement dummy fops for bpf objects
^ permalink raw reply
* Re: [PATCH v4 9/9] net-next: New ax88796 platform driver for Amiga X-Surf 100 Zorro board (m68k)
From: Michael Schmitz @ 2018-06-09 20:09 UTC (permalink / raw)
To: Michael Karcher
Cc: Geert Uytterhoeven, netdev, Andrew Lunn, Finn Thain,
Florian Fainelli, Linux/m68k, Michael Karcher
In-Reply-To: <16480.46.183.103.8.1528535711.webmail@webmail.zedat.fu-berlin.de>
Hi Michael,
Am 09.06.2018 um 21:15 schrieb Michael Karcher:
> Michael Schmitz schrieb:
>> Hi Michael,
>>> actually, the the block_input / block_output functions were the reason I
>>> included the lib8390.c file. Except for xs100_write / xs100_read, they
>>> are
>>> a verbatim copy from ax88796.c I'm not that enthusiastic about that idea
>>> anymore, but did not get around to improve it. I added a customization
>>> point to ax88796 for a custom block_input / block_output, because the
>>> 8390
>>> core already provides that customization point. What I really need is a
>>> customization point just for the 8390-remote-DMA-via-MMIO functions
>>> (i.e.
>>> xs100_write, xs100_read) instead of the whole block transfer core that
>>> also sets up the remote DMA engine and tries to re-initialize the card
>>> in
>>> case of unexplained problems.
>>
>> OK, so essentially change
>>
>> if (ei_local->word16) {
>> ioread16_rep(nic_base + NE_DATAPORT, buf, count >> 1);
>> if (count & 0x01)
>> buf[count-1] = ei_inb(nic_base + NE_DATAPORT);
>>
>> } else {
>> ioread8_rep(nic_base + NE_DATAPORT, buf, count);
>> }
>>
>> to something like
>>
>> if (ax->block_read) {
>> ax->block_read(dev, buf, count);
>> } else if (ei_local->word16) {
>> ioread16_rep(nic_base + NE_DATAPORT, buf, count >> 1);
>> if (count & 0x01)
>> buf[count-1] = ei_inb(nic_base + NE_DATAPORT);
>>
>> } else {
>> ioread8_rep(nic_base + NE_DATAPORT, buf, count);
>> }
>>
>> and populate ax->block_read() and ax_block_write() from platform data,
>> instead of substituting ax_block_input() / ax_block_output() wholesale?
>
> That's basically how I think the whole lib8390.c story should in fact be
> tackled. Less code duplication, no second include of lib8390 and constrain
> xsurf100.c to the pieces that make this piece of hardware unique.
OK, I'll try that.
>> I must be missing something here.
>
> I don't think so.
>
>> Adds one test for
>> ax->block_read on the critical path but we already have the test for
>> ei_local->word16 there. May need rearranging the tests so the majority
>> of ax88796 users isn't impacted.
> Rearranging sounds like a good idea. As I understand, the only valid
> rearrangement is putting it inside the 16-bit branch, because the xs100
> uses 16-bit transfers and needs the extra byte for odd counts. The code
Thanks, I missed that.
> checks word16 at the beginning of xs100_block_output for that. This has
> the advantage of not hurting users of the 8 bit interface, which might be
> the slowest users of the ax88796, but comes at the cost of not being able
> to customize the block_input/block_output for 8-bit users. As this "cost"
> is not a problem now (no one can customize block_input/block_output
> currently), lets put the block_read check into the word16 block. You might
> want to name the member block_read16 instead of just block_read to convey
> the information, that it is only used if word16 is set.
Fair enough - since any block_input/block_output function always needs
to duplicate quite a bit of 8390 control code, this might be easier.
I'll have to ask Adrian to set up something for me to run speed tests on
though, to see any eventual impact of these changes.
Cheers,
Michael
>> Anyway, your code, your call.
> On the other hand: Your polishing, your call. Thank you for your work on
> gettting the code in good shape for merging.
>
> Kind regards,
> Michael Karcher
>
^ permalink raw reply
* BUG: unable to handle kernel NULL pointer dereference in sock_poll
From: syzbot @ 2018-06-09 19:57 UTC (permalink / raw)
To: davem, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 7d3bf613e99a Merge tag 'libnvdimm-for-4.18' of git://git.k..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1188a05f800000
kernel config: https://syzkaller.appspot.com/x/.config?x=f04d8d0a2afb789a
dashboard link: https://syzkaller.appspot.com/bug?extid=344bb0f46d7719cd9483
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=12b5841f800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17f4005f800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+344bb0f46d7719cd9483@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
PGD 1b2931067 P4D 1b2931067 PUD 1d0ae1067 PMD 0
Oops: 0010 [#1] SMP KASAN
CPU: 0 PID: 4493 Comm: syz-executor249 Not tainted 4.17.0+ #92
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010: (null)
Code: Bad RIP value.
RSP: 0018:ffff8801b3bd7590 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8801b2994800 RCX: 1ffffffff10ea8e5
RDX: ffff8801b3bd7ab0 RSI: ffff8801ace8c980 RDI: ffff8801b378d800
RBP: ffff8801b3bd7700 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 1ffff1003677aeb7
R13: ffff8801b3bd7ab0 R14: ffff8801b2994812 R15: ffff8801b2994c58
FS: 00000000018d6880(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd6 CR3: 00000001b2a10000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
sock_poll+0x1d1/0x710 net/socket.c:1156
vfs_poll+0x77/0x2a0 fs/select.c:40
do_pollfd fs/select.c:848 [inline]
do_poll fs/select.c:896 [inline]
do_sys_poll+0x6fd/0x1100 fs/select.c:990
__do_sys_poll fs/select.c:1048 [inline]
__se_sys_poll fs/select.c:1036 [inline]
__x64_sys_poll+0x189/0x510 fs/select.c:1036
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x43fcc9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 6b 45 00 00 c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffc32252d08 EFLAGS: 00000213 ORIG_RAX: 0000000000000007
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fcc9
RDX: 0000000000000003 RSI: 0000000000000001 RDI: 0000000020000040
RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000213 R12: 00000000004015f0
R13: 0000000000401680 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
Dumping ftrace buffer:
(ftrace buffer empty)
CR2: 0000000000000000
---[ end trace c755e9b5f9cf1fa4 ]---
RIP: 0010: (null)
Code: Bad RIP value.
RSP: 0018:ffff8801b3bd7590 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8801b2994800 RCX: 1ffffffff10ea8e5
RDX: ffff8801b3bd7ab0 RSI: ffff8801ace8c980 RDI: ffff8801b378d800
RBP: ffff8801b3bd7700 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 1ffff1003677aeb7
R13: ffff8801b3bd7ab0 R14: ffff8801b2994812 R15: ffff8801b2994c58
FS: 00000000018d6880(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd6 CR3: 00000001b2a10000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
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: netdevice notifier and device private data
From: Michael Richardson @ 2018-06-09 19:01 UTC (permalink / raw)
To: Alexander Aring; +Cc: netdev, linux-wpan, linux-bluetooth
In-Reply-To: <20180609152921.hqfmprmd4ryttaie@x220t>
[-- Attachment #1: Type: text/plain, Size: 861 bytes --]
Alexander Aring <aring@mojatatu.com> wrote:
> Futhermore user space programs e.g. radvd will do 6lowpan specific
> handling on 6lowpan dev->type, it will not work either on tun
> devices.
> I know that wpantund from NestLabs do this switch, I am very
> curious about the reason but I think they do it because the name
> is 6LoWPAN. But wpantund is just a SLIP like protocol with
> additional radio/foo commands.
How do they change it then, and what does it do?
It totally seems like broken behaviour. Maybe it's not even intentional.
Maybe they are just foobar.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 464 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 2/2] net-next: xsurf100: drop include of lib8390.c
From: Michael Schmitz @ 2018-06-09 19:00 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: netdev, Linux/m68k, Andrew Lunn, Finn Thain
In-Reply-To: <CAMuHMdVfjE=+YiqCrPfGObeYYkQwKGiQEWyprQr-n9z7J9-X-A@mail.gmail.com>
Hi Geert,
Am 10.06.2018 um 02:33 schrieb Geert Uytterhoeven:
> Hi Michael,
>
> On Sat, Jun 9, 2018 at 7:58 AM Michael Schmitz <schmitzmic@gmail.com> wrote:
>>
>> Now that ax88796.c exports the ax_NS8390_init() symbol, we can
>> include 8390.h instead of lib8390.c, avoiding duplication of that
>> function and killing a few compile warnings in the bargain.
>>
>> Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
>
> Thanks for your patch!
>
>
>> --- a/drivers/net/ethernet/8390/xsurf100.c
>> +++ b/drivers/net/ethernet/8390/xsurf100.c
>> @@ -33,8 +33,6 @@
>> #define HW_CHIPID 0x70
>> #define HW_SCRATCH 0x78
>>
>> -#define __NS8390_init ax_NS8390_init
>> -
>> /* force unsigned long back to 'void __iomem *' */
>> #define ax_convert_addr(_a) ((void __force __iomem *)(_a))
>>
>> @@ -80,12 +78,10 @@ static void reg_write16(void __iomem *base, u16 reg, u16 val)
>
> This doesn't apply against net-next, which doesn't have reg_write16() (yet?).
Bummer - that's from my experimental ISP1173 probe code, nothing to do
with network code.
I'll redo these patches against net-next (and add a non-static wrapper
for ax_NS8390_init to allow compiling in the driver).
Thanks,
Michael
> Apart from that, your patch looks fine to me.
>
> Gr{oetje,eeting}s,
>
> Geert
>
^ permalink raw reply
* Re: Qualcomm rmnet driver and qmi_wwan
From: Subash Abhinov Kasiviswanathan @ 2018-06-09 17:55 UTC (permalink / raw)
To: Daniele Palmas; +Cc: Bjørn Mork, Dan Williams, netdev
In-Reply-To: <CAGRyCJFo6PAg3-ukZZFDMEAyqHR=N8me-f-SLOzuJq4ibRBwhA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 582 bytes --]
> thanks, I will test it on Monday.
>
> Just a question for my knowledge: is the new sysfs attribute really
> needed? I mean, is there not any other way to understand from qmi_wwan
> without user intervention that there is the rmnet device attached?
>
> Regards,
> Daniele
>
Hi Daniele
You can check for the rx_handler attached to qmi_wwan dev and see if it
belongs to rmnet. You can use the attached patch for it but it think the
sysfs way might be a bit cleaner.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-net-qmi_wwan-Allow-packets-to-pass-through-to-rmnet.patch --]
[-- Type: text/x-diff; name=0001-net-qmi_wwan-Allow-packets-to-pass-through-to-rmnet.patch, Size: 3460 bytes --]
From f7a2b90948da47ade1b345eddb37b721f5ab65f4 Mon Sep 17 00:00:00 2001
From: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date: Sat, 9 Jun 2018 11:14:22 -0600
Subject: [PATCH] net: qmi_wwan: Allow packets to pass through to rmnet
Pass through mode is to allow packets in MAP format to be passed
on to rmnet if the rmnet rx handler is attached to it.
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
---
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 4 +++-
drivers/net/usb/qmi_wwan.c | 10 ++++++++++
include/linux/if_rmnet.h | 20 ++++++++++++++++++++
3 files changed, 33 insertions(+), 1 deletion(-)
create mode 100644 include/linux/if_rmnet.h
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c b/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
index 5f4e447..164a18f 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
@@ -17,6 +17,7 @@
#include <linux/module.h>
#include <linux/netlink.h>
#include <linux/netdevice.h>
+#include <linux/if_rmnet.h>
#include "rmnet_config.h"
#include "rmnet_handlers.h"
#include "rmnet_vnd.h"
@@ -48,10 +49,11 @@
[IFLA_RMNET_FLAGS] = { .len = sizeof(struct ifla_rmnet_flags) },
};
-static int rmnet_is_real_dev_registered(const struct net_device *real_dev)
+int rmnet_is_real_dev_registered(const struct net_device *real_dev)
{
return rcu_access_pointer(real_dev->rx_handler) == rmnet_rx_handler;
}
+EXPORT_SYMBOL(rmnet_is_real_dev_registered);
/* Needs rtnl lock */
static struct rmnet_port*
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index f52a9be..abdae63 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -22,6 +22,7 @@
#include <linux/usb/cdc.h>
#include <linux/usb/usbnet.h>
#include <linux/usb/cdc-wdm.h>
+#include <linux/if_rmnet.h>
/* This driver supports wwan (3G/LTE/?) devices using a vendor
* specific management protocol called Qualcomm MSM Interface (QMI) -
@@ -354,6 +355,10 @@ static ssize_t add_mux_store(struct device *d, struct device_attribute *attr, c
if (kstrtou8(buf, 0, &mux_id))
return -EINVAL;
+ /* rmnet is already attached here */
+ if (rmnet_is_real_dev_registered(to_net_dev(d)))
+ return -EINVAL;
+
/* mux_id [1 - 0x7f] range empirically found */
if (mux_id < 1 || mux_id > 0x7f)
return -EINVAL;
@@ -543,6 +548,11 @@ static int qmi_wwan_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
if (skb->len < dev->net->hard_header_len)
return 0;
+ if (rawip && rmnet_is_real_dev_registered(skb->dev)) {
+ skb->protocol = htons(ETH_P_MAP);
+ return (netif_rx(skb) == NET_RX_SUCCESS);
+ }
+
if (info->flags & QMI_WWAN_FLAG_MUX)
return qmimux_rx_fixup(dev, skb);
diff --git a/include/linux/if_rmnet.h b/include/linux/if_rmnet.h
new file mode 100644
index 0000000..7a7fb96
--- /dev/null
+++ b/include/linux/if_rmnet.h
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ *
+ */
+#ifndef _LINUX_IF_RMNET_H_
+#define _LINUX_IF_RMNET_H_
+#include <linux/netdevice.h>
+
+#if defined(CONFIG_RMNET)
+extern int rmnet_is_real_dev_registered(const struct net_device *real_dev);
+#else
+static inline
+int rmnet_is_real_dev_registered(const struct net_device *real_dev)
+{
+ return 0;
+}
+#endif
+
+#endif /* !(_LINUX_IF_RMNET_H_) */
--
1.9.1
^ permalink raw reply related
* Re: general protection fault in __vfs_write
From: syzbot @ 2018-06-09 15:36 UTC (permalink / raw)
To: alexei.starovoitov, ast, daniel, linux-fsdevel, linux-kernel,
netdev, syzkaller-bugs, viro, willy
In-Reply-To: <000000000000973c2c056e0ecddd@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 3a979e8c07e3 Merge tag 'mailbox-v4.18' of git://git.linaro..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11e0c81f800000
kernel config: https://syzkaller.appspot.com/x/.config?x=412e35656a3f7c09
dashboard link: https://syzkaller.appspot.com/bug?extid=7ade6c94abb2774c0fee
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1665abf7800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+7ade6c94abb2774c0fee@syzkaller.appspotmail.com
IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
bpfilter: read fail -512
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
CPU: 0 PID: 4546 Comm: syz-executor6 Not tainted 4.17.0+ #83
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:file_write_hint include/linux/fs.h:1932 [inline]
RIP: 0010:init_sync_kiocb include/linux/fs.h:1942 [inline]
RIP: 0010:new_sync_write fs/read_write.c:470 [inline]
RIP: 0010:__vfs_write+0x4a6/0x960 fs/read_write.c:487
Code: c1 ea 03 80 3c 02 00 0f 85 1b 04 00 00 48 b8 00 00 00 00 00 fc ff df
4c 8b 63 20 49 8d bc 24 c8 00 00 00 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84
c0 74 08 3c 03 0f 8e ec 02 00 00 41 8b 84 24 c8 00
RSP: 0018:ffff8801ae407850 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff8801cd88f580 RCX: ffffffff81c0d6fb
RDX: 0000000000000019 RSI: ffffffff81c0d70a RDI: 00000000000000c8
RBP: ffff8801ae4079c8 R08: ffff8801d88ee680 R09: fffffbfff130c5d9
R10: ffff8801ae407a10 R11: ffffffff89862ecb R12: 0000000000000000
R13: ffff8801ae4079a0 R14: 0000000000000000 R15: ffff8801ae407a88
FS: 000000000102f940(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f5f52ac0518 CR3: 00000001d8d8a000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__kernel_write+0x10c/0x380 fs/read_write.c:506
__bpfilter_process_sockopt+0x1d8/0x35b net/bpfilter/bpfilter_kern.c:66
bpfilter_mbox_request+0x4d/0xb0 net/ipv4/bpfilter/sockopt.c:25
bpfilter_ip_get_sockopt+0x6b/0x90 net/ipv4/bpfilter/sockopt.c:42
ip_getsockopt+0x238/0x2a0 net/ipv4/ip_sockglue.c:1563
tcp_getsockopt+0x93/0xe0 net/ipv4/tcp.c:3532
sock_common_getsockopt+0x9a/0xe0 net/core/sock.c:3012
__sys_getsockopt+0x1a5/0x370 net/socket.c:1972
__do_sys_getsockopt net/socket.c:1983 [inline]
__se_sys_getsockopt net/socket.c:1980 [inline]
__x64_sys_getsockopt+0xbe/0x150 net/socket.c:1980
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4584ea
Code: b8 34 01 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 1d 8f fb ff c3 66 2e 0f
1f 84 00 00 00 00 00 66 90 49 89 ca b8 37 00 00 00 0f 05 <48> 3d 01 f0 ff
ff 0f 83 fa 8e fb ff c3 66 0f 1f 84 00 00 00 00 00
RSP: 002b:0000000000a3e328 EFLAGS: 00000246 ORIG_RAX: 0000000000000037
RAX: ffffffffffffffda RBX: 0000000000a3e350 RCX: 00000000004584ea
RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 0000000000706f20 R08: 0000000000a3e34c R09: 0000000000004000
R10: 0000000000a3e350 R11: 0000000000000246 R12: 0000000000000003
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000706860
Modules linked in:
Dumping ftrace buffer:
(ftrace buffer empty)
---[ end trace 9a583fc95516c106 ]---
RIP: 0010:file_write_hint include/linux/fs.h:1932 [inline]
RIP: 0010:init_sync_kiocb include/linux/fs.h:1942 [inline]
RIP: 0010:new_sync_write fs/read_write.c:470 [inline]
RIP: 0010:__vfs_write+0x4a6/0x960 fs/read_write.c:487
Code: c1 ea 03 80 3c 02 00 0f 85 1b 04 00 00 48 b8 00 00 00 00 00 fc ff df
4c 8b 63 20 49 8d bc 24 c8 00 00 00 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84
c0 74 08 3c 03 0f 8e ec 02 00 00 41 8b 84 24 c8 00
RSP: 0018:ffff8801ae407850 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff8801cd88f580 RCX: ffffffff81c0d6fb
RDX: 0000000000000019 RSI: ffffffff81c0d70a RDI: 00000000000000c8
RBP: ffff8801ae4079c8 R08: ffff8801d88ee680 R09: fffffbfff130c5d9
R10: ffff8801ae407a10 R11: ffffffff89862ecb R12: 0000000000000000
R13: ffff8801ae4079a0 R14: 0000000000000000 R15: ffff8801ae407a88
FS: 000000000102f940(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f5f52ac0518 CR3: 00000001d8d8a000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
^ permalink raw reply
* Re: netdevice notifier and device private data
From: Alexander Aring @ 2018-06-09 15:29 UTC (permalink / raw)
To: Michael Richardson; +Cc: netdev, linux-wpan, linux-bluetooth
In-Reply-To: <32763.1528486664@localhost>
Hi,
On Fri, Jun 08, 2018 at 03:37:44PM -0400, Michael Richardson wrote:
>
> Alexander Aring <aring@mojatatu.com> wrote:
> Alex> I already see code outside who changed tun netdevice to the
> Alex> ARPHRD_6LOWPAN type and I suppose they running into this
> Alex> issue. (Btw: I don't know why somebody wants to changed that
> Alex> type to ARPHRD_6LOWPAN on tun).
>
> so that they can have the kernel do 6lowpan processing, emitting 6lowPAN
> packets into userspace to be transfered into a radio via some proprietary
> interface (including, for instance SLIP over USB cable to Contiki or OpenWSN stack,
> set up to act as radio only)
>
No, the datapath doesn't change. If the user space evaluate the
dev->type (there exists some ioctl() for it) it will assume it has a
6LoWPAN type interface.
A lot of user space software outside will doing interface specific
handling after detect the type. E.g. wireshark will select some dissector
handling.
On a tun interface and switch to 6LoWPAN it will not change much the
dissector view, because both raw IPv6 packets on datapath. For me as
6LoWPAN maintainer it makes no sense to switch to it. Currently
some netdevice notifier will crash (if you a lucky it will not).
Futhermore user space programs e.g. radvd will do 6lowpan specific
handling on 6lowpan dev->type, it will not work either on tun devices.
I know that wpantund from NestLabs do this switch, I am very curious
about the reason but I think they do it because the name is 6LoWPAN. But
wpantund is just a SLIP like protocol with additional radio/foo commands.
---
According to the people who say "I like to have a 6LoWPAN tun device,
that would be nice" - I don't know how this will ever work since 6LoWPAN
header highly depends on MAC header information. Tun devices works
because IP architecture allows a separation from MAC layer. I already
saw protocols at IETF where MAC header information are needed on top of
UDP payload in case of 6LoWPAN. (I talked about that at last netdev in
Montreal).
Bluetooth wanted to add a tun 6lowpan interface and I was curious how
this works. At the end it was a "Bluetooth mapping to ethernet header"
(not as tunnel, as propagated). I was not acking it, because if there
are protocols who needs more information than just what you can map to
ethernet... it will not work. At least it will also not work with IEEE
802.15.4 at all. They was just lucky that Bluetooth and ethernet use the
same mac address length (And I had some questions to the multicast bit
as well).
Tunnel might work to get mac information. But so far 6loWPAN works it is
that you have a L2 underlaying interface and on top (ip link set master)
a raw IPv6 interface which do the adaptation automatically as a protocol
translation (That's why I cannot understand Bluetooth 6LoWPAN use tx
queues on their 6LoWPAN interface, they need to fix the queue in the
underlaying L2 interface).
As an alternative solution I think it should be something done like TAP
like interface per subsystem. I mean NO ETHERTNET, but the ethernet in
TAP interfaces out and replace it with Bluetooth or IEEE 802.15.4.
I might can easily create a simple TAP IEEE 802.15.4 to show what I
mean.
With an IEEE 802.15.4 TAP device and a 6lowpan interface on top you can
realize your use case and pass 802.15.4 L2 frames to device node -> pops
up at 6LoPWAN interface and send IPv6 stuff and you can read on device
node.
I am still in the opinion the L2 TAP like interface is the way to go to
offer such feature.
- Alex
^ permalink raw reply
* Re: [PATCH 3/3] bpfilter: do not (ab)use host-program build rule
From: Masahiro Yamada @ 2018-06-09 15:13 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: netdev, Alexei Starovoitov, David S . Miller, Arnd Bergmann,
Geert Uytterhoeven, Linux Kernel Mailing List, YueHaibing,
Daniel Borkmann
In-Reply-To: <20180608205256.cpniquglftmie5vl@ast-mbp.dhcp.thefacebook.com>
2018-06-09 5:52 GMT+09:00 Alexei Starovoitov <alexei.starovoitov@gmail.com>:
> On Sat, Jun 09, 2018 at 02:12:10AM +0900, Masahiro Yamada wrote:
>> It is an ugly hack to overwrite $(HOSTCC) with $(CC) to reuse the
>> build rules from scripts/Makefile.host. It should not be tedious
>> to write a build rule for its own.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> ---
>>
>> net/bpfilter/Makefile | 17 +++++++++++------
>> net/bpfilter/{main.c => bpfilter_umh.c} | 0
>> 2 files changed, 11 insertions(+), 6 deletions(-)
>> rename net/bpfilter/{main.c => bpfilter_umh.c} (100%)
>>
>> diff --git a/net/bpfilter/Makefile b/net/bpfilter/Makefile
>> index 39c6980..6571b30 100644
>> --- a/net/bpfilter/Makefile
>> +++ b/net/bpfilter/Makefile
>> @@ -3,18 +3,23 @@
>> # Makefile for the Linux BPFILTER layer.
>> #
>>
>> -hostprogs-y := bpfilter_umh
>> -bpfilter_umh-objs := main.o
>> -HOSTCFLAGS += -I. -Itools/include/ -Itools/include/uapi
>> -HOSTCC := $(CC)
>
> that is a hack indeed. I don't like it either, but see below.
>
>> -
>> ifeq ($(CONFIG_BPFILTER_UMH), y)
>> # builtin bpfilter_umh should be compiled with -static
>> # since rootfs isn't mounted at the time of __init
>> # function is called and do_execv won't find elf interpreter
>> -HOSTLDFLAGS += -static
>> +STATIC := -static
>> endif
>>
>> +quiet_cmd_cc_user = CC $@
>> + cmd_cc_user = $(CC) -Wall -Wmissing-prototypes -O2 -std=gnu89 \
>> + -I$(srctree) -I$(srctree)/tools/include/ \
>> + -I$(srctree)/tools/include/uapi $(STATIC) -o $@ $<
>> +
>> +$(obj)/bpfilter_umh: $(src)/bpfilter_umh.c FORCE
>> + $(call if_changed,cc_user)
>
> Does this scale?
> Please see two top patches here:
> https://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf.git/log/?h=ipt_bpf
> that add more meat to bpfilter and a lot more files.
Oh, I just thought main.c was the only user-program file.
> Recompiling all of them at once isn't nice either.
Indeed.
It should be able to compile .c -> .o separately.
> This Makefile needs different .c -> .o rules for bpfilter_kern.c files
> that get compiled into kernel module and for the rest of umh files:
> main.c ctor.c init.c gen.c etc
> that need to be compiled .c -> .o differently.
> I don't see how to do it without ugly hacks in Makefile.
> In that sense HOSTCC = CC hack looked the least ugly to me that's
> why I went with it.
> Better ideas?
I will think about it after your patches land.
I will drop this for now.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [RFC PATCH 2/2] net-next: xsurf100: drop include of lib8390.c
From: Geert Uytterhoeven @ 2018-06-09 14:33 UTC (permalink / raw)
To: Michael Schmitz; +Cc: netdev, Linux/m68k, Andrew Lunn, Finn Thain
In-Reply-To: <1528523869-3403-3-git-send-email-schmitzmic@gmail.com>
Hi Michael,
On Sat, Jun 9, 2018 at 7:58 AM Michael Schmitz <schmitzmic@gmail.com> wrote:
>
> Now that ax88796.c exports the ax_NS8390_init() symbol, we can
> include 8390.h instead of lib8390.c, avoiding duplication of that
> function and killing a few compile warnings in the bargain.
>
> Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
Thanks for your patch!
> --- a/drivers/net/ethernet/8390/xsurf100.c
> +++ b/drivers/net/ethernet/8390/xsurf100.c
> @@ -33,8 +33,6 @@
> #define HW_CHIPID 0x70
> #define HW_SCRATCH 0x78
>
> -#define __NS8390_init ax_NS8390_init
> -
> /* force unsigned long back to 'void __iomem *' */
> #define ax_convert_addr(_a) ((void __force __iomem *)(_a))
>
> @@ -80,12 +78,10 @@ static void reg_write16(void __iomem *base, u16 reg, u16 val)
This doesn't apply against net-next, which doesn't have reg_write16() (yet?).
Apart from that, your patch looks fine to me.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [RFC PATCH 1/2] net-next: ax88796: export ax_NS8390_init() hook
From: Geert Uytterhoeven @ 2018-06-09 14:31 UTC (permalink / raw)
To: Michael Schmitz; +Cc: netdev, Linux/m68k, Andrew Lunn, Finn Thain
In-Reply-To: <1528523869-3403-2-git-send-email-schmitzmic@gmail.com>
Hi Michael,
On Sat, Jun 9, 2018 at 7:58 AM Michael Schmitz <schmitzmic@gmail.com> wrote:
> The block I/O code for the new X-Surf 100 ax88796 driver needs
> ax_NS8390_init() for error fixup in its block_output function.
>
> Export this function so we can lose the lib8380.c include in the
> X-Surf 100 driver.
>
> Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
Thanks for your patch!
> --- a/drivers/net/ethernet/8390/ax88796.c
> +++ b/drivers/net/ethernet/8390/ax88796.c
> @@ -62,6 +62,8 @@
>
> #include "lib8390.c"
>
> +EXPORT_SYMBOL_GPL(ax_NS8390_init);
While that works for the modular case, it doesn't work for the builtin case,
as the function is static.
You can fix that by adding a non-static wrapper, and exporting that one instead.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] net: phy: Add TJA1100 BroadR-Reach PHY driver.
From: Andrew Lunn @ 2018-06-09 14:07 UTC (permalink / raw)
To: Kirill Kranke; +Cc: Florian Fainelli, davem, netdev
In-Reply-To: <CAJAJcrHLhjEPoQ--6kenb9HSnv_V7p2wbDf6J=fnsokZ2jWv4g@mail.gmail.com>
> It seems that this is going to be 100Base-T1 mess while IEEE 802.3bw
> miss Clause 22 updates. Clause 45 is rarely used from my experience. Probably
> IEEE expected 100Base-T1 PHYs to go for Clause 45 MDIO and this did not work
> so far.
Hi Kirill
Thanks for this information. So lets forget generic support for the
moment.
Andrew
^ permalink raw reply
* Re: [PATCH 2/3] bpfilter: include bpfilter_umh in assembly instead of using objcopy
From: Masahiro Yamada @ 2018-06-09 12:45 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: netdev, Alexei Starovoitov, David S . Miller, Arnd Bergmann,
Geert Uytterhoeven, Linux Kernel Mailing List, YueHaibing
In-Reply-To: <20180608204727.jggtai5iro7ao34v@ast-mbp.dhcp.thefacebook.com>
2018-06-09 5:47 GMT+09:00 Alexei Starovoitov <alexei.starovoitov@gmail.com>:
> On Sat, Jun 09, 2018 at 02:12:09AM +0900, Masahiro Yamada wrote:
>> Do not use the troublesome ELF magic. What is happening here is to
>> embed a user-space program into the kernel. Simply wrap it in the
>> assembly with the '.incbin' directive.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> ---
>>
>> net/bpfilter/Makefile | 15 ++-------------
>> net/bpfilter/bpfilter_kern.c | 11 +++++------
>> net/bpfilter/bpfilter_umh_blob.S | 7 +++++++
>> 3 files changed, 14 insertions(+), 19 deletions(-)
>> create mode 100644 net/bpfilter/bpfilter_umh_blob.S
>>
>> diff --git a/net/bpfilter/Makefile b/net/bpfilter/Makefile
>> index aafa720..39c6980 100644
>> --- a/net/bpfilter/Makefile
>> +++ b/net/bpfilter/Makefile
>> @@ -15,18 +15,7 @@ ifeq ($(CONFIG_BPFILTER_UMH), y)
>> HOSTLDFLAGS += -static
>> endif
>>
>> -# a bit of elf magic to convert bpfilter_umh binary into a binary blob
>> -# inside bpfilter_umh.o elf file referenced by
>> -# _binary_net_bpfilter_bpfilter_umh_start symbol
>> -# which bpfilter_kern.c passes further into umh blob loader at run-time
>> -quiet_cmd_copy_umh = GEN $@
>> - cmd_copy_umh = echo ':' > $(obj)/.bpfilter_umh.o.cmd; \
>> - $(OBJCOPY) -I binary -O $(CONFIG_OUTPUT_FORMAT) \
>> - -B `$(OBJDUMP) -f $<|grep architecture|cut -d, -f1|cut -d' ' -f2` \
>> - --rename-section .data=.init.rodata $< $@
>> -
>> -$(obj)/bpfilter_umh.o: $(obj)/bpfilter_umh
>> - $(call cmd,copy_umh)
>> +$(obj)/bpfilter_umh_blob.o: $(obj)/bpfilter_umh
>>
>> obj-$(CONFIG_BPFILTER_UMH) += bpfilter.o
>> -bpfilter-objs += bpfilter_kern.o bpfilter_umh.o
>> +bpfilter-objs += bpfilter_kern.o bpfilter_umh_blob.o
>> diff --git a/net/bpfilter/bpfilter_kern.c b/net/bpfilter/bpfilter_kern.c
>> index b13d058..fcc1a7c 100644
>> --- a/net/bpfilter/bpfilter_kern.c
>> +++ b/net/bpfilter/bpfilter_kern.c
>> @@ -10,11 +10,8 @@
>> #include <linux/file.h>
>> #include "msgfmt.h"
>>
>> -#define UMH_start _binary_net_bpfilter_bpfilter_umh_start
>> -#define UMH_end _binary_net_bpfilter_bpfilter_umh_end
>> -
>> -extern char UMH_start;
>> -extern char UMH_end;
>> +extern char bpfilter_umh_start;
>> +extern char bpfilter_umh_end;
>>
>> static struct umh_info info;
>> /* since ip_getsockopt() can run in parallel, serialize access to umh */
>> @@ -89,7 +86,9 @@ static int __init load_umh(void)
>> int err;
>>
>> /* fork usermode process */
>> - err = fork_usermode_blob(&UMH_start, &UMH_end - &UMH_start, &info);
>> + err = fork_usermode_blob(&bpfilter_umh_end,
>> + &bpfilter_umh_end - &bpfilter_umh_start,
>> + &info);
>> if (err)
>> return err;
>> pr_info("Loaded bpfilter_umh pid %d\n", info.pid);
>> diff --git a/net/bpfilter/bpfilter_umh_blob.S b/net/bpfilter/bpfilter_umh_blob.S
>> new file mode 100644
>> index 0000000..40311d1
>> --- /dev/null
>> +++ b/net/bpfilter/bpfilter_umh_blob.S
>> @@ -0,0 +1,7 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> + .section .init.rodata, "a"
>> + .global bpfilter_umh_start
>> +bpfilter_umh_start:
>> + .incbin "net/bpfilter/bpfilter_umh"
>
> Interesting. I think this is good idea. Looks cleaner than objcopy magic.
> btw CONFIG_OUTPUT_FORMAT already fixed by
> commit 8d97ca6b6755 ("bpfilter: fix OUTPUT_FORMAT") in net tree.
> Could you please rebase on top of that tree?
>
OK, I will rebase it.
BTW, I only compile-tested this patch.
Could you check if it really works?
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Dear Talented
From: Lisa Clement @ 2018-06-09 10:56 UTC (permalink / raw)
To: Recipients
Dear Talented,
I am Talent Scout For BLUE SKY FILM STUDIO, Present Blue sky Studio a
Film Corporation Located in the United State, is Soliciting for the
Right to use Your Photo/Face and Personality as One of the Semi -Major
Role/ Character in our Upcoming ANIMATED Stereoscope 3D Movie-The Story
of Spies in Disguise (Spies in Disguise 2019) The Movie is Currently Filming (In
Production) Please Note That There Will Be No Auditions, Traveling or
Any Special / Professional Acting Skills, Since the Production of This
Movie Will Be Done with our State of Art Computer -Generating Imagery
Equipment. We Are Prepared to Pay the Total Sum of $620,000.00 USD. For
More Information/Understanding, Please Write us on the E-Mail Below.
CONTACT EMAIL: bluesky.filmstudio@usa.com
All Reply to: bluesky.filmstudio@usa.com
Note: Only the Response send to this mail will be Given a Prior
Consideration.
Talent Scout
Lisa Clement
^ permalink raw reply
* Re: Donation-
From: M. M. Fridman @ 2018-06-09 4:19 UTC (permalink / raw)
To: Recipients
I Mikhail Fridman. has selected you specially as one of my beneficiaries
for my Charitable Donation, Just as I have declared on May 23, 2016 to give
my fortune as charity.
Check the link below for confirmation:
http://www.ibtimes.co.uk/russias-second-wealthiest-man-mikhail-fridman-plans-leaving-14-2bn-fortune-charity-1561604
Reply as soon as possible with further directives.
Best Regards,
Mikhail Fridman.
^ permalink raw reply
* Re: [PATCH v4 9/9] net-next: New ax88796 platform driver for Amiga X-Surf 100 Zorro board (m68k)
From: Michael Karcher @ 2018-06-09 9:15 UTC (permalink / raw)
To: Michael Schmitz
Cc: Geert Uytterhoeven, netdev, Andrew Lunn, Finn Thain,
Florian Fainelli, Linux/m68k, Michael Karcher
In-Reply-To: <8144eec6-7bc1-95e0-e762-8b5af1c18583@gmail.com>
Michael Schmitz schrieb:
> Hi Michael,
>> actually, the the block_input / block_output functions were the reason I
>> included the lib8390.c file. Except for xs100_write / xs100_read, they
>> are
>> a verbatim copy from ax88796.c I'm not that enthusiastic about that idea
>> anymore, but did not get around to improve it. I added a customization
>> point to ax88796 for a custom block_input / block_output, because the
>> 8390
>> core already provides that customization point. What I really need is a
>> customization point just for the 8390-remote-DMA-via-MMIO functions
>> (i.e.
>> xs100_write, xs100_read) instead of the whole block transfer core that
>> also sets up the remote DMA engine and tries to re-initialize the card
>> in
>> case of unexplained problems.
>
> OK, so essentially change
>
> if (ei_local->word16) {
> ioread16_rep(nic_base + NE_DATAPORT, buf, count >> 1);
> if (count & 0x01)
> buf[count-1] = ei_inb(nic_base + NE_DATAPORT);
>
> } else {
> ioread8_rep(nic_base + NE_DATAPORT, buf, count);
> }
>
> to something like
>
> if (ax->block_read) {
> ax->block_read(dev, buf, count);
> } else if (ei_local->word16) {
> ioread16_rep(nic_base + NE_DATAPORT, buf, count >> 1);
> if (count & 0x01)
> buf[count-1] = ei_inb(nic_base + NE_DATAPORT);
>
> } else {
> ioread8_rep(nic_base + NE_DATAPORT, buf, count);
> }
>
> and populate ax->block_read() and ax_block_write() from platform data,
> instead of substituting ax_block_input() / ax_block_output() wholesale?
That's basically how I think the whole lib8390.c story should in fact be
tackled. Less code duplication, no second include of lib8390 and constrain
xsurf100.c to the pieces that make this piece of hardware unique.
> I must be missing something here.
I don't think so.
> Adds one test for
> ax->block_read on the critical path but we already have the test for
> ei_local->word16 there. May need rearranging the tests so the majority
> of ax88796 users isn't impacted.
Rearranging sounds like a good idea. As I understand, the only valid
rearrangement is putting it inside the 16-bit branch, because the xs100
uses 16-bit transfers and needs the extra byte for odd counts. The code
checks word16 at the beginning of xs100_block_output for that. This has
the advantage of not hurting users of the 8 bit interface, which might be
the slowest users of the ax88796, but comes at the cost of not being able
to customize the block_input/block_output for 8-bit users. As this "cost"
is not a problem now (no one can customize block_input/block_output
currently), lets put the block_read check into the word16 block. You might
want to name the member block_read16 instead of just block_read to convey
the information, that it is only used if word16 is set.
> Anyway, your code, your call.
On the other hand: Your polishing, your call. Thank you for your work on
gettting the code in good shape for merging.
Kind regards,
Michael Karcher
^ permalink raw reply
* [PATCH net-next V3] net: phy: Add TJA1100 BroadR-Reach PHY driver.
From: Kirill Kranke @ 2018-06-09 8:48 UTC (permalink / raw)
To: andrew, f.fainelli, davem, netdev; +Cc: Kirill Kranke
Current generic PHY driver does not work with TJA1100 BroadR-REACH PHY
properly. TJA1100 does not have any standard ability enabled at MII_BMSR
register. Instead it has BroadR-REACH ability at MII_ESTATUS enabled, which
is not handled by generic driver yet. Therefore generic driver is unable to
guess required link speed, duplex etc. Device is started up with 10Mbps
halfduplex which is incorrect.
BroadR-REACH able flag is not specified in IEEE802.3-2015. Which is why I
did not add BroadR-REACH able flag support at generic driver. Once
BroadR-REACH able flag gets into IEEE802.3 it should be reasonable to
support it in the generic PHY driver.
Signed-off-by: Kirill Kranke <kranke.kirill@gmail.com>
---
Notes:
Second edition of the patch miss changes list and V2 flag. Changes are
included here.
Changes from V1 to V2:
- Remove unused #define from tja1100.c
- Do not touch phydev->supported and phydev->advertising
at tja1100_phy_config_init
- Use proper error codes at tja1100_phy_config_aneg
- Use phydev_err instead of pr_err
- Do not specify read_status and soft_reset while they
are default to required value
- Correct wrong Signed-off-by email address
Changes from V2 to V3:
- Add 'net-next' tree
- Add this notes
- Rename config option from TJA1100_PHY to NXP_TJA1100_PHY
- Minor update to config help message: specify that able flag
is TJA1100's custom
- Add SUPPORTED_TP feature
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 343989f..ec30de4 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -387,6 +387,15 @@ config NATIONAL_PHY
---help---
Currently supports the DP83865 PHY.
+config NXP_TJA1100_PHY
+ tristate "NXP TJA1100 PHY"
+ help
+ Support of NXP TJA1100 BroadR-REACH ethernet PHY.
+ Generic driver is not suitable for TJA1100 PHY while the PHY does not
+ advertise any standard IEEE capabilities. It uses custom BroadR-REACH
+ able flag instead. This driver configures capabilities of the PHY
+ properly.
+
config QSEMI_PHY
tristate "Quality Semiconductor PHYs"
---help---
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 5805c0b..c1bc14d4 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_MICROCHIP_PHY) += microchip.o
obj-$(CONFIG_MICROCHIP_T1_PHY) += microchip_t1.o
obj-$(CONFIG_MICROSEMI_PHY) += mscc.o
obj-$(CONFIG_NATIONAL_PHY) += national.o
+obj-$(CONFIG_NXP_TJA1100_PHY) += tja1100.o
obj-$(CONFIG_QSEMI_PHY) += qsemi.o
obj-$(CONFIG_REALTEK_PHY) += realtek.o
obj-$(CONFIG_RENESAS_PHY) += uPD60620.o
diff --git a/drivers/net/phy/tja1100.c b/drivers/net/phy/tja1100.c
new file mode 100644
index 0000000..2b03057
--- /dev/null
+++ b/drivers/net/phy/tja1100.c
@@ -0,0 +1,69 @@
+// SPDX-License-Identifier: GPL-2.0
+/* tja1100.c: TJA1100 BoardR-REACH PHY driver.
+ *
+ * Copyright (c) 2017 Kirill Kranke <kirill.kranke@gmail.com>
+ * Author: Kirill Kranke <kirill.kranke@gmail.com>
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/phy.h>
+
+static int tja1100_phy_config_init(struct phy_device *phydev)
+{
+ phydev->autoneg = AUTONEG_DISABLE;
+ phydev->speed = SPEED_100;
+ phydev->duplex = DUPLEX_FULL;
+
+ return 0;
+}
+
+static int tja1100_phy_config_aneg(struct phy_device *phydev)
+{
+ if (phydev->autoneg == AUTONEG_ENABLE) {
+ phydev_err(phydev, "autonegotiation is not supported\n");
+ return -EINVAL;
+ }
+
+ if (phydev->speed != SPEED_100 || phydev->duplex != DUPLEX_FULL) {
+ phydev_err(phydev, "only 100MBps Full Duplex allowed\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static struct phy_driver tja1100_phy_driver[] = {
+ {
+ .phy_id = 0x0180dc48,
+ .phy_id_mask = 0xfffffff0,
+ .name = "NXP TJA1100",
+
+ /* TJA1100 has only 100BASE-BroadR-REACH ability specified
+ * at MII_ESTATUS register. Standard modes are not
+ * supported. Therefore BroadR-REACH allow only 100Mbps
+ * full duplex without autoneg.
+ */
+ .features = SUPPORTED_100baseT_Full | SUPPORTED_MII
+ | SUPPORTED_TP,
+
+ .config_aneg = tja1100_phy_config_aneg,
+ .config_init = tja1100_phy_config_init,
+
+ .suspend = genphy_suspend,
+ .resume = genphy_resume,
+ }
+};
+
+module_phy_driver(tja1100_phy_driver);
+
+MODULE_DESCRIPTION("NXP TJA1100 driver");
+MODULE_AUTHOR("Kirill Kranke <kkranke@topcon.com>");
+MODULE_LICENSE("GPL");
+
+static struct mdio_device_id __maybe_unused nxp_tbl[] = {
+ { 0x0180dc48, 0xfffffff0 },
+ {}
+};
+
+MODULE_DEVICE_TABLE(mdio, nxp_tbl);
^ permalink raw reply related
* Re: Qualcomm rmnet driver and qmi_wwan
From: Daniele Palmas @ 2018-06-09 7:22 UTC (permalink / raw)
To: Subash Abhinov Kasiviswanathan; +Cc: Bjørn Mork, Dan Williams, netdev
In-Reply-To: <8ad179b53c866ef67823570d055071a3@codeaurora.org>
Hi Subash,
2018-06-09 4:19 GMT+02:00 Subash Abhinov Kasiviswanathan
<subashab@codeaurora.org>:
>> This sounds like a good idea. I probably won't have any time to look at
>> this in the near future, though. Sorry about that. Extremely overloaded
>> both at work and private right now...
>>
>> But I trust that you and Daniele can work out something. Please keep me
>> CCed, but don't expect timely replies.
>>
>
> Hi Daniele
>
> Can you try out the attached patch.
> I have added a new sysfs attribute pass_through to be used in raw_ip mode
> only. Once you attach rmnet devices on it, the rx_handler will be setup
> and the packet will be processed by rmnet.
>
thanks, I will test it on Monday.
Just a question for my knowledge: is the new sysfs attribute really
needed? I mean, is there not any other way to understand from qmi_wwan
without user intervention that there is the rmnet device attached?
Regards,
Daniele
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH] net: phy: Add TJA1100 BroadR-Reach PHY driver.
From: Kirill Kranke @ 2018-06-09 7:08 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, davem, netdev
In-Reply-To: <20180608155529.GA19702@lunn.ch>
Hi Andrew.
Thanks for your comments. I will update the patch a bit later.
>
> Does 100Base-T1/cause 96 define a way to identify a PHY which
> implements this? I'm just wondering if we can do this in the generic
> code, for devices which correctly implement the standard?
>
Well, I did research IEEE 802.3 standards before implementing the
Patch. Initially I
wanted to update generic phy driver. I did not find a way to identify
100Base-T1 PHY
using Clause 22 MDIO. This section is completely missing at IEEE 802.3bw, which
describe 100Base-T1.
There are some updates to Clause 45 registers at IEEE 802.3bw. They add
"BASE-T1 PMA/PMD extended ability" to PMA/PMD registers.
At Clause 96 they state following: "The MDIO capability described in Clause 45
defines several variables that provide control and status information for and
about the PMA and PCS."
In the same time I have played with a two different 100Base-T1 PHYs. Both
use different Clause 22 registers to advertise their abilities, both
are incompatible.
None use Clause 45 for this purpose.
It seems that this is going to be 100Base-T1 mess while IEEE 802.3bw
miss Clause 22 updates. Clause 45 is rarely used from my experience. Probably
IEEE expected 100Base-T1 PHYs to go for Clause 45 MDIO and this did not work
so far.
>
> This is the second T1 driver we have had recently. It might make sense to add a
> PHY_T1_FEATURES macro the include/linux/phy.h
>
This seems reasonable, indeed.
>
> Don't you also want SUPPORTED_TP?
>
True, I will add SUPPORTED_TP in next revision of the Patch.
Kirill
^ permalink raw reply
* [RFC PATCH 1/2] net-next: ax88796: export ax_NS8390_init() hook
From: Michael Schmitz @ 2018-06-09 5:57 UTC (permalink / raw)
To: netdev; +Cc: linux-m68k, andrew, geert, fthain, Michael Schmitz
In-Reply-To: <CAMuHMdWsibY4h5zwBC4qs8ZLq_1-627qjpeDLGzVjaGjG_A4PA@mail.gmail.com>
The block I/O code for the new X-Surf 100 ax88796 driver needs
ax_NS8390_init() for error fixup in its block_output function.
Export this function so we can lose the lib8380.c include in the
X-Surf 100 driver.
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
---
drivers/net/ethernet/8390/ax88796.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/8390/ax88796.c b/drivers/net/ethernet/8390/ax88796.c
index 2a0ddec..470142f 100644
--- a/drivers/net/ethernet/8390/ax88796.c
+++ b/drivers/net/ethernet/8390/ax88796.c
@@ -62,6 +62,8 @@
#include "lib8390.c"
+EXPORT_SYMBOL_GPL(ax_NS8390_init);
+
#define DRV_NAME "ax88796"
#define DRV_VERSION "1.00"
--
1.7.0.4
^ permalink raw reply related
* [RFC PATCH 2/2] net-next: xsurf100: drop include of lib8390.c
From: Michael Schmitz @ 2018-06-09 5:57 UTC (permalink / raw)
To: netdev; +Cc: linux-m68k, andrew, geert, fthain, Michael Schmitz
In-Reply-To: <CAMuHMdWsibY4h5zwBC4qs8ZLq_1-627qjpeDLGzVjaGjG_A4PA@mail.gmail.com>
Now that ax88796.c exports the ax_NS8390_init() symbol, we can
include 8390.h instead of lib8390.c, avoiding duplication of that
function and killing a few compile warnings in the bargain.
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
---
drivers/net/ethernet/8390/xsurf100.c | 10 +++-------
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/8390/xsurf100.c b/drivers/net/ethernet/8390/xsurf100.c
index 4c6f9cb..32caa5e 100644
--- a/drivers/net/ethernet/8390/xsurf100.c
+++ b/drivers/net/ethernet/8390/xsurf100.c
@@ -33,8 +33,6 @@
#define HW_CHIPID 0x70
#define HW_SCRATCH 0x78
-#define __NS8390_init ax_NS8390_init
-
/* force unsigned long back to 'void __iomem *' */
#define ax_convert_addr(_a) ((void __force __iomem *)(_a))
@@ -80,12 +78,10 @@ static void reg_write16(void __iomem *base, u16 reg, u16 val)
writew(val, base + reg*4);
}
+#define NS8390_CORE
+#include "8390.h"
-
-static unsigned char version[] =
- "ax88796.c: Copyright 2005,2007 Simtec Electronics\n";
-
-#include "lib8390.c"
+extern void ax_NS8390_init(struct net_device *dev, int startp);
/* from ne.c */
#define NE_CMD EI_SHIFT(0x00)
--
1.7.0.4
^ permalink raw reply related
* [RFC PATCH 0/2] net-next: cleanup use of lib8390.c code in xsurf100.c
From: Michael Schmitz @ 2018-06-09 5:57 UTC (permalink / raw)
To: netdev; +Cc: linux-m68k, andrew, geert, fthain
In-Reply-To: <CAMuHMdWsibY4h5zwBC4qs8ZLq_1-627qjpeDLGzVjaGjG_A4PA@mail.gmail.com>
As suggested by Geert, xsurf100.c really does not need to duplicate code
from lib8390.c which is already part of ax88796.c, by including that file.
All we need from lib8390.c in the xsurf100 block output function is one
single function: ax_NS8390_init(). Export this symbol in ax88796.c so
the xsurf100 driver can use it.
This is rather a quick band-aid fix to deal with the ugliest code duplication
(including lib8390.c where it really isn't needed). The xsurf100 block_input
and block_output functiond are almost exact duplicated of the generic ax88796
functions, and changing those to make use of platform-specific block MMIO
transfer functions might be a better way to fix this issue.
Tested on Amiga hardware (elgar).
Cheers,
Michael
^ permalink raw reply
* Re: next-20180605 - BUG in ipv6_add_addr
From: Dexuan-Linux Cui @ 2018-06-09 2:54 UTC (permalink / raw)
To: David Ahern
Cc: valdis.kletnieks, netdev, Linux Kernel Mailing List, Dexuan Cui
In-Reply-To: <6471e14e-2872-3ba4-7336-7c5840d28c12@gmail.com>
On Thu, Jun 7, 2018 at 5:51 PM, David Ahern <dsahern@gmail.com> wrote:
>
> ...
> I know you don't have a reliable reproducer, but I did find one spot
> where I was too clever and did not initialize a new cfg variable:
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 89019bf59f46..59c22a25e654 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -1324,6 +1324,7 @@ static int ipv6_create_tempaddr(struct
> inet6_ifaddr *ifp,
> }
> }
>
> + memset(&cfg, 0, sizeof(cfg));
> cfg.valid_lft = min_t(__u32, ifp->valid_lft,
> idev->cnf.temp_valid_lft + age);
> cfg.preferred_lft = cnf_temp_preferred_lft + age -
> idev->desync_factor;
This works for me. Great!
Thanks,
-- Dexuan
^ 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