- 20 Apr, 2018 20 commits
-
-
Eric Dumazet authored
If ip6_convert_metrics() fails to allocate memory, it should not overwrite rt->fib6_metrics or we risk a crash later as syzbot found. BUG: KASAN: null-ptr-deref in atomic_read include/asm-generic/atomic-instrumented.h:21 [inline] BUG: KASAN: null-ptr-deref in refcount_sub_and_test+0x92/0x330 lib/refcount.c:179 Read of size 4 at addr 0000000000000044 by task syzkaller832429/4487 CPU: 1 PID: 4487 Comm: syzkaller832429 Not tainted 4.16.0+ #6 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 kasan_report_error mm/kasan/report.c:352 [inline] kasan_report.cold.7+0x6d/0x2fe mm/kasan/report.c:412 check_memory_region_inline mm/kasan/kasan.c:260 [inline] check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267 kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272 atomic_read include/asm-generic/atomic-instrumented.h:21 [inline] refcount_sub_and_test+0x92/0x330 lib/refcount.c:179 refcount_dec_and_test+0x1a/0x20 lib/refcount.c:212 fib6_info_destroy+0x2d0/0x3c0 net/ipv6/ip6_fib.c:206 fib6_info_release include/net/ip6_fib.h:304 [inline] ip6_route_info_create+0x677/0x3240 net/ipv6/route.c:3020 ip6_route_add+0x23/0xb0 net/ipv6/route.c:3030 inet6_rtm_newroute+0x142/0x160 net/ipv6/route.c:4406 rtnetlink_rcv_msg+0x466/0xc10 net/core/rtnetlink.c:4648 netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2448 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4666 netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline] netlink_unicast+0x58b/0x740 net/netlink/af_netlink.c:1336 netlink_sendmsg+0x9f0/0xfa0 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:629 [inline] sock_sendmsg+0xd5/0x120 net/socket.c:639 ___sys_sendmsg+0x805/0x940 net/socket.c:2117 __sys_sendmsg+0x115/0x270 net/socket.c:2155 SYSC_sendmsg net/socket.c:2164 [inline] SyS_sendmsg+0x29/0x30 net/socket.c:2162 do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x42/0xb7 Fixes: d4ead6b3 ("net/ipv6: move metrics from dst to rt6_info") Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: David Ahern <dsa@cumulusnetworks.com> Reported-by:
syzbot <syzkaller@googlegroups.com> Acked-by:
David Ahern <dsa@cumulusnetworks.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Shahed Shaikh says: ==================== qed* : Use trust mode to override forced MAC This patchset adds a support to override forced MAC (MAC set by PF for a VF) when trust mode is enabled using First patch adds a real change to use .ndo_set_vf_trust to override forced MAC and allow user to change VFs from VF interface itself. Second patch takes care of a corner case, where MAC change from VF won't take effect when VF interface is down, by introducing a new TLV (a way to send message from VF to PF) to give a hint to PF to update its bulletin board. ==================== Signed-off-by: -
Shahed Shaikh authored
There may be a need for VF driver to request PF to explicitly update its bulletin with a MAC address. e.g. When user assigns a MAC address to VF while VF is still down, and PF's bulletin board contains different MAC address, in this case, when VF's interface is brought up, it gets loaded with MAC address from bulletin board which is not desirable. To handle this corner case, we need a new TLV to request PF to update its bulletin board with suggested MAC. This request will be honored only for trusted VFs. Signed-off-by:
Shahed Shaikh <shahed.shaikh@cavium.com> Signed-off-by:
-
Shahed Shaikh authored
As per existing behavior, when PF sets a MAC address for a VF (also called as forced MAC), VF is not allowed to change its MAC address afterwards. This puts the limitation on few use cases such as bonding of VFs, where bonding driver asks VF to change its MAC address. This patch uses a VF trust mode to allow VF to change its MAC address in spite PF has set a forced MAC for that VF. Signed-off-by:
-
David S. Miller authored
Alexey Kodanev says: ==================== geneve: verify user specified MTU or adjust with a lower device The first two patches don't introduce any functional changes and contain minor cleanups for code readability. The last one adds a new function geneve_link_config() similar to the other tunnels. The function will be used on a new link creation or when 'remote' parameter is changed. It adjusts a user specified MTU or, if it finds a lower device, tunes the tunnel MTU using it. ==================== Signed-off-by: -
Alexey Kodanev authored
Currently, on a new link creation or when 'remote' address parameter is updated, an MTU is not changed and always equals 1500. When a lower device has a larger MTU, it might not be efficient, e.g. for UDP, and requires the manual MTU adjustments to match the MTU of the lower device. This patch tries to automate this process, finds a lower device using the 'remote' address parameter, then uses its MTU to tune GENEVE's MTU: * on a new link creation * when 'remote' parameter is changed Also with this patch, the MTU from a user, on a new link creation, is passed to geneve_change_mtu() where it is verified, and MTU adjustments with a lower device is skipped in that case. Prior that change, it was possible to set the invalid MTU values on a new link creation. Signed-off-by:
Alexey Kodanev <alexey.kodanev@oracle.com> Signed-off-by:
-
Alexey Kodanev authored
geneve_change_mtu() will be used not only as ndo_change_mtu() callback, but also to verify a user specified MTU on a new link creation in the next patch. Signed-off-by:
-
Alexey Kodanev authored
Use ETH_HLEN instead and introduce two new macros: GENEVE_IPV4_HLEN and GENEVE_IPV6_HLEN that include Ethernet header length, corresponded IP header length and GENEVE_BASE_HLEN. Signed-off-by:
-
Alexey Kodanev authored
Signed-off-by:
-
George Wilkie authored
Account for operational state when determining port linkup state, as per Documentation/networking/operstates.txt. Signed-off-by:
George Wilkie <gwilkie@vyatta.att-mail.com> Acked-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
David S. Miller authored
GhantaKrishnamurthy MohanKrishna says: ==================== tipc: Confgiuration of MTU for media UDP Systematic measurements have shown that an emulated MTU of 14k for UDP bearers is the optimal value for maximal throughput. Accordingly, the default MTU of UDP bearers is changed to 14k. We also provide users with a fallback option from this value, by providing support to configure MTU for UDP bearers. The following options are introduced which are symmetrical to the design of confguring link tolerance. - Configure media with new MTU value, which will take effect on links going up after the moment it was configured. Alternatively, the bearer has to be disabled and re-enabled, for existing links to reflect the configured value. - Configure bearer with new MTU value, which take effect on running links dynamically. Please note: - User has to change MTU at both endpoints, otherwise the link will fall back to smallest MTU after a reset. - Failover from a link with higher MTU to a link with lower MTU ==================== Signed-off-by: -
GhantaKrishnamurthy MohanKrishna authored
Currently, we have option to configure MTU of UDP media. The configured MTU takes effect on the links going up after that moment. I.e, a user has to reset bearer to have new value applied across its links. This is confusing and disturbing on a running cluster. We now introduce the functionality to change the default UDP bearer MTU in struct tipc_bearer. Additionally, the links are updated dynamically, without any need for a reset, when bearer value is changed. We leverage the existing per-link functionality and the design being symetrical to the confguration of link tolerance. Acked-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
GhantaKrishnamurthy MohanKrishna <mohan.krishna.ghanta.krishnamurthy@ericsson.com> Signed-off-by:
-
GhantaKrishnamurthy MohanKrishna authored
In previous commit, we changed the default emulated MTU for UDP bearers to 14k. This commit adds the functionality to set/change the default value by configuring new MTU for UDP media. UDP bearer(s) have to be disabled and enabled back for the new MTU to take effect. Acked-by:
Ying Xue <ying.xue@windriver.com> Acked-by:
-
GhantaKrishnamurthy MohanKrishna authored
Currently, all bearers are configured with MTU value same as the underlying L2 device. However, in case of bearers with media type UDP, higher throughput is possible with a fixed and higher emulated MTU value than adapting to the underlying L2 MTU. In this commit, we introduce a parameter mtu in struct tipc_media and a default value is set for UDP. A default value of 14k was determined by experimentation and found to have a higher throughput than 16k. MTU for UDP bearers are assigned the above set value of media MTU. Acked-by:
-
Intiyaz Basha authored
Added the ndo to gather VF statistics through the PF. Collect VF statistics via mailbox from VF. Signed-off-by:
Intiyaz Basha <intiyaz.basha@cavium.com> Signed-off-by:
Felix Manlunas <felix.manlunas@cavium.com> Signed-off-by:
-
David S. Miller authored
Kunihiko Hayashi says: ==================== ave: fix the activation issues for some UniPhier SoCs This add the following stuffs to fix the activation issues and satisfy requirements for AVE ethernet driver implemented on some UniPhier SoCs. - Add support for additional necessary clocks and resets, because the kernel is stalled on Pro4 due to lack of them. - Check whether the SoC supports the specified phy-mode - Add DT property support indicating system controller that has the feature for configurating phy-mode including built-in phy on LD11. v1: https://www.spinics.net/lists/netdev/msg494904.html Changes since v1: - Add 'Reviewed-by' lines ==================== Signed-off-by:
-
Kunihiko Hayashi authored
This patch adds support for specifying system controller that configures phy-mode setting. According to the DT property "phy-mode", it's necessary to configure the controller, which is used to choose the settings of the MAC suitable, for example, mdio pin connections, internal clocks, and so on. Supported phy-modes are SoC-dependent. The driver allows phy-mode to set "internal" if the SoC has a built-in PHY, and {"mii", "rmii", "rgmii"} if the SoC supports each mode. So we have to check whether the phy-mode is valid or not. This adds the following features for each SoC: - check whether the SoC supports the specified phy-mode - configure the controller accroding to phy-mode The DT property accepts one argument to distinguish them for multiple MAC instances. ethernet@65000000 { ... socionext,syscon-phy-mode = <&soc_glue 0>; }; ethernet@65200000 { ... socionext,syscon-phy-mode = <&soc_glue 1>; }; Signed-off-by:Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Kunihiko Hayashi authored
Add "socionext,syscon-phy-mode" property to specify system controller that configures the settings about phy-mode. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Kunihiko Hayashi authored
When the link is becoming up for Pro4 SoC, the kernel is stalled due to some missing clocks and resets. The AVE block for Pro4 is connected to the GIO bus in the SoC. Without its clock/reset, the access to the AVE register makes the system stall. In the same way, another MAC clock for Giga-bit Connection and the PHY clock are also required for Pro4 to activate the Giga-bit feature and to recognize the PHY. To satisfy these requirements, this patch adds support for multiple clocks and resets, and adds the clock-names and reset-names to the binding because we need to distinguish clock/reset for the AVE main block and the others. Also, make the resets a required property. Currently, "reset is optional" relies on that the bootloader or firmware has deasserted the reset before booting the kernel. Drivers should work without such expectation. Fixes: 4c270b55 ("net: ethernet: socionext: add AVE ethernet driver") Suggested-by:
-
Andrew Lunn authored
mdiobus_register will search for any mdiobus board info registered for the bus being registered. If found, it will probe devices on the bus. That device, if for example it is an ethernet switch, may then try to register an mdio bus. Thus we need to allow recursive calls to mdiobus_register. Holding the mdio_board_lock will cause a deadlock during this recursion. Release the lock and use list_for_each_entry_safe. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
- 19 Apr, 2018 20 commits
-
-
David S. Miller authored
Michael Schmitz says: ==================== New network driver for Amiga X-Surf 100 (m68k) [This is a resend of my v3 series which was based on the wrong version and tree. Only substantial change is to Asix AX99796B PHY driver.] This patch series adds support for the Individual Computers X-Surf 100 network card for m68k Amiga, a network adapter based on the AX88796 chip set. The driver was originally written for kernel version 3.19 by Michael Karcher (see CC:), and adapted to 4.16+ for submission to netdev by me. Questions regarding motivation for some of the changes are probably best directed at Michael Karcher. The driver has been tested by Adrian <glaubitz@physik.fu-berlin.de> who will send his Tested-by tag separately. A few changes to the ax88796 driver were required: - to read the MAC address, some setup of the ax99796 chip must be done, - attach to the MII bus only on device open to allow module unloading, - allow to supersede ax_block_input/ax_block_output by card-specific optimized code, - use an optional interrupt status callback to allow easier sharing of the card interrupt, - set IRQF_SHARED if platform IRQ resource is marked shareable The Asix Electronix PHY used on the X-Surf 100 is buggy, and causes the software reset to hang if the previous command sent to the PHY was also a soft reset. This bug requires addition of a PHY driver for Asix PHYs to provide a fixed .soft_reset function, included in this series. Some additional cleanup: - do not attempt to free IRQ in ax_remove (complements 82533ad9), - clear platform drvdata on probe fail and module remove. Changes since v1: Raised in review by Andrew Lunn: - move MII code around to avoid need for forward declaration, - combine patches 2 and 7 to add cleanup in error path Changes since v2: - corrected authorship attribution to Michael Karcher Suggested by Geert Uytterhoeven: - use ei_local->reset_8390() instead of duplicating ax_reset_8390(), - use %pR to format struct resource pointers, - assign pdev and xs100 pointers in declaration, - don't split error messages, - change Kconfig logic to only require XSURF100 set on Amiga Suggested by Andrew Lunn: - add COMPILE_TEST to ax88796 Kconfig options, - use new Asix PHY driver for X-Surf 100 Suggested by Andrew Lunn/Finn Thain: - declare struct sk_buff in ax88796.h, - correct whitespace error in ax88796.h Changes since v3: - various checkpatch cleanup Andrew Lunn: - don't duplicate genphy_soft_reset in Asix PHY driver, just call genphy_soft_reset after writing zero to control register ==================== Signed-off-by:
-
Michael Karcher authored
Add platform device driver to populate the ax88796 platform data from information provided by the XSurf100 zorro device driver. The ax88796 module will be loaded through this module's probe function. Signed-off-by:
Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de> Signed-off-by:
Michael Schmitz <schmitzmic@gmail.com> Signed-off-by:
-
Michael Schmitz authored
The net device struct pointer is stored as platform device drvdata on module probe - clear the drvdata entry on probe fail there, as well as when unloading the module. Signed-off-by:
-
Michael Karcher authored
On the Amiga X-Surf100, the network card interrupt is shared with many other interrupt sources, so requires the IRQF_SHARED flag to register. Signed-off-by:
-
Michael Karcher authored
To be able to tell the ax88796 driver whether it is sensible to enter the 8390 interrupt handler, an "is this interrupt caused by the 88796" callback has been added to the ax_plat_data structure (with NULL being compatible to the previous behaviour). Signed-off-by:
-
Michael Karcher authored
Add platform specific hooks for block transfer reads/writes of packet buffer data, superseding the default provided ax_block_input/output. Currently used for m68k Amiga XSurf100. Signed-off-by:
-
Michael Karcher authored
This complements the fix in 82533ad9 ("net: ethernet: ax88796: don't call free_irq without request_irq first") that removed the free_irq call in the error path of probe, to also not call free_irq when remove is called to revert the effects of probe. Fixes: 82533ad9 (net: ethernet: ax88796: don't call free_irq without request_irq first) Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Michael Karcher authored
Call ax_mii_init in ax_open(), and unregister/remove mdiobus resources in ax_close(). This is needed to be able to unload the module, as the module is busy while the MII bus is attached. Signed-off-by:
-
Michael Karcher authored
To read the MAC address from the (virtual) SAprom, the remote DMA unit needs to be set up like for every other process access to card-local memory. Signed-off-by:
-
Michael Schmitz authored
The Asix Electronics PHY found on the X-Surf 100 Amiga Zorro network card by Individual Computers is buggy, and needs the reset bit toggled as workaround to make a PHY soft reset succeed. Add workaround driver just for this special case. Suggested in xsurf100 patch series review by Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
David S. Miller authored
Andrew Lunn says: ==================== Modernize mdio-gpio This patchset is inspired by a previous version by Linus Walleij It reworks the mdio-gpio code to make use of gpio descriptors instead of gpio numbers. However compared to the previous version, it retains support for platform devices. It does however remove the platform_data header file. The needed GPIOs are now passed by making use of a gpiod lookup table. e.g: static struct gpiod_lookup_table zii_scu_mdio_gpiod_table = { .dev_id = "mdio-gpio.0", .table = { GPIO_LOOKUP_IDX("gpio_ich", 17, NULL, MDIO_GPIO_MDC, GPIO_ACTIVE_HIGH), GPIO_LOOKUP_IDX("gpio_ich", 2, NULL, MDIO_GPIO_MDIO, GPIO_ACTIVE_HIGH), GPIO_LOOKUP_IDX("gpio_ich", 21, NULL, MDIO_GPIO_MDO, GPIO_ACTIVE_LOW), }, }; ==================== Signed-off-by: -
Andrew Lunn authored
The platform data header file is now unused. Remove it, but add an extra include which it brought in. Signed-off-by:
-
Andrew Lunn authored
The GPIOs are described in device tree using a list, without names. Add defines to indicate what each index in the list means. These defines should also be used by platform devices passing GPIOs via a GPIO lookup table. Signed-off-by:
-
Andrew Lunn authored
The same parsing code can be used for both OF and platform devices, if the platform device uses a gpiod_lookup_table. Parse these properties directly into the bitbang structure, rather than use an intermediate platform data structure. Signed-off-by:
-
Andrew Lunn authored
Moving the allocation of this structure to the probe function is a step towards making it the core data structure of the driver. Signed-off-by:
-
Andrew Lunn authored
This simplifies the code, removing the need to handle active low flags, etc. Signed-off-by:
-
Andrew Lunn authored
No current devices use IRQs in platform data, so remove support for it. The MDIO core will also initialise the new bus such that all addresses are polled, so remove the unneeded re-initialisation. Signed-off-by:
-
Andrew Lunn authored
This is not needed any more by devices using platform data, so remove it. Signed-off-by:
-
Andrew Lunn authored
This is not needed any more by devices using platform data, so remove it. Signed-off-by:
-
Andrew Lunn authored
The mdio-gpio driver was the only user of the interface reset option. Since it no longer uses it, remove it from the bit banging code. Signed-off-by:
-
