aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-02-07tmpfs: switch to use of invalfc()Al Viro1-3/+3
Signed-off-by: Al Viro <[email protected]>
2020-02-07cgroup1: switch to use of errorfc() et.al.Al Viro1-12/+12
Signed-off-by: Al Viro <[email protected]>
2020-02-07procfs: switch to use of invalfc()Al Viro1-1/+1
Signed-off-by: Al Viro <[email protected]>
2020-02-07hugetlbfs: switch to use of invalfc()Al Viro1-1/+1
Signed-off-by: Al Viro <[email protected]>
2020-02-07cramfs: switch to use of errofc() et.al.Al Viro1-7/+7
Signed-off-by: Al Viro <[email protected]>
2020-02-07gfs2: switch to use of errorfc() et.al.Al Viro1-15/+15
Signed-off-by: Al Viro <[email protected]>
2020-02-07fuse: switch to use errorfc() et.al.Al Viro1-6/+6
Signed-off-by: Al Viro <[email protected]>
2020-02-07ceph: use errorfc() and friends instead of spelling the prefix outAl Viro2-9/+9
Signed-off-by: Al Viro <[email protected]>
2020-02-07prefix-handling analogues of errorf() and friendsAl Viro1-0/+4
called errorfc/infofc/warnfc/invalfc Signed-off-by: Al Viro <[email protected]>
2020-02-07turn fs_param_is_... into functionsAl Viro3-129/+139
Signed-off-by: Al Viro <[email protected]>
2020-02-07fs_parse: handle optional arguments sanelyAl Viro5-121/+82
Don't bother with "mixed" options that would allow both the form with and without argument (i.e. both -o foo and -o foo=bar). Rather than trying to shove both into a single fs_parameter_spec, allow having with-argument and no-argument specs with the same name and teach fs_parse to handle that. There are very few options of that sort, and they are actually easier to handle that way - callers end up with less postprocessing. Signed-off-by: Al Viro <[email protected]>
2020-02-07fs_parse: fold fs_parameter_desc/fs_parameter_specAl Viro29-198/+106
The former contains nothing but a pointer to an array of the latter... Signed-off-by: Al Viro <[email protected]>
2020-02-07fs_parser: remove fs_parameter_description name fieldEric Sandeen26-44/+11
Unused now. Signed-off-by: Eric Sandeen <[email protected]> Acked-by: David Howells <[email protected]> Signed-off-by: Al Viro <[email protected]>
2020-02-07add prefix to fs_context->logAl Viro6-27/+23
... turning it into struct p_log embedded into fs_context. Initialize the prefix with fs_type->name, turning fs_parse() into a trivial inline wrapper for __fs_parse(). This makes fs_parameter_description->name completely unused. Signed-off-by: Al Viro <[email protected]>
2020-02-07ceph_parse_param(), ceph_parse_mon_ips(): switch to passing fc_logAl Viro3-8/+9
... and now errorf() et.al. are never called with NULL fs_context, so we can get rid of conditional in those. Signed-off-by: Al Viro <[email protected]>
2020-02-07new primitive: __fs_parse()Al Viro5-12/+23
fs_parse() analogue taking p_log instead of fs_context. fs_parse() turned into a wrapper, callers in ceph_common and rbd switched to __fs_parse(). As the result, fs_parse() never gets NULL fs_context and neither do fs_context-based logging primitives Signed-off-by: Al Viro <[email protected]>
2020-02-07switch rbd and libceph to p_log-based primitivesAl Viro2-20/+20
Signed-off-by: Al Viro <[email protected]>
2020-02-07struct p_log, variants of warnf() et.al. taking that one insteadAl Viro2-0/+12
primitives for prefixed logging Signed-off-by: Al Viro <[email protected]>
2020-02-07teach logfc() to handle prefices, give it saner calling conventionsAl Viro2-52/+27
Signed-off-by: Al Viro <[email protected]>
2020-02-07get rid of cg_invalf()Al Viro1-14/+12
pointless alias for invalf()... Signed-off-by: Al Viro <[email protected]>
2020-02-07get rid of fs_value_is_filename_emptyAl Viro4-16/+5
Its behaviour is identical to that of fs_value_is_filename. It makes no sense, anyway - LOOKUP_EMPTY affects nothing whatsoever once the pathname has been imported from userland. And both fs_value_is_filename and fs_value_is_filename_empty carry an already imported pathname. Signed-off-by: Al Viro <[email protected]>
2020-02-07don't bother with explicit length argument for __lookup_constant()Al Viro3-18/+21
Have the arrays of constant_table self-terminated (by NULL ->name in the final entry). Simplifies lookup_constant() and allows to reuse the search for enum params as well. Signed-off-by: Al Viro <[email protected]>
2020-02-07sunrpc: expiry_time should be seconds not timevalRoberto Bergantinos Corpas1-0/+4
When upcalling gssproxy, cache_head.expiry_time is set as a timeval, not seconds since boot. As such, RPC cache expiry logic will not clean expired objects created under auth.rpcsec.context cache. This has proven to cause kernel memory leaks on field. Using 64 bit variants of getboottime/timespec Expiration times have worked this way since 2010's c5b29f885afe "sunrpc: use seconds since boot in expiry cache". The gssproxy code introduced in 2012 added gss_proxy_save_rsc and introduced the bug. That's a while for this to lurk, but it required a bit of an extreme case to make it obvious. Signed-off-by: Roberto Bergantinos Corpas <[email protected]> Cc: [email protected] Fixes: 030d794bf498 "SUNRPC: Use gssproxy upcall for server..." Tested-By: Frank Sorenson <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]>
2020-02-07nfsd: make nfsd_filecache_wq variable staticChen Zhou1-1/+1
Fix sparse warning: fs/nfsd/filecache.c:55:25: warning: symbol 'nfsd_filecache_wq' was not declared. Should it be static? Reported-by: Hulk Robot <[email protected]> Signed-off-by: Chen Zhou <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]>
2020-02-07drop_monitor: Do not cancel uninitialized work itemIdo Schimmel1-1/+3
Drop monitor uses a work item that takes care of constructing and sending netlink notifications to user space. In case drop monitor never started to monitor, then the work item is uninitialized and not associated with a function. Therefore, a stop command from user space results in canceling an uninitialized work item which leads to the following warning [1]. Fix this by not processing a stop command if drop monitor is not currently monitoring. [1] [ 31.735402] ------------[ cut here ]------------ [ 31.736470] WARNING: CPU: 0 PID: 143 at kernel/workqueue.c:3032 __flush_work+0x89f/0x9f0 ... [ 31.738120] CPU: 0 PID: 143 Comm: dwdump Not tainted 5.5.0-custom-09491-g16d4077796b8 #727 [ 31.741968] RIP: 0010:__flush_work+0x89f/0x9f0 ... [ 31.760526] Call Trace: [ 31.771689] __cancel_work_timer+0x2a6/0x3b0 [ 31.776809] net_dm_cmd_trace+0x300/0xef0 [ 31.777549] genl_rcv_msg+0x5c6/0xd50 [ 31.781005] netlink_rcv_skb+0x13b/0x3a0 [ 31.784114] genl_rcv+0x29/0x40 [ 31.784720] netlink_unicast+0x49f/0x6a0 [ 31.787148] netlink_sendmsg+0x7cf/0xc80 [ 31.790426] ____sys_sendmsg+0x620/0x770 [ 31.793458] ___sys_sendmsg+0xfd/0x170 [ 31.802216] __sys_sendmsg+0xdf/0x1a0 [ 31.806195] do_syscall_64+0xa0/0x540 [ 31.806885] entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: 8e94c3bc922e ("drop_monitor: Allow user to start monitoring hardware drops") Signed-off-by: Ido Schimmel <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-07Merge branch 'mlxsw-Various-fixes'David S. Miller5-6/+142
Ido Schimmel says: ==================== mlxsw: Various fixes This patch set contains various fixes for the mlxsw driver. Patch #1 fixes an issue introduced in 5.6 in which a route in the main table can replace an identical route in the local table despite the local table having an higher precedence. Patch #2 contains a test case for the bug fixed in patch #1. Patch #3 also fixes an issue introduced in 5.6 in which the driver failed to clear the offload indication from IPv6 nexthops upon abort. Patch #4 fixes an issue that prevents the driver from loading on Spectrum-3 systems. The problem and solution are explained in detail in the commit message. Patch #5 adds a missing error path. Discovered using smatch. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-02-07mlxsw: spectrum_dpipe: Add missing error pathIdo Schimmel1-1/+2
In case devlink_dpipe_entry_ctx_prepare() failed, release RTNL that was previously taken and free the memory allocated by mlxsw_sp_erif_entry_prepare(). Fixes: 2ba5999f009d ("mlxsw: spectrum: Add Support for erif table entries access") Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-07mlxsw: core: Add validation of hardware device types for MGPIR registerVadim Pasternak2-4/+10
When reading the number of gearboxes from the hardware, the driver does not validate the returned 'device type' field. The driver can therefore wrongly assume that the queried devices are gearboxes. On Spectrum-3 systems that support different types of devices, this can prevent the driver from loading, as it will try to query the temperature sensors from devices which it assumes are gearboxes and in fact are not. For example: [ 218.129230] mlxsw_minimal 2-0048: Reg cmd access status failed (status=7(bad parameter)) [ 218.138282] mlxsw_minimal 2-0048: Reg cmd access failed (reg_id=900a(mtmp),type=write) [ 218.147131] mlxsw_minimal 2-0048: Failed to setup temp sensor number 256 [ 218.534480] mlxsw_minimal 2-0048: Fail to register core bus [ 218.540714] mlxsw_minimal: probe of 2-0048 failed with error -5 Fix this by validating the 'device type' field. Fixes: 2e265a8b6c094 ("mlxsw: core: Extend hwmon interface with inter-connect temperature attributes") Fixes: f14f4e621b1b4 ("mlxsw: core: Extend thermal core with per inter-connect device thermal zones") Signed-off-by: Vadim Pasternak <[email protected]> Acked-by: Jiri Pirko <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-07mlxsw: spectrum_router: Clear offload indication from IPv6 nexthops on abortIdo Schimmel1-0/+3
Unlike IPv4, in IPv6 there is no unique structure to represent the nexthop and both the route and nexthop information are squashed to the same structure ('struct fib6_info'). In order to improve resource utilization the driver consolidates identical nexthop groups to the same internal representation of a nexthop group. Therefore, when the offload indication of a nexthop changes, the driver needs to iterate over all the linked fib6_info and toggle their offload flag accordingly. During abort, all the routes are removed from the device and unlinked from their nexthop group. The offload indication is cleared just before the group is destroyed, but by that time no fib6_info is linked to the group and the offload indication remains set. Fix this by clearing the offload indication just before dropping the reference from the nexthop. Fixes: ee5a0448e72b ("mlxsw: spectrum_router: Set hardware flags for routes") Reported-by: Alex Kushnarov <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Acked-by: Jiri Pirko <[email protected]> Tested-by: Alex Kushnarov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-07selftests: mlxsw: Add test cases for local table route replacementIdo Schimmel1-0/+76
Test that routes in the main table do not replace identical routes in the local table and that routes in the local table do replace identical routes in the main table. Signed-off-by: Ido Schimmel <[email protected]> Acked-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-07mlxsw: spectrum_router: Prevent incorrect replacement of local table routesIdo Schimmel1-1/+51
The driver uses the same table to represent both the main and local routing tables. Prevent routes in the main table from replacing routes in the local table to reflect the fact that the local table is consulted first during lookup. Fixes: b6a1d871d37a ("mlxsw: spectrum_router: Start using new IPv4 route notifications") Fixes: dacad7b34b59 ("mlxsw: spectrum_router: Start using new IPv6 route notifications") Signed-off-by: Ido Schimmel <[email protected]> Acked-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-07net: dsa: microchip: enable module autoprobeRazvan Stefanescu1-0/+6
This matches /sys/devices/.../spi1.0/modalias content. Fixes: 9b2d9f05cddf ("net: dsa: microchip: add ksz9567 to ksz9477 driver") Fixes: d9033ae95cf4 ("net: dsa: microchip: add KSZ8563 compatibility string") Fixes: 8c29bebb1f8a ("net: dsa: microchip: add KSZ9893 switch support") Fixes: 45316818371d ("net: dsa: add support for ksz9897 ethernet switch") Fixes: b987e98e50ab ("dsa: add DSA switch driver for Microchip KSZ9477") Signed-off-by: Razvan Stefanescu <[email protected]> Signed-off-by: Codrin Ciubotariu <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-07ipv6/addrconf: fix potential NULL deref in inet6_set_link_af()Eric Dumazet1-0/+3
__in6_dev_get(dev) called from inet6_set_link_af() can return NULL. The needed check has been recently removed, let's add it back. While do_setlink() does call validate_linkmsg() : ... err = validate_linkmsg(dev, tb); /* OK at this point */ ... It is possible that the following call happening before the ->set_link_af() removes IPv6 if MTU is less than 1280 : if (tb[IFLA_MTU]) { err = dev_set_mtu_ext(dev, nla_get_u32(tb[IFLA_MTU]), extack); if (err < 0) goto errout; status |= DO_SETLINK_MODIFIED; } ... if (tb[IFLA_AF_SPEC]) { ... err = af_ops->set_link_af(dev, af); ->inet6_set_link_af() // CRASH because idev is NULL Please note that IPv4 is immune to the bug since inet_set_link_af() does : struct in_device *in_dev = __in_dev_get_rcu(dev); if (!in_dev) return -EAFNOSUPPORT; This problem has been mentioned in commit cf7afbfeb8ce ("rtnl: make link af-specific updates atomic") changelog : This method is not fail proof, while it is currently sufficient to make set_link_af() inerrable and thus 100% atomic, the validation function method will not be able to detect all error scenarios in the future, there will likely always be errors depending on states which are f.e. not protected by rtnl_mutex and thus may change between validation and setting. IPv6: ADDRCONF(NETDEV_CHANGE): lo: link becomes ready general protection fault, probably for non-canonical address 0xdffffc0000000056: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x00000000000002b0-0x00000000000002b7] CPU: 0 PID: 9698 Comm: syz-executor712 Not tainted 5.5.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:inet6_set_link_af+0x66e/0xae0 net/ipv6/addrconf.c:5733 Code: 38 d0 7f 08 84 c0 0f 85 20 03 00 00 48 8d bb b0 02 00 00 45 0f b6 64 24 04 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 1a 03 00 00 44 89 a3 b0 02 00 RSP: 0018:ffffc90005b06d40 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff86df39a6 RDX: 0000000000000056 RSI: ffffffff86df3e74 RDI: 00000000000002b0 RBP: ffffc90005b06e70 R08: ffff8880a2ac0380 R09: ffffc90005b06db0 R10: fffff52000b60dbe R11: ffffc90005b06df7 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8880a1fcc424 R15: dffffc0000000000 FS: 0000000000c46880(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f0494ca0d0 CR3: 000000009e4ac000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: do_setlink+0x2a9f/0x3720 net/core/rtnetlink.c:2754 rtnl_group_changelink net/core/rtnetlink.c:3103 [inline] __rtnl_newlink+0xdd1/0x1790 net/core/rtnetlink.c:3257 rtnl_newlink+0x69/0xa0 net/core/rtnetlink.c:3377 rtnetlink_rcv_msg+0x45e/0xaf0 net/core/rtnetlink.c:5438 netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477 rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5456 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] netlink_unicast+0x59e/0x7e0 net/netlink/af_netlink.c:1328 netlink_sendmsg+0x91c/0xea0 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xd7/0x130 net/socket.c:672 ____sys_sendmsg+0x753/0x880 net/socket.c:2343 ___sys_sendmsg+0x100/0x170 net/socket.c:2397 __sys_sendmsg+0x105/0x1d0 net/socket.c:2430 __do_sys_sendmsg net/socket.c:2439 [inline] __se_sys_sendmsg net/socket.c:2437 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2437 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4402e9 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007fffd62fbcf8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004402e9 RDX: 0000000000000000 RSI: 0000000020000080 RDI: 0000000000000003 RBP: 00000000006ca018 R08: 0000000000000008 R09: 00000000004002c8 R10: 0000000000000005 R11: 0000000000000246 R12: 0000000000401b70 R13: 0000000000401c00 R14: 0000000000000000 R15: 0000000000000000 Modules linked in: ---[ end trace cfa7664b8fdcdff3 ]--- RIP: 0010:inet6_set_link_af+0x66e/0xae0 net/ipv6/addrconf.c:5733 Code: 38 d0 7f 08 84 c0 0f 85 20 03 00 00 48 8d bb b0 02 00 00 45 0f b6 64 24 04 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 1a 03 00 00 44 89 a3 b0 02 00 RSP: 0018:ffffc90005b06d40 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff86df39a6 RDX: 0000000000000056 RSI: ffffffff86df3e74 RDI: 00000000000002b0 RBP: ffffc90005b06e70 R08: ffff8880a2ac0380 R09: ffffc90005b06db0 R10: fffff52000b60dbe R11: ffffc90005b06df7 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8880a1fcc424 R15: dffffc0000000000 FS: 0000000000c46880(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000004 CR3: 000000009e4ac000 CR4: 00000000001406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Fixes: 7dc2bccab0ee ("Validate required parameters in inet6_validate_link_af") Signed-off-by: Eric Dumazet <[email protected]> Bisected-and-reported-by: syzbot <[email protected]> Cc: Maxim Mikityanskiy <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-07smp/up: Make smp_call_function_single() match SMP semanticsPaul E. McKenney1-1/+2
In CONFIG_SMP=y kernels, smp_call_function_single() returns -ENXIO when invoked for a non-existent CPU. In contrast, in CONFIG_SMP=n kernels, a splat is emitted and smp_call_function_single() otherwise silently ignores its "cpu" argument, instead pretending that the caller intended to have something happen on CPU 0. Given that there is now code that expects smp_call_function_single() to return an error if a bad CPU was specified, this difference in semantics needs to be addressed. Bring the semantics of the CONFIG_SMP=n version of smp_call_function_single() into alignment with its CONFIG_SMP=y counterpart. Signed-off-by: Paul E. McKenney <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lkml.kernel.org/r/20200205143409.GA7021@paulmck-ThinkPad-P72
2020-02-07x86/apic: Mask IOAPIC entries when disabling the local APICTony W Wang-oc1-0/+7
When a system suspends, the local APIC is disabled in the suspend sequence, but the IOAPIC is left in the current state. This means unmasked interrupt lines stay unmasked. This is usually the case for IOAPIC pin 9 to which the ACPI interrupt is connected. That means that in suspended state the IOAPIC can respond to an external interrupt, e.g. the wakeup via keyboard/RTC/ACPI, but the interrupt message cannot be handled by the disabled local APIC. As a consequence the Remote IRR bit is set, but the local APIC does not send an EOI to acknowledge it. This causes the affected interrupt line to become stale and the stale Remote IRR bit will cause a hang when __synchronize_hardirq() is invoked for that interrupt line. To prevent this, mask all IOAPIC entries before disabling the local APIC. The resume code already has the unmask operation inside. [ tglx: Massaged changelog ] Signed-off-by: Tony W Wang-oc <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-02-07dpaa_eth: support all modes with rate adapting PHYsMadalin Bucur1-3/+11
Stop removing modes that are not supported on the system interface when the connected PHY is capable of rate adaptation. This addresses an issue with the LS1046ARDB board 10G interface no longer working with an 1G link partner after autonegotiation support was added for the Aquantia PHY on board in commit 09c4c57f7bc4 ("net: phy: aquantia: add support for auto-negotiation configuration") Before this commit the values advertised by the PHY were not influenced by the dpaa_eth driver removal of system-side unsupported modes as the aqr_config_aneg() was basically a no-op. After this commit, the modes removed by the dpaa_eth driver were no longer advertised thus autonegotiation with 1G link partners failed. Reported-by: Mian Yousaf Kaukab <[email protected]> Signed-off-by: Madalin Bucur <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-07Merge branch 'stmmac-fixes'David S. Miller3-13/+20
Ong Boon Leong says: ==================== net: stmmac: general fixes for Ethernet functionality 1/5: It ensures that the previous value of GMAC_VLAN_TAG register is read first before for updating the register. 2/5: Similar to 2/6 patch but it is a fix for XGMAC_VLAN_TAG register as requested by Jose Abreu. 3/5: It ensures the GMAC IP v4.xx and above behaves correctly to:- ip link set <devname> multicast off|on 4/5: Added similar IFF_MULTICAST flag for xgmac2, similar to 4/6. 5/5: It ensures PCI platform data is using plat->phy_interface. Changes from v4:- patch 1/6 - this patch is dropped now and will take the input on handling return value from netif_set_real_num_rx| tx_queues() in future patch series. v3:- patch 1/6 - add rtnl_lock() and rtnl_unlock() for stmmac_hw_setup() called inside stmmac_resume() patch 3/6 - Added new patch to fix XGMAC_VLAN_TAG register writting v2:- patch 1/5 - added control for rtnl_lock() & rtnl_unlock() to ensure they are used forstmmac_resume() patch 4/5 - added IFF_MULTICAST flag check for xgmac to ensure multicast works correctly. v1:- - Drop v1 patches (1/7, 3/7 & 4/7) that are not valid. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-02-07net: stmmac: update pci platform data to use phy_interfaceVoon Weifeng1-6/+8
The recent patch to support passive mode converter did not take care the phy interface configuration in PCI platform data. Hence, converting all the PCI platform data from plat->interface to plat->phy_interface as the default mode is meant for PHY. Fixes: 0060c8783330 ("net: stmmac: implement support for passive mode converters via dt") Signed-off-by: Voon Weifeng <[email protected]> Tested-by: Tan, Tee Min <[email protected]> Signed-off-by: Ong Boon Leong <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-07net: stmmac: xgmac: fix missing IFF_MULTICAST checki in dwxgmac2_set_filterTan, Tee Min1-1/+1
Without checking for IFF_MULTICAST flag, it is wrong to assume multicast filtering is always enabled. By checking against IFF_MULTICAST, now the driver behaves correctly when the multicast support is toggled by below command:- ip link set <devname> multicast off|on Fixes: 0efedbf11f07a ("net: stmmac: xgmac: Fix XGMAC selftests") Signed-off-by: Tan, Tee Min <[email protected]> Signed-off-by: Ong Boon Leong <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-07net: stmmac: fix missing IFF_MULTICAST check in dwmac4_set_filterVerma, Aashish1-1/+1
Without checking for IFF_MULTICAST flag, it is wrong to assume multicast filtering is always enabled. By checking against IFF_MULTICAST, now the driver behaves correctly when the multicast support is toggled by below command:- ip link set <devname> multicast off|on Fixes: 477286b53f55 ("stmmac: add GMAC4 core support") Signed-off-by: Verma, Aashish <[email protected]> Tested-by: Tan, Tee Min <[email protected]> Signed-off-by: Ong Boon Leong <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-07net: stmmac: xgmac: fix incorrect XGMAC_VLAN_TAG register writtingOng Boon Leong1-2/+6
We should always do a read of current value of XGMAC_VLAN_TAG instead of directly overwriting the register value. Fixes: 3cd1cfcba26e2 ("net: stmmac: Implement VLAN Hash Filtering in XGMAC") Signed-off-by: Ong Boon Leong <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-07net: stmmac: fix incorrect GMAC_VLAN_TAG register writting in GMAC4+Tan, Tee Min1-3/+4
It should always do a read of current value of GMAC_VLAN_TAG instead of directly overwriting the register value. Fixes: c1be0022df0d ("net: stmmac: Add VLAN HASH filtering support in GMAC4+") Signed-off-by: Tan, Tee Min <[email protected]> Signed-off-by: Ong Boon Leong <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-07hv_netvsc: Fix XDP refcnt for synthetic and VF NICsHaiyang Zhang2-3/+15
The caller of XDP_SETUP_PROG has already incremented refcnt in __bpf_prog_get(), so drivers should only increment refcnt by num_queues - 1. To fix the issue, update netvsc_xdp_set() to add the correct number to refcnt. Hold a refcnt in netvsc_xdp_set()’s other caller, netvsc_attach(). And, do the same in netvsc_vf_setxdp(). Otherwise, every time when VF is removed and added from the host side, the refcnt will be decreased by one, which may cause page fault when unloading xdp program. Fixes: 351e1581395f ("hv_netvsc: Add XDP support") Signed-off-by: Haiyang Zhang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-07Merge branch 'taprio-Some-fixes'David S. Miller1-35/+57
Vinicius Costa Gomes says: ==================== taprio: Some fixes Changes from v3: - Replaced ENOTSUPP error code with EOPNOTSUPP (Jakub Kicinski); - Added the missing policy validation for the flags netlink argument (Jakub Kicinski); - Fixed the destroy() flow to also destroy the priority to traffic class mapping (David Miller); - Fixed dropping packets when taprio offloading is used together with ETF offloading (more on this below); Changes from v2: - Squashed commits 2/3 and 3/3 into a single one (I think a single commit is going to be easier to review); - Removed an "improvement" that was causing changes in user visible behavior; Changes from v1: - Fixed ignoring the 'flags' argument when adding a new instance (Vladimir Oltean); - Changed the order of commits; Updated cover letter: One bit that might need some attention is the fix for not dropping all packets when taprio and ETF offloading are used, patch 5/5. The behavior when the fix is applied is that packets that have a 'txtime' that would fall outside of their transmission window are now dropped by taprio. The question that might be raised is: should taprio be responsible for dropping these packets, or should it be handled lower in the stack? My opinion is: taprio has all the information, and it's able to give feeback to the user. Lower in the stack, those packets might go into the void, and the only feedback could be a hard to find counter increasing. Patch 1/5: Reported by Po Liu, is more of a improvement of usability for drivers implementing offloading features, now they can rely on the value of dev->num_tc, instead of going through some hops to get this value. Patch 2/5: Use 'q->flags' as the source of truth for the offloading flags. Tries to solidify the current behavior, while avoiding going into invalid states, one of which was causing a "rcu stall" (more information in the commit message). Patch 3/5: Adds the missing netlink attribute validation for TCA_TAPRIO_ATTR_FLAGS. Patch 4/5: Replaces the usage of netdev_set_num_tc() with netdev_reset_tc() in taprio_destroy(), taprio_destroy() is called when applying a configuration fails, making sure that the device traffic class configuration goes back to the default state. @Vladimir: If possible, I would appreciate your Ack on patch 2/5. I have been looking at this code for so long that I might have missed something obvious (and my growing dislike for the word 'flags' may be affecting my judgement :-). ==================== Signed-off-by: David S. Miller <[email protected]>
2020-02-07taprio: Fix dropping packets when using taprio + ETF offloadingVinicius Costa Gomes1-2/+2
When using taprio offloading together with ETF offloading, configured like this, for example: $ tc qdisc replace dev $IFACE parent root handle 100 taprio \ num_tc 4 \ map 2 2 1 0 3 2 2 2 2 2 2 2 2 2 2 2 \ queues 1@0 1@1 1@2 1@3 \ base-time $BASE_TIME \ sched-entry S 01 1000000 \ sched-entry S 0e 1000000 \ flags 0x2 $ tc qdisc replace dev $IFACE parent 100:1 etf \ offload delta 300000 clockid CLOCK_TAI During enqueue, it works out that the verification added for the "txtime" assisted mode is run when using taprio + ETF offloading, the only thing missing is initializing the 'next_txtime' of all the cycle entries. (if we don't set 'next_txtime' all packets from SO_TXTIME sockets are dropped) Fixes: 4cfd5779bd6e ("taprio: Add support for txtime-assist mode") Signed-off-by: Vinicius Costa Gomes <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-07taprio: Use taprio_reset_tc() to reset Traffic Classes configurationVinicius Costa Gomes1-1/+1
When destroying the current taprio instance, which can happen when the creation of one fails, we should reset the traffic class configuration back to the default state. netdev_reset_tc() is a better way because in addition to setting the number of traffic classes to zero, it also resets the priority to traffic classes mapping to the default value. Fixes: 5a781ccbd19e ("tc: Add support for configuring the taprio scheduler") Signed-off-by: Vinicius Costa Gomes <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-07taprio: Add missing policy validation for flagsVinicius Costa Gomes1-0/+1
netlink policy validation for the 'flags' argument was missing. Fixes: 4cfd5779bd6e ("taprio: Add support for txtime-assist mode") Signed-off-by: Vinicius Costa Gomes <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-07taprio: Fix still allowing changing the flags during runtimeVinicius Costa Gomes1-20/+41
Because 'q->flags' starts as zero, and zero is a valid value, we aren't able to detect the transition from zero to something else during "runtime". The solution is to initialize 'q->flags' with an invalid value, so we can detect if 'q->flags' was set by the user or not. To better solidify the behavior, 'flags' handling is moved to a separate function. The behavior is: - 'flags' if unspecified by the user, is assumed to be zero; - 'flags' cannot change during "runtime" (i.e. a change() request cannot modify it); With this new function we can remove taprio_flags, which should reduce the risk of future accidents. Allowing flags to be changed was causing the following RCU stall: [ 1730.558249] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: [ 1730.558258] rcu: 6-...0: (190 ticks this GP) idle=922/0/0x1 softirq=25580/25582 fqs=16250 [ 1730.558264] (detected by 2, t=65002 jiffies, g=33017, q=81) [ 1730.558269] Sending NMI from CPU 2 to CPUs 6: [ 1730.559277] NMI backtrace for cpu 6 [ 1730.559277] CPU: 6 PID: 0 Comm: swapper/6 Tainted: G E 5.5.0-rc6+ #35 [ 1730.559278] Hardware name: Gigabyte Technology Co., Ltd. Z390 AORUS ULTRA/Z390 AORUS ULTRA-CF, BIOS F7 03/14/2019 [ 1730.559278] RIP: 0010:__hrtimer_run_queues+0xe2/0x440 [ 1730.559278] Code: 48 8b 43 28 4c 89 ff 48 8b 75 c0 48 89 45 c8 e8 f4 bb 7c 00 0f 1f 44 00 00 65 8b 05 40 31 f0 68 89 c0 48 0f a3 05 3e 5c 25 01 <0f> 82 fc 01 00 00 48 8b 45 c8 48 89 df ff d0 89 45 c8 0f 1f 44 00 [ 1730.559279] RSP: 0018:ffff9970802d8f10 EFLAGS: 00000083 [ 1730.559279] RAX: 0000000000000006 RBX: ffff8b31645bff38 RCX: 0000000000000000 [ 1730.559280] RDX: 0000000000000000 RSI: ffffffff9710f2ec RDI: ffffffff978daf0e [ 1730.559280] RBP: ffff9970802d8f68 R08: 0000000000000000 R09: 0000000000000000 [ 1730.559280] R10: 0000018336d7944e R11: 0000000000000001 R12: ffff8b316e39f9c0 [ 1730.559281] R13: ffff8b316e39f940 R14: ffff8b316e39f998 R15: ffff8b316e39f7c0 [ 1730.559281] FS: 0000000000000000(0000) GS:ffff8b316e380000(0000) knlGS:0000000000000000 [ 1730.559281] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1730.559281] CR2: 00007f1105303760 CR3: 0000000227210005 CR4: 00000000003606e0 [ 1730.559282] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1730.559282] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1730.559282] Call Trace: [ 1730.559282] <IRQ> [ 1730.559283] ? taprio_dequeue_soft+0x2d0/0x2d0 [sch_taprio] [ 1730.559283] hrtimer_interrupt+0x104/0x220 [ 1730.559283] ? irqtime_account_irq+0x34/0xa0 [ 1730.559283] smp_apic_timer_interrupt+0x6d/0x230 [ 1730.559284] apic_timer_interrupt+0xf/0x20 [ 1730.559284] </IRQ> [ 1730.559284] RIP: 0010:cpu_idle_poll+0x35/0x1a0 [ 1730.559285] Code: 88 82 ff 65 44 8b 25 12 7d 73 68 0f 1f 44 00 00 e8 90 c3 89 ff fb 65 48 8b 1c 25 c0 7e 01 00 48 8b 03 a8 08 74 0b eb 1c f3 90 <48> 8b 03 a8 08 75 13 8b 05 be a8 a8 00 85 c0 75 ed e8 75 48 84 ff [ 1730.559285] RSP: 0018:ffff997080137ea8 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff13 [ 1730.559285] RAX: 0000000000000001 RBX: ffff8b316bc3c580 RCX: 0000000000000000 [ 1730.559286] RDX: 0000000000000001 RSI: 000000002819aad9 RDI: ffffffff978da730 [ 1730.559286] RBP: ffff997080137ec0 R08: 0000018324a6d387 R09: 0000000000000000 [ 1730.559286] R10: 0000000000000400 R11: 0000000000000001 R12: 0000000000000006 [ 1730.559286] R13: ffff8b316bc3c580 R14: 0000000000000000 R15: 0000000000000000 [ 1730.559287] ? cpu_idle_poll+0x20/0x1a0 [ 1730.559287] ? cpu_idle_poll+0x20/0x1a0 [ 1730.559287] do_idle+0x4d/0x1f0 [ 1730.559287] ? complete+0x44/0x50 [ 1730.559288] cpu_startup_entry+0x1b/0x20 [ 1730.559288] start_secondary+0x142/0x180 [ 1730.559288] secondary_startup_64+0xb6/0xc0 [ 1776.686313] nvme nvme0: I/O 96 QID 1 timeout, completion polled Fixes: 4cfd5779bd6e ("taprio: Add support for txtime-assist mode") Signed-off-by: Vinicius Costa Gomes <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-07taprio: Fix enabling offload with wrong number of traffic classesVinicius Costa Gomes1-13/+13
If the driver implementing taprio offloading depends on the value of the network device number of traffic classes (dev->num_tc) for whatever reason, it was going to receive the value zero. The value was only set after the offloading function is called. So, moving setting the number of traffic classes to before the offloading function is called fixes this issue. This is safe because this only happens when taprio is instantiated (we don't allow this configuration to be changed without first removing taprio). Fixes: 9c66d1564676 ("taprio: Add support for hardware offloading") Reported-by: Po Liu <[email protected]> Signed-off-by: Vinicius Costa Gomes <[email protected]> Acked-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-07net: dsa: bcm_sf2: Only 7278 supports 2Gb/sec IMP portFlorian Fainelli1-1/+3
The 7445 switch clocking profiles do not allow us to run the IMP port at 2Gb/sec in a way that it is reliable and consistent. Make sure that the setting is only applied to the 7278 family. Fixes: 8f1880cbe8d0 ("net: dsa: bcm_sf2: Configure IMP port for 2Gb/sec") Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.