1. 29 May, 2019 9 commits
    • 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
  2. 28 May, 2019 3 commits
  3. 27 May, 2019 11 commits
  4. 26 May, 2019 5 commits
  5. 25 May, 2019 7 commits
  6. 24 May, 2019 3 commits
  7. 23 May, 2019 2 commits
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · 71e15f76
      David S. Miller authored
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter/IPVS fixes for net
      
      The following patchset contains Netfilter/IPVS fixes for your net tree:
      
      1) Fix crash when dumping rules after conversion to RCU,
         from Florian Westphal.
      
      2) Fix incorrect hook reinjection from nf_queue in case NF_REPEAT,
         from Jagdish Motwani.
      
      3) Fix check for route existence in fib extension, from Phil Sutter.
      
      4) Fix use after free in ip_vs_in() hook, from YueHaibing.
      
      5) Check for veth existence from netfilter selftests,
         from Jeffrin Jose T.
      
      6) Checksum corruption in UDP NAT helpers due to typo,
         from Florian Westphal.
      
      7) Pass up packets to classic forwarding path regardless of
         IPv4 DF bit, patch for the flowtable infrastructure from Florian.
      
      8) Set liberal TCP tracking for flows that are placed in the
         flowtable, in case they need to go back to classic forwarding path,
         also from Florian.
      
      9) Don't add flow with sequence adjustment to flowtable, from Florian.
      
      10) Skip IPv4 options from IPv6 datapath in flowtable, from Florian.
      
      11) Add selftest for the flowtable infrastructure, from Florian.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      71e15f76
    • Raju Rangoju's avatar
      cxgb4: offload VLAN flows regardless of VLAN ethtype · b5730061
      Raju Rangoju authored
      VLAN flows never get offloaded unless ivlan_vld is set in filter spec.
      It's not compulsory for vlan_ethtype to be set.
      
      So, always enable ivlan_vld bit for offloading VLAN flows regardless of
      vlan_ethtype is set or not.
      
      Fixes: ad9af3e0 (cxgb4: add tc flower match support for vlan)
      Signed-off-by: default avatarRaju Rangoju <rajur@chelsio.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b5730061