* Re: pull-request: ieee802154 2018-05-08
From: David Miller @ 2018-05-08 14:18 UTC (permalink / raw)
To: s.schmidt; +Cc: linux-wpan, alex.aring, netdev
In-Reply-To: <20180508082927.7928-1-s.schmidt@samsung.com>
From: Stefan Schmidt <s.schmidt@samsung.com>
Date: Tue, 8 May 2018 10:29:27 +0200
> An update from ieee802154 for your *net* tree.
>
> Two fixes for the mcr20a driver, which was being added in the 4.17 merge window,
> by Gustavo and myself.
> The atusb driver got a change to GFP_KERNEL where no GFP_ATOMIC is needed by
> Jia-Ju.
>
> The last and most important fix is from Alex to get IPv6 reassembly working
> again for the ieee802154 6lowpan adaptation. This got broken in 4.16 so please
> queue this one also up for the 4.16 stable tree.
Pulled, thanks.
Please submit the -stable fix directly, you can feel free to CC: me.
Thank yuo.
^ permalink raw reply
* Re: [PATCH net-next 0/4] bnxt_en: Fixes for net-next.
From: David Miller @ 2018-05-08 14:15 UTC (permalink / raw)
To: michael.chan; +Cc: netdev
In-Reply-To: <1525763921-20698-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Tue, 8 May 2018 03:18:37 -0400
> This series includes a bug fix for a regression in firmware message polling
> introduced recently on net-next. There are 3 additional minor fixes for
> unsupported link speed checking, VF MAC address handling, and setting
> PHY eeprom length.
Series applied, thanks Michael.
^ permalink raw reply
* [PATCH] net: phy: DP83811: Add support for the phy
From: Dan Murphy @ 2018-05-08 14:11 UTC (permalink / raw)
To: andrew, f.fainelli; +Cc: netdev, linux-kernel, Dan Murphy
Add support for the DP83811 phy by extending
the DP83822 driver to recognize the PHY IDs.
The DP83811 supports both rgmii and sgmii interfaces.
There are 2 part numbers for this the DP83811R does not
reliably support the SGMII interface but the DP83811S will.
There is not a way to differentiate these parts from the
hardware or register set. So this is controlled via the DT
to indicate which phy mode is required. Or the part can be
strapped to a certain interface.
Data sheet can be found here:
http://www.ti.com/product/DP83TC811S-Q1/description
http://www.ti.com/product/DP83TC811R-Q1/description
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
drivers/net/phy/dp83822.c | 42 ++++++++++++++++++++++++++++++++++++---
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/dp83822.c b/drivers/net/phy/dp83822.c
index 6e8a2a4f3a6e..5c379ff25dac 100644
--- a/drivers/net/phy/dp83822.c
+++ b/drivers/net/phy/dp83822.c
@@ -23,8 +23,10 @@
#include <linux/netdevice.h>
#define DP83822_PHY_ID 0x2000a240
+#define DP83811_PHY_ID 0x2000a253
#define DP83822_DEVADDR 0x1f
+#define MII_DP83811_SGMII_CTRL 0x09
#define MII_DP83822_PHYSCR 0x11
#define MII_DP83822_MISR1 0x12
#define MII_DP83822_MISR2 0x13
@@ -79,6 +81,13 @@
#define DP83822_WOL_INDICATION_SEL BIT(8)
#define DP83822_WOL_CLR_INDICATION BIT(11)
+/* DP83811 SGMII CTRL bits */
+#define DP83811_TDR_AUTO BIT(8)
+#define DP83811_SGMII_EN BIT(12)
+#define DP83811_SGMII_AUTO_NEG_EN BIT(13)
+#define DP83811_SGMII_TX_ERR_DIS BIT(14)
+#define DP83811_SGMII_SOFT_RESET BIT(15)
+
static int dp83822_ack_interrupt(struct phy_device *phydev)
{
int err;
@@ -267,6 +276,17 @@ static int dp83822_config_init(struct phy_device *phydev)
if (err < 0)
return err;
+ if ((phydev->interface == PHY_INTERFACE_MODE_SGMII &&
+ phydev->phy_id == DP83811_PHY_ID)) {
+ value = phy_read(phydev, MII_DP83811_SGMII_CTRL);
+ if (!(value & DP83811_SGMII_EN)) {
+ err = phy_write(phydev, MII_DP83811_SGMII_CTRL,
+ (DP83811_SGMII_EN | value));
+ if (err < 0)
+ return err;
+ }
+ }
+
value = DP83822_WOL_MAGIC_EN | DP83822_WOL_SECURE_ON | DP83822_WOL_EN;
return phy_write_mmd(phydev, DP83822_DEVADDR, MII_DP83822_WOL_CFG,
@@ -328,15 +348,31 @@ static struct phy_driver dp83822_driver[] = {
.suspend = dp83822_suspend,
.resume = dp83822_resume,
},
+ {
+ .phy_id = DP83811_PHY_ID,
+ .phy_id_mask = 0xfffffff0,
+ .name = "TI DP83811",
+ .features = PHY_BASIC_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_init = genphy_config_init,
+ .soft_reset = dp83822_phy_reset,
+ .get_wol = dp83822_get_wol,
+ .set_wol = dp83822_set_wol,
+ .ack_interrupt = dp83822_ack_interrupt,
+ .config_intr = dp83822_config_intr,
+ .suspend = dp83822_suspend,
+ .resume = dp83822_resume,
+ },
};
module_phy_driver(dp83822_driver);
static struct mdio_device_id __maybe_unused dp83822_tbl[] = {
- { DP83822_PHY_ID, 0xfffffff0 },
- { },
+ {DP83822_PHY_ID, 0xfffffff0},
+ {DP83811_PHY_ID, 0xfffffff0},
+ {}
};
MODULE_DEVICE_TABLE(mdio, dp83822_tbl);
-MODULE_DESCRIPTION("Texas Instruments DP83822 PHY driver");
+MODULE_DESCRIPTION("Texas Instruments DP83811/22 PHY driver");
MODULE_AUTHOR("Dan Murphy <dmurphy@ti.com");
MODULE_LICENSE("GPL");
--
2.17.0.252.gfe0a9eaf3
^ permalink raw reply related
* KASAN: use-after-free Read in sctp_do_sm
From: syzbot @ 2018-05-08 13:58 UTC (permalink / raw)
To: davem, linux-kernel, linux-sctp, marcelo.leitner, netdev, nhorman,
syzkaller-bugs, vyasevich
Hello,
syzbot found the following crash on:
HEAD commit: f142f08bf7ec Fix typo in comment.
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1159ade7800000
kernel config: https://syzkaller.appspot.com/x/.config?x=31f4b3733894ef79
dashboard link: https://syzkaller.appspot.com/bug?extid=141d898c5f24489db4aa
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+141d898c5f24489db4aa@syzkaller.appspotmail.com
RDX: 0000000000000008 RSI: 0000000020000000 RDI: 0000000000000014
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000015
R13: 000000000000071e R14: 00000000006feb70 R15: 0000000000000007
==================================================================
BUG: KASAN: use-after-free in sctp_cmd_interpreter
net/sctp/sm_sideeffect.c:1817 [inline]
BUG: KASAN: use-after-free in sctp_side_effects
net/sctp/sm_sideeffect.c:1220 [inline]
BUG: KASAN: use-after-free in sctp_do_sm+0x6015/0x7160
net/sctp/sm_sideeffect.c:1191
Read of size 1 at addr ffff8801c7883cb8 by task syz-executor6/18616
CPU: 1 PID: 18616 Comm: syz-executor6 Not tainted 4.17.0-rc4+ #38
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+0x242/0x2fe mm/kasan/report.c:412
__asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1817 [inline]
sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
sctp_do_sm+0x6015/0x7160 net/sctp/sm_sideeffect.c:1191
sctp_assoc_bh_rcv+0x30f/0x520 net/sctp/associola.c:1065
sctp_inq_push+0x263/0x320 net/sctp/inqueue.c:95
sctp_backlog_rcv+0x192/0xc00 net/sctp/input.c:350
sk_backlog_rcv include/net/sock.h:909 [inline]
__release_sock+0x12f/0x3a0 net/core/sock.c:2335
release_sock+0xa4/0x2b0 net/core/sock.c:2850
sctp_sendmsg+0x13cc/0x1d70 net/sctp/socket.c:2128
inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:639
sock_write_iter+0x35a/0x5a0 net/socket.c:908
call_write_iter include/linux/fs.h:1784 [inline]
new_sync_write fs/read_write.c:474 [inline]
__vfs_write+0x64d/0x960 fs/read_write.c:487
vfs_write+0x1f8/0x560 fs/read_write.c:549
ksys_write+0xf9/0x250 fs/read_write.c:598
__do_sys_write fs/read_write.c:610 [inline]
__se_sys_write fs/read_write.c:607 [inline]
__x64_sys_write+0x73/0xb0 fs/read_write.c:607
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x455979
RSP: 002b:00007f6fad842c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f6fad8436d4 RCX: 0000000000455979
RDX: 0000000000000008 RSI: 0000000020000000 RDI: 0000000000000014
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000015
R13: 000000000000071e R14: 00000000006feb70 R15: 0000000000000007
Allocated by task 18616:
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
kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554
kmem_cache_zalloc include/linux/slab.h:691 [inline]
sctp_chunkify+0xce/0x400 net/sctp/sm_make_chunk.c:1355
sctp_rcv+0xc65/0x3a60 net/sctp/input.c:221
sctp6_rcv+0x15/0x30 net/sctp/ipv6.c:1045
ip6_input_finish+0x3ff/0x1a30 net/ipv6/ip6_input.c:284
NF_HOOK include/linux/netfilter.h:288 [inline]
ip6_input+0xe1/0x5e0 net/ipv6/ip6_input.c:327
dst_input include/net/dst.h:450 [inline]
ip6_rcv_finish+0x29c/0xa10 net/ipv6/ip6_input.c:71
NF_HOOK include/linux/netfilter.h:288 [inline]
ipv6_rcv+0xed6/0x22a0 net/ipv6/ip6_input.c:208
__netif_receive_skb_core+0x26f5/0x3630 net/core/dev.c:4592
__netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4657
process_backlog+0x219/0x760 net/core/dev.c:5337
napi_poll net/core/dev.c:5735 [inline]
net_rx_action+0x7b7/0x1930 net/core/dev.c:5801
__do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
Freed by task 18616:
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]
kmem_cache_free+0x86/0x2d0 mm/slab.c:3756
sctp_chunk_destroy net/sctp/sm_make_chunk.c:1481 [inline]
sctp_chunk_put+0x321/0x440 net/sctp/sm_make_chunk.c:1504
sctp_ulpevent_make_rcvmsg+0x955/0xd40 net/sctp/ulpevent.c:718
sctp_ulpq_tail_data+0xa8/0x12b0 net/sctp/ulpqueue.c:108
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1478 [inline]
sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
sctp_do_sm+0x1658/0x7160 net/sctp/sm_sideeffect.c:1191
sctp_assoc_bh_rcv+0x30f/0x520 net/sctp/associola.c:1065
sctp_inq_push+0x263/0x320 net/sctp/inqueue.c:95
sctp_backlog_rcv+0x192/0xc00 net/sctp/input.c:350
sk_backlog_rcv include/net/sock.h:909 [inline]
__release_sock+0x12f/0x3a0 net/core/sock.c:2335
release_sock+0xa4/0x2b0 net/core/sock.c:2850
sctp_sendmsg+0x13cc/0x1d70 net/sctp/socket.c:2128
inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:639
sock_write_iter+0x35a/0x5a0 net/socket.c:908
call_write_iter include/linux/fs.h:1784 [inline]
new_sync_write fs/read_write.c:474 [inline]
__vfs_write+0x64d/0x960 fs/read_write.c:487
vfs_write+0x1f8/0x560 fs/read_write.c:549
ksys_write+0xf9/0x250 fs/read_write.c:598
__do_sys_write fs/read_write.c:610 [inline]
__se_sys_write fs/read_write.c:607 [inline]
__x64_sys_write+0x73/0xb0 fs/read_write.c:607
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8801c7883bc0
which belongs to the cache sctp_chunk of size 256
The buggy address is located 248 bytes inside of
256-byte region [ffff8801c7883bc0, ffff8801c7883cc0)
The buggy address belongs to the page:
page:ffffea00071e20c0 count:1 mapcount:0 mapping:ffff8801c7883080 index:0x0
flags: 0x2fffc0000000100(slab)
raw: 02fffc0000000100 ffff8801c7883080 0000000000000000 000000010000000c
raw: ffffea000723a220 ffff8801cdb66f48 ffff8801cdb65600 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801c7883b80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
ffff8801c7883c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801c7883c80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
^
ffff8801c7883d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801c7883d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
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] selinux: add AF_UNSPEC and INADDR_ANY checks to selinux_socket_bind()
From: Alexey Kodanev @ 2018-05-08 14:05 UTC (permalink / raw)
To: selinux
Cc: Richard Haines, Paul Moore, Stephen Smalley, Eric Paris,
linux-security-module, netdev, Alexey Kodanev
Commit d452930fd3b9 ("selinux: Add SCTP support") breaks compatibility
with the old programs that can pass sockaddr_in with AF_UNSPEC and
INADDR_ANY to bind(). As a result, bind() returns EAFNOSUPPORT error.
It was found with LTP/asapi_01 test.
Similar to commit 29c486df6a20 ("net: ipv4: relax AF_INET check in
bind()"), which relaxed AF_INET check for compatibility, add AF_UNSPEC
case to AF_INET and make sure that the address is INADDR_ANY.
Also, in the end of selinux_socket_bind(), instead of adding AF_UNSPEC
to 'address->sa_family == AF_INET', verify AF_INET6 first.
Fixes: d452930fd3b9 ("selinux: Add SCTP support")
Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
---
security/selinux/hooks.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 4cafe6a..649a3be 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -4602,10 +4602,16 @@ static int selinux_socket_bind(struct socket *sock, struct sockaddr *address, in
* sk->sk_family = PF_INET6 with addr->sa_family = AF_INET.
*/
switch (address->sa_family) {
+ case AF_UNSPEC:
case AF_INET:
if (addrlen < sizeof(struct sockaddr_in))
return -EINVAL;
addr4 = (struct sockaddr_in *)address;
+
+ if (address->sa_family == AF_UNSPEC &&
+ addr4->sin_addr.s_addr != htonl(INADDR_ANY))
+ return -EAFNOSUPPORT;
+
snum = ntohs(addr4->sin_port);
addrp = (char *)&addr4->sin_addr.s_addr;
break;
@@ -4681,10 +4687,10 @@ static int selinux_socket_bind(struct socket *sock, struct sockaddr *address, in
ad.u.net->sport = htons(snum);
ad.u.net->family = family;
- if (address->sa_family == AF_INET)
- ad.u.net->v4info.saddr = addr4->sin_addr.s_addr;
- else
+ if (address->sa_family == AF_INET6)
ad.u.net->v6info.saddr = addr6->sin6_addr;
+ else
+ ad.u.net->v4info.saddr = addr4->sin_addr.s_addr;
err = avc_has_perm(&selinux_state,
sksec->sid, sid,
--
1.8.3.1
^ permalink raw reply related
* [PATCH net] tipc: eliminate KMSAN uninit-value in strcmp complaint
From: Ying Xue @ 2018-05-08 13:44 UTC (permalink / raw)
To: davem, jon.maloy; +Cc: netdev, syzkaller-bugs, tipc-discussion
When we get link properties through netlink interface with
tipc_nl_node_get_link(), we don't validate TIPC_NLA_LINK_NAME
attribute at all, instead we directly use it. As a consequence,
KMSAN detected the TIPC_NLA_LINK_NAME attribute was an uninitialized
value, and then posted the following complaint:
==================================================================
BUG: KMSAN: uninit-value in strcmp+0xf7/0x160 lib/string.c:329
CPU: 1 PID: 4527 Comm: syz-executor655 Not tainted 4.16.0+ #87
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+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
strcmp+0xf7/0x160 lib/string.c:329
tipc_nl_node_get_link+0x220/0x6f0 net/tipc/node.c:1881
genl_family_rcv_msg net/netlink/genetlink.c:599 [inline]
genl_rcv_msg+0x1686/0x1810 net/netlink/genetlink.c:624
netlink_rcv_skb+0x378/0x600 net/netlink/af_netlink.c:2447
genl_rcv+0x63/0x80 net/netlink/genetlink.c:635
netlink_unicast_kernel net/netlink/af_netlink.c:1311 [inline]
netlink_unicast+0x166b/0x1740 net/netlink/af_netlink.c:1337
netlink_sendmsg+0x1048/0x1310 net/netlink/af_netlink.c:1900
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg net/socket.c:640 [inline]
___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
__sys_sendmsg net/socket.c:2080 [inline]
SYSC_sendmsg+0x2a3/0x3d0 net/socket.c:2091
SyS_sendmsg+0x54/0x80 net/socket.c:2087
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x445589
RSP: 002b:00007fb7ee66cdb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00000000006dac24 RCX: 0000000000445589
RDX: 0000000000000000 RSI: 0000000020023000 RDI: 0000000000000003
RBP: 00000000006dac20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fffa2bf3f3f R14: 00007fb7ee66d9c0 R15: 0000000000000001
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
slab_post_alloc_hook mm/slab.h:445 [inline]
slab_alloc_node mm/slub.c:2737 [inline]
__kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
__kmalloc_reserve net/core/skbuff.c:138 [inline]
__alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
alloc_skb include/linux/skbuff.h:984 [inline]
netlink_alloc_large_skb net/netlink/af_netlink.c:1183 [inline]
netlink_sendmsg+0x9a6/0x1310 net/netlink/af_netlink.c:1875
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg net/socket.c:640 [inline]
___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
__sys_sendmsg net/socket.c:2080 [inline]
SYSC_sendmsg+0x2a3/0x3d0 net/socket.c:2091
SyS_sendmsg+0x54/0x80 net/socket.c:2087
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
==================================================================
To quiet the complaint, TIPC_NLA_LINK_NAME attribute has been
validated in tipc_nl_node_get_link() before it's used.
Reported-by: syzbot+df0257c92ffd4fcc58cd@syzkaller.appspotmail.com
Signed-off-by: Ying Xue <ying.xue@windriver.com>
---
net/tipc/node.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/net/tipc/node.c b/net/tipc/node.c
index baaf93f..f29549d 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -1950,6 +1950,7 @@ int tipc_nl_node_set_link(struct sk_buff *skb, struct genl_info *info)
int tipc_nl_node_get_link(struct sk_buff *skb, struct genl_info *info)
{
struct net *net = genl_info_net(info);
+ struct nlattr *attrs[TIPC_NLA_LINK_MAX + 1];
struct tipc_nl_msg msg;
char *name;
int err;
@@ -1957,9 +1958,19 @@ int tipc_nl_node_get_link(struct sk_buff *skb, struct genl_info *info)
msg.portid = info->snd_portid;
msg.seq = info->snd_seq;
- if (!info->attrs[TIPC_NLA_LINK_NAME])
+ if (!info->attrs[TIPC_NLA_LINK])
return -EINVAL;
- name = nla_data(info->attrs[TIPC_NLA_LINK_NAME]);
+
+ err = nla_parse_nested(attrs, TIPC_NLA_LINK_MAX,
+ info->attrs[TIPC_NLA_LINK],
+ tipc_nl_link_policy, info->extack);
+ if (err)
+ return err;
+
+ if (!attrs[TIPC_NLA_LINK_NAME])
+ return -EINVAL;
+
+ name = nla_data(attrs[TIPC_NLA_LINK_NAME]);
msg.skb = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
if (!msg.skb)
--
2.7.4
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply related
* [PATCH v4 2/2] selftests/bpf: ignore build products
From: Sirio Balmelli @ 2018-05-08 13:36 UTC (permalink / raw)
To: daniel; +Cc: netdev
Update .gitignore files
Signed-off-by: Sirio Balmelli <sirio@b-ad.ch>
---
tools/bpf/bpftool/.gitignore | 3 +++
tools/testing/selftests/bpf/.gitignore | 1 +
2 files changed, 4 insertions(+)
create mode 100644 tools/bpf/bpftool/.gitignore
diff --git a/tools/bpf/bpftool/.gitignore b/tools/bpf/bpftool/.gitignore
new file mode 100644
index 0000000..0d4e3a5
--- /dev/null
+++ b/tools/bpf/bpftool/.gitignore
@@ -0,0 +1,3 @@
+*d
+bpftool
+FEATURE-DUMP.bpftool
diff --git a/tools/testing/selftests/bpf/.gitignore b/tools/testing/selftests/bpf/.gitignore
index 3e3b3ce..adc8e54 100644
--- a/tools/testing/selftests/bpf/.gitignore
+++ b/tools/testing/selftests/bpf/.gitignore
@@ -16,3 +16,4 @@ test_sock
test_sock_addr
urandom_read
test_btf
+test_sockmap
--
2.7.4
^ permalink raw reply related
* [PATCH v4 1/2] selftests/bpf: add architecture-agnostic headers
From: Sirio Balmelli @ 2018-05-08 13:36 UTC (permalink / raw)
To: daniel; +Cc: netdev
bpf selftests fail to build with missing headers
'asm/bitsperlong.h' and 'asm/errno.h'
These already exist in 'tools/arch/[arch]/include';
add architecture-agnostic header files in 'tools/include/uapi'
to reference them.
Signed-off-by: Sirio Balmelli <sirio@b-ad.ch>
---
tools/include/uapi/asm/bitsperlong.h | 18 ++++++++++++++++++
tools/include/uapi/asm/errno.h | 17 +++++++++++++++++
2 files changed, 35 insertions(+)
create mode 100644 tools/include/uapi/asm/bitsperlong.h
create mode 100644 tools/include/uapi/asm/errno.h
diff --git a/tools/include/uapi/asm/bitsperlong.h b/tools/include/uapi/asm/bitsperlong.h
new file mode 100644
index 0000000..8dd6aef
--- /dev/null
+++ b/tools/include/uapi/asm/bitsperlong.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#if defined(__i386__) || defined(__x86_64__)
+#include "../../arch/x86/include/uapi/asm/bitsperlong.h"
+#elif defined(__aarch64__)
+#include "../../arch/arm64/include/uapi/asm/bitsperlong.h"
+#elif defined(__powerpc__)
+#include "../../arch/powerpc/include/uapi/asm/bitsperlong.h"
+#elif defined(__s390__)
+#include "../../arch/s390/include/uapi/asm/bitsperlong.h"
+#elif defined(__sparc__)
+#include "../../arch/sparc/include/uapi/asm/bitsperlong.h"
+#elif defined(__mips__)
+#include "../../arch/mips/include/uapi/asm/bitsperlong.h"
+#elif defined(__ia64__)
+#include "../../arch/ia64/include/uapi/asm/bitsperlong.h"
+#else
+#include <asm-generic/bitsperlong.h>
+#endif
diff --git a/tools/include/uapi/asm/errno.h b/tools/include/uapi/asm/errno.h
new file mode 100644
index 0000000..8fe11c0
--- /dev/null
+++ b/tools/include/uapi/asm/errno.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#if defined(__i386__) || defined(__x86_64__)
+#include "../../arch/x86/include/uapi/asm/errno.h"
+#elif defined(__powerpc__)
+#include "../../arch/powerpc/include/uapi/asm/errno.h"
+#elif defined(__sparc__)
+#include "../../arch/sparc/include/uapi/asm/errno.h"
+#elif defined(__alpha__)
+#include "../../arch/alpha/include/uapi/asm/errno.h"
+#elif defined(__mips__)
+#include "../../arch/mips/include/uapi/asm/errno.h"
+#elif defined(__ia64__)
+#include "../../arch/ia64/include/uapi/asm/errno.h"
+#elif defined(__xtensa__)
+#include "../../arch/xtensa/include/uapi/asm/errno.h"
+#else
+#include <asm-generic/errno.h>
+#endif
--
2.7.4
^ permalink raw reply related
* [PATCH v4 0/2] selftests/bpf
From: Sirio Balmelli @ 2018-05-08 13:35 UTC (permalink / raw)
To: daniel; +Cc: netdev
Review of v3 patch much appreciated.
Respun the series to omit the Makefile include, will work on
a separate patch for that;
replied to the v3 thread with queries specific to the include issue.
best,
Sirio
Sirio Balmelli (2):
selftests/bpf: add architecture-agnostic headers
selftests/bpf: ignore build products
tools/bpf/bpftool/.gitignore | 3 +++
tools/include/uapi/asm/bitsperlong.h | 18 ++++++++++++++++++
tools/include/uapi/asm/errno.h | 17 +++++++++++++++++
tools/testing/selftests/bpf/.gitignore | 1 +
4 files changed, 39 insertions(+)
create mode 100644 tools/bpf/bpftool/.gitignore
create mode 100644 tools/include/uapi/asm/bitsperlong.h
create mode 100644 tools/include/uapi/asm/errno.h
--
2.7.4
^ permalink raw reply
* Re: [PATCH net-next] net:sched: add gkprio scheduler
From: Michel Machado @ 2018-05-08 12:59 UTC (permalink / raw)
To: Nishanth Devarajan, Cong Wang; +Cc: jiri, jhs, davem, netdev, doucette
In-Reply-To: <20180508101210.GB4383@gmail.com>
>> Overall it looks good to me, just one thing below:
>>
>>> +struct Qdisc_ops gkprio_qdisc_ops __read_mostly = {
>>> + .id = "gkprio",
>>> + .priv_size = sizeof(struct gkprio_sched_data),
>>> + .enqueue = gkprio_enqueue,
>>> + .dequeue = gkprio_dequeue,
>>> + .peek = qdisc_peek_dequeued,
>>> + .init = gkprio_init,
>>> + .reset = gkprio_reset,
>>> + .change = gkprio_change,
>>> + .dump = gkprio_dump,
>>> + .destroy = gkprio_destroy,
>>> + .owner = THIS_MODULE,
>>> +};
>>
>> You probably want to add Qdisc_class_ops here so that you can
>> dump the stats of each internal queue.
Hi Cong,
In the production scenario we are targeting, this priority queue
must be classless; being classful would only bloat the code for us. I
don't see making this queue classful as a problem per se, but I suggest
leaving it as a future improvement for when someone can come up with a
useful scenario for it.
[ ]'s
Michel Machado
^ permalink raw reply
* Re: [PATCH net-next] net:sched: add gkprio scheduler
From: Jamal Hadi Salim @ 2018-05-08 13:29 UTC (permalink / raw)
To: Michel Machado, Nishanth Devarajan, Cong Wang
Cc: jiri, davem, netdev, doucette
In-Reply-To: <273f91db-7a2f-acda-b306-5a78dd948478@digirati.com.br>
On 08/05/18 08:59 AM, Michel Machado wrote:
>>> Overall it looks good to me, just one thing below:
>>>
>>>> +struct Qdisc_ops gkprio_qdisc_ops __read_mostly = {
>>>> + .id = "gkprio",
>>>> + .priv_size = sizeof(struct gkprio_sched_data),
>>>> + .enqueue = gkprio_enqueue,
>>>> + .dequeue = gkprio_dequeue,
>>>> + .peek = qdisc_peek_dequeued,
>>>> + .init = gkprio_init,
>>>> + .reset = gkprio_reset,
>>>> + .change = gkprio_change,
>>>> + .dump = gkprio_dump,
>>>> + .destroy = gkprio_destroy,
>>>> + .owner = THIS_MODULE,
>>>> +};
>>>
>>> You probably want to add Qdisc_class_ops here so that you can
>>> dump the stats of each internal queue.
>
> Hi Cong,
>
> In the production scenario we are targeting, this priority queue
> must be classless; being classful would only bloat the code for us. I
> don't see making this queue classful as a problem per se, but I suggest
> leaving it as a future improvement for when someone can come up with a
> useful scenario for it.
I am actually struggling with this whole thing.
Have you considered using skb->prio instead of peeking into the packet
header.
Also have you looked at the dsmark qdisc?
cheers,
jamal
^ permalink raw reply
* Re: KMSAN: uninit-value in strcmp
From: Ying Xue @ 2018-05-08 13:12 UTC (permalink / raw)
To: David Miller, syzbot+df0257c92ffd4fcc58cd
Cc: netdev, syzkaller-bugs, linux-kernel, tipc-discussion
In-Reply-To: <20180503.152213.740988890883315228.davem@davemloft.net>
On 05/04/2018 03:22 AM, David Miller wrote:
> From: syzbot <syzbot+df0257c92ffd4fcc58cd@syzkaller.appspotmail.com>
> Date: Thu, 03 May 2018 11:44:02 -0700
>
>> Call Trace:
>> __dump_stack lib/dump_stack.c:17 [inline]
>> dump_stack+0x185/0x1d0 lib/dump_stack.c:53
>> kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
>> __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
>> strcmp+0xf7/0x160 lib/string.c:329
>> tipc_nl_node_get_link+0x220/0x6f0 net/tipc/node.c:1881
>> genl_family_rcv_msg net/netlink/genetlink.c:599 [inline]
>
> Hmmm, TIPC_NL_LINK_GET uses tipc_nl_policy, which has a proper nesting
> entry for TIPC_NLA_LINK. I wonder how the code goes about validating
> TIPC_NLA_LINK_NAME in such a case? Does it?
>
> This may be the problem.
David, you are right. This is absolutely a real bug. As you said, we
didn't validate TIPC_NLA_LINK_NAME attribute in tipc_nl_node_get_link()
at all.
I will submit a patch to fix the issue soon.
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply
* Re: [PATCH] mac80211: ethtool: avoid 32 bit multiplication overflow
From: Johannes Berg @ 2018-05-08 13:01 UTC (permalink / raw)
To: Colin King, David S . Miller, linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20180508125732.5153-1-colin.king@canonical.com>
On Tue, 2018-05-08 at 13:57 +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The multiplication of 100000 * cfg80211_calculate_bitrate() is a 32 bit
> operation and can overflow if cfg80211_calculate_bitrate is greater
> than 42949. Although I don't believe this is occurring at present, it
> would be safer to avoid the potential overflow by making the constant
> 100000 an ULL to ensure a 64 multiplication occurs.
Yeah it can't happen since mac80211 doesn't support 60 GHz devices, and
all others are limited to less than than.
Still, applied.
johannes
^ permalink raw reply
* [PATCH] mac80211: ethtool: avoid 32 bit multiplication overflow
From: Colin King @ 2018-05-08 12:57 UTC (permalink / raw)
To: Johannes Berg, David S . Miller, linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The multiplication of 100000 * cfg80211_calculate_bitrate() is a 32 bit
operation and can overflow if cfg80211_calculate_bitrate is greater
than 42949. Although I don't believe this is occurring at present, it
would be safer to avoid the potential overflow by making the constant
100000 an ULL to ensure a 64 multiplication occurs.
Detected by CoverityScan, CID#1468643 ("Unintentional integer overflow")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
net/mac80211/ethtool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/ethtool.c b/net/mac80211/ethtool.c
index 08408520c3f8..2ba5686cbcab 100644
--- a/net/mac80211/ethtool.c
+++ b/net/mac80211/ethtool.c
@@ -117,11 +117,11 @@ static void ieee80211_get_stats(struct net_device *dev,
if (sinfo.filled & BIT(NL80211_STA_INFO_TX_BITRATE))
- data[i] = 100000 *
+ data[i] = 100000ULL *
cfg80211_calculate_bitrate(&sinfo.txrate);
i++;
if (sinfo.filled & BIT(NL80211_STA_INFO_RX_BITRATE))
- data[i] = 100000 *
+ data[i] = 100000ULL *
cfg80211_calculate_bitrate(&sinfo.rxrate);
i++;
--
2.17.0
^ permalink raw reply related
* Re: [PATCH net-next] drivers: net: davinci_mdio: prevent sprious timeout
From: Andrew Lunn @ 2018-05-08 12:48 UTC (permalink / raw)
To: Sekhar Nori; +Cc: Grygorii Strashko, David S . Miller, linux-omap, netdev
In-Reply-To: <20180508082638.5707-1-nsekhar@ti.com>
On Tue, May 08, 2018 at 01:56:38PM +0530, Sekhar Nori wrote:
> A well timed kernel preemption in the time_after() loop
> in wait_for_idle() can result in a spurious timeout
> error to be returned.
>
> Fix it by checking for status of hardware before returning
> timeout error.
>
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
I've seen this with other drivers as well.
I suggest you make use of readx_poll_timeout(), or one of its
cousins. They get this right.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 03/13] net: phy: sfp: warn the user when no tx_disable pin is available
From: Russell King - ARM Linux @ 2018-05-08 12:45 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, mw, ymarkman, jason, Antoine Tenart, netdev,
gregory.clement, kishon, nadavh, linux-arm-kernel,
thomas.petazzoni, miquel.raynal, stefanc, maxime.chevallier,
davem, linux-kernel, sebastian.hesselbarth
In-Reply-To: <20180505205242.GA2876@lunn.ch>
On Sat, May 05, 2018 at 10:52:42PM +0200, Andrew Lunn wrote:
> On Sat, May 05, 2018 at 01:38:31PM -0700, Florian Fainelli wrote:
> > On May 4, 2018 10:14:25 AM PDT, Andrew Lunn <andrew@lunn.ch> wrote:
> > >On Fri, May 04, 2018 at 10:07:53AM -0700, Florian Fainelli wrote:
> > >> On 05/04/2018 06:56 AM, Antoine Tenart wrote:
> > >> > In case no Tx disable pin is available the SFP modules will always
> > >be
> > >> > emitting. This could be an issue when using modules using laser as
> > >their
> > >> > light source as we would have no way to disable it when the fiber
> > >is
> > >> > removed. This patch adds a warning when registering an SFP cage
> > >which do
> > >> > not have its tx_disable pin wired or available.
> > >>
> > >> Is this something that was done in a possibly earlier revision of a
> > >> given board design and which was finally fixed? Nothing wrong with
> > >the
> > >> patch, but this seems like a pretty serious board design mistake,
> > >that
> > >> needs to be addressed.
> > >
> > >Hi Florian
> > >
> > >Zii Devel B is like this. Only the "Signal Detect" pin is wired to a
> > >GPIO.
> >
>
> > Good point, indeed. BTW what do you think about exposing the SFF's
> > EEPROM and diagnostics through the standard ethtool operations even
> > if we have to keep the description of the SFF as a fixed link in
> > Device Tree because of the unfortunate wiring?
>
> I believe in Antoine case, all the control plane is broken. He cannot
> read the EEPROM, nor any of the modules pins via GPIOs.
Correct.
> For Zii Devel B, the EEPROM is accessible, and so is the SD pin. What
> is missing is transmit disable. So i would expose it as an SFF module.
Agreed.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH net-next] net: phy: sfp: handle cases where neither BR,min nor BR,max is given
From: Russell King - ARM Linux @ 2018-05-08 12:44 UTC (permalink / raw)
To: Florian Fainelli
Cc: Antoine Tenart, davem, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, gregory.clement, miquel.raynal, nadavh,
stefanc, ymarkman, mw
In-Reply-To: <53A4DFE3-C335-49B2-89C5-061A96C6D99D@gmail.com>
On Sat, May 05, 2018 at 01:35:34PM -0700, Florian Fainelli wrote:
> On May 4, 2018 8:21:03 AM PDT, Antoine Tenart <antoine.tenart@bootlin.com> wrote:
> >When computing the bitrate using values read from an SFP module EEPROM,
> >we use the nominal BR plus BR,min and BR,max to determine the
> >boundaries. But in some cases BR,min and BR,max aren't provided, which
> >led the SFP code to end up having the nominal value for both the
> >minimum
> >and maximum bitrate values. When using a passive cable, the nominal
> >value should be used as the maximum one, and there is no minimum one
> >so we should use 0.
> >
> >Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
> >---
> >
> >Hi Russell,
> >
> >I'm not completely sure about this patch as this case is not really
> >specified in the specification. But the issue is there, and I've
> >discuss
> >this with others. It seemed logical (at least to us :)) to use the
> >BR,nominal values as br_max and 0 as br_min when using a passive cable
> >which only provides BR,nominal as this would be the highest rate at
> >which the cable could work. And because it's passive, there should be
> >no
> >issues using it at a lower rate.
> >
> >I've tested this with one passive cable which only reports its
> >BR,nominal (which was 10300) while it could be used when using
> >1000baseX
> >or 2500baseX modes.
>
> Which SFP modules (vendor and model) exposed this out of curiosity?
> Russell and I already saw the Cotsworks modules having so e issues
> with checksums, so building a table of quirks would help. Thanks!
I think this is just manufacturers being lazy with their EEPROM
contents - looking around, most passive cables are specified to be
"up to" some figure, and that's definitely what's specified by the
SFP+ specification by way of the high-pass pole requirement of the
coupling capacitors.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH net-next v2 06/13] phy: add 2.5G SGMII mode to the phy_mode enum
From: Russell King - ARM Linux @ 2018-05-08 12:34 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <20180504135643.23466-7-antoine.tenart@bootlin.com>
On Fri, May 04, 2018 at 03:56:36PM +0200, Antoine Tenart wrote:
> This patch adds one more generic PHY mode to the phy_mode enum, to allow
> configuring generic PHYs to the 2.5G SGMII mode by using the set_mode
> callback.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Hi,
Would it be possible to get the 2.5G SGMII comphy support merged
ahead of the rest of this series please - I don't think there's been
any objections to it, and having it in mainline would then mean I can
drop the Marvell Comphy code from my tree and transition to the bootlin
Comphy code instead.
Of course, the perfect solution would be to get the whole series merged,
but I'm just thinking about the situation where we're still discussing
points when the next merge window opens.
Thanks.
> ---
> include/linux/phy/phy.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index c9d14eeee7f5..9713aebdd348 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -36,6 +36,7 @@ enum phy_mode {
> PHY_MODE_USB_DEVICE_SS,
> PHY_MODE_USB_OTG,
> PHY_MODE_SGMII,
> + PHY_MODE_2500SGMII,
> PHY_MODE_10GKR,
> PHY_MODE_UFS_HS_A,
> PHY_MODE_UFS_HS_B,
> --
> 2.17.0
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH net-next] net: phy: sfp: handle cases where neither BR,min nor BR,max is given
From: Russell King - ARM Linux @ 2018-05-08 12:30 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, netdev, linux-kernel, thomas.petazzoni, maxime.chevallier,
gregory.clement, miquel.raynal, nadavh, stefanc, ymarkman, mw
In-Reply-To: <20180504152103.18152-1-antoine.tenart@bootlin.com>
On Fri, May 04, 2018 at 05:21:03PM +0200, Antoine Tenart wrote:
> When computing the bitrate using values read from an SFP module EEPROM,
> we use the nominal BR plus BR,min and BR,max to determine the
> boundaries. But in some cases BR,min and BR,max aren't provided, which
> led the SFP code to end up having the nominal value for both the minimum
> and maximum bitrate values. When using a passive cable, the nominal
> value should be used as the maximum one, and there is no minimum one
> so we should use 0.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
> ---
>
> Hi Russell,
>
> I'm not completely sure about this patch as this case is not really
> specified in the specification. But the issue is there, and I've discuss
> this with others. It seemed logical (at least to us :)) to use the
> BR,nominal values as br_max and 0 as br_min when using a passive cable
> which only provides BR,nominal as this would be the highest rate at
> which the cable could work. And because it's passive, there should be no
> issues using it at a lower rate.
>
> I've tested this with one passive cable which only reports its
> BR,nominal (which was 10300) while it could be used when using 1000baseX
> or 2500baseX modes.
The electronic engineer in me says that using zero isn't really valid
because there are coupling capacitors in the SFP module that block DC.
These blocking capacitors are required by the SFP+ specs to have a high
pass pole of between 20kHz and 100kHz - in other words, frequencies
below this are attenuated by the coupling capacitors. The relationship
between this and the bit rate will be a function of the encoding, so we
can't come to a definitive figure without some math (and I want to be
lazy about that!)
Practically, we're talking about SerDes Ethernet, where the bit rate is
no lower than 100Mbps [*], which will always have a frequency well above
this cut-off. So, I don't have any problem with your approach to
setting the minimum to zero. Therefore,
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Please send me the EEPROM dump using:
ethtool -m <ethernetdevice> raw on > foo.bin
so I can add it to my database for future testing and validation.
Thanks.
* - 10Mbps SGMII is 1Gbps SGMII with each bit repeated 100 times.
100Mbps SGMII is 1Gbps SGMII with each bit repeated 10 times.
There is a capability bits for transceivers supporting
100base-FX/LX but no one has tested those yet.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH net] bridge: netfilter stp fix reference to uninitialized data
From: Pablo Neira Ayuso @ 2018-05-08 12:17 UTC (permalink / raw)
To: Stephen Hemminger
Cc: kadlec, fw, davem, netfilter-devel, bridge, netdev,
Stephen Hemminger
In-Reply-To: <20180427181609.3103-1-sthemmin@microsoft.com>
On Fri, Apr 27, 2018 at 11:16:09AM -0700, Stephen Hemminger wrote:
> The destination mac (destmac) is only valid if EBT_DESTMAC flag
> is set. Fix by changing the order of the comparison to look for
> the flag first.
Applied, thanks Stephen.
^ permalink raw reply
* Re: INFO: rcu detected stall in sctp_generate_heartbeat_event
From: Marcelo Ricardo Leitner @ 2018-05-08 12:06 UTC (permalink / raw)
To: syzbot
Cc: davem, linux-kernel, linux-sctp, netdev, nhorman, syzkaller-bugs,
vyasevich
In-Reply-To: <000000000000062c1c056bacd39f@google.com>
On Tue, May 08, 2018 at 12:35:02AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 90278871d4b0 Merge git://git.kernel.org/pub/scm/linux/kern..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=119a7237800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=aea320d3af5ef99d
> dashboard link: https://syzkaller.appspot.com/bug?extid=e4a5bbd54260c93014f9
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
A reproducer will be welcomed. With just these traces, I don't think
we have enough information.
Marcelo
^ permalink raw reply
* Re: [PATCH net] net: phy: sfp: fix the BR,min computation
From: Russell King - ARM Linux @ 2018-05-08 12:05 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, netdev, linux-kernel, thomas.petazzoni, maxime.chevallier,
gregory.clement, miquel.raynal, nadavh, stefanc, ymarkman, mw
In-Reply-To: <20180504151054.17525-1-antoine.tenart@bootlin.com>
On Fri, May 04, 2018 at 05:10:54PM +0200, Antoine Tenart wrote:
> In an SFP EEPROM values can be read to get information about a given SFP
> module. One of those is the bitrate, which can be determined using a
> nominal bitrate in addition with min and max values (in %). The SFP code
> currently compute both BR,min and BR,max values thanks to this nominal
> and min,max values.
>
> This patch fixes the BR,min computation as the min value should be
> subtracted to the nominal one, not added.
>
> Fixes: 9962acf7fb8c ("sfp: add support for 1000Base-PX and 1000Base-BX10")
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
I know David has already applied it, but for the record, your fix looks
correct, thanks.
> ---
> drivers/net/phy/sfp-bus.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
> index 0381da78d228..fd6c23f69c2f 100644
> --- a/drivers/net/phy/sfp-bus.c
> +++ b/drivers/net/phy/sfp-bus.c
> @@ -125,7 +125,7 @@ void sfp_parse_support(struct sfp_bus *bus, const struct sfp_eeprom_id *id,
> if (id->base.br_nominal) {
> if (id->base.br_nominal != 255) {
> br_nom = id->base.br_nominal * 100;
> - br_min = br_nom + id->base.br_nominal * id->ext.br_min;
> + br_min = br_nom - id->base.br_nominal * id->ext.br_min;
> br_max = br_nom + id->base.br_nominal * id->ext.br_max;
> } else if (id->ext.br_max) {
> br_nom = 250 * id->ext.br_max;
> --
> 2.17.0
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [iproute-next v2] tipc: Add support to set and get MTU for UDP bearer
From: GhantaKrishnamurthy MohanKrishna @ 2018-05-08 11:55 UTC (permalink / raw)
To: tipc-discussion, jon.maloy, maloy, ying.xue,
mohan.krishna.ghanta.krishnamurthy, netdev, stephen, dsahern
In this commit we introduce the ability to set and get
MTU for UDP media and bearer.
For set and get properties such as tolerance, window and priority,
we already do:
$ tipc media set PPROPERTY media MEDIA
$ tipc media get PPROPERTY media MEDIA
$ tipc bearer set OPTION media MEDIA ARGS
$ tipc bearer get [OPTION] media MEDIA ARGS
The same has been extended for MTU, with an exception to support
only media type UDP.
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: GhantaKrishnamurthy MohanKrishna <mohan.krishna.ghanta.krishnamurthy@ericsson.com>
---
tipc/bearer.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++---------
tipc/media.c | 24 ++++++++++++++++++++++--
2 files changed, 68 insertions(+), 11 deletions(-)
diff --git a/tipc/bearer.c b/tipc/bearer.c
index 0d8457015062..05dc84aa8ded 100644
--- a/tipc/bearer.c
+++ b/tipc/bearer.c
@@ -42,7 +42,8 @@ static void _print_bearer_opts(void)
"OPTIONS\n"
" priority - Bearer link priority\n"
" tolerance - Bearer link tolerance\n"
- " window - Bearer link window\n");
+ " window - Bearer link window\n"
+ " mtu - Bearer link mtu\n");
}
void print_bearer_media(void)
@@ -194,6 +195,21 @@ static int nl_add_udp_enable_opts(struct nlmsghdr *nlh, struct opt *opts,
return 0;
}
+static char *cmd_get_media_type(const struct cmd *cmd, struct cmdl *cmdl,
+ struct opt *opts)
+{
+ struct opt *opt = get_opt(opts, "media");
+
+ if (!opt) {
+ if (help_flag)
+ (cmd->help)(cmdl);
+ else
+ fprintf(stderr, "error, missing bearer media\n");
+ return NULL;
+ }
+ return opt->val;
+}
+
static int nl_add_bearer_name(struct nlmsghdr *nlh, const struct cmd *cmd,
struct cmdl *cmdl, struct opt *opts,
const struct tipc_sup_media *sup_media)
@@ -217,15 +233,8 @@ int cmd_get_unique_bearer_name(const struct cmd *cmd, struct cmdl *cmdl,
struct opt *opt;
const struct tipc_sup_media *entry;
-
- if (!(opt = get_opt(opts, "media"))) {
- if (help_flag)
- (cmd->help)(cmdl);
- else
- fprintf(stderr, "error, missing bearer media\n");
+ if (!(media = cmd_get_media_type(cmd, cmdl, opts)))
return -EINVAL;
- }
- media = opt->val;
for (entry = sup_media; entry->media; entry++) {
if (strcmp(entry->media, media))
@@ -559,6 +568,8 @@ static int cmd_bearer_set_prop(struct nlmsghdr *nlh, const struct cmd *cmd,
prop = TIPC_NLA_PROP_TOL;
else if ((strcmp(cmd->cmd, "window") == 0))
prop = TIPC_NLA_PROP_WIN;
+ else if ((strcmp(cmd->cmd, "mtu") == 0))
+ prop = TIPC_NLA_PROP_MTU;
else
return -EINVAL;
@@ -571,6 +582,17 @@ static int cmd_bearer_set_prop(struct nlmsghdr *nlh, const struct cmd *cmd,
if (parse_opts(opts, cmdl) < 0)
return -EINVAL;
+ if (prop == TIPC_NLA_PROP_MTU) {
+ char *media = cmd_get_media_type(cmd, cmdl, opts);
+
+ if (!media)
+ return -EINVAL;
+ else if (strcmp(media, "udp")) {
+ fprintf(stderr, "error, not supported for media\n");
+ return -EINVAL;
+ }
+ }
+
if (!(nlh = msg_init(buf, TIPC_NL_BEARER_SET))) {
fprintf(stderr, "error, message initialisation failed\n");
return -1;
@@ -597,6 +619,7 @@ static int cmd_bearer_set(struct nlmsghdr *nlh, const struct cmd *cmd,
{ "priority", cmd_bearer_set_prop, cmd_bearer_set_help },
{ "tolerance", cmd_bearer_set_prop, cmd_bearer_set_help },
{ "window", cmd_bearer_set_prop, cmd_bearer_set_help },
+ { "mtu", cmd_bearer_set_prop, cmd_bearer_set_help },
{ NULL }
};
@@ -877,12 +900,25 @@ static int cmd_bearer_get_prop(struct nlmsghdr *nlh, const struct cmd *cmd,
prop = TIPC_NLA_PROP_TOL;
else if ((strcmp(cmd->cmd, "window") == 0))
prop = TIPC_NLA_PROP_WIN;
+ else if ((strcmp(cmd->cmd, "mtu") == 0))
+ prop = TIPC_NLA_PROP_MTU;
else
return -EINVAL;
if (parse_opts(opts, cmdl) < 0)
return -EINVAL;
+ if (prop == TIPC_NLA_PROP_MTU) {
+ char *media = cmd_get_media_type(cmd, cmdl, opts);
+
+ if (!media)
+ return -EINVAL;
+ else if (strcmp(media, "udp")) {
+ fprintf(stderr, "error, not supported for media\n");
+ return -EINVAL;
+ }
+ }
+
if (!(nlh = msg_init(buf, TIPC_NL_BEARER_GET))) {
fprintf(stderr, "error, message initialisation failed\n");
return -1;
@@ -904,6 +940,7 @@ static int cmd_bearer_get(struct nlmsghdr *nlh, const struct cmd *cmd,
{ "priority", cmd_bearer_get_prop, cmd_bearer_get_help },
{ "tolerance", cmd_bearer_get_prop, cmd_bearer_get_help },
{ "window", cmd_bearer_get_prop, cmd_bearer_get_help },
+ { "mtu", cmd_bearer_get_prop, cmd_bearer_get_help },
{ "media", cmd_bearer_get_media, cmd_bearer_get_help },
{ NULL }
};
diff --git a/tipc/media.c b/tipc/media.c
index 6e10c7e5d8e6..969ef6578b3b 100644
--- a/tipc/media.c
+++ b/tipc/media.c
@@ -103,6 +103,8 @@ static int cmd_media_get_prop(struct nlmsghdr *nlh, const struct cmd *cmd,
prop = TIPC_NLA_PROP_TOL;
else if ((strcmp(cmd->cmd, "window") == 0))
prop = TIPC_NLA_PROP_WIN;
+ else if ((strcmp(cmd->cmd, "mtu") == 0))
+ prop = TIPC_NLA_PROP_MTU;
else
return -EINVAL;
@@ -123,6 +125,12 @@ static int cmd_media_get_prop(struct nlmsghdr *nlh, const struct cmd *cmd,
fprintf(stderr, "error, missing media\n");
return -EINVAL;
}
+
+ if ((prop == TIPC_NLA_PROP_MTU) &&
+ (strcmp(opt->val, "udp"))) {
+ fprintf(stderr, "error, not supported for media\n");
+ return -EINVAL;
+ }
nest = mnl_attr_nest_start(nlh, TIPC_NLA_MEDIA);
mnl_attr_put_strz(nlh, TIPC_NLA_MEDIA_NAME, opt->val);
mnl_attr_nest_end(nlh, nest);
@@ -136,7 +144,8 @@ static void cmd_media_get_help(struct cmdl *cmdl)
"PROPERTIES\n"
" tolerance - Get media tolerance\n"
" priority - Get media priority\n"
- " window - Get media window\n",
+ " window - Get media window\n"
+ " mtu - Get media mtu\n",
cmdl->argv[0]);
}
@@ -147,6 +156,7 @@ static int cmd_media_get(struct nlmsghdr *nlh, const struct cmd *cmd,
{ "priority", cmd_media_get_prop, cmd_media_get_help },
{ "tolerance", cmd_media_get_prop, cmd_media_get_help },
{ "window", cmd_media_get_prop, cmd_media_get_help },
+ { "mtu", cmd_media_get_prop, cmd_media_get_help },
{ NULL }
};
@@ -159,7 +169,8 @@ static void cmd_media_set_help(struct cmdl *cmdl)
"PROPERTIES\n"
" tolerance TOLERANCE - Set media tolerance\n"
" priority PRIORITY - Set media priority\n"
- " window WINDOW - Set media window\n",
+ " window WINDOW - Set media window\n"
+ " mtu MTU - Set media mtu\n",
cmdl->argv[0]);
}
@@ -183,6 +194,8 @@ static int cmd_media_set_prop(struct nlmsghdr *nlh, const struct cmd *cmd,
prop = TIPC_NLA_PROP_TOL;
else if ((strcmp(cmd->cmd, "window") == 0))
prop = TIPC_NLA_PROP_WIN;
+ else if ((strcmp(cmd->cmd, "mtu") == 0))
+ prop = TIPC_NLA_PROP_MTU;
else
return -EINVAL;
@@ -210,6 +223,12 @@ static int cmd_media_set_prop(struct nlmsghdr *nlh, const struct cmd *cmd,
fprintf(stderr, "error, missing media\n");
return -EINVAL;
}
+
+ if ((prop == TIPC_NLA_PROP_MTU) &&
+ (strcmp(opt->val, "udp"))) {
+ fprintf(stderr, "error, not supported for media\n");
+ return -EINVAL;
+ }
mnl_attr_put_strz(nlh, TIPC_NLA_MEDIA_NAME, opt->val);
props = mnl_attr_nest_start(nlh, TIPC_NLA_MEDIA_PROP);
@@ -228,6 +247,7 @@ static int cmd_media_set(struct nlmsghdr *nlh, const struct cmd *cmd,
{ "priority", cmd_media_set_prop, cmd_media_set_help },
{ "tolerance", cmd_media_set_prop, cmd_media_set_help },
{ "window", cmd_media_set_prop, cmd_media_set_help },
+ { "mtu", cmd_media_set_prop, cmd_media_set_help },
{ NULL }
};
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net-next v2 03/13] net: phy: sfp: warn the user when no tx_disable pin is available
From: Russell King - ARM Linux @ 2018-05-08 11:53 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <20180504135643.23466-4-antoine.tenart@bootlin.com>
On Fri, May 04, 2018 at 03:56:33PM +0200, Antoine Tenart wrote:
> In case no Tx disable pin is available the SFP modules will always be
> emitting. This could be an issue when using modules using laser as their
> light source as we would have no way to disable it when the fiber is
> removed. This patch adds a warning when registering an SFP cage which do
> not have its tx_disable pin wired or available.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Looks fine, thanks.
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> drivers/net/phy/sfp.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
> index 8e323a4b70da..d4f503b2e3e2 100644
> --- a/drivers/net/phy/sfp.c
> +++ b/drivers/net/phy/sfp.c
> @@ -1093,6 +1093,15 @@ static int sfp_probe(struct platform_device *pdev)
> if (!sfp->gpio[GPIO_MODDEF0] && !sfp->gpio[GPIO_LOS])
> sfp->sm_dev_state = SFP_DEV_UNKNOWN;
>
> + /* We could have an issue in cases no Tx disable pin is available or
> + * wired as modules using a laser as their light source will continue to
> + * be active when the fiber is removed. This could be a safety issue and
> + * we should at least warn the user about that.
> + */
> + if (!sfp->gpio[GPIO_TX_DISABLE])
> + dev_warn(sfp->dev,
> + "No tx_disable pin: SFP modules will always be emitting.\n");
> +
> return 0;
> }
>
> --
> 2.17.0
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH net-next v2 02/13] net: phy: sfp: handle non-wired SFP connectors
From: Russell King - ARM Linux @ 2018-05-08 11:52 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <20180504135643.23466-3-antoine.tenart@bootlin.com>
On Fri, May 04, 2018 at 03:56:32PM +0200, Antoine Tenart wrote:
> SFP connectors can be solder on a board without having any of their pins
> (LOS, i2c...) wired. In such cases the SFP link state cannot be guessed,
> and the overall link status reporting is left to other layers.
>
> In order to achieve this, a new SFP_DEV status is added, named UNKNOWN.
> This mode is set when it is not possible for the SFP code to get the
> link status and as a result the link status is reported to be always UP
> from the SFP point of view.
This looks weird to me. SFP_DEV_* states track the netdevice up/down
state and have little to do with whether LOS or MODDEF0 are implemented.
I think it would be better to have a new SFP_MOD_* and to force
sm_mod_state to that in this circumstance.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ 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