1. 30 May, 2019 3 commits
    • Stephen Hemminger's avatar
      net: core: support XDP generic on stacked devices. · 458bf2f2
      Stephen Hemminger authored
      When a device is stacked like (team, bonding, failsafe or netvsc) the
      XDP generic program for the parent device was not called.
      
      Move the call to XDP generic inside __netif_receive_skb_core where
      it can be done multiple times for stacked case.
      
      Fixes: d4455169 ("net: xdp: support xdp generic on virtual devices")
      Signed-off-by: default avatarStephen Hemminger <sthemmin@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      458bf2f2
    • Stephen Hemminger's avatar
      netvsc: unshare skb in VF rx handler · 996ed047
      Stephen Hemminger authored
      The netvsc VF skb handler should make sure that skb is not
      shared. Similar logic already exists in bonding and team device
      drivers.
      
      This is not an issue in practice because the VF devicex
      does not send up shared skb's. But the netvsc driver
      should do the right thing if it did.
      
      Fixes: 0c195567 ("netvsc: transparent VF management")
      Signed-off-by: default avatarStephen Hemminger <sthemmin@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      996ed047
    • Sean Tranchetti's avatar
      udp: Avoid post-GRO UDP checksum recalculation · f2696099
      Sean Tranchetti authored
      Currently, when resegmenting an unexpected UDP GRO packet, the full UDP
      checksum will be calculated for every new SKB created by skb_segment()
      because the netdev features passed in by udp_rcv_segment() lack any
      information about checksum offload capabilities.
      
      Usually, we have no need to perform this calculation again, as
        1) The GRO implementation guarantees that any packets making it to the
           udp_rcv_segment() function had correct checksums, and, more
           importantly,
        2) Upon the successful return of udp_rcv_segment(), we immediately pull
           the UDP header off and either queue the segment to the socket or
           hand it off to a new protocol handler.
      
      Unless userspace has set the IP_CHECKSUM sockopt to indicate that they
      want the final checksum values, we can pass the needed netdev feature
      flags to __skb_gso_segment() to avoid checksumming each segment in
      skb_segment().
      
      Fixes: cf329aa4 ("udp: cope with UDP GRO packet misdirection")
      Cc: Paolo Abeni <pabeni@redhat.com>
      Cc: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
      Signed-off-by: default avatarSean Tranchetti <stranche@codeaurora.org>
      Acked-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f2696099
  2. 29 May, 2019 11 commits
    • David S. Miller's avatar
      Merge branch 'net-phy-dp83867-add-some-fixes' · 58e8b370
      David S. Miller authored
      Max Uvarov says:
      
      ====================
      net: phy: dp83867: add some fixes
      
      v3: use phy_modify_mmd()
      v2: fix minor comments by Heiner Kallweit and Florian Fainelli
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      58e8b370
    • Max Uvarov's avatar
      net: phy: dp83867: Set up RGMII TX delay · 2b892649
      Max Uvarov authored
      PHY_INTERFACE_MODE_RGMII_RXID is less then TXID
      so code to set tx delay is never called.
      
      Fixes: 2a10154a ("net: phy: dp83867: Add TI dp83867 phy")
      Signed-off-by: default avatarMax Uvarov <muvarov@gmail.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2b892649
    • Max Uvarov's avatar
      net: phy: dp83867: do not call config_init twice · c8081fc3
      Max Uvarov authored
      Phy state machine calls _config_init just after
      reset.
      Signed-off-by: default avatarMax Uvarov <muvarov@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c8081fc3
    • Max Uvarov's avatar
      net: phy: dp83867: increase SGMII autoneg timer duration · 1a97a477
      Max Uvarov authored
      After reset SGMII Autoneg timer is set to 2us (bits 6 and 5 are 01).
      That is not enough to finalize autonegatiation on some devices.
      Increase this timer duration to maximum supported 16ms.
      Signed-off-by: default avatarMax Uvarov <muvarov@gmail.com>
      Cc: Heiner Kallweit <hkallweit1@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1a97a477
    • Max Uvarov's avatar
      net: phy: dp83867: fix speed 10 in sgmii mode · 333061b9
      Max Uvarov authored
      For supporting 10Mps speed in SGMII mode DP83867_10M_SGMII_RATE_ADAPT bit
      of DP83867_10M_SGMII_CFG register has to be cleared by software.
      That does not affect speeds 100 and 1000 so can be done on init.
      Signed-off-by: default avatarMax Uvarov <muvarov@gmail.com>
      Cc: Heiner Kallweit <hkallweit1@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      333061b9
    • Russell King's avatar
      net: phy: marvell10g: report if the PHY fails to boot firmware · 3d3ced2e
      Russell King authored
      Some boards do not have the PHY firmware programmed in the 3310's flash,
      which leads to the PHY not working as expected.  Warn the user when the
      PHY fails to boot the firmware and refuse to initialise.
      
      Fixes: 20b2af32 ("net: phy: add Marvell Alaska X 88X3310 10Gigabit PHY support")
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Tested-by: default avatarMaxime Chevallier <maxime.chevallier@bootlin.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3d3ced2e
    • Russell King's avatar
      net: phylink: ensure consistent phy interface mode · c6787263
      Russell King authored
      Ensure that we supply the same phy interface mode to mac_link_down() as
      we did for the corresponding mac_link_up() call.  This ensures that MAC
      drivers that use the phy interface mode in these methods can depend on
      mac_link_down() always corresponding to a mac_link_up() call for the
      same interface mode.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c6787263
    • Yoshihiro Shimoda's avatar
      net: sh_eth: fix mdio access in sh_eth_close() for R-Car Gen2 and RZ/A1 SoCs · 315ca92d
      Yoshihiro Shimoda authored
      The sh_eth_close() resets the MAC and then calls phy_stop()
      so that mdio read access result is incorrect without any error
      according to kernel trace like below:
      
      ifconfig-216   [003] .n..   109.133124: mdio_access: ee700000.ethernet-ffffffff read  phy:0x01 reg:0x00 val:0xffff
      
      According to the hardware manual, the RMII mode should be set to 1
      before operation the Ethernet MAC. However, the previous code was not
      set to 1 after the driver issued the soft_reset in sh_eth_dev_exit()
      so that the mdio read access result seemed incorrect. To fix the issue,
      this patch adds a condition and set the RMII mode register in
      sh_eth_dev_exit() for R-Car Gen2 and RZ/A1 SoCs.
      
      Note that when I have tried to move the sh_eth_dev_exit() calling
      after phy_stop() on sh_eth_close(), but it gets worse (kernel panic
      happened and it seems that a register is accessed while the clock is
      off).
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      315ca92d
    • Florian Fainelli's avatar
      Documentation: net-sysfs: Remove duplicate PHY device documentation · a6cd0d2d
      Florian Fainelli authored
      Both sysfs-bus-mdio and sysfs-class-net-phydev contain the same
      duplication information. There is not currently any MDIO bus specific
      attribute, but there are PHY device (struct phy_device) specific
      attributes. Use the more precise description from sysfs-bus-mdio and
      carry that over to sysfs-class-net-phydev.
      
      Fixes: 86f22d04 ("net: sysfs: Document PHY device sysfs attributes")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a6cd0d2d
    • Eric Dumazet's avatar
      llc: fix skb leak in llc_build_and_send_ui_pkt() · 8fb44d60
      Eric Dumazet authored
      If llc_mac_hdr_init() returns an error, we must drop the skb
      since no llc_build_and_send_ui_pkt() caller will take care of this.
      
      BUG: memory leak
      unreferenced object 0xffff8881202b6800 (size 2048):
        comm "syz-executor907", pid 7074, jiffies 4294943781 (age 8.590s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          1a 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
        backtrace:
          [<00000000e25b5abe>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
          [<00000000e25b5abe>] slab_post_alloc_hook mm/slab.h:439 [inline]
          [<00000000e25b5abe>] slab_alloc mm/slab.c:3326 [inline]
          [<00000000e25b5abe>] __do_kmalloc mm/slab.c:3658 [inline]
          [<00000000e25b5abe>] __kmalloc+0x161/0x2c0 mm/slab.c:3669
          [<00000000a1ae188a>] kmalloc include/linux/slab.h:552 [inline]
          [<00000000a1ae188a>] sk_prot_alloc+0xd6/0x170 net/core/sock.c:1608
          [<00000000ded25bbe>] sk_alloc+0x35/0x2f0 net/core/sock.c:1662
          [<000000002ecae075>] llc_sk_alloc+0x35/0x170 net/llc/llc_conn.c:950
          [<00000000551f7c47>] llc_ui_create+0x7b/0x140 net/llc/af_llc.c:173
          [<0000000029027f0e>] __sock_create+0x164/0x250 net/socket.c:1430
          [<000000008bdec225>] sock_create net/socket.c:1481 [inline]
          [<000000008bdec225>] __sys_socket+0x69/0x110 net/socket.c:1523
          [<00000000b6439228>] __do_sys_socket net/socket.c:1532 [inline]
          [<00000000b6439228>] __se_sys_socket net/socket.c:1530 [inline]
          [<00000000b6439228>] __x64_sys_socket+0x1e/0x30 net/socket.c:1530
          [<00000000cec820c1>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
          [<000000000c32554f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      BUG: memory leak
      unreferenced object 0xffff88811d750d00 (size 224):
        comm "syz-executor907", pid 7074, jiffies 4294943781 (age 8.600s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 f0 0c 24 81 88 ff ff 00 68 2b 20 81 88 ff ff  ...$.....h+ ....
        backtrace:
          [<0000000053026172>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
          [<0000000053026172>] slab_post_alloc_hook mm/slab.h:439 [inline]
          [<0000000053026172>] slab_alloc_node mm/slab.c:3269 [inline]
          [<0000000053026172>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
          [<00000000fa8f3c30>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:198
          [<00000000d96fdafb>] alloc_skb include/linux/skbuff.h:1058 [inline]
          [<00000000d96fdafb>] alloc_skb_with_frags+0x5f/0x250 net/core/skbuff.c:5327
          [<000000000a34a2e7>] sock_alloc_send_pskb+0x269/0x2a0 net/core/sock.c:2225
          [<00000000ee39999b>] sock_alloc_send_skb+0x32/0x40 net/core/sock.c:2242
          [<00000000e034d810>] llc_ui_sendmsg+0x10a/0x540 net/llc/af_llc.c:933
          [<00000000c0bc8445>] sock_sendmsg_nosec net/socket.c:652 [inline]
          [<00000000c0bc8445>] sock_sendmsg+0x54/0x70 net/socket.c:671
          [<000000003b687167>] __sys_sendto+0x148/0x1f0 net/socket.c:1964
          [<00000000922d78d9>] __do_sys_sendto net/socket.c:1976 [inline]
          [<00000000922d78d9>] __se_sys_sendto net/socket.c:1972 [inline]
          [<00000000922d78d9>] __x64_sys_sendto+0x2a/0x30 net/socket.c:1972
          [<00000000cec820c1>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
          [<000000000c32554f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8fb44d60
    • Stefano Brivio's avatar
      selftests: pmtu: Fix encapsulating device in pmtu_vti6_link_change_mtu · 73f51d15
      Stefano Brivio authored
      In the pmtu_vti6_link_change_mtu test, both local and remote addresses
      for the vti6 tunnel are assigned to the same address given to the dummy
      interface that we use as encapsulating device with a known MTU.
      
      This works as long as the dummy interface is actually selected, via
      rt6_lookup(), as encapsulating device. But if the remote address of the
      tunnel is a local address too, the loopback interface could also be
      selected, and there's nothing wrong with it.
      
      This is what some older -stable kernels do (3.18.z, at least), and
      nothing prevents us from subtly changing FIB implementation to revert
      back to that behaviour in the future.
      
      Define an IPv6 prefix instead, and use two separate addresses as local
      and remote for vti6, so that the encapsulating device can't be a
      loopback interface.
      Reported-by: default avatarXiumei Mu <xmu@redhat.com>
      Fixes: 1fad59ea ("selftests: pmtu: Add pmtu_vti6_link_change_mtu test")
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      73f51d15
  3. 28 May, 2019 3 commits
  4. 27 May, 2019 11 commits
  5. 26 May, 2019 5 commits
  6. 25 May, 2019 7 commits