1. 29 May, 2019 6 commits
    • 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 5 commits