* Re: [PATCH net 1/2] ibmvnic: Handle all login error conditions
From: Nathan Fontenot @ 2018-04-11 15:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jallen, tlfalcon
In-Reply-To: <20180411.110731.507616117263900808.davem@davemloft.net>
On 04/11/2018 10:07 AM, David Miller wrote:
> From: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> Date: Wed, 11 Apr 2018 09:37:21 -0500
>
>> There is a bug in handling the possible return codes from sending the
>> login CRQ. The current code treats any non-success return value,
>> minus failure to send the crq and a timeout waiting for a login response,
>> as a need to re-send the login CRQ. This can put the drive in an
> ^^^^^
>
> "driver"
>
>> inifinite loop of trying to login when getting return values other
> ^^^^^^^^^
>
> "infinite"
>
>> that a partial success such as a return code of aborted. For these
>> scenarios the login will not ever succeed at this point and the
>> driver would need to be reset again.
>>
>> To resolve this loop trying to login is updated to only retry the
>> login if the driver gets a return code of a partial success. Other
>> return coes are treated as an error and the driver returns an error
> ^^^^
>
> "codes"
>
>> from ibmvnic_login().
>>
>> To avoid infinite looping in the partial success return cases, the
>> number of retries is capped at the maximum number of supported
>> queues. This value was chosen because the driver does a renegatiation
> ^^^^^^^^^^^^^
>
> "renegotiation"
>
>> of capabilities which sets the number of queus possible and allows
> ^^^^^
>
> "queues"
>
Oh man, complete spelling failure. resending.
-Nathan
^ permalink raw reply
* Re: WARNING: kobject bug in br_add_if
From: Dmitry Vyukov @ 2018-04-11 15:18 UTC (permalink / raw)
To: syzbot
Cc: bridge, David Miller, LKML, netdev, stephen hemminger,
syzkaller-bugs, Greg Kroah-Hartman
In-Reply-To: <001a113de2d878ade40569941a21@google.com>
On Wed, Apr 11, 2018 at 5:15 PM, syzbot
<syzbot+de73361ee4971b6e6f75@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> 10b84daddbec72c6b440216a69de9a9605127f7a (Sat Mar 31 17:59:00 2018 +0000)
> Merge branch 'perf-urgent-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=de73361ee4971b6e6f75
>
> So far this crash happened 4 times on net-next, upstream.
> Unfortunately, I don't have any reproducer for this crash yet.
> Raw console output:
> https://syzkaller.appspot.com/x/log.txt?id=5007286875455488
> Kernel config:
> https://syzkaller.appspot.com/x/.config?id=-2760467897697295172
> compiler: gcc (GCC) 7.1.1 20170620
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+de73361ee4971b6e6f75@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
+Greg
The plan is to remove this WARNING from kobject_add, if there are no objections.
> ------------[ cut here ]------------
> binder: 23650:23651 unknown command 1078223622
> kobject_add_internal failed for brport (error: -12 parent: bond0)
> binder: 23650:23651 ioctl c0306201 2000dfd0 returned -22
> WARNING: CPU: 1 PID: 23647 at lib/kobject.c:242
> kobject_add_internal+0x3f6/0xbc0 lib/kobject.c:240
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 1 PID: 23647 Comm: syz-executor7 Not tainted 4.16.0-rc7+ #374
> binder: BINDER_SET_CONTEXT_MGR already set
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x24d lib/dump_stack.c:53
> panic+0x1e4/0x41c kernel/panic.c:183
> __warn+0x1dc/0x200 kernel/panic.c:547
> report_bug+0x1f4/0x2b0 lib/bug.c:186
> fixup_bug.part.10+0x37/0x80 arch/x86/kernel/traps.c:178
> fixup_bug arch/x86/kernel/traps.c:247 [inline]
> do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
> invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:986
> RIP: 0010:kobject_add_internal+0x3f6/0xbc0 lib/kobject.c:240
> RSP: 0018:ffff8801d089f560 EFLAGS: 00010286
> RAX: dffffc0000000008 RBX: ffff8801adbee178 RCX: ffffffff815b193e
> RDX: 0000000000040000 RSI: ffffc900022aa000 RDI: 1ffff1003a113e31
> RBP: ffff8801d089f658 R08: 1ffff1003a113df3 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: 1ffff1003a113eb2
> R13: 00000000fffffff4 R14: ffff8801abd88828 R15: ffff8801d75a1e00
> kobject_add_varg lib/kobject.c:364 [inline]
> kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
> br_add_if+0x79a/0x1a70 net/bridge/br_if.c:533
> add_del_if+0xf4/0x140 net/bridge/br_ioctl.c:101
> br_dev_ioctl+0xa2/0xc0 net/bridge/br_ioctl.c:396
> dev_ifsioc+0x333/0x9b0 net/core/dev_ioctl.c:334
> dev_ioctl+0x176/0xbe0 net/core/dev_ioctl.c:500
> sock_do_ioctl+0x1ba/0x390 net/socket.c:981
> sock_ioctl+0x367/0x670 net/socket.c:1081
> vfs_ioctl fs/ioctl.c:46 [inline]
> do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
> SYSC_ioctl fs/ioctl.c:701 [inline]
> SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
> do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x42/0xb7
> RIP: 0033:0x454e79
> RSP: 002b:00007eff7dab7c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 00007eff7dab86d4 RCX: 0000000000454e79
> RDX: 0000000020000000 RSI: 00000000000089a2 RDI: 0000000000000014
> RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000015
> R13: 0000000000000369 R14: 00000000006f7278 R15: 0000000000000006
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/001a113de2d878ade40569941a21%40google.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH] selftests: net: add in_netns.sh to TEST_PROGS
From: Anders Roxell @ 2018-04-11 15:17 UTC (permalink / raw)
To: davem, shuah; +Cc: netdev, linux-kselftest, linux-kernel, Anders Roxell
Script in_netns.sh isn't installed.
--------------------
running psock_fanout test
--------------------
./run_afpackettests: line 12: ./in_netns.sh: No such file or directory
[FAIL]
--------------------
running psock_tpacket test
--------------------
./run_afpackettests: line 22: ./in_netns.sh: No such file or directory
[FAIL]
In current code added in_netns.sh to be installed.
Fixes: cc30c93fa020 ("selftests/net: ignore background traffic in psock_fanout")
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
tools/testing/selftests/net/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
index 785fc18a16b4..8f1e13d2e547 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -5,7 +5,7 @@ CFLAGS = -Wall -Wl,--no-as-needed -O2 -g
CFLAGS += -I../../../../usr/include/
TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh rtnetlink.sh
-TEST_PROGS += fib_tests.sh fib-onlink-tests.sh pmtu.sh
+TEST_PROGS += fib_tests.sh fib-onlink-tests.sh in_netns.sh pmtu.sh
TEST_GEN_FILES = socket
TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy
TEST_GEN_PROGS = reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
--
2.16.3
^ permalink raw reply related
* WARNING: kobject bug in br_add_if
From: syzbot @ 2018-04-11 15:15 UTC (permalink / raw)
To: bridge, davem, linux-kernel, netdev, stephen, syzkaller-bugs
Hello,
syzbot hit the following crash on upstream commit
10b84daddbec72c6b440216a69de9a9605127f7a (Sat Mar 31 17:59:00 2018 +0000)
Merge branch 'perf-urgent-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=de73361ee4971b6e6f75
So far this crash happened 4 times on net-next, upstream.
Unfortunately, I don't have any reproducer for this crash yet.
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=5007286875455488
Kernel config:
https://syzkaller.appspot.com/x/.config?id=-2760467897697295172
compiler: gcc (GCC) 7.1.1 20170620
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+de73361ee4971b6e6f75@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
R13: 0000000000000369 R14: 00000000006f7278 R15: 0000000000000006
------------[ cut here ]------------
binder: 23650:23651 unknown command 1078223622
kobject_add_internal failed for brport (error: -12 parent: bond0)
binder: 23650:23651 ioctl c0306201 2000dfd0 returned -22
WARNING: CPU: 1 PID: 23647 at lib/kobject.c:242
kobject_add_internal+0x3f6/0xbc0 lib/kobject.c:240
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 23647 Comm: syz-executor7 Not tainted 4.16.0-rc7+ #374
binder: BINDER_SET_CONTEXT_MGR already set
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x24d lib/dump_stack.c:53
panic+0x1e4/0x41c kernel/panic.c:183
__warn+0x1dc/0x200 kernel/panic.c:547
report_bug+0x1f4/0x2b0 lib/bug.c:186
fixup_bug.part.10+0x37/0x80 arch/x86/kernel/traps.c:178
fixup_bug arch/x86/kernel/traps.c:247 [inline]
do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:986
RIP: 0010:kobject_add_internal+0x3f6/0xbc0 lib/kobject.c:240
RSP: 0018:ffff8801d089f560 EFLAGS: 00010286
RAX: dffffc0000000008 RBX: ffff8801adbee178 RCX: ffffffff815b193e
RDX: 0000000000040000 RSI: ffffc900022aa000 RDI: 1ffff1003a113e31
RBP: ffff8801d089f658 R08: 1ffff1003a113df3 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 1ffff1003a113eb2
R13: 00000000fffffff4 R14: ffff8801abd88828 R15: ffff8801d75a1e00
kobject_add_varg lib/kobject.c:364 [inline]
kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
br_add_if+0x79a/0x1a70 net/bridge/br_if.c:533
add_del_if+0xf4/0x140 net/bridge/br_ioctl.c:101
br_dev_ioctl+0xa2/0xc0 net/bridge/br_ioctl.c:396
dev_ifsioc+0x333/0x9b0 net/core/dev_ioctl.c:334
dev_ioctl+0x176/0xbe0 net/core/dev_ioctl.c:500
sock_do_ioctl+0x1ba/0x390 net/socket.c:981
sock_ioctl+0x367/0x670 net/socket.c:1081
vfs_ioctl fs/ioctl.c:46 [inline]
do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
SYSC_ioctl fs/ioctl.c:701 [inline]
SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x454e79
RSP: 002b:00007eff7dab7c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007eff7dab86d4 RCX: 0000000000454e79
RDX: 0000000020000000 RSI: 00000000000089a2 RDI: 0000000000000014
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000015
R13: 0000000000000369 R14: 00000000006f7278 R15: 0000000000000006
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* [PATCH] net: stmmac: fix missing support for 802.1AD tag on reception
From: Elad Nachman @ 2018-04-11 15:07 UTC (permalink / raw)
To: netdev@vger.kernel.org, David Miller
Stmmac reception handler calls stmmac_rx_vlan() to strip the vlan before calling napi_gro_receive().
The function assumes VLAN tagged frames are always tagged with 802.1Q protocol,
and assigns ETH_P_8021Q to the skb by hard-coding the parameter on call to __vlan_hwaccel_put_tag() .
This causes packets not to be passed to the VLAN slave if it was created with 802.1AD protocol
(ip link add link eth0 eth0.100 type vlan proto 802.1ad id 100).
This fix passes the protocol from the VLAN header into __vlan_hwaccel_put_tag()
instead of using the hard-coded value of ETH_P_8021Q.
Signed-off-by: Elad Nachman <eladn@gilat.com>
---
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c2018-04-11 17:04:00.586057300 +0300
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c2018-04-11 17:05:33.601992400 +0300
@@ -3293,17 +3293,19 @@ dma_map_err:
static void stmmac_rx_vlan(struct net_device *dev, struct sk_buff *skb)
{
-struct ethhdr *ehdr;
+struct vlan_ethhdr *veth;
u16 vlanid;
+__be16 vlan_proto;
if ((dev->features & NETIF_F_HW_VLAN_CTAG_RX) ==
NETIF_F_HW_VLAN_CTAG_RX &&
!__vlan_get_tag(skb, &vlanid)) {
/* pop the vlan tag */
-ehdr = (struct ethhdr *)skb->data;
-memmove(skb->data + VLAN_HLEN, ehdr, ETH_ALEN * 2);
+veth = (struct vlan_ethhdr *)skb->data;
+vlan_proto = veth->h_vlan_proto;
+memmove(skb->data + VLAN_HLEN, veth, ETH_ALEN * 2);
skb_pull(skb, VLAN_HLEN);
-__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlanid);
+__vlan_hwaccel_put_tag(skb, vlan_proto, vlanid);
}
}
IMPORTANT - This email and any attachments is intended for the above named addressee(s), and may contain information which is confidential or privileged. If you are not the intended recipient, please inform the sender immediately and delete this email: you should not copy or use this e-mail for any purpose nor disclose its contents to any person.
^ permalink raw reply
* Re: [PATCH net 1/2] ibmvnic: Handle all login error conditions
From: David Miller @ 2018-04-11 15:07 UTC (permalink / raw)
To: nfont; +Cc: netdev, jallen, tlfalcon
In-Reply-To: <152345744074.41721.14779103174755605325.stgit@ltcalpine2-lp14.aus.stglabs.ibm.com>
From: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Date: Wed, 11 Apr 2018 09:37:21 -0500
> There is a bug in handling the possible return codes from sending the
> login CRQ. The current code treats any non-success return value,
> minus failure to send the crq and a timeout waiting for a login response,
> as a need to re-send the login CRQ. This can put the drive in an
^^^^^
"driver"
> inifinite loop of trying to login when getting return values other
^^^^^^^^^
"infinite"
> that a partial success such as a return code of aborted. For these
> scenarios the login will not ever succeed at this point and the
> driver would need to be reset again.
>
> To resolve this loop trying to login is updated to only retry the
> login if the driver gets a return code of a partial success. Other
> return coes are treated as an error and the driver returns an error
^^^^
"codes"
> from ibmvnic_login().
>
> To avoid infinite looping in the partial success return cases, the
> number of retries is capped at the maximum number of supported
> queues. This value was chosen because the driver does a renegatiation
^^^^^^^^^^^^^
"renegotiation"
> of capabilities which sets the number of queus possible and allows
^^^^^
"queues"
^ permalink raw reply
* [PATCH v2 net] lan78xx: PHY DSP registers initialization to address EEE link drop issues with long cables
From: Raghuram Chary J @ 2018-04-11 15:06 UTC (permalink / raw)
To: davem; +Cc: netdev, unglinuxdriver, woojung.huh, raghuramchary.jallipalli
The patch is to configure DSP registers of PHY device
to handle Gbe-EEE failures with >40m cable length.
Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
Signed-off-by: Raghuram Chary J <raghuramchary.jallipalli@microchip.com>
---
v0->v1:
* Use phy_save_page to save current page before switching to TR page.
* Use phy_restore_page to restore saved page.
* Add read_page and write_page callbacks.
* __phy_read, __phy_write to read,write phy registers.
* Handle error conditions.
v1->v2:
* Sending the patch to net separately from enhancements.
---
drivers/net/phy/microchip.c | 178 ++++++++++++++++++++++++++++++++++++++++++-
include/linux/microchipphy.h | 8 ++
2 files changed, 185 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/microchip.c b/drivers/net/phy/microchip.c
index 0f293ef28935..4a8e91922eaa 100644
--- a/drivers/net/phy/microchip.c
+++ b/drivers/net/phy/microchip.c
@@ -20,6 +20,7 @@
#include <linux/ethtool.h>
#include <linux/phy.h>
#include <linux/microchipphy.h>
+#include <linux/delay.h>
#define DRIVER_AUTHOR "WOOJUNG HUH <woojung.huh@microchip.com>"
#define DRIVER_DESC "Microchip LAN88XX PHY driver"
@@ -30,6 +31,16 @@ struct lan88xx_priv {
__u32 wolopts;
};
+static int lan88xx_read_page(struct phy_device *phydev)
+{
+ return __phy_read(phydev, LAN88XX_EXT_PAGE_ACCESS);
+}
+
+static int lan88xx_write_page(struct phy_device *phydev, int page)
+{
+ return __phy_write(phydev, LAN88XX_EXT_PAGE_ACCESS, page);
+}
+
static int lan88xx_phy_config_intr(struct phy_device *phydev)
{
int rc;
@@ -66,6 +77,150 @@ static int lan88xx_suspend(struct phy_device *phydev)
return 0;
}
+static int lan88xx_TR_reg_set(struct phy_device *phydev, u16 regaddr,
+ u32 data)
+{
+ int val, save_page, ret = 0;
+ u16 buf;
+
+ /* Save current page */
+ save_page = phy_save_page(phydev);
+ if (save_page < 0) {
+ pr_warn("Failed to get current page\n");
+ goto err;
+ }
+
+ /* Switch to TR page */
+ lan88xx_write_page(phydev, LAN88XX_EXT_PAGE_ACCESS_TR);
+
+ ret = __phy_write(phydev, LAN88XX_EXT_PAGE_TR_LOW_DATA,
+ (data & 0xFFFF));
+ if (ret < 0) {
+ pr_warn("Failed to write TR low data\n");
+ goto err;
+ }
+
+ ret = __phy_write(phydev, LAN88XX_EXT_PAGE_TR_HIGH_DATA,
+ (data & 0x00FF0000) >> 16);
+ if (ret < 0) {
+ pr_warn("Failed to write TR high data\n");
+ goto err;
+ }
+
+ /* Config control bits [15:13] of register */
+ buf = (regaddr & ~(0x3 << 13));/* Clr [14:13] to write data in reg */
+ buf |= 0x8000; /* Set [15] to Packet transmit */
+
+ ret = __phy_write(phydev, LAN88XX_EXT_PAGE_TR_CR, buf);
+ if (ret < 0) {
+ pr_warn("Failed to write data in reg\n");
+ goto err;
+ }
+
+ usleep_range(1000, 2000);/* Wait for Data to be written */
+ val = __phy_read(phydev, LAN88XX_EXT_PAGE_TR_CR);
+ if (!(val & 0x8000))
+ pr_warn("TR Register[0x%X] configuration failed\n", regaddr);
+err:
+ return phy_restore_page(phydev, save_page, ret);
+}
+
+static void lan88xx_config_TR_regs(struct phy_device *phydev)
+{
+ int err;
+
+ /* Get access to Channel 0x1, Node 0xF , Register 0x01.
+ * Write 24-bit value 0x12B00A to register. Setting MrvlTrFix1000Kf,
+ * MrvlTrFix1000Kp, MasterEnableTR bits.
+ */
+ err = lan88xx_TR_reg_set(phydev, 0x0F82, 0x12B00A);
+ if (err < 0)
+ pr_warn("Failed to Set Register[0x0F82]\n");
+
+ /* Get access to Channel b'10, Node b'1101, Register 0x06.
+ * Write 24-bit value 0xD2C46F to register. Setting SSTrKf1000Slv,
+ * SSTrKp1000Mas bits.
+ */
+ err = lan88xx_TR_reg_set(phydev, 0x168C, 0xD2C46F);
+ if (err < 0)
+ pr_warn("Failed to Set Register[0x168C]\n");
+
+ /* Get access to Channel b'10, Node b'1111, Register 0x11.
+ * Write 24-bit value 0x620 to register. Setting rem_upd_done_thresh
+ * bits
+ */
+ err = lan88xx_TR_reg_set(phydev, 0x17A2, 0x620);
+ if (err < 0)
+ pr_warn("Failed to Set Register[0x17A2]\n");
+
+ /* Get access to Channel b'10, Node b'1101, Register 0x10.
+ * Write 24-bit value 0xEEFFDD to register. Setting
+ * eee_TrKp1Long_1000, eee_TrKp2Long_1000, eee_TrKp3Long_1000,
+ * eee_TrKp1Short_1000,eee_TrKp2Short_1000, eee_TrKp3Short_1000 bits.
+ */
+ err = lan88xx_TR_reg_set(phydev, 0x16A0, 0xEEFFDD);
+ if (err < 0)
+ pr_warn("Failed to Set Register[0x16A0]\n");
+
+ /* Get access to Channel b'10, Node b'1101, Register 0x13.
+ * Write 24-bit value 0x071448 to register. Setting
+ * slv_lpi_tr_tmr_val1, slv_lpi_tr_tmr_val2 bits.
+ */
+ err = lan88xx_TR_reg_set(phydev, 0x16A6, 0x071448);
+ if (err < 0)
+ pr_warn("Failed to Set Register[0x16A6]\n");
+
+ /* Get access to Channel b'10, Node b'1101, Register 0x12.
+ * Write 24-bit value 0x13132F to register. Setting
+ * slv_sigdet_timer_val1, slv_sigdet_timer_val2 bits.
+ */
+ err = lan88xx_TR_reg_set(phydev, 0x16A4, 0x13132F);
+ if (err < 0)
+ pr_warn("Failed to Set Register[0x16A4]\n");
+
+ /* Get access to Channel b'10, Node b'1101, Register 0x14.
+ * Write 24-bit value 0x0 to register. Setting eee_3level_delay,
+ * eee_TrKf_freeze_delay bits.
+ */
+ err = lan88xx_TR_reg_set(phydev, 0x16A8, 0x0);
+ if (err < 0)
+ pr_warn("Failed to Set Register[0x16A8]\n");
+
+ /* Get access to Channel b'01, Node b'1111, Register 0x34.
+ * Write 24-bit value 0x91B06C to register. Setting
+ * FastMseSearchThreshLong1000, FastMseSearchThreshShort1000,
+ * FastMseSearchUpdGain1000 bits.
+ */
+ err = lan88xx_TR_reg_set(phydev, 0x0FE8, 0x91B06C);
+ if (err < 0)
+ pr_warn("Failed to Set Register[0x0FE8]\n");
+
+ /* Get access to Channel b'01, Node b'1111, Register 0x3E.
+ * Write 24-bit value 0xC0A028 to register. Setting
+ * FastMseKp2ThreshLong1000, FastMseKp2ThreshShort1000,
+ * FastMseKp2UpdGain1000, FastMseKp2ExitEn1000 bits.
+ */
+ err = lan88xx_TR_reg_set(phydev, 0x0FFC, 0xC0A028);
+ if (err < 0)
+ pr_warn("Failed to Set Register[0x0FFC]\n");
+
+ /* Get access to Channel b'01, Node b'1111, Register 0x35.
+ * Write 24-bit value 0x041600 to register. Setting
+ * FastMseSearchPhShNum1000, FastMseSearchClksPerPh1000,
+ * FastMsePhChangeDelay1000 bits.
+ */
+ err = lan88xx_TR_reg_set(phydev, 0x0FEA, 0x041600);
+ if (err < 0)
+ pr_warn("Failed to Set Register[0x0FEA]\n");
+
+ /* Get access to Channel b'10, Node b'1101, Register 0x03.
+ * Write 24-bit value 0x000004 to register. Setting TrFreeze bits.
+ */
+ err = lan88xx_TR_reg_set(phydev, 0x1686, 0x000004);
+ if (err < 0)
+ pr_warn("Failed to Set Register[0x1686]\n");
+}
+
static int lan88xx_probe(struct phy_device *phydev)
{
struct device *dev = &phydev->mdio.dev;
@@ -132,6 +287,25 @@ static void lan88xx_set_mdix(struct phy_device *phydev)
phy_write(phydev, LAN88XX_EXT_PAGE_ACCESS, LAN88XX_EXT_PAGE_SPACE_0);
}
+static int lan88xx_config_init(struct phy_device *phydev)
+{
+ int val;
+
+ genphy_config_init(phydev);
+ /*Zerodetect delay enable */
+ val = phy_read_mmd(phydev, MDIO_MMD_PCS,
+ PHY_ARDENNES_MMD_DEV_3_PHY_CFG);
+ val |= PHY_ARDENNES_MMD_DEV_3_PHY_CFG_ZD_DLY_EN_;
+
+ phy_write_mmd(phydev, MDIO_MMD_PCS, PHY_ARDENNES_MMD_DEV_3_PHY_CFG,
+ val);
+
+ /* Config DSP registers */
+ lan88xx_config_TR_regs(phydev);
+
+ return 0;
+}
+
static int lan88xx_config_aneg(struct phy_device *phydev)
{
lan88xx_set_mdix(phydev);
@@ -151,7 +325,7 @@ static struct phy_driver microchip_phy_driver[] = {
.probe = lan88xx_probe,
.remove = lan88xx_remove,
- .config_init = genphy_config_init,
+ .config_init = lan88xx_config_init,
.config_aneg = lan88xx_config_aneg,
.ack_interrupt = lan88xx_phy_ack_interrupt,
@@ -160,6 +334,8 @@ static struct phy_driver microchip_phy_driver[] = {
.suspend = lan88xx_suspend,
.resume = genphy_resume,
.set_wol = lan88xx_set_wol,
+ .read_page = lan88xx_read_page,
+ .write_page = lan88xx_write_page,
} };
module_phy_driver(microchip_phy_driver);
diff --git a/include/linux/microchipphy.h b/include/linux/microchipphy.h
index eb492d47f717..8f9c90379732 100644
--- a/include/linux/microchipphy.h
+++ b/include/linux/microchipphy.h
@@ -70,4 +70,12 @@
#define LAN88XX_MMD3_CHIP_ID (32877)
#define LAN88XX_MMD3_CHIP_REV (32878)
+/* DSP registers */
+#define PHY_ARDENNES_MMD_DEV_3_PHY_CFG (0x806A)
+#define PHY_ARDENNES_MMD_DEV_3_PHY_CFG_ZD_DLY_EN_ (0x2000)
+#define LAN88XX_EXT_PAGE_ACCESS_TR (0x52B5)
+#define LAN88XX_EXT_PAGE_TR_CR 16
+#define LAN88XX_EXT_PAGE_TR_LOW_DATA 17
+#define LAN88XX_EXT_PAGE_TR_HIGH_DATA 18
+
#endif /* _MICROCHIPPHY_H */
--
2.16.2
^ permalink raw reply related
* KASAN: use-after-free Read in tipc_sub_unsubscribe (2)
From: syzbot @ 2018-04-11 15:02 UTC (permalink / raw)
To: davem, jon.maloy, linux-kernel, netdev, syzkaller-bugs,
tipc-discussion, ying.xue
Hello,
syzbot hit the following crash on upstream commit
b284d4d5a6785f8cd07eda2646a95782373cd01e (Tue Apr 10 19:25:30 2018 +0000)
Merge tag 'ceph-for-4.17-rc1' of git://github.com/ceph/ceph-client
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=aa245f26d42b8305d157
So far this crash happened 2 times on upstream.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5881855630901248
syzkaller reproducer:
https://syzkaller.appspot.com/x/repro.syz?id=5979790213382144
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=5808961445953536
Kernel config:
https://syzkaller.appspot.com/x/.config?id=-1223000601505858474
compiler: gcc (GCC) 8.0.1 20180301 (experimental)
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+aa245f26d42b8305d157@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
R10: 0000000020b89fe4 R11: 0000000000000246 R12: 0000000000000005
R13: ffffffffffffffff R14: 0000000000000000 R15: 0000000000000000
Service creation failed, no memory
Failed to subscribe for {1906,0,4294967295}
==================================================================
BUG: KASAN: use-after-free in tipc_sub_unsubscribe+0x22d/0x305
net/tipc/subscr.c:167
Read of size 4 at addr ffff8801b78718d8 by task syzkaller446011/4466
CPU: 1 PID: 4466 Comm: syzkaller446011 Not tainted 4.16.0+ #19
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0xac/0x2f5 mm/kasan/report.c:412
__asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
tipc_sub_unsubscribe+0x22d/0x305 net/tipc/subscr.c:167
tipc_conn_delete_sub+0x32d/0x530 net/tipc/topsrv.c:245
tipc_topsrv_kern_unsubscr+0x280/0x3f0 net/tipc/topsrv.c:598
tipc_group_delete+0x2dd/0x3f0 net/tipc/group.c:231
tipc_sk_leave+0x10e/0x210 net/tipc/socket.c:2800
tipc_release+0x146/0x1290 net/tipc/socket.c:576
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
SYSC_exit_group kernel/exit.c:979 [inline]
SyS_exit_group+0x1d/0x20 kernel/exit.c:977
do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x43f1f8
RSP: 002b:00007fff7867bac8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000000000043f1f8
RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
RBP: 00000000004bf2e8 R08: 00000000000000e7 R09: ffffffffffffffd0
R10: 0000000020b89fe4 R11: 0000000000000246 R12: 0000000000000001
R13: 00000000006d1180 R14: 0000000000000000 R15: 0000000000000000
Allocated by task 4466:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
kmem_cache_alloc_trace+0x152/0x780 mm/slab.c:3620
kmalloc include/linux/slab.h:512 [inline]
tipc_sub_subscribe+0x25a/0x6b0 net/tipc/subscr.c:143
tipc_conn_rcv_sub.isra.5+0x42c/0x7e0 net/tipc/topsrv.c:381
tipc_topsrv_kern_subscr+0x72b/0xad0 net/tipc/topsrv.c:582
tipc_group_create+0x72e/0xa50 net/tipc/group.c:194
tipc_sk_join net/tipc/socket.c:2766 [inline]
tipc_setsockopt+0x2c9/0xd70 net/tipc/socket.c:2881
__sys_setsockopt+0x1bd/0x390 net/socket.c:1903
SYSC_setsockopt net/socket.c:1914 [inline]
SyS_setsockopt+0x34/0x50 net/socket.c:1911
do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
Freed by task 4466:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xd9/0x260 mm/slab.c:3813
tipc_sub_kref_release net/tipc/subscr.c:117 [inline]
kref_put include/linux/kref.h:70 [inline]
tipc_sub_put+0x33/0x40 net/tipc/subscr.c:122
tipc_nametbl_unsubscribe+0x52c/0xaf0 net/tipc/name_table.c:709
tipc_sub_unsubscribe+0x6d/0x305 net/tipc/subscr.c:166
tipc_conn_delete_sub+0x32d/0x530 net/tipc/topsrv.c:245
tipc_topsrv_kern_unsubscr+0x280/0x3f0 net/tipc/topsrv.c:598
tipc_group_delete+0x2dd/0x3f0 net/tipc/group.c:231
tipc_sk_leave+0x10e/0x210 net/tipc/socket.c:2800
tipc_release+0x146/0x1290 net/tipc/socket.c:576
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
SYSC_exit_group kernel/exit.c:979 [inline]
SyS_exit_group+0x1d/0x20 kernel/exit.c:977
do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
The buggy address belongs to the object at ffff8801b7871840
which belongs to the cache kmalloc-256 of size 256
The buggy address is located 152 bytes inside of
256-byte region [ffff8801b7871840, ffff8801b7871940)
The buggy address belongs to the page:
page:ffffea0006de1c40 count:1 mapcount:0 mapping:ffff8801b78710c0 index:0x0
flags: 0x2fffc0000000100(slab)
raw: 02fffc0000000100 ffff8801b78710c0 0000000000000000 000000010000000c
raw: ffffea00071ce1a0 ffffea0006db8fa0 ffff8801dac007c0 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801b7871780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801b7871800: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
> ffff8801b7871880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8801b7871900: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
ffff8801b7871980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* Re: [PATCH net] sctp: do not check port in sctp_inet6_cmp_addr
From: Marcelo Ricardo Leitner @ 2018-04-11 14:59 UTC (permalink / raw)
To: Neil Horman; +Cc: Xin Long, network dev, linux-sctp, davem
In-Reply-To: <20180411143607.GA4141@hmswarspite.think-freely.org>
On Wed, Apr 11, 2018 at 10:36:07AM -0400, Neil Horman wrote:
> On Wed, Apr 11, 2018 at 08:58:05PM +0800, Xin Long wrote:
> > pf->cmp_addr() is called before binding a v6 address to the sock. It
> > should not check ports, like in sctp_inet_cmp_addr.
> >
> > But sctp_inet6_cmp_addr checks the addr by invoking af(6)->cmp_addr,
> > sctp_v6_cmp_addr where it also compares the ports.
> >
> > This would cause that setsockopt(SCTP_SOCKOPT_BINDX_ADD) could bind
> > multiple duplicated IPv6 addresses after Commit 40b4f0fd74e4 ("sctp:
> > lack the check for ports in sctp_v6_cmp_addr").
> >
> > This patch is to remove af->cmp_addr called in sctp_inet6_cmp_addr,
> > but do the proper check for both v6 addrs and v4mapped addrs.
> >
> > Fixes: 40b4f0fd74e4 ("sctp: lack the check for ports in sctp_v6_cmp_addr")
> > Reported-by: Jianwen Ji <jiji@redhat.com>
> > Signed-off-by: Xin Long <lucien.xin@gmail.com>
> > ---
> > net/sctp/ipv6.c | 27 ++++++++++++++++++++++++---
> > 1 file changed, 24 insertions(+), 3 deletions(-)
> >
> > diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
> > index f1fc48e..be4b72c 100644
> > --- a/net/sctp/ipv6.c
> > +++ b/net/sctp/ipv6.c
> > @@ -846,8 +846,8 @@ static int sctp_inet6_cmp_addr(const union sctp_addr *addr1,
> > const union sctp_addr *addr2,
> > struct sctp_sock *opt)
> > {
> > - struct sctp_af *af1, *af2;
> > struct sock *sk = sctp_opt2sk(opt);
> > + struct sctp_af *af1, *af2;
> >
> > af1 = sctp_get_af_specific(addr1->sa.sa_family);
> > af2 = sctp_get_af_specific(addr2->sa.sa_family);
> > @@ -863,10 +863,31 @@ static int sctp_inet6_cmp_addr(const union sctp_addr *addr1,
> > if (sctp_is_any(sk, addr1) || sctp_is_any(sk, addr2))
> > return 1;
> >
> > - if (addr1->sa.sa_family != addr2->sa.sa_family)
> > + if (addr1->sa.sa_family != addr2->sa.sa_family) {
> > + if (addr1->sa.sa_family == AF_INET &&
> > + addr2->sa.sa_family == AF_INET6 &&
> > + ipv6_addr_v4mapped(&addr2->v6.sin6_addr))
> > + if (addr2->v6.sin6_addr.s6_addr32[3] ==
> > + addr1->v4.sin_addr.s_addr)
> > + return 1;
> > + if (addr2->sa.sa_family == AF_INET &&
> > + addr1->sa.sa_family == AF_INET6 &&
> > + ipv6_addr_v4mapped(&addr1->v6.sin6_addr))
> > + if (addr1->v6.sin6_addr.s6_addr32[3] ==
> > + addr2->v4.sin_addr.s_addr)
> > + return 1;
> > + return 0;
> > + }
> > +
> > + if (!ipv6_addr_equal(&addr1->v6.sin6_addr, &addr2->v6.sin6_addr))
> > + return 0;
> > +
> > + if ((ipv6_addr_type(&addr1->v6.sin6_addr) & IPV6_ADDR_LINKLOCAL) &&
> > + addr1->v6.sin6_scope_id && addr2->v6.sin6_scope_id &&
> > + addr1->v6.sin6_scope_id != addr2->v6.sin6_scope_id)
> > return 0;
> >
> > - return af1->cmp_addr(addr1, addr2);
> > + return 1;
> > }
> >
> > /* Verify that the provided sockaddr looks bindable. Common verification,
> > --
> > 2.1.0
> >
> This looks correct to me, but is it worth duplicating the comparison code like
> this from the cmp_addr function? It might be more worthwhile to add a flag to
> the cmp_addr method to direct weather it needs to check port values or not.
> That way you could continue to use the cmp_addr function here.
Adding a flag into sctp_v6_cmp_addr will get us a terrible code to
read. It's already not one of the best looking part of it. Maybe
still duplicate part of it it, but at 'af' level? As in:
- af->cmp_addr
- af->cmp_addr_port
Marcelo
^ permalink raw reply
* Re: [PATCH] dec: tulip: de4x5: Replace mdelay with usleep_range in de4x5_hw_init
From: kbuild test robot @ 2018-04-11 14:58 UTC (permalink / raw)
To: Jia-Ju Bai
Cc: kbuild-all, davem, dhowells, stephen, johannes.berg,
arvind.yadav.cs, netdev, linux-parisc, linux-kernel, Jia-Ju Bai
In-Reply-To: <1523412054-2108-1-git-send-email-baijiaju1990@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4811 bytes --]
Hi Jia-Ju,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
[also build test ERROR on v4.16 next-20180411]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Jia-Ju-Bai/dec-tulip-de4x5-Replace-mdelay-with-usleep_range-in-de4x5_hw_init/20180411-222527
config: i386-randconfig-x015-201814 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/net//ethernet/dec/tulip/de4x5.c: In function 'de4x5_hw_init':
>> drivers/net//ethernet/dec/tulip/de4x5.c:1110:5: error: implicit declaration of function 'usleep'; did you mean 'ssleep'? [-Werror=implicit-function-declaration]
usleep(10000, 11000);
^~~~~~
ssleep
cc1: some warnings being treated as errors
vim +1110 drivers/net//ethernet/dec/tulip/de4x5.c
1091
1092
1093 static int
1094 de4x5_hw_init(struct net_device *dev, u_long iobase, struct device *gendev)
1095 {
1096 char name[DE4X5_NAME_LENGTH + 1];
1097 struct de4x5_private *lp = netdev_priv(dev);
1098 struct pci_dev *pdev = NULL;
1099 int i, status=0;
1100
1101 dev_set_drvdata(gendev, dev);
1102
1103 /* Ensure we're not sleeping */
1104 if (lp->bus == EISA) {
1105 outb(WAKEUP, PCI_CFPM);
1106 } else {
1107 pdev = to_pci_dev (gendev);
1108 pci_write_config_byte(pdev, PCI_CFDA_PSM, WAKEUP);
1109 }
> 1110 usleep(10000, 11000);
1111
1112 RESET_DE4X5;
1113
1114 if ((inl(DE4X5_STS) & (STS_TS | STS_RS)) != 0) {
1115 return -ENXIO; /* Hardware could not reset */
1116 }
1117
1118 /*
1119 ** Now find out what kind of DC21040/DC21041/DC21140 board we have.
1120 */
1121 lp->useSROM = false;
1122 if (lp->bus == PCI) {
1123 PCI_signature(name, lp);
1124 } else {
1125 EISA_signature(name, gendev);
1126 }
1127
1128 if (*name == '\0') { /* Not found a board signature */
1129 return -ENXIO;
1130 }
1131
1132 dev->base_addr = iobase;
1133 printk ("%s: %s at 0x%04lx", dev_name(gendev), name, iobase);
1134
1135 status = get_hw_addr(dev);
1136 printk(", h/w address %pM\n", dev->dev_addr);
1137
1138 if (status != 0) {
1139 printk(" which has an Ethernet PROM CRC error.\n");
1140 return -ENXIO;
1141 } else {
1142 skb_queue_head_init(&lp->cache.queue);
1143 lp->cache.gepc = GEP_INIT;
1144 lp->asBit = GEP_SLNK;
1145 lp->asPolarity = GEP_SLNK;
1146 lp->asBitValid = ~0;
1147 lp->timeout = -1;
1148 lp->gendev = gendev;
1149 spin_lock_init(&lp->lock);
1150 timer_setup(&lp->timer, de4x5_ast, 0);
1151 de4x5_parse_params(dev);
1152
1153 /*
1154 ** Choose correct autosensing in case someone messed up
1155 */
1156 lp->autosense = lp->params.autosense;
1157 if (lp->chipset != DC21140) {
1158 if ((lp->chipset==DC21040) && (lp->params.autosense&TP_NW)) {
1159 lp->params.autosense = TP;
1160 }
1161 if ((lp->chipset==DC21041) && (lp->params.autosense&BNC_AUI)) {
1162 lp->params.autosense = BNC;
1163 }
1164 }
1165 lp->fdx = lp->params.fdx;
1166 sprintf(lp->adapter_name,"%s (%s)", name, dev_name(gendev));
1167
1168 lp->dma_size = (NUM_RX_DESC + NUM_TX_DESC) * sizeof(struct de4x5_desc);
1169 #if defined(__alpha__) || defined(__powerpc__) || defined(CONFIG_SPARC) || defined(DE4X5_DO_MEMCPY)
1170 lp->dma_size += RX_BUFF_SZ * NUM_RX_DESC + DE4X5_ALIGN;
1171 #endif
1172 lp->rx_ring = dma_alloc_coherent(gendev, lp->dma_size,
1173 &lp->dma_rings, GFP_ATOMIC);
1174 if (lp->rx_ring == NULL) {
1175 return -ENOMEM;
1176 }
1177
1178 lp->tx_ring = lp->rx_ring + NUM_RX_DESC;
1179
1180 /*
1181 ** Set up the RX descriptor ring (Intels)
1182 ** Allocate contiguous receive buffers, long word aligned (Alphas)
1183 */
1184 #if !defined(__alpha__) && !defined(__powerpc__) && !defined(CONFIG_SPARC) && !defined(DE4X5_DO_MEMCPY)
1185 for (i=0; i<NUM_RX_DESC; i++) {
1186 lp->rx_ring[i].status = 0;
1187 lp->rx_ring[i].des1 = cpu_to_le32(RX_BUFF_SZ);
1188 lp->rx_ring[i].buf = 0;
1189 lp->rx_ring[i].next = 0;
1190 lp->rx_skb[i] = (struct sk_buff *) 1; /* Dummy entry */
1191 }
1192
---
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: 31227 bytes --]
^ permalink raw reply
* Re: WARNING in kobject_add_internal
From: Dmitry Vyukov @ 2018-04-11 14:57 UTC (permalink / raw)
To: syzbot
Cc: bridge, David Miller, Greg Kroah-Hartman, LKML, netdev,
stephen hemminger, syzkaller-bugs
In-Reply-To: <001a113f8036fab00405620e4d72@google.com>
On Fri, Jan 5, 2018 at 10:41 PM, syzbot
<syzbot+e204ced820ef739d71ef5438f5e1976a874abc8d@syzkaller.appspotmail.com>
wrote:
> syzkaller has found reproducer for the following crash on
> 89876f275e8d562912d9c238cd888b52065cf25c
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by:
> syzbot+e204ced820ef739d71ef5438f5e1976a874abc8d@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed.
#syz dup: WARNING: kobject bug in device_add
> ------------[ cut here ]------------
> kobject_add_internal failed for (error: -12 parent: net)
> WARNING: CPU: 1 PID: 3494 at lib/kobject.c:244
> kobject_add_internal+0x3f6/0xbc0 lib/kobject.c:242
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 1 PID: 3494 Comm: syzkaller425998 Not tainted 4.15.0-rc6+ #249
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x257 lib/dump_stack.c:53
> panic+0x1e4/0x41c kernel/panic.c:183
> __warn+0x1dc/0x200 kernel/panic.c:547
> report_bug+0x211/0x2d0 lib/bug.c:184
> fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
> fixup_bug arch/x86/kernel/traps.c:247 [inline]
> do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
> invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1079
> RIP: 0010:kobject_add_internal+0x3f6/0xbc0 lib/kobject.c:242
> RSP: 0018:ffff8801c53c76f0 EFLAGS: 00010286
> RAX: dffffc0000000008 RBX: ffff8801bf5a88d8 RCX: ffffffff8159da9e
> RDX: 0000000000000000 RSI: 1ffff10038a78e99 RDI: ffff8801c53c73f8
> RBP: ffff8801c53c77e8 R08: 1ffff10038a78e5b R09: 0000000000000000
> R10: ffff8801c53c74b0 R11: 0000000000000000 R12: 1ffff10038a78ee4
> R13: 00000000fffffff4 R14: ffff8801d8359a80 R15: ffffffff86201980
> kobject_add_varg lib/kobject.c:366 [inline]
> kobject_add+0x132/0x1f0 lib/kobject.c:411
> device_add+0x35d/0x1650 drivers/base/core.c:1787
> netdev_register_kobject+0x183/0x360 net/core/net-sysfs.c:1604
> register_netdevice+0xb2b/0x1010 net/core/dev.c:7698
> tun_set_iff drivers/net/tun.c:2319 [inline]
> __tun_chr_ioctl+0x1d89/0x3dd0 drivers/net/tun.c:2524
> tun_chr_ioctl+0x2a/0x40 drivers/net/tun.c:2773
> vfs_ioctl fs/ioctl.c:46 [inline]
> do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
> SYSC_ioctl fs/ioctl.c:701 [inline]
> SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
> entry_SYSCALL_64_fastpath+0x23/0x9a
> RIP: 0033:0x444fc9
> RSP: 002b:00007fff53389dc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 0000000000444fc9
> RDX: 0000000020533000 RSI: 00000000400454ca RDI: 0000000000000004
> RBP: 0000000000000005 R08: 0000000000000002 R09: 0000006f00003131
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000402500
> R13: 0000000000402590 R14: 0000000000000000 R15: 0000000000000000
>
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
^ permalink raw reply
* [PATCH net 2/2] ibmvnic: Do not notify peers on parameter change resets
From: Nathan Fontenot @ 2018-04-11 14:37 UTC (permalink / raw)
To: netdev; +Cc: jallen, tlfalcon
In-Reply-To: <152345733402.41721.15717591824692008270.stgit@ltcalpine2-lp14.aus.stglabs.ibm.com>
When attempting to change the driver parameters, such as the MTU
value or number of queues, do not call netdev_notify_peers().
Doing so will deadlock on the rtnl_lock.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index c6d5e9448eef..fdca1ea5bbf9 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1843,7 +1843,8 @@ static int do_reset(struct ibmvnic_adapter *adapter,
for (i = 0; i < adapter->req_rx_queues; i++)
napi_schedule(&adapter->napi[i]);
- if (adapter->reset_reason != VNIC_RESET_FAILOVER)
+ if (adapter->reset_reason != VNIC_RESET_FAILOVER &&
+ adapter->reset_reason != VNIC_RESET_CHANGE_PARAM)
netdev_notify_peers(netdev);
netif_carrier_on(netdev);
^ permalink raw reply related
* Re: [PATCH v3 0/2] vhost: fix vhost_vq_access_ok() log check
From: David Miller @ 2018-04-11 14:55 UTC (permalink / raw)
To: mst
Cc: stefanha, virtualization, torvalds, jasowang, netdev,
syzkaller-bugs, kvm, linux-kernel
In-Reply-To: <20180411162345-mutt-send-email-mst@kernel.org>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Wed, 11 Apr 2018 16:24:02 +0300
> On Wed, Apr 11, 2018 at 10:35:39AM +0800, Stefan Hajnoczi wrote:
>> v3:
>> * Rebased onto net/master and resolved conflict [DaveM]
>>
>> v2:
>> * Rewrote the conditional to make the vq access check clearer [Linus]
>> * Added Patch 2 to make the return type consistent and harder to misuse [Linus]
>>
>> The first patch fixes the vhost virtqueue access check which was recently
>> broken. The second patch replaces the int return type with bool to prevent
>> future bugs.
>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>
> We need the 1st one on stable I think.
Series applied and patch #1 queued up for -stable.
^ permalink raw reply
* [PATCH net 1/2] ibmvnic: Handle all login error conditions
From: Nathan Fontenot @ 2018-04-11 14:37 UTC (permalink / raw)
To: netdev; +Cc: jallen, tlfalcon
In-Reply-To: <152345733402.41721.15717591824692008270.stgit@ltcalpine2-lp14.aus.stglabs.ibm.com>
There is a bug in handling the possible return codes from sending the
login CRQ. The current code treats any non-success return value,
minus failure to send the crq and a timeout waiting for a login response,
as a need to re-send the login CRQ. This can put the drive in an
inifinite loop of trying to login when getting return values other
that a partial success such as a return code of aborted. For these
scenarios the login will not ever succeed at this point and the
driver would need to be reset again.
To resolve this loop trying to login is updated to only retry the
login if the driver gets a return code of a partial success. Other
return coes are treated as an error and the driver returns an error
from ibmvnic_login().
To avoid infinite looping in the partial success return cases, the
number of retries is capped at the maximum number of supported
queues. This value was chosen because the driver does a renegatiation
of capabilities which sets the number of queus possible and allows
the driver to attempt a login for possible value for the number
of queues supported.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 55 +++++++++++++++++++++++-------------
drivers/net/ethernet/ibm/ibmvnic.h | 1 -
2 files changed, 35 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index aad5658d79d5..c6d5e9448eef 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -794,46 +794,61 @@ static int ibmvnic_login(struct net_device *netdev)
{
struct ibmvnic_adapter *adapter = netdev_priv(netdev);
unsigned long timeout = msecs_to_jiffies(30000);
- struct device *dev = &adapter->vdev->dev;
+ int retry_count = 0;
int rc;
do {
- if (adapter->renegotiate) {
- adapter->renegotiate = false;
+ if (retry_count > IBMVNIC_MAX_QUEUES) {
+ netdev_warn(netdev, "Login attempts exceeded\n");
+ return -1;
+ }
+
+ adapter->init_done_rc = 0;
+ reinit_completion(&adapter->init_done);
+ rc = send_login(adapter);
+ if (rc) {
+ netdev_warn(netdev, "Unable to login\n");
+ return rc;
+ }
+
+ if (!wait_for_completion_timeout(&adapter->init_done,
+ timeout)) {
+ netdev_warn(netdev, "Login timed out\n");
+ return -1;
+ }
+
+ if (adapter->init_done_rc == PARTIALSUCCESS) {
+ retry_count++;
release_sub_crqs(adapter, 1);
+ adapter->init_done_rc = 0;
reinit_completion(&adapter->init_done);
send_cap_queries(adapter);
if (!wait_for_completion_timeout(&adapter->init_done,
timeout)) {
- dev_err(dev, "Capabilities query timeout\n");
+ netdev_warn(netdev,
+ "Capabilities query timed out\n");
return -1;
}
+
rc = init_sub_crqs(adapter);
if (rc) {
- dev_err(dev,
- "Initialization of SCRQ's failed\n");
+ netdev_warn(netdev,
+ "SCRQ initialization failed\n");
return -1;
}
+
rc = init_sub_crq_irqs(adapter);
if (rc) {
- dev_err(dev,
- "Initialization of SCRQ's irqs failed\n");
+ netdev_warn(netdev,
+ "SCRQ irq initialization failed\n");
return -1;
}
- }
-
- reinit_completion(&adapter->init_done);
- rc = send_login(adapter);
- if (rc) {
- dev_err(dev, "Unable to attempt device login\n");
- return rc;
- } else if (!wait_for_completion_timeout(&adapter->init_done,
- timeout)) {
- dev_err(dev, "Login timeout\n");
+ } else if (adapter->init_done_rc) {
+ netdev_warn(netdev, "Adapter login failed\n");
return -1;
}
- } while (adapter->renegotiate);
+ } while (adapter->init_done_rc == PARTIALSUCCESS);
/* handle pending MAC address changes after successful login */
if (adapter->mac_change_pending) {
@@ -3942,7 +3957,7 @@ static int handle_login_rsp(union ibmvnic_crq *login_rsp_crq,
* to resend the login buffer with fewer queues requested.
*/
if (login_rsp_crq->generic.rc.code) {
- adapter->renegotiate = true;
+ adapter->init_done_rc = login_rsp_crq->generic.rc.code;
complete(&adapter->init_done);
return 0;
}
diff --git a/drivers/net/ethernet/ibm/ibmvnic.h b/drivers/net/ethernet/ibm/ibmvnic.h
index 99c0b58c2c39..22391e8805f6 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.h
+++ b/drivers/net/ethernet/ibm/ibmvnic.h
@@ -1035,7 +1035,6 @@ struct ibmvnic_adapter {
struct ibmvnic_sub_crq_queue **tx_scrq;
struct ibmvnic_sub_crq_queue **rx_scrq;
- bool renegotiate;
/* rx structs */
struct napi_struct *napi;
^ permalink raw reply related
* [PATCH net 0/2] ibmvnic: Fix parameter change request handling
From: Nathan Fontenot @ 2018-04-11 14:37 UTC (permalink / raw)
To: netdev; +Cc: jallen, tlfalcon
When updating parameters for the ibmvnic driver there is a possibility
of entering an infinite loop if a return value other that a partial
success is received from sending the login CRQ.
Also, a deadlock can occur on the rtnl lock if netdev_notify_peers()
is called during driver reset for a parameter change reset.
This patch set corrects both of these issues by updating the return
code handling in ibmvnic_login() nand gaurding against calling
netdev_notify_peers() for parameter change requests.
-Nathan
---
Nathan Fontenot (2):
ibmvnic: Handle all login error conditions
ibmvnic: Do not notify peers on parameter change resets
drivers/net/ethernet/ibm/ibmvnic.c | 58 +++++++++++++++++++++++-------------
drivers/net/ethernet/ibm/ibmvnic.h | 1 -
2 files changed, 37 insertions(+), 22 deletions(-)
^ permalink raw reply
* RE: [PATCH v1 net 0/3] lan78xx: Fixes and enhancements
From: RaghuramChary.Jallipalli @ 2018-04-11 14:54 UTC (permalink / raw)
To: davem; +Cc: netdev, UNGLinuxDriver, Woojung.Huh
In-Reply-To: <20180411.102009.742541645869806513.davem@davemloft.net>
>
> > These series of patches have fix and enhancements for lan78xx driver.
>
> Two problems with this series:
>
> 1) Only bug fixes are appropriate at this time. Features and "enhancements"
> belong in net-next which is not open right now.
>
> 2) Patch #3 doesn't even apply cleanly. Always base your patches on the
> current tree.
>
Sure, will send #2,#3 patches in net-next when it opens.
Also will make sure they will be based on current tree.
Thanks,
Raghu
^ permalink raw reply
* Re: [RFC PATCH net-next v5 3/4] virtio_net: Extend virtio to use VF datapath when available
From: Jiri Pirko @ 2018-04-11 14:51 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Samudrala, Sridhar, stephen, davem, netdev, virtualization,
virtio-dev, jesse.brandeburg, alexander.h.duyck, kubakici,
jasowang, loseweigh
In-Reply-To: <20180411174157-mutt-send-email-mst@kernel.org>
Wed, Apr 11, 2018 at 04:45:07PM CEST, mst@redhat.com wrote:
>On Wed, Apr 11, 2018 at 10:03:32AM +0200, Jiri Pirko wrote:
>> Wed, Apr 11, 2018 at 08:24:43AM CEST, sridhar.samudrala@intel.com wrote:
>> >On 4/10/2018 11:03 PM, Jiri Pirko wrote:
>> >> Tue, Apr 10, 2018 at 05:59:02PM CEST, sridhar.samudrala@intel.com wrote:
>> >> > On 4/10/2018 8:43 AM, Jiri Pirko wrote:
>> >> > > Tue, Apr 10, 2018 at 05:27:48PM CEST, sridhar.samudrala@intel.com wrote:
>> >> > > > On 4/10/2018 8:22 AM, Jiri Pirko wrote:
>> >> > > > > Tue, Apr 10, 2018 at 05:13:40PM CEST, sridhar.samudrala@intel.com wrote:
>> >> > > > > > On 4/10/2018 3:55 AM, Jiri Pirko wrote:
>> >> > > > > > > Mon, Apr 09, 2018 at 08:47:06PM CEST, sridhar.samudrala@intel.com wrote:
>> >> > > > > > > > On 4/9/2018 1:07 AM, Jiri Pirko wrote:
>> >> > > > > > > > > Sat, Apr 07, 2018 at 12:59:14AM CEST, sridhar.samudrala@intel.com wrote:
>> >> > > > > > > > > > On 4/6/2018 5:48 AM, Jiri Pirko wrote:
>> >> > > > > > > > > > > Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudrala@intel.com wrote:
>> >> > > > > > > > > [...]
>> >> > > > > > > > >
>> >> > > > > > > > > > > > +static int virtnet_bypass_join_child(struct net_device *bypass_netdev,
>> >> > > > > > > > > > > > + struct net_device *child_netdev)
>> >> > > > > > > > > > > > +{
>> >> > > > > > > > > > > > + struct virtnet_bypass_info *vbi;
>> >> > > > > > > > > > > > + bool backup;
>> >> > > > > > > > > > > > +
>> >> > > > > > > > > > > > + vbi = netdev_priv(bypass_netdev);
>> >> > > > > > > > > > > > + backup = (child_netdev->dev.parent == bypass_netdev->dev.parent);
>> >> > > > > > > > > > > > + if (backup ? rtnl_dereference(vbi->backup_netdev) :
>> >> > > > > > > > > > > > + rtnl_dereference(vbi->active_netdev)) {
>> >> > > > > > > > > > > > + netdev_info(bypass_netdev,
>> >> > > > > > > > > > > > + "%s attempting to join bypass dev when %s already present\n",
>> >> > > > > > > > > > > > + child_netdev->name, backup ? "backup" : "active");
>> >> > > > > > > > > > > Bypass module should check if there is already some other netdev
>> >> > > > > > > > > > > enslaved and refuse right there.
>> >> > > > > > > > > > This will work for virtio-net with 3 netdev model, but this check has to be done by netvsc
>> >> > > > > > > > > > as its bypass_netdev is same as the backup_netdev.
>> >> > > > > > > > > > Will add a flag while registering with the bypass module to indicate if the driver is doing
>> >> > > > > > > > > > a 2 netdev or 3 netdev model and based on that flag this check can be done in bypass module
>> >> > > > > > > > > > for 3 netdev scenario.
>> >> > > > > > > > > Just let me undestand it clearly. What I expect the difference would be
>> >> > > > > > > > > between 2netdev and3 netdev model is this:
>> >> > > > > > > > > 2netdev:
>> >> > > > > > > > > bypass_master
>> >> > > > > > > > > /
>> >> > > > > > > > > /
>> >> > > > > > > > > VF_slave
>> >> > > > > > > > >
>> >> > > > > > > > > 3netdev:
>> >> > > > > > > > > bypass_master
>> >> > > > > > > > > / \
>> >> > > > > > > > > / \
>> >> > > > > > > > > VF_slave backup_slave
>> >> > > > > > > > >
>> >> > > > > > > > > Is that correct? If not, how does it look like?
>> >> > > > > > > > >
>> >> > > > > > > > >
>> >> > > > > > > > Looks correct.
>> >> > > > > > > > VF_slave and backup_slave are the original netdevs and are present in both the models.
>> >> > > > > > > > In the 3 netdev model, bypass_master netdev is created and VF_slave and backup_slave are
>> >> > > > > > > > marked as the 2 slaves of this new netdev.
>> >> > > > > > > You say it looks correct and in another sentence you provide completely
>> >> > > > > > > different description. Could you please look again?
>> >> > > > > > >
>> >> > > > > > To be exact, 2 netdev model with netvsc looks like this.
>> >> > > > > >
>> >> > > > > > netvsc_netdev
>> >> > > > > > /
>> >> > > > > > /
>> >> > > > > > VF_slave
>> >> > > > > >
>> >> > > > > > With virtio_net, 3 netdev model
>> >> > > > > >
>> >> > > > > > bypass_netdev
>> >> > > > > > / \
>> >> > > > > > / \
>> >> > > > > > VF_slave virtio_net netdev
>> >> > > > > Could you also mark the original netdev which is there now? is it
>> >> > > > > bypass_netdev or virtio_net_netdev ?
>> >> > > > bypass_netdev
>> >> > > > / \
>> >> > > > / \
>> >> > > > VF_slave virtio_net netdev (original)
>> >> > > That does not make sense.
>> >> > > 1) You diverge from the behaviour of the netvsc, where the original
>> >> > > netdev is a master of the VF
>> >> > > 2) If the original netdev is a slave, you cannot have any IP address
>> >> > > configured on it (well you could, but the rx_handler would eat every
>> >> > > incoming packet). So you will break the user bacause he would have to
>> >> > > move the configuration to the new master device.
>> >> > > This only makes sense that the original netdev becomes the master for both
>> >> > > netvsc and virtio_net.
>> >> > Forgot to mention that bypass_netdev takes over the name of the original
>> >> > netdev and
>> >> > virtio_net netdev will get the backup name.
>> >> What do you mean by "name"?
>> >
>> >bypass_netdev also is associated with the same pci device as the original virtio_net
>> >netdev via SET_NETDEV_DEV(). Also, we added ndo_get_phys_port_name() to virtio_net
>> >that will return _bkup when BACKUP feature is enabled.
>>
>> Okay.
>>
>> >
>> >So for ex: if virtio_net inteface was getting 'ens12' as the name assigned by udev
>> >without BACKUP feature, when BACKUP feature is enabled, the bypass_netdev will be
>> >named 'ens12' and the original virtio_net will get named as ens12n_bkup.
>>
>> Got it.
>>
>> I don't like the bypass_master to look differently in netvsc and
>> virtio_net :/ The best would be to convert netvsc to 3 netdev model and
>> treat them the same. The more I think about it, the more the 2 netdev
>> model feels wrong.
>
>If you believe that, then this patchset is a step in the right
>direction.
>
>With something like this patchset applied, converting netvsc to a 3
>device model will presumably be just a flag flip away. Afterwards
If done properly. Yes.
>we'll be able to drop dead code handling the bypass_master flag.
>
>>
>> >
>> >
>> >>
>> >> > So the userspace network configuration doesn't need to change.
>> >> >
>> >> >
>> >
^ permalink raw reply
* Re: [PATCH net] sctp: do not check port in sctp_inet6_cmp_addr
From: David Miller @ 2018-04-11 14:51 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <340aad3be762046ca9d02e54edba5bfefa2f4e71.1523451485.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Wed, 11 Apr 2018 20:58:05 +0800
> @@ -863,10 +863,31 @@ static int sctp_inet6_cmp_addr(const union sctp_addr *addr1,
> if (sctp_is_any(sk, addr1) || sctp_is_any(sk, addr2))
> return 1;
>
> - if (addr1->sa.sa_family != addr2->sa.sa_family)
> + if (addr1->sa.sa_family != addr2->sa.sa_family) {
> + if (addr1->sa.sa_family == AF_INET &&
> + addr2->sa.sa_family == AF_INET6 &&
> + ipv6_addr_v4mapped(&addr2->v6.sin6_addr))
> + if (addr2->v6.sin6_addr.s6_addr32[3] ==
> + addr1->v4.sin_addr.s_addr)
> + return 1;
> + if (addr2->sa.sa_family == AF_INET &&
> + addr1->sa.sa_family == AF_INET6 &&
> + ipv6_addr_v4mapped(&addr1->v6.sin6_addr))
> + if (addr1->v6.sin6_addr.s6_addr32[3] ==
> + addr2->v4.sin_addr.s_addr)
> + return 1;
> + return 0;
> + }
> +
> + if (!ipv6_addr_equal(&addr1->v6.sin6_addr, &addr2->v6.sin6_addr))
> + return 0;
> +
> + if ((ipv6_addr_type(&addr1->v6.sin6_addr) & IPV6_ADDR_LINKLOCAL) &&
> + addr1->v6.sin6_scope_id && addr2->v6.sin6_scope_id &&
> + addr1->v6.sin6_scope_id != addr2->v6.sin6_scope_id)
> return 0;
>
> - return af1->cmp_addr(addr1, addr2);
> + return 1;
> }
I agree with Neil that we should try to avoid the code duplication here
somehow.
Although we risk gcc emitting two copies of the function if we do
something like:
__sctp_v6_cmp_addr(addr1, addr2, check_ports)
{
}
sctp_v6_cmp_addr(addr, addr2)
{
return __sctp_v6_cmp_addr(addr1, addr2, true);
}
and invoke __sctp_v6_cmp_addr(addr1, addr2, true) from sctp_inet6_cmp_addr().
^ permalink raw reply
* Re: [PATCH net] sctp: do not check port in sctp_inet6_cmp_addr
From: Marcelo Ricardo Leitner @ 2018-04-11 14:51 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Neil Horman
In-Reply-To: <20180411144241.GA3711@localhost.localdomain>
On Wed, Apr 11, 2018 at 11:42:41AM -0300, Marcelo Ricardo Leitner wrote:
> On Wed, Apr 11, 2018 at 08:58:05PM +0800, Xin Long wrote:
> > pf->cmp_addr() is called before binding a v6 address to the sock. It
> > should not check ports, like in sctp_inet_cmp_addr.
> >
> > But sctp_inet6_cmp_addr checks the addr by invoking af(6)->cmp_addr,
> > sctp_v6_cmp_addr where it also compares the ports.
> >
> > This would cause that setsockopt(SCTP_SOCKOPT_BINDX_ADD) could bind
> > multiple duplicated IPv6 addresses after Commit 40b4f0fd74e4 ("sctp:
> > lack the check for ports in sctp_v6_cmp_addr").
> >
> > This patch is to remove af->cmp_addr called in sctp_inet6_cmp_addr,
> > but do the proper check for both v6 addrs and v4mapped addrs.
> >
> > Fixes: 40b4f0fd74e4 ("sctp: lack the check for ports in sctp_v6_cmp_addr")
> > Reported-by: Jianwen Ji <jiji@redhat.com>
> > Signed-off-by: Xin Long <lucien.xin@gmail.com>
>
> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Sorry, I take this back.
^ permalink raw reply
* Re: [RFC PATCH net-next v5 3/4] virtio_net: Extend virtio to use VF datapath when available
From: Michael S. Tsirkin @ 2018-04-11 14:45 UTC (permalink / raw)
To: Jiri Pirko
Cc: Samudrala, Sridhar, stephen, davem, netdev, virtualization,
virtio-dev, jesse.brandeburg, alexander.h.duyck, kubakici,
jasowang, loseweigh
In-Reply-To: <20180411080332.GL2028@nanopsycho>
On Wed, Apr 11, 2018 at 10:03:32AM +0200, Jiri Pirko wrote:
> Wed, Apr 11, 2018 at 08:24:43AM CEST, sridhar.samudrala@intel.com wrote:
> >On 4/10/2018 11:03 PM, Jiri Pirko wrote:
> >> Tue, Apr 10, 2018 at 05:59:02PM CEST, sridhar.samudrala@intel.com wrote:
> >> > On 4/10/2018 8:43 AM, Jiri Pirko wrote:
> >> > > Tue, Apr 10, 2018 at 05:27:48PM CEST, sridhar.samudrala@intel.com wrote:
> >> > > > On 4/10/2018 8:22 AM, Jiri Pirko wrote:
> >> > > > > Tue, Apr 10, 2018 at 05:13:40PM CEST, sridhar.samudrala@intel.com wrote:
> >> > > > > > On 4/10/2018 3:55 AM, Jiri Pirko wrote:
> >> > > > > > > Mon, Apr 09, 2018 at 08:47:06PM CEST, sridhar.samudrala@intel.com wrote:
> >> > > > > > > > On 4/9/2018 1:07 AM, Jiri Pirko wrote:
> >> > > > > > > > > Sat, Apr 07, 2018 at 12:59:14AM CEST, sridhar.samudrala@intel.com wrote:
> >> > > > > > > > > > On 4/6/2018 5:48 AM, Jiri Pirko wrote:
> >> > > > > > > > > > > Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudrala@intel.com wrote:
> >> > > > > > > > > [...]
> >> > > > > > > > >
> >> > > > > > > > > > > > +static int virtnet_bypass_join_child(struct net_device *bypass_netdev,
> >> > > > > > > > > > > > + struct net_device *child_netdev)
> >> > > > > > > > > > > > +{
> >> > > > > > > > > > > > + struct virtnet_bypass_info *vbi;
> >> > > > > > > > > > > > + bool backup;
> >> > > > > > > > > > > > +
> >> > > > > > > > > > > > + vbi = netdev_priv(bypass_netdev);
> >> > > > > > > > > > > > + backup = (child_netdev->dev.parent == bypass_netdev->dev.parent);
> >> > > > > > > > > > > > + if (backup ? rtnl_dereference(vbi->backup_netdev) :
> >> > > > > > > > > > > > + rtnl_dereference(vbi->active_netdev)) {
> >> > > > > > > > > > > > + netdev_info(bypass_netdev,
> >> > > > > > > > > > > > + "%s attempting to join bypass dev when %s already present\n",
> >> > > > > > > > > > > > + child_netdev->name, backup ? "backup" : "active");
> >> > > > > > > > > > > Bypass module should check if there is already some other netdev
> >> > > > > > > > > > > enslaved and refuse right there.
> >> > > > > > > > > > This will work for virtio-net with 3 netdev model, but this check has to be done by netvsc
> >> > > > > > > > > > as its bypass_netdev is same as the backup_netdev.
> >> > > > > > > > > > Will add a flag while registering with the bypass module to indicate if the driver is doing
> >> > > > > > > > > > a 2 netdev or 3 netdev model and based on that flag this check can be done in bypass module
> >> > > > > > > > > > for 3 netdev scenario.
> >> > > > > > > > > Just let me undestand it clearly. What I expect the difference would be
> >> > > > > > > > > between 2netdev and3 netdev model is this:
> >> > > > > > > > > 2netdev:
> >> > > > > > > > > bypass_master
> >> > > > > > > > > /
> >> > > > > > > > > /
> >> > > > > > > > > VF_slave
> >> > > > > > > > >
> >> > > > > > > > > 3netdev:
> >> > > > > > > > > bypass_master
> >> > > > > > > > > / \
> >> > > > > > > > > / \
> >> > > > > > > > > VF_slave backup_slave
> >> > > > > > > > >
> >> > > > > > > > > Is that correct? If not, how does it look like?
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > Looks correct.
> >> > > > > > > > VF_slave and backup_slave are the original netdevs and are present in both the models.
> >> > > > > > > > In the 3 netdev model, bypass_master netdev is created and VF_slave and backup_slave are
> >> > > > > > > > marked as the 2 slaves of this new netdev.
> >> > > > > > > You say it looks correct and in another sentence you provide completely
> >> > > > > > > different description. Could you please look again?
> >> > > > > > >
> >> > > > > > To be exact, 2 netdev model with netvsc looks like this.
> >> > > > > >
> >> > > > > > netvsc_netdev
> >> > > > > > /
> >> > > > > > /
> >> > > > > > VF_slave
> >> > > > > >
> >> > > > > > With virtio_net, 3 netdev model
> >> > > > > >
> >> > > > > > bypass_netdev
> >> > > > > > / \
> >> > > > > > / \
> >> > > > > > VF_slave virtio_net netdev
> >> > > > > Could you also mark the original netdev which is there now? is it
> >> > > > > bypass_netdev or virtio_net_netdev ?
> >> > > > bypass_netdev
> >> > > > / \
> >> > > > / \
> >> > > > VF_slave virtio_net netdev (original)
> >> > > That does not make sense.
> >> > > 1) You diverge from the behaviour of the netvsc, where the original
> >> > > netdev is a master of the VF
> >> > > 2) If the original netdev is a slave, you cannot have any IP address
> >> > > configured on it (well you could, but the rx_handler would eat every
> >> > > incoming packet). So you will break the user bacause he would have to
> >> > > move the configuration to the new master device.
> >> > > This only makes sense that the original netdev becomes the master for both
> >> > > netvsc and virtio_net.
> >> > Forgot to mention that bypass_netdev takes over the name of the original
> >> > netdev and
> >> > virtio_net netdev will get the backup name.
> >> What do you mean by "name"?
> >
> >bypass_netdev also is associated with the same pci device as the original virtio_net
> >netdev via SET_NETDEV_DEV(). Also, we added ndo_get_phys_port_name() to virtio_net
> >that will return _bkup when BACKUP feature is enabled.
>
> Okay.
>
> >
> >So for ex: if virtio_net inteface was getting 'ens12' as the name assigned by udev
> >without BACKUP feature, when BACKUP feature is enabled, the bypass_netdev will be
> >named 'ens12' and the original virtio_net will get named as ens12n_bkup.
>
> Got it.
>
> I don't like the bypass_master to look differently in netvsc and
> virtio_net :/ The best would be to convert netvsc to 3 netdev model and
> treat them the same. The more I think about it, the more the 2 netdev
> model feels wrong.
If you believe that, then this patchset is a step in the right
direction.
With something like this patchset applied, converting netvsc to a 3
device model will presumably be just a flag flip away. Afterwards
we'll be able to drop dead code handling the bypass_master flag.
>
> >
> >
> >>
> >> > So the userspace network configuration doesn't need to change.
> >> >
> >> >
> >
^ permalink raw reply
* Re: [PATCH net] sctp: do not check port in sctp_inet6_cmp_addr
From: Marcelo Ricardo Leitner @ 2018-04-11 14:42 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Neil Horman
In-Reply-To: <340aad3be762046ca9d02e54edba5bfefa2f4e71.1523451485.git.lucien.xin@gmail.com>
On Wed, Apr 11, 2018 at 08:58:05PM +0800, Xin Long wrote:
> pf->cmp_addr() is called before binding a v6 address to the sock. It
> should not check ports, like in sctp_inet_cmp_addr.
>
> But sctp_inet6_cmp_addr checks the addr by invoking af(6)->cmp_addr,
> sctp_v6_cmp_addr where it also compares the ports.
>
> This would cause that setsockopt(SCTP_SOCKOPT_BINDX_ADD) could bind
> multiple duplicated IPv6 addresses after Commit 40b4f0fd74e4 ("sctp:
> lack the check for ports in sctp_v6_cmp_addr").
>
> This patch is to remove af->cmp_addr called in sctp_inet6_cmp_addr,
> but do the proper check for both v6 addrs and v4mapped addrs.
>
> Fixes: 40b4f0fd74e4 ("sctp: lack the check for ports in sctp_v6_cmp_addr")
> Reported-by: Jianwen Ji <jiji@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
^ permalink raw reply
* Re: [PATCH net 0/2] Aquantia atlantic critical fixes 04/2018
From: David Miller @ 2018-04-11 14:41 UTC (permalink / raw)
To: igor.russkikh; +Cc: netdev, darcari, pavel.belous
In-Reply-To: <cover.1523449097.git.igor.russkikh@aquantia.com>
From: Igor Russkikh <igor.russkikh@aquantia.com>
Date: Wed, 11 Apr 2018 15:23:23 +0300
> Two regressions on latest 4.16 driver reported by users
>
> Some of old FW (1.5.44) had a link management logic which prevents
> driver to make clean reset. Driver of 4.16 has a full hardware reset
> implemented and that broke the link and traffic on such a cards.
>
> Second is oops on shutdown callback in case interface is already
> closed or was never opened.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH linux] net: fix deadlock while clearing neighbor proxy table
From: David Miller @ 2018-04-11 14:38 UTC (permalink / raw)
To: w.bumiller; +Cc: netdev, yoshfuji
In-Reply-To: <5acdfcbd910c6_a7b2ac7838cb0d497@olga.notmuch>
From: Wolfgang Bumiller <w.bumiller@proxmox.com>
Date: Wed, 11 Apr 2018 14:17:01 +0200
> David Miller wrote:
>> Another way is to rename pneigh_ifdown() to "pneigh_ifdown_and_unlock()".
>
> Sure, I can send a v2 with whichever is preferred - personally I prefer
> the rename as it'll be visible at both the calling & implementation
> side.
Yeah the rename is probably best.
^ permalink raw reply
* RE: [PATCH] lan78xx: Don't reset the interface on open
From: Nisar.Sayed @ 2018-04-11 14:37 UTC (permalink / raw)
To: phil, Woojung.Huh, UNGLinuxDriver, agraf, tbogendoerfer, netdev,
linux-usb, linux-kernel
In-Reply-To: <dc7f30e2-624c-17d8-911b-d20ce96c2652@raspberrypi.org>
Hi Phil,
> Hi Nisar,
>
> On 10/04/2018 15:16, Nisar.Sayed@microchip.com wrote:
> > Thanks Phil, for identifying the issues.
> >
> >> - ret = lan78xx_reset(dev);
> >> - if (ret < 0)
> >> - goto done;
> >> -
> >> phy_start(net->phydev);
> >>
> >> netif_dbg(dev, ifup, dev->net, "phy initialised successfully");
> >> --
> >
> > You may need to start the interrupts before "phy_start" instead of
> suppressing call to "lan78xx_reset".
> >
> > + if (dev->domain_data.phyirq > 0)
> > + phy_start_interrupts(dev->net->phydev);
>
> Shouldn't phy_connect_direct, called from lan78xx_phy_init, already have
> enabled interrupts for us?
>
> This patch addresses two problems - time wasted by renegotiating the link
> after the reset and the missed interrupt - and I'd like both to be fixed. Unless
> you can come up with a good reason for performing the reset from the open
> handler I think it should be removed.
>
> Phil
Thanks, we have verified suspected test cases and these are passed, the changes are good to go.
- Nisar
^ permalink raw reply
* Re: [PATCH] cdc_ether: flag the Cinterion AHS8 modem by gemalto as WWAN
From: David Miller @ 2018-04-11 14:37 UTC (permalink / raw)
To: oneukum; +Cc: bassem.boubaker, linux-kernel, linux-usb, netdev
In-Reply-To: <1523445938.22084.3.camel@suse.com>
From: Oliver Neukum <oneukum@suse.com>
Date: Wed, 11 Apr 2018 13:25:38 +0200
> Am Mittwoch, den 11.04.2018, 13:15 +0200 schrieb Bassem Boubaker:
>> The Cinterion AHS8 is a 3G device with one embedded WWAN interface
>> using cdc_ether as a driver.
>>
>> The modem is controlled via AT commands through the exposed TTYs.
>>
>> AT+CGDCONT write command can be used to activate or deactivate a WWAN
>> connection for a PDP context defined with the same command. UE supports
>> one WWAN adapter.
>>
>> Signed-off-by: Bassem Boubaker <bassem.boubaker@actia.fr>
> Acked-by: Oliver Neukum <oneukum@suse.com>
Applied and queued up for -stable.
^ 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