1. 08 10月, 2015 2 次提交
    • J
      net: mdio-octeon: Drop obsolete Kconfig advice · 9d3a6386
      Jean Delvare 提交于
      "Y" was the right answer for MDIO_OCTEON when this option was only
      available on CAVIUM_OCTEON_SOC. But now that the option is visible on
      all (64-bit) systems, this piece of advice no longer makes sense. This
      helper module is selected automatically by drivers which need it
      anyway.
      Signed-off-by: NJean Delvare <jdelvare@suse.de>
      Fixes: a6d67864 ("net: mdio-octeon: Modify driver to work on both ThunderX and Octeon")
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Sunil Goutham <sgoutham@cavium.com>
      Cc: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
      Cc: David Daney <david.daney@cavium.com>
      Cc: David S. Miller <davem@davemloft.net>
      Acked-by: NDavid Daney <david.daney@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9d3a6386
    • A
      mlxsw: fix warnings for big-endian 32-bit dma_addr_t · bcb9db49
      Arnd Bergmann 提交于
      The recently added mlxsw driver produces warnings in ARM
      allmodconfig:
      
      drivers/net/ethernet/mellanox/mlxsw/pci.c: In function 'mlxsw_pci_cmd_exec':
      drivers/net/ethernet/mellanox/mlxsw/pci.c:1585:59: warning: right shift count >= width of type [-Wshift-count-overflow]
      linux/byteorder/big_endian.h:38:51: note: in definition of macro '__cpu_to_be32'
      drivers/net/ethernet/mellanox/mlxsw/pci.c:76:2: note: in expansion of macro 'iowrite32be'
      
      This uses upper_32_bits() to extract the bits while avoiding that warning.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Fixes: eda6500a "mlxsw: Add PCI bus implementation"
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bcb9db49
  2. 07 10月, 2015 1 次提交
  3. 06 10月, 2015 1 次提交
  4. 05 10月, 2015 5 次提交
    • J
      i40e: fix offload of GRE tunnels · fec31fff
      Jesse Brandeburg 提交于
      The driver still was not offloading TSO on GRE tunnels because
      it forgot to set the GSO_GRE flag, causing lots of retransmits.
      
      This fixes generic GRE traffic (like a tunnel added like below)
      whereas before it would get 1Gb/s or less, now on a 10G adapter
      it gets 8.7Gb/s.
      
      ip ad ad 11.1.0.2/24 dev ens2f0
      ip l set ens2f0 up
      ip link add gre2 type gretap remote 11.1.0.1 local 11.1.0.2 dev ens2f0
      ip l set gre2 up
      ip ad ad 192.168.124.2/24 dev gre2
      ping 192.168.124.1
      netperf -H 192.168.124.1
      Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fec31fff
    • V
      net: lpc_eth: fix warnings caused by enabling unprepared clock · 33a8316d
      Vladimir Zapolskiy 提交于
      If common clock framework is configured, the driver generates warnings,
      which are fixed by this change:
      
          WARNING: CPU: 0 PID: 1 at linux/drivers/clk/clk.c:727 clk_core_enable+0x2c/0xa4()
          Modules linked in:
          CPU: 0 PID: 1 Comm: swapper Not tainted 4.3.0-rc2+ #141
          Hardware name: LPC32XX SoC (Flattened Device Tree)
          Backtrace:
          [<>] (dump_backtrace) from [<>] (show_stack+0x18/0x1c)
          [<>] (show_stack) from [<>] (dump_stack+0x20/0x28)
          [<>] (dump_stack) from [<>] (warn_slowpath_common+0x90/0xb8)
          [<>] (warn_slowpath_common) from [<>] (warn_slowpath_null+0x24/0x2c)
          [<>] (warn_slowpath_null) from [<>] (clk_core_enable+0x2c/0xa4)
          [<>] (clk_core_enable) from [<>] (clk_enable+0x24/0x38)
          [<>] (clk_enable) from [<>] (lpc_eth_drv_probe+0xfc/0x99c)
          [<>] (lpc_eth_drv_probe) from [<>] (platform_drv_probe+0x50/0xa0)
          [<>] (platform_drv_probe) from [<>] (driver_probe_device+0x18c/0x408)
          [<>] (driver_probe_device) from [<>] (__driver_attach+0x70/0x94)
          [<>] (__driver_attach) from [<>] (bus_for_each_dev+0x74/0x98)
          [<>] (bus_for_each_dev) from [<>] (driver_attach+0x20/0x28)
          [<>] (driver_attach) from [<>] (bus_add_driver+0x11c/0x248)
          [<>] (bus_add_driver) from [<>] (driver_register+0xa4/0xe8)
          [<>] (driver_register) from [<>] (__platform_driver_register+0x50/0x64)
          [<>] (__platform_driver_register) from [<>] (lpc_eth_driver_init+0x18/0x20)
          [<>] (lpc_eth_driver_init) from [<>] (do_one_initcall+0x11c/0x1dc)
          [<>] (do_one_initcall) from [<>] (kernel_init_freeable+0x10c/0x1d4)
          [<>] (kernel_init_freeable) from [<>] (kernel_init+0x10/0xec)
          [<>] (kernel_init) from [<>] (ret_from_fork+0x14/0x24)
      Signed-off-by: NVladimir Zapolskiy <vz@mleia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      33a8316d
    • D
      net: usb: asix: Fix crash on skb alloc failure · f6194bcf
      David B. Robins 提交于
      If asix_rx_fixup_internal() fails to allocate rx->ax_skb, it will return
      but not clear rx->size. rx points to driver private data. A later call
      assumes that nonzero size means ax_skb was allocated and passes a null
      ax_skb to skb_put. Changed allocation failure return to clear size first.
      
      Found testing board with AX88772B devices.
      Signed-off-by: NDavid B. Robins <linux@davidrobins.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f6194bcf
    • G
      amd-xgbe: fix potential memory leak in xgbe-debugfs · 9dc80a74
      Geliang Tang 提交于
      Added kfree() to avoid the memory leak when debugfs_create_dir() fails.
      Signed-off-by: NGeliang Tang <geliangtang@163.com>
      Acked-by: NTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9dc80a74
    • G
      ppp: don't override sk->sk_state in pppoe_flush_dev() · e6740165
      Guillaume Nault 提交于
      Since commit 2b018d57 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release"),
      pppoe_release() calls dev_put(po->pppoe_dev) if sk is in the
      PPPOX_ZOMBIE state. But pppoe_flush_dev() can set sk->sk_state to
      PPPOX_ZOMBIE _and_ reset po->pppoe_dev to NULL. This leads to the
      following oops:
      
      [  570.140800] BUG: unable to handle kernel NULL pointer dereference at 00000000000004e0
      [  570.142931] IP: [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe]
      [  570.144601] PGD 3d119067 PUD 3dbc1067 PMD 0
      [  570.144601] Oops: 0000 [#1] SMP
      [  570.144601] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pppoe pppox ppp_generic slhc loop crc32c_intel ghash_clmulni_intel jitterentropy_rng sha256_generic hmac drbg ansi_cprng aesni_intel aes_x86_64 ablk_helper cryptd lrw gf128mul glue_helper acpi_cpufreq evdev serio_raw processor button ext4 crc16 mbcache jbd2 virtio_net virtio_blk virtio_pci virtio_ring virtio
      [  570.144601] CPU: 1 PID: 15738 Comm: ppp-apitest Not tainted 4.2.0 #1
      [  570.144601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
      [  570.144601] task: ffff88003d30d600 ti: ffff880036b60000 task.ti: ffff880036b60000
      [  570.144601] RIP: 0010:[<ffffffffa018c701>]  [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe]
      [  570.144601] RSP: 0018:ffff880036b63e08  EFLAGS: 00010202
      [  570.144601] RAX: 0000000000000000 RBX: ffff880034340000 RCX: 0000000000000206
      [  570.144601] RDX: 0000000000000006 RSI: ffff88003d30dd20 RDI: ffff88003d30dd20
      [  570.144601] RBP: ffff880036b63e28 R08: 0000000000000001 R09: 0000000000000000
      [  570.144601] R10: 00007ffee9b50420 R11: ffff880034340078 R12: ffff8800387ec780
      [  570.144601] R13: ffff8800387ec7b0 R14: ffff88003e222aa0 R15: ffff8800387ec7b0
      [  570.144601] FS:  00007f5672f48700(0000) GS:ffff88003fc80000(0000) knlGS:0000000000000000
      [  570.144601] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  570.144601] CR2: 00000000000004e0 CR3: 0000000037f7e000 CR4: 00000000000406a0
      [  570.144601] Stack:
      [  570.144601]  ffffffffa018f240 ffff8800387ec780 ffffffffa018f240 ffff8800387ec7b0
      [  570.144601]  ffff880036b63e48 ffffffff812caabe ffff880039e4e000 0000000000000008
      [  570.144601]  ffff880036b63e58 ffffffff812cabad ffff880036b63ea8 ffffffff811347f5
      [  570.144601] Call Trace:
      [  570.144601]  [<ffffffff812caabe>] sock_release+0x1a/0x75
      [  570.144601]  [<ffffffff812cabad>] sock_close+0xd/0x11
      [  570.144601]  [<ffffffff811347f5>] __fput+0xff/0x1a5
      [  570.144601]  [<ffffffff811348cb>] ____fput+0x9/0xb
      [  570.144601]  [<ffffffff81056682>] task_work_run+0x66/0x90
      [  570.144601]  [<ffffffff8100189e>] prepare_exit_to_usermode+0x8c/0xa7
      [  570.144601]  [<ffffffff81001a26>] syscall_return_slowpath+0x16d/0x19b
      [  570.144601]  [<ffffffff813babb1>] int_ret_from_sys_call+0x25/0x9f
      [  570.144601] Code: 48 8b 83 c8 01 00 00 a8 01 74 12 48 89 df e8 8b 27 14 e1 b8 f7 ff ff ff e9 b7 00 00 00 8a 43 12 a8 0b 74 1c 48 8b 83 a8 04 00 00 <48> 8b 80 e0 04 00 00 65 ff 08 48 c7 83 a8 04 00 00 00 00 00 00
      [  570.144601] RIP  [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe]
      [  570.144601]  RSP <ffff880036b63e08>
      [  570.144601] CR2: 00000000000004e0
      [  570.200518] ---[ end trace 46956baf17349563 ]---
      
      pppoe_flush_dev() has no reason to override sk->sk_state with
      PPPOX_ZOMBIE. pppox_unbind_sock() already sets sk->sk_state to
      PPPOX_DEAD, which is the correct state given that sk is unbound and
      po->pppoe_dev is NULL.
      
      Fixes: 2b018d57 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release")
      Tested-by: NOleksii Berezhniak <core@irc.lg.ua>
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e6740165
  5. 30 9月, 2015 4 次提交
  6. 29 9月, 2015 3 次提交
  7. 27 9月, 2015 6 次提交
  8. 26 9月, 2015 4 次提交
    • R
      net: update docbook comment for __mdiobus_register() · 59f06978
      Russell King 提交于
      Update the docbook comment for __mdiobus_register() to include the new
      module owner argument.  This resolves a warning found by the 0-day
      builder.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      59f06978
    • G
      ppp: fix lockdep splat in ppp_dev_uninit() · 58a89eca
      Guillaume Nault 提交于
      ppp_dev_uninit() locks all_ppp_mutex while under rtnl mutex protection.
      ppp_create_interface() must then lock these mutexes in that same order
      to avoid possible deadlock.
      
      [  120.880011] ======================================================
      [  120.880011] [ INFO: possible circular locking dependency detected ]
      [  120.880011] 4.2.0 #1 Not tainted
      [  120.880011] -------------------------------------------------------
      [  120.880011] ppp-apitest/15827 is trying to acquire lock:
      [  120.880011]  (&pn->all_ppp_mutex){+.+.+.}, at: [<ffffffffa0145f56>] ppp_dev_uninit+0x64/0xb0 [ppp_generic]
      [  120.880011]
      [  120.880011] but task is already holding lock:
      [  120.880011]  (rtnl_mutex){+.+.+.}, at: [<ffffffff812e4255>] rtnl_lock+0x12/0x14
      [  120.880011]
      [  120.880011] which lock already depends on the new lock.
      [  120.880011]
      [  120.880011]
      [  120.880011] the existing dependency chain (in reverse order) is:
      [  120.880011]
      [  120.880011] -> #1 (rtnl_mutex){+.+.+.}:
      [  120.880011]        [<ffffffff81073a6f>] lock_acquire+0xcf/0x10e
      [  120.880011]        [<ffffffff813ab18a>] mutex_lock_nested+0x56/0x341
      [  120.880011]        [<ffffffff812e4255>] rtnl_lock+0x12/0x14
      [  120.880011]        [<ffffffff812d9d94>] register_netdev+0x11/0x27
      [  120.880011]        [<ffffffffa0147b17>] ppp_ioctl+0x289/0xc98 [ppp_generic]
      [  120.880011]        [<ffffffff8113b367>] do_vfs_ioctl+0x4ea/0x532
      [  120.880011]        [<ffffffff8113b3fd>] SyS_ioctl+0x4e/0x7d
      [  120.880011]        [<ffffffff813ad7d7>] entry_SYSCALL_64_fastpath+0x12/0x6f
      [  120.880011]
      [  120.880011] -> #0 (&pn->all_ppp_mutex){+.+.+.}:
      [  120.880011]        [<ffffffff8107334e>] __lock_acquire+0xb07/0xe76
      [  120.880011]        [<ffffffff81073a6f>] lock_acquire+0xcf/0x10e
      [  120.880011]        [<ffffffff813ab18a>] mutex_lock_nested+0x56/0x341
      [  120.880011]        [<ffffffffa0145f56>] ppp_dev_uninit+0x64/0xb0 [ppp_generic]
      [  120.880011]        [<ffffffff812d5263>] rollback_registered_many+0x19e/0x252
      [  120.880011]        [<ffffffff812d5381>] rollback_registered+0x29/0x38
      [  120.880011]        [<ffffffff812d53fa>] unregister_netdevice_queue+0x6a/0x77
      [  120.880011]        [<ffffffffa0146a94>] ppp_release+0x42/0x79 [ppp_generic]
      [  120.880011]        [<ffffffff8112d9f6>] __fput+0xec/0x192
      [  120.880011]        [<ffffffff8112dacc>] ____fput+0x9/0xb
      [  120.880011]        [<ffffffff8105447a>] task_work_run+0x66/0x80
      [  120.880011]        [<ffffffff81001801>] prepare_exit_to_usermode+0x8c/0xa7
      [  120.880011]        [<ffffffff81001900>] syscall_return_slowpath+0xe4/0x104
      [  120.880011]        [<ffffffff813ad931>] int_ret_from_sys_call+0x25/0x9f
      [  120.880011]
      [  120.880011] other info that might help us debug this:
      [  120.880011]
      [  120.880011]  Possible unsafe locking scenario:
      [  120.880011]
      [  120.880011]        CPU0                    CPU1
      [  120.880011]        ----                    ----
      [  120.880011]   lock(rtnl_mutex);
      [  120.880011]                                lock(&pn->all_ppp_mutex);
      [  120.880011]                                lock(rtnl_mutex);
      [  120.880011]   lock(&pn->all_ppp_mutex);
      [  120.880011]
      [  120.880011]  *** DEADLOCK ***
      
      Fixes: 8cb775bc ("ppp: fix device unregistration upon netns deletion")
      Reported-by: NSedat Dilek <sedat.dilek@gmail.com>
      Tested-by: NSedat Dilek <sedat.dilek@gmail.com>
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      58a89eca
    • S
      net: via/Kconfig: GENERIC_PCI_IOMAP required if PCI not selected · 21343ac2
      Sudip Mukherjee 提交于
      The builds of allmodconfig of avr32 is failing with:
      
      drivers/net/ethernet/via/via-rhine.c:1098:2: error: implicit declaration
      of function 'pci_iomap' [-Werror=implicit-function-declaration]
      drivers/net/ethernet/via/via-rhine.c:1119:2: error: implicit declaration
      of function 'pci_iounmap' [-Werror=implicit-function-declaration]
      
      The generic empty pci_iomap and pci_iounmap is used only if CONFIG_PCI
      is not defined and CONFIG_GENERIC_PCI_IOMAP is defined.
      
      Add GENERIC_PCI_IOMAP in the dependency list for VIA_RHINE as we are
      getting build failure when CONFIG_PCI and CONFIG_GENERIC_PCI_IOMAP both
      are not defined.
      Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      21343ac2
    • R
      phy: marvell: add link partner advertised modes · 357cd64c
      Russell King 提交于
      Read the standard link partner advertisment registers and store it in
      phydev->lp_advertising, so ethtool can report this information to
      userspace via ethtool.  Zero it as per genphy if autonegotiation is
      disabled.  Tested with a Marvell 88E1512 PHY.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      357cd64c
  9. 25 9月, 2015 9 次提交
  10. 24 9月, 2015 5 次提交