summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-02-22Merge tag 'kbuild-fixes-v5.0-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull more Kbuild fixes from Masahiro Yamada: - fix scripts/kallsyms.c to correctly check too long symbol names - fix sh build error for the combination of CONFIG_OF_EARLY_FLATTREE=y and CONFIG_USE_BUILTIN_DTB=n * tag 'kbuild-fixes-v5.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: sh: fix build error for invisible CONFIG_BUILTIN_DTB_SOURCE kallsyms: Handle too long symbols in kallsyms.c
2019-02-22Merge branch 'udp-a-few-fixes'David S. Miller
Paolo Abeni says: ==================== udp: a few fixes This series includes some UDP-related fixlet. All this stuff has been pointed out by the sparse tool. The first two patches are just annotation related, while the last 2 cover some very unlikely races. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22udp: fix possible user after free in error handlerPaolo Abeni
Similar to the previous commit, this addresses the same issue for ipv4: use a single fetch operation and use the correct rcu annotation. Fixes: e7cc082455cb ("udp: Support for error handlers of tunnels with arbitrary destination port") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Acked-by: Stefano Brivio <sbrivio@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22udpv6: fix possible user after free in error handlerPaolo Abeni
Before derefencing the encap pointer, commit e7cc082455cb ("udp: Support for error handlers of tunnels with arbitrary destination port") checks for a NULL value, but the two fetch operation can race with removal. Fix the above using a single access. Also fix a couple of type annotations, to make sparse happy. Fixes: e7cc082455cb ("udp: Support for error handlers of tunnels with arbitrary destination port") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Acked-by: Stefano Brivio <sbrivio@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22fou6: fix proto error handler argument typePaolo Abeni
Last argument of gue6_err_proto_handler() has a wrong type annotation, fix it and make sparse happy again. Fixes: b8a51b38e4d4 ("fou, fou6: ICMP error handlers for FoU and GUE") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Acked-by: Stefano Brivio <sbrivio@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22udpv6: add the required annotation to mib typePaolo Abeni
In commit 029a37434880 ("udp6: cleanup stats accounting in recvmsg()") I forgot to add the percpu annotation for the mib pointer. Add it, and make sparse happy. Fixes: 029a37434880 ("udp6: cleanup stats accounting in recvmsg()") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22mdio_bus: Fix use-after-free on device_register failsYueHaibing
KASAN has found use-after-free in fixed_mdio_bus_init, commit 0c692d07842a ("drivers/net/phy/mdio_bus.c: call put_device on device_register() failure") call put_device() while device_register() fails,give up the last reference to the device and allow mdiobus_release to be executed ,kfreeing the bus. However in most drives, mdiobus_free be called to free the bus while mdiobus_register fails. use-after-free occurs when access bus again, this patch revert it to let mdiobus_free free the bus. KASAN report details as below: BUG: KASAN: use-after-free in mdiobus_free+0x85/0x90 drivers/net/phy/mdio_bus.c:482 Read of size 4 at addr ffff8881dc824d78 by task syz-executor.0/3524 CPU: 1 PID: 3524 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xfa/0x1ce lib/dump_stack.c:113 print_address_description+0x65/0x270 mm/kasan/report.c:187 kasan_report+0x149/0x18d mm/kasan/report.c:317 mdiobus_free+0x85/0x90 drivers/net/phy/mdio_bus.c:482 fixed_mdio_bus_init+0x283/0x1000 [fixed_phy] ? 0xffffffffc0e40000 ? 0xffffffffc0e40000 ? 0xffffffffc0e40000 do_one_initcall+0xfa/0x5ca init/main.c:887 do_init_module+0x204/0x5f6 kernel/module.c:3460 load_module+0x66b2/0x8570 kernel/module.c:3808 __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902 do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x462e99 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 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 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6215c19c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99 RDX: 0000000000000000 RSI: 0000000020000080 RDI: 0000000000000003 RBP: 00007f6215c19c70 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6215c1a6bc R13: 00000000004bcefb R14: 00000000006f7030 R15: 0000000000000004 Allocated by task 3524: set_track mm/kasan/common.c:85 [inline] __kasan_kmalloc.constprop.3+0xa0/0xd0 mm/kasan/common.c:496 kmalloc include/linux/slab.h:545 [inline] kzalloc include/linux/slab.h:740 [inline] mdiobus_alloc_size+0x54/0x1b0 drivers/net/phy/mdio_bus.c:143 fixed_mdio_bus_init+0x163/0x1000 [fixed_phy] do_one_initcall+0xfa/0x5ca init/main.c:887 do_init_module+0x204/0x5f6 kernel/module.c:3460 load_module+0x66b2/0x8570 kernel/module.c:3808 __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902 do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 3524: set_track mm/kasan/common.c:85 [inline] __kasan_slab_free+0x130/0x180 mm/kasan/common.c:458 slab_free_hook mm/slub.c:1409 [inline] slab_free_freelist_hook mm/slub.c:1436 [inline] slab_free mm/slub.c:2986 [inline] kfree+0xe1/0x270 mm/slub.c:3938 device_release+0x78/0x200 drivers/base/core.c:919 kobject_cleanup lib/kobject.c:662 [inline] kobject_release lib/kobject.c:691 [inline] kref_put include/linux/kref.h:67 [inline] kobject_put+0x146/0x240 lib/kobject.c:708 put_device+0x1c/0x30 drivers/base/core.c:2060 __mdiobus_register+0x483/0x560 drivers/net/phy/mdio_bus.c:382 fixed_mdio_bus_init+0x26b/0x1000 [fixed_phy] do_one_initcall+0xfa/0x5ca init/main.c:887 do_init_module+0x204/0x5f6 kernel/module.c:3460 load_module+0x66b2/0x8570 kernel/module.c:3808 __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902 do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff8881dc824c80 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 248 bytes inside of 2048-byte region [ffff8881dc824c80, ffff8881dc825480) The buggy address belongs to the page: page:ffffea0007720800 count:1 mapcount:0 mapping:ffff8881f6c02800 index:0x0 compound_mapcount: 0 flags: 0x2fffc0000010200(slab|head) raw: 02fffc0000010200 0000000000000000 0000000500000001 ffff8881f6c02800 raw: 0000000000000000 00000000800f000f 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881dc824c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8881dc824c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8881dc824d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881dc824d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881dc824e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Fixes: 0c692d07842a ("drivers/net/phy/mdio_bus.c: call put_device on device_register() failure") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22Merge branch 'net-phy-at803x-Update-delays-for-RGMII-modes'David S. Miller
Vinod Koul says: ==================== net: phy: at803x: Update delays for RGMII modes Peter[1] reported that patch cd28d1d6e52e: ("net: phy: at803x: Disable phy delay for RGMII mode") caused regression on am335x-evmsk board. This board expects the Phy delay to be enabled but specified RGMII mode which refers to delays being disabled. So fix this by disabling delay only for RGMII mode and enable for RGMII_ID and RGMII_TXID/RXID modes. While at it, as pointed by Dave, don't inline the helpers. [1]: https://www.spinics.net/lists/netdev/msg550749.html Changes in v4: - fix log & comments nbased on Marc's feedback ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22net: phy: at803x: disable delay only for RGMII modeVinod Koul
Per "Documentation/devicetree/bindings/net/ethernet.txt" RGMII mode should not have delay in PHY whereas RGMII_ID and RGMII_RXID/RGMII_TXID can have delay in PHY. So disable the delay only for RGMII mode and enable for other modes. Also treat the default case as disabled delays. Fixes: cd28d1d6e52e: ("net: phy: at803x: Disable phy delay for RGMII mode") Reported-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Niklas Cassel <niklas.cassel@linaro.org> Tested-by: Peter Ujfalusi <peter.ujflausi@ti.com> Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22net: phy: at803x: don't inline helpersVinod Koul
Some helpers were declared with the "inline" function specifier. It is preferable to let the compiler pick the right optimizations, so drop the specifier for at803x_disable_rx_delay() and at803x_disable_tx_delay() Reviewed-by: Niklas Cassel <niklas.cassel@linaro.org> Tested-by: Peter Ujfalusi <peter.ujflausi@ti.com> Reviewed-by: Marc Gonzalez <marc.w.gonzalez@free.fr> Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22net_sched: initialize net pointer inside tcf_exts_init()Cong Wang
For tcindex filter, it is too late to initialize the net pointer in tcf_exts_validate(), as tcf_exts_get_net() requires a non-NULL net pointer. We can just move its initialization into tcf_exts_init(), which just requires an additional parameter. This makes the code in tcindex_alloc_perfect_hash() prettier. Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Jiri Pirko <jiri@resnulli.us> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22net: Set rtm_table to RT_TABLE_COMPAT for ipv6 for tables > 255Kalash Nainwal
Set rtm_table to RT_TABLE_COMPAT for ipv6 for tables > 255 to keep legacy software happy. This is similar to what was done for ipv4 in commit 709772e6e065 ("net: Fix routing tables with id > 255 for legacy software"). Signed-off-by: Kalash Nainwal <kalash@arista.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22Merge branch 'bnxt_en-firmware-message-delay-fixes'David S. Miller
Michael Chan says: ==================== bnxt_en: firmware message delay fixes. We were seeing some intermittent firmware message timeouts in our lab and these 2 small patches fix them. Please apply to stable as well. Thanks. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22bnxt_en: Wait longer for the firmware message response to complete.Michael Chan
The code waits up to 20 usec for the firmware response to complete once we've seen the valid response header in the buffer. It turns out that in some scenarios, this wait time is not long enough. Extend it to 150 usec and use usleep_range() instead of udelay(). Fixes: 9751e8e71487 ("bnxt_en: reduce timeout on initial HWRM calls") Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22bnxt_en: Fix typo in firmware message timeout logic.Michael Chan
The logic that polls for the firmware message response uses a shorter sleep interval for the first few passes. But there was a typo so it was using the wrong counter (larger counter) for these short sleep passes. The result is a slightly shorter timeout period for these firmware messages than intended. Fix it by using the proper counter. Fixes: 9751e8e71487 ("bnxt_en: reduce timeout on initial HWRM calls") Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-23Merge branch 'bpf-nfp-codegen-fixes'Daniel Borkmann
Jiong Wang says: ==================== Code-gen for BPF_ALU | BPF_XOR | BPF_K is wrong when imm is -1, also high 32-bit of 64-bit register should always be cleared. This set fixed both bugs. ==================== Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-02-23nfp: bpf: fix ALU32 high bits clearance bugJiong Wang
NFP BPF JIT compiler is doing a couple of small optimizations when jitting ALU imm instructions, some of these optimizations could save code-gen, for example: A & -1 = A A | 0 = A A ^ 0 = A However, for ALU32, high 32-bit of the 64-bit register should still be cleared according to ISA semantics. Fixes: cd7df56ed3e6 ("nfp: add BPF to NFP code translator") Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Jiong Wang <jiong.wang@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-02-23nfp: bpf: fix code-gen bug on BPF_ALU | BPF_XOR | BPF_KJiong Wang
The intended optimization should be A ^ 0 = A, not A ^ -1 = A. Fixes: cd7df56ed3e6 ("nfp: add BPF to NFP code translator") Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Jiong Wang <jiong.wang@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-02-22MAINTAINERS: Update Ampere email addressKhuong Dinh
This patch updates all APM email addresses to Ampere new email addresses. Signed-off-by: Khuong Dinh <khuong@os.amperecomputing.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-02-22net/mlx5: Support ndo bridge_setlink and getlinkHuy Nguyen
Allow enabling VEPA mode on the HCA's port in legacy devlink mode. Example: bridge link set dev ens1f0 hwmode vepa will turn on VEPA mode on the netdev ens1f0. Signed-off-by: Huy Nguyen <huyn@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2019-02-22net/mlx5: E-Switch, Add support for VEPA in legacy mode.Huy Nguyen
In Virtual Ethernet Port Aggregator (VEPA) mode, the packet skips the system internal virtual switch and forwards to external network switch. In Mellanox HCA case, the virtual switch is the HCA's Eswitch. To support this, an new FDB flow table are created with level 0 and linked to the existing FDB flow table in legacy mode. By default, VEPA is turned off and this FDB flow table is empty. When VEPA is turned on, two rules are created. One rule to forward on uplink vport traffic to the legacy FDB. The other rule forward all other traffic to uplink vport. Other design alternatives were not chosen as explained below: 1. Create a forward rule in ACL flow table (most efficient design). This approach is the not chosen because firmware does not support forward rule to uplink vport (0xffff) for ACL flow table. 2. Add additional source port criteria in all the FDB rules to make the FDB rules to be received rules only. This approach is not chosen because it is not efficient as there can many rules in the FDB and VEPA mode cannot be controlled per vport. 3. Add a highest prioirty flow group in the existing legacy FDB Flow Table instead of a new flow table. This approoach does not work because the new flow group has the same match criteria as the promiscuous flow group and mlx5_add_flow_rules does not allow specifying flow group. Signed-off-by: Huy Nguyen <huyn@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2019-02-22net/mlx5e: Fix mlx5e_tx_reporter_create return valueEran Ben Elisha
If reporter is ERR_PTR or NULL, error code shall be returned. At all other cases it shall return success. Fix that. Fixes: de8650a82071 ("net/mlx5e: Add tx reporter support") Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2019-02-22net/mlx5e: Fix return status of TX reporter timeout recoverEran Ben Elisha
In case of lost interrupt recover, we shall return success. Fix that. Fixes: 7d91126b1aea ("net/mlx5e: Add tx timeout support for mlx5e tx reporter") Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com> Reported-by: Maria Pasechnik <mariap@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2019-02-22net/mlx5e: Re-add support for TX timeout when TX reporter is not validEran Ben Elisha
When TX reporter was introduced, it took ownership over TX timeout error handling. this introduced a regression in case TX reporter is not valid (NET_DEVLINK is not set, or devlink_health_reporter_create failure). Fix mlx5e_tx_reporter_timeout function so it can be called at all times. In addition, remove a warning print that indicates that a TX timeout won't be handled in case of no valid TX reporter. Fixes: 7d91126b1aea ("net/mlx5e: Add tx timeout support for mlx5e tx reporter") Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2019-02-22net/mlx5e: Fix warn print in case of TX reporter creation failureEran Ben Elisha
Print warning message in case of TX reporter creation failure, only if the return value is ERR_PTR type. NULL pointer return indicates that NET_DEVLINK is not set, and the warning print can be skipped. Fixes: de8650a82071 ("net/mlx5e: Add tx reporter support") Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2019-02-22net/mlx5e: Fix GRE key by controlling port tunnel entropy calculationEli Britstein
Flow entropy is calculated on the inner packet headers and used for flow distribution in processing, routing etc. For GRE-type encapsulations the entropy value is placed in the eight LSB of the key field in the GRE header as defined in NVGRE RFC 7637. For UDP based encapsulations the entropy value is placed in the source port of the UDP header. The hardware may support entropy calculation specifically for GRE and for all tunneling protocols. With commit df2ef3bff193 ("net/mlx5e: Add GRE protocol offloading") GRE is offloaded, but the hardware is configured by default to calculate flow entropy so packets transmitted on the wire have a wrong key. To support UDP based tunnels (i.e VXLAN), GRE (i.e. no flow entropy) and NVGRE (i.e. with flow entropy) the hardware behaviour must be controlled by the driver. Ensure port entropy calculation is enabled for offloaded VXLAN tunnels and disable port entropy calculation in the presence of offloaded GRE tunnels by monitoring the presence of entropy enabling tunnels (i.e VXLAN) and entropy disabing tunnels (i.e GRE). Fixes: df2ef3bff193 ("net/mlx5e: Add GRE protocol offloading") Signed-off-by: Eli Britstein <elibr@mellanox.com> Reviewed-by: Oz Shlomo <ozsh@mellanox.com> Reviewed-by: Roi Dayan <roid@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2019-02-22net/mlx5: Introduce tunnel entropy control in PCMR registerEli Britstein
When using the device packet encapsulation offload, the device calculates an entropy value, representing the inner packet headers. The entropy field is placed inside the outer packet headers. For UDP-type encapsulations, the entropy is placed in the source port field of the UDP header. For GRE-type encapsulations, the entropy is placed in the 8 LSB of the key field in the GRE header. If the device does not recognize the encapsulation type, the entropy is not placed in the packet. Entropy setting can be controlled using PCMR register. if encapsulation offload is not used force_entropy_cap should be set to 0x0. Entropy setting is enabled/disabled using entropy_calc, and could be additionally enabled/disabled for GRE encapsulation by entropy_gre_calc. As a pre-step to automatically control the tunnel entropy, introduce the entropy fields in the PCMR register with no functional change. Signed-off-by: Eli Britstein <elibr@mellanox.com> Reviewed-by: Oz Shlomo <ozsh@mellanox.com> Reviewed-by: Roi Dayan <roid@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2019-02-22net/mlx5: Use read-modify-write when changing PCMR register valuesEli Britstein
Currently changing a PCMR field is done by setting the field in a zeroed buffer, zeroing other unrelated fields. Fix this behaviour by modifying only the required field after first reading the current register values, as a pre-step towards using more fields in PCMR register. Signed-off-by: Eli Britstein <elibr@mellanox.com> Reviewed-by: Oz Shlomo <ozsh@mellanox.com> Reviewed-by: Roi Dayan <roid@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2019-02-22Merge tag 'omap-for-v5.1/cpsw-signed' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/late One change to deprecate old CPSW Ethernet PHY mode selection driver With the device tree changes configuring CPSW with a proper PHY driver, we want to deprecate the old driver to avoid new users for it. Note that this driver is based on the related dts changes. * tag 'omap-for-v5.1/cpsw-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: net: ethernet: ti: cpsw: deprecate cpsw-phy-sel driver Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-02-22ARM: defconfig: integrator: Switch to DRMLinus Walleij
This switches the ARM Integrator to use the new PL11x DRM driver. We need CMA enabled to get coherent allocations at all times. The dumb VGA DAC bridge is needed for the VGA output on the reference designs, and backlight is needed when using an external display. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-02-22Merge tag 'wireless-drivers-next-for-davem-2019-02-22' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 5.1 Most likely the last set of patches for 5.1. WPA3 support to ath10k and qtnfmac. FTM support to iwlwifi and ath10k. And of course other new features and bugfixes. wireless-drivers was merged due to dependency in mt76. Major changes: iwlwifi * HE radiotap * FTM (Fine Timing Measurement) initiator and responder implementation * bump supported firmware API to 46 * VHT extended NSS support * new PCI IDs for 9260 and 22000 series ath10k * change QMI interface to support the new (and backwards incompatible) interface from HL3.1 and used in recent HL2.0 branch firmware releases * support WPA3 with WCN3990 * support for mac80211 airtime fairness based on transmit rate estimation, the firmware needs to support WMI_SERVICE_PEER_STATS to enable this * report transmit airtime to mac80211 with firmwares having WMI_SERVICE_REPORT_AIRTIME feature, this to have more accurate airtime fairness based on real transmit time (instead of just estimated from transmit rate) * support Fine Timing Measurement (FTM) responder role * add dynamic VLAN support with firmware having WMI_SERVICE_PER_PACKET_SW_ENCRYPT * switch to use SPDX license identifiers ath * add new country codes for US brcmfmac * support monitor frames with the hardware/ucode header qtnfmac * enable WPA3 SAE and OWE support mt76 * beacon support for USB devices (mesh+ad-hoc only) rtlwifi * convert to use SPDX license identifiers libertas_tf * get the MAC address before registering the device ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22Merge branch 'AF_PACKET-transport_offset-fix'David S. Miller
Maxim Mikityanskiy says: ==================== AF_PACKET transport_offset fix This patch series contains the implementation of the RFC that was posted on this mailing list previously: https://www.spinics.net/lists/netdev/msg541709.html It fixes having incorrect skb->transport_header values in cases when dissect fails. Having correct values set by the kernel fixes mlx5 operation and allows to remove some unnecessary code flows in mlx5. v2 changes: - Rebase against the fresh net-next. - Don't return bool from skb_probe_transport_header (and don't rename the function). - WARN_ON_ONCE and error path in case of GSO without the L4 header. ==================== Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22net/mlx5e: Trust kernel regarding transport offsetMaxim Mikityanskiy
After AF_PACKET is fixed to calculate the transport header offset correctly, trust the value set by the kernel. If the offset wasn't set, it means there is no transport header in the packet. Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com> Reviewed-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22net/mlx5e: Remove the wrong assumption about transport offsetMaxim Mikityanskiy
skb_transport_offset() == 0 is not a special value. The only special value is when skb->transport_header is ~0U, and it's checked by skb_transport_header_was_set(). Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com> Reviewed-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22net/packet: Remove redundant skb->protocol setMaxim Mikityanskiy
c72219b75f introduced tpacket_set_protocol that parses the Ethernet L2 header and sets skb->protocol if it's unset. It is no longer needed since the introduction of packet_parse_headers. In case of SOCK_RAW and unset skb->protocol, packet_parse_headers asks the driver to tell the protocol number, and it's implemented for all Ethernet devices. As the old function supported only Ethernet, no functionality is lost. Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22net/packet: Ask driver for protocol if not provided by userMaxim Mikityanskiy
If a socket was created with socket(AF_PACKET, SOCK_RAW, 0), the protocol number is unavailable. Try to ask the driver to extract it from the L2 header in order for skb_try_probe_transport_header to succeed. Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22net/ethernet: Add parse_protocol header_ops supportMaxim Mikityanskiy
The previous commit introduced parse_protocol callback which should extract the protocol number from the L2 header. Make all Ethernet devices support it. Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22net: Introduce parse_protocol header_ops callbackMaxim Mikityanskiy
Introduce a new optional header_ops callback called parse_protocol and a wrapper function dev_parse_header_protocol, similar to dev_parse_header. The new callback's purpose is to extract the protocol number from the L2 header, the format of which is known to the driver, but not to the upper layers of the stack. Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22net: Don't set transport offset to invalid valueMaxim Mikityanskiy
If the socket was created with socket(AF_PACKET, SOCK_RAW, 0), skb->protocol will be unset, __skb_flow_dissect() will fail, and skb_probe_transport_header() will fall back to the offset_hint, making the resulting skb_transport_offset incorrect. If, however, there is no transport header in the packet, transport_header shouldn't be set to an arbitrary value. Fix it by leaving the transport offset unset if it couldn't be found, to be explicit rather than to fill it with some wrong value. It changes the behavior, but if some code relied on the old behavior, it would be broken anyway, as the old one is incorrect. Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22asm-generic/page.h: fix typo in #error text requiring a real asm/page.hMike Rapoport
Replace "need to prove a real asm/page.h" with "need to provide a real asm/page.h" Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-02-22Merge tag 'mac80211-next-for-davem-2019-02-22' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== This time we have, of note: * the massive patch series for multi-BSSID support, I ended up applying that through a side branch to record some details * CSA improvements * HE (802.11ax) updates to Draft 3.3 * strongly typed element iteration/etc. to make such code more readable - this came up in particular in multi-BSSID * rhashtable conversion patches from Herbert Along, as usual, with various fixes and improvements. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22Merge tag 'mac80211-for-davem-2019-02-22' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 Johannes Berg says: ==================== Three more fixes: * mac80211 mesh code wasn't allocating SKB tailroom properly in some cases * tx_sk_pacing_shift should be 7 for better performance * mac80211_hwsim wasn't propagating genlmsg_reply() errors ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22Documentation: networking: switchdev: Update port parent ID sectionFlorian Fainelli
Update the section about switchdev drivers having to implement a switchdev_port_attr_get() function to return SWITCHDEV_ATTR_ID_PORT_PARENT_ID since that is no longer valid after commit bccb30254a4a ("net: Get rid of SWITCHDEV_ATTR_ID_PORT_PARENT_ID"). Fixes: bccb30254a4a ("net: Get rid of SWITCHDEV_ATTR_ID_PORT_PARENT_ID") Reviewed-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22Merge branch 'dsa-vlan'David S. Miller
Florian Fainelli says: ==================== net: dsa: VLAN devices w/ filtering This patch series supports having VLAN devices on top of DSA/switch ports while the switch has VLAN filtering globally turned on (as is the case with Broadcom switches). Whether the switch does global or per-port VLAN filtering, having VLAN entries for these VLAN devices is beneficial. We take care of a few possibly problematic cases: - adding a VLAN device while there is an existing VLAN entry created by a VLAN aware bridge. The entire bridge's VLAN database and not just the specific bridge port is being checked to be safe and conserative - adding a bridge VLAN entry when there is an existing VLAN device created is also not possible because that would lead to the bridge being able to manipulate the VLAN device's VID/attributes under its feet - enslaving a VLAN device into a VLAN aware bridge since that duplicates functionality already offered by the VLAN aware bridge Here are the different test cases that were run to exercise this: ip addr flush dev gphy ip link add dev br0 type bridge echo 1 > /sys/class/net/br0/bridge/vlan_filtering ip link set dev gphy master br0 udhcpc -i br0 vconfig add rgmii_1 100 ifconfig rgmii_1.100 192.168.100.10 ping -c 2 192.168.100.1 vconfig add br0 42 bridge vlan add vid 42 dev gphy bridge vlan add vid 42 dev br0 self ifconfig br0.42 192.168.42.2 ping -c 2 192.168.42.1 ip link del rgmii_1.100 vconfig add rgmii_1 100 ifconfig rgmii_1.100 192.168.100.10 ping -c 2 192.168.100.1 echo 0 > /sys/class/net/br0/bridge/vlan_filtering ping -c 2 192.168.100.1 ip link del rgmii_1.100 echo 1 > /sys/class/net/br0/bridge/vlan_filtering vconfig add rgmii_1 100 brctl addif br0 rgmii_1 bridge vlan add vid 100 dev rgmii_1 vconfig rem rgmii_1.100 bridge vlan add vid 100 dev rgmii_1 vconfig add rgmii_1 100 bridge vlan del vid 100 dev rgmii_1 vconfig add rgmii_1 100 brctl addif br0 rgmii_1.100 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementationFlorian Fainelli
In order to properly support VLAN filtering being enabled/disabled on a bridge, while having other ports being non bridge port members, we need to support the ndo_vlan_rx_{add,kill}_vid callbacks in order to make sure the non-bridge ports can continue receiving VLAN tags, even when the switch is globally configured to do ingress/egress VID checking. Since we can call dsa_port_vlan_{add,del} with a bridge_dev pointer NULL, we now need to check that in these two functions. We specifically deal with two possibly problematic cases: - creating a bridge VLAN entry while there is an existing VLAN device claiming that same VID - creating a VLAN device while there is an existing bridge VLAN entry with that VID Those are both resolved with returning -EBUSY back to user-space. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22net: dsa: Deny enslaving VLAN devices into VLAN aware bridgeFlorian Fainelli
VLAN devices on top of a DSA network device which is already part of a bridge and with said bridge being VLAN aware should not be allowed to be enslaved into that bridge. For one, this duplicates functionality offered by the VLAN aware bridge which supports tagged and untagged VLAN frames processing and it would make things needlessly complex to e.g.: propagate FDB/MDB accordingly. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22perf data: Add global path holderJiri Olsa
Add a 'path' member to 'struct perf_data'. It will keep the configured path for the data (const char *). The path in struct perf_data_file is now dynamically allocated (duped) from it. This scheme is useful/used in following patches where struct perf_data::path holds the 'configure' directory path and struct perf_data_file::path holds the allocated path for specific files. Also it actually makes the code little simpler. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Alexey Budankov <alexey.budankov@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/r/20190221094145.9151-3-jolsa@kernel.org [ Fixup data-convert-bt.c missing conversion ] Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-02-22perf data: Move size to struct perf_data_fileJiri Olsa
We are about to add support for multiple files, so we need each file to keep its size. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Alexey Budankov <alexey.budankov@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/r/20190221094145.9151-2-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-02-22perf, pt, coresight: Fix address filters for vmas with non-zero offsetAlexander Shishkin
Currently, the address range calculation for file-based filters works as long as the vma that maps the matching part of the object file starts from offset zero into the file (vm_pgoff==0). Otherwise, the resulting filter range would be off by vm_pgoff pages. Another related problem is that in case of a partially matching vma, that is, a vma that matches part of a filter region, the filter range size wouldn't be adjusted. Fix the arithmetics around address filter range calculations, taking into account vma offset, so that the entire calculation is done before the filter configuration is passed to the PMU drivers instead of having those drivers do the final bit of arithmetics. Based on the patch by Adrian Hunter <adrian.hunter.intel.com>. Reported-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Tested-by: Mathieu Poirier <mathieu.poirier@linaro.org> Acked-by: Peter Zijlstra <peterz@infradead.org> Cc: Jiri Olsa <jolsa@redhat.com> Fixes: 375637bc5249 ("perf/core: Introduce address range filtering") Link: http://lkml.kernel.org/r/20190215115655.63469-3-alexander.shishkin@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-02-22perf: Copy parent's address filter offsets on cloneAlexander Shishkin
When a child event is allocated in the inherit_event() path, the VMA based filter offsets are not copied from the parent, even though the address space mapping of the new task remains the same, which leads to no trace for the new task until exec. Reported-by: Mansour Alharthi <malharthi9@gatech.edu> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Tested-by: Mathieu Poirier <mathieu.poirier@linaro.org> Acked-by: Peter Zijlstra <peterz@infradead.org> Cc: Jiri Olsa <jolsa@redhat.com> Fixes: 375637bc5249 ("perf/core: Introduce address range filtering") Link: http://lkml.kernel.org/r/20190215115655.63469-2-alexander.shishkin@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>