1. 10 Nov, 2015 5 commits
    • Vlad Yasevich's avatar
      Revert "bridge: Allow forward delay to be cfgd when STP enabled" · 8a921265
      Vlad Yasevich authored
      This reverts commit 34c2d9fb.
      
      There are 2 reasons for this revert:
       1)  The commit in question doesn't do what it says it does.  The
           description reads: "Allow bridge forward delay to be configured
           when Spanning Tree is enabled."  This was already the case before
           the commit was made.  What the commit actually do was disallow
           invalid values or 'forward_delay' when STP was turned off.
      
       2)  The above change was actually a change in the user observed
           behavior and broke things like libvirt and other network configs
           that set 'forward_delay' to 0 without enabling STP.  The value
           of 0 is actually used when STP is turned off to immediately mark
           the bridge as forwarding.
      Signed-off-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8a921265
    • Steven Rostedt's avatar
      bpf_trace: Make dependent on PERF_EVENTS · a31d82d8
      Steven Rostedt authored
      Arnd Bergmann reported:
      
        In my ARM randconfig tests, I'm getting a build error for
        newly added code in bpf_perf_event_read and bpf_perf_event_output
        whenever CONFIG_PERF_EVENTS is disabled:
      
        kernel/trace/bpf_trace.c: In function 'bpf_perf_event_read':
        kernel/trace/bpf_trace.c:203:11: error: 'struct perf_event' has no member named 'oncpu'
        if (event->oncpu != smp_processor_id() ||
                 ^
        kernel/trace/bpf_trace.c:204:11: error: 'struct perf_event' has no member named 'pmu'
              event->pmu->count)
      
        This can happen when UPROBE_EVENT is enabled but KPROBE_EVENT
        is disabled. I'm not sure if that is a configuration we care
        about, otherwise we could prevent this case from occuring by
        adding Kconfig dependencies.
      
      Looking at this further, it's really that UPROBE_EVENT enables PERF_EVENTS.
      By just having BPF_EVENTS depend on PERF_EVENTS, then all is fine.
      
      Link: http://lkml.kernel.org/r/4525348.Aq9YoXkChv@wuerfelReported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a31d82d8
    • Arnd Bergmann's avatar
      qed: select ZLIB_INFLATE · 4bdb96cb
      Arnd Bergmann authored
      The newly added qlogic qed driver uses the zlib library, but
      misses the dependency:
      
      drivers/built-in.o: In function `qed_alloc_stream_mem':
      drivers/net/ethernet/qlogic/qed/qed_main.c:707: undefined reference to `zlib_inflate_workspacesize'
      drivers/built-in.o: In function `qed_unzip_data':
      drivers/net/ethernet/qlogic/qed/qed_main.c:675: undefined reference to `zlib_inflateInit2'
      
      This changes Kconfig to always select zlib when needed.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: fe56b9e6 ("qed: Add module with basic common support")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4bdb96cb
    • Eric Dumazet's avatar
      net: fix a race in dst_release() · d69bbf88
      Eric Dumazet authored
      Only cpu seeing dst refcount going to 0 can safely
      dereference dst->flags.
      
      Otherwise an other cpu might already have freed the dst.
      
      Fixes: 27b75c95 ("net: avoid RCU for NOCACHE dst")
      Reported-by: default avatarGreg Thelen <gthelen@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d69bbf88
    • Justin Maggard's avatar
      net: mvneta: Fix memory use after free. · 8c94ddbc
      Justin Maggard authored
      After changing an interface's MTU, then bringing the interface down and
      back up again, I immediately saw tons of kernel messages like below.
      The reason for this bad behavior is mvneta_rxq_drop_pkts(), which calls
      dma_unmap_single() on already-freed memory.  So we need to switch the
      order of those two operations.
      
      [  152.388518] BUG: Bad page state in process ifconfig  pfn:1b518
      [  152.388526] page:dff3dbc0 count:0 mapcount:0 mapping:  (null) index:0x0
      [  152.395178] flags: 0x200(arch_1)
      [  152.398441] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set
      [  152.398446] bad because of flags:
      [  152.398450] flags: 0x200(arch_1)
      [  152.401716] Modules linked in:
      [  152.401728] CPU: 0 PID: 1453 Comm: ifconfig Tainted: P    B      O    4.1.12.armada.1 #1
      [  152.401733] Hardware name: Marvell Armada 370/XP (Device Tree)
      [  152.401749] [<c0015b1c>] (unwind_backtrace) from [<c0011d8c>] (show_stack+0x10/0x14)
      [  152.401762] [<c0011d8c>] (show_stack) from [<c06aa68c>] (dump_stack+0x74/0x90)
      [  152.401772] [<c06aa68c>] (dump_stack) from [<c0096c08>] (bad_page+0xc4/0x124)
      [  152.401783] [<c0096c08>] (bad_page) from [<c0099378>] (get_page_from_freelist+0x4e4/0x644)
      [  152.401794] [<c0099378>] (get_page_from_freelist) from [<c0099620>] (__alloc_pages_nodemask+0x148/0x784)
      [  152.401805] [<c0099620>] (__alloc_pages_nodemask) from [<c00ac658>] (kmalloc_order+0x10/0x20)
      [  152.401818] [<c00ac658>] (kmalloc_order) from [<c04c6f44>] (mvneta_rx_refill+0xc4/0xe8)
      [  152.401830] [<c04c6f44>] (mvneta_rx_refill) from [<c04c96c0>] (mvneta_setup_rxqs+0x298/0x39c)
      [  152.401842] [<c04c96c0>] (mvneta_setup_rxqs) from [<c04c9904>] (mvneta_open+0x3c/0x150)
      [  152.401853] [<c04c9904>] (mvneta_open) from [<c0597764>] (__dev_open+0xac/0x124)
      [  152.401864] [<c0597764>] (__dev_open) from [<c05979e4>] (__dev_change_flags+0x8c/0x148)
      [  152.401875] [<c05979e4>] (__dev_change_flags) from [<c0597ac0>] (dev_change_flags+0x18/0x48)
      [  152.401886] [<c0597ac0>] (dev_change_flags) from [<c060d308>] (devinet_ioctl+0x620/0x6d0)
      [  152.401897] [<c060d308>] (devinet_ioctl) from [<c057d810>] (sock_ioctl+0x64/0x288)
      [  152.401908] [<c057d810>] (sock_ioctl) from [<c00dcb7c>] (do_vfs_ioctl+0x78/0x608)
      [  152.401918] [<c00dcb7c>] (do_vfs_ioctl) from [<c00dd170>] (SyS_ioctl+0x64/0x74)
      [  152.401930] [<c00dd170>] (SyS_ioctl) from [<c000f3a0>] (ret_fast_syscall+0x0/0x3c)
      Signed-off-by: default avatarJustin Maggard <jmaggard@netgear.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8c94ddbc
  2. 09 Nov, 2015 15 commits
    • Niklas Cassel's avatar
      net: Documentation: Fix default value tcp_limit_output_bytes · 821b4144
      Niklas Cassel authored
      Commit c39c4c6a ("tcp: double default TSQ output bytes limit")
      updated default value for tcp_limit_output_bytes
      Signed-off-by: default avatarNiklas Cassel <niklas.cassel@axis.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      821b4144
    • Vlad Yasevich's avatar
      macvtap: Resolve possible __might_sleep warning in macvtap_do_read() · a499a2e9
      Vlad Yasevich authored
      macvtap_do_read code calls macvtap_put_user while it might be set up
      to wait for the user.  This results in the following warning:
      
      Jun 23 16:25:26 galen kernel: ------------[ cut here ]------------
      Jun 23 16:25:26 galen kernel: WARNING: CPU: 0 PID: 30433 at kernel/sched/core.c:
      7286 __might_sleep+0x7f/0x90()
      Jun 23 16:25:26 galen kernel: do not call blocking ops when !TASK_RUNNING; state
      =1 set at [<ffffffff810f1c1f>] prepare_to_wait+0x2f/0x90
      Jun 23 16:25:26 galen kernel: CPU: 0 PID: 30433 Comm: cat Not tainted 4.1.0-rc6+
       #11
      Jun 23 16:25:26 galen kernel: Call Trace:
      Jun 23 16:25:26 galen kernel: [<ffffffff817f76ba>] dump_stack+0x4c/0x65
      Jun 23 16:25:26 galen kernel: [<ffffffff810a07ca>] warn_slowpath_common+0x8a/0xc
      0
      Jun 23 16:25:26 galen kernel: [<ffffffff810a0846>] warn_slowpath_fmt+0x46/0x50
      Jun 23 16:25:26 galen kernel: [<ffffffff810f1c1f>] ?  prepare_to_wait+0x2f/0x90
      Jun 23 16:25:26 galen kernel: [<ffffffff810f1c1f>] ?  prepare_to_wait+0x2f/0x90
      Jun 23 16:25:26 galen kernel: [<ffffffff810cdc1f>] __might_sleep+0x7f/0x90
      Jun 23 16:25:26 galen kernel: [<ffffffff811f8e15>] might_fault+0x55/0xb0
      Jun 23 16:25:26 galen kernel: [<ffffffff810fab9d>] ?  trace_hardirqs_on_caller+0x fd/0x1c0
      Jun 23 16:25:26 galen kernel: [<ffffffff813f639c>] copy_to_iter+0x7c/0x360
      Jun 23 16:25:26 galen kernel: [<ffffffffa052da86>] macvtap_do_read+0x256/0x3d0 [macvtap]
      Jun 23 16:25:26 galen kernel: [<ffffffff810f20e0>] ?  prepare_to_wait_event+0x110/0x110
      Jun 23 16:25:26 galen kernel: [<ffffffffa052dcab>] macvtap_read_iter+0x2b/0x50 [macvtap]
      Jun 23 16:25:26 galen kernel: [<ffffffff81247f2e>] __vfs_read+0xae/0xe0
      Jun 23 16:25:26 galen kernel: [<ffffffff81248526>] vfs_read+0x86/0x140
      Jun 23 16:25:26 galen kernel: [<ffffffff812493b9>] SyS_read+0x49/0xb0
      Jun 23 16:25:26 galen kernel: [<ffffffff8180182e>] system_call_fastpath+0x12/0x76
      Jun 23 16:25:26 galen kernel: ---[ end trace 22e33f67e70c0c2a ]---
      
      Make sure thet we call finish_wait() if we have the skb to process
      before trying to actually process it.
      Signed-off-by: default avatarVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a499a2e9
    • Arnd Bergmann's avatar
      mvneta: add FIXED_PHY dependency · 4bed5395
      Arnd Bergmann authored
      The fixed_phy infrastructure is done in a way that is optional,
      by providing 'static inline' helper functions doing nothing in
      include/linux/phy_fixed.h for all its APIs. However, three out
      of the four users (DSA, BCMGENET, and SYSTEMPORT) always
      'select FIXED_PHY', presumably because they need that.
      MVNETA is the fourth one, and if that is built-in but FIXED_PHY
      is configured as a loadable module, we get a link error:
      
      drivers/built-in.o: In function `mvneta_fixed_link_update':
      fpga-mgr.c:(.text+0x33ed80): undefined reference to `fixed_phy_update_state'
      
      Presumably this driver has the same dependency as the others,
      so this patch also uses 'select' to ensure that the fixed-phy
      support is built-in.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 898b2970 ("mvneta: implement SGMII-based in-band link state signaling")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4bed5395
    • Rasmus Villemoes's avatar
      net: caif: check return value of alloc_netdev · cfb76d77
      Rasmus Villemoes authored
      I don't know if dev can actually be NULL here, but the test should be
      above alloc_netdev(), to avoid leaking the struct net_device in case
      dev is actually NULL. And of course the return value from alloc_netdev
      should be tested.
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cfb76d77
    • Geert Uytterhoeven's avatar
      net: hisilicon: NET_VENDOR_HISILICON should depend on HAS_DMA · 3870502a
      Geert Uytterhoeven authored
      If NO_DMA=y:
      
          ERROR: "dma_set_mask" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_unmap_single" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_unmap_page" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_mapping_error" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_map_page" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_supported" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_map_single" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_set_mask" [drivers/net/ethernet/hisilicon/hns/hns_dsaf.ko] undefined!
          ERROR: "dma_supported" [drivers/net/ethernet/hisilicon/hns/hns_dsaf.ko] undefined!
          ERROR: "dma_unmap_single" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined!
          ERROR: "dma_unmap_page" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined!
          ERROR: "dma_mapping_error" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined!
          ERROR: "dma_map_page" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined!
          ERROR: "dma_map_single" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined!
          ERROR: "dma_alloc_coherent" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined!
          ERROR: "dma_mapping_error" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined!
          ERROR: "dma_map_single" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined!
          ERROR: "dma_unmap_single" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined!
          ERROR: "dma_free_coherent" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined!
          ERROR: "dma_alloc_coherent" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined!
          ERROR: "dma_mapping_error" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined!
          ERROR: "dma_map_single" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined!
          ERROR: "dma_unmap_single" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined!
          ERROR: "dma_free_coherent" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined!
      
      As this affects all of HNS_ENET, HNS_DSAF, HNS, HIX5HD2_GMAC, and
      HIP04_ETH, add a dependency on HAS_DMA to the main NET_VENDOR_HISILICON
      symbol to fix this.
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3870502a
    • Iyappan Subramanian's avatar
      drivers: net: xgene: fix RGMII 10/100Mb mode · 761d4be5
      Iyappan Subramanian authored
      This patch fixes the RGMII 10/100M mode by reprogramming the clock.
      Signed-off-by: default avatarIyappan Subramanian <isubramanian@apm.com>
      Tested-by: default avatarFushen Chen <fchen@apm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      761d4be5
    • David S. Miller's avatar
      Merge branch 'skb_to_full_sk' · b73c8bfd
      David S. Miller authored
      Eric Dumazet says:
      
      ====================
      net: add skb_to_full_sk() helper
      
      Many contexts need to reach listener socket from skb attached
      to a request socket. This patch series add skb_to_full_sk() to
      clearly express this need and use it where appropriate.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b73c8bfd
    • Eric Dumazet's avatar
      netfilter: nft_meta: use skb_to_full_sk() helper · 3aed8225
      Eric Dumazet authored
      SYNACK packets might be attached to request sockets.
      
      Fixes: ca6fb065 ("tcp: attach SYNACK messages to request sockets instead of listener")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3aed8225
    • Eric Dumazet's avatar
      net_sched: em_meta: use skb_to_full_sk() helper · 02a56c81
      Eric Dumazet authored
      SYNACK packets might be attached to request sockets.
      
      Fixes: ca6fb065 ("tcp: attach SYNACK messages to request sockets instead of listener")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      02a56c81
    • Eric Dumazet's avatar
      sched: cls_flow: use skb_to_full_sk() helper · 743b2a66
      Eric Dumazet authored
      SYNACK packets might be attached to request sockets.
      
      Fixes: ca6fb065 ("tcp: attach SYNACK messages to request sockets instead of listener")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      743b2a66
    • Eric Dumazet's avatar
      netfilter: xt_owner: use skb_to_full_sk() helper · fdd723e2
      Eric Dumazet authored
      SYNACK packets might be attached to a request socket,
      xt_owner wants to gte the listener in this case.
      
      Fixes: ca6fb065 ("tcp: attach SYNACK messages to request sockets instead of listener")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fdd723e2
    • Eric Dumazet's avatar
      smack: use skb_to_full_sk() helper · 8827d90e
      Eric Dumazet authored
      This module wants to access sk->sk_security, which is not
      available for request sockets.
      
      Fixes: ca6fb065 ("tcp: attach SYNACK messages to request sockets instead of listener")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8827d90e
    • Eric Dumazet's avatar
      net: add skb_to_full_sk() helper and use it in selinux_netlbl_skbuff_setsid() · 54abc686
      Eric Dumazet authored
      Generalize selinux_skb_sk() added in commit 212cd089
      ("selinux: fix random read in selinux_ip_postroute_compat()")
      so that we can use it other contexts.
      
      Use it right away in selinux_netlbl_skbuff_setsid()
      
      Fixes: ca6fb065 ("tcp: attach SYNACK messages to request sockets instead of listener")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      54abc686
    • David S. Miller's avatar
      Merge tag 'nfc-fixes-4.4-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-fixes · fb9a10d9
      David S. Miller authored
      Samuel Ortiz says:
      
      ====================
      NFC 4.4 fixes
      
      This is the 1st NFC fixes pull request for 4.4.
      
      It includes bug fixes and one fix for a build failure, all of them
      introduced with the first NFC pull request for 4.4.
      
      We have:
      
      - Fix nfcmrvl SPI driver potential build error due to a broken Kconfig
        dependency.
      - A few fixes for the firmware download implementation for the nfcmrvl
        UART driver.
      - A GPIO allocation leak for the nfcmrvl driver.
      - One code simplification for the nfcmrvl DT handling.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fb9a10d9
    • Yang Shi's avatar
      bpf: doc: correct arch list for supported eBPF JIT · d0b89141
      Yang Shi authored
      aarch64 and s390x support eBPF JIT too, correct document to reflect this and
      avoid any confusion.
      Signed-off-by: default avatarYang Shi <yang.shi@linaro.org>
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d0b89141
  3. 07 Nov, 2015 4 commits
    • Markus Elfring's avatar
      dwc_eth_qos: Delete an unnecessary check before the function call "of_node_put" · 3694bfbd
      Markus Elfring authored
      The of_node_put() function tests whether its argument is NULL
      and then returns immediately.
      Thus the test around the call is not needed.
      
      This issue was detected by using the Coccinelle software.
      Signed-off-by: default avatarMarkus Elfring <elfring@users.sourceforge.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3694bfbd
    • Jay Vosburgh's avatar
      bonding: fix panic on non-ARPHRD_ETHER enslave failure · 40baec22
      Jay Vosburgh authored
      Since commit 7d5cd2ce529b, when bond_enslave fails on devices that
      are not ARPHRD_ETHER, if needed, it resets the bonding device back to
      ARPHRD_ETHER by calling ether_setup.
      
      	Unfortunately, ether_setup clobbers dev->flags, clearing IFF_UP
      if the bond device is up, leaving it in a quasi-down state without
      having actually gone through dev_close.  For bonding, if any periodic
      work queue items are active (miimon, arp_interval, etc), those will
      remain running, as they are stopped by bond_close.  At this point, if
      the bonding module is unloaded or the bond is deleted, the system will
      panic when the work function is called.
      
      	This panic is resolved by calling dev_close on the bond itself
      prior to calling ether_setup.
      
      Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
      Fixes: 7d5cd2ce ("bonding: correctly handle bonding type change on enslave failure")
      Acked-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      40baec22
    • Jarod Wilson's avatar
      net/qlcnic: fix mac address restore in bond mode 5/6 · e824de8a
      Jarod Wilson authored
      The bonding driver saves a copy of slaves' original mac address and then
      assigns whatever mac as needed to the slave, depending on mode. In at
      least modes 5 and 6 (balance-tlb, balance-alb), it often ends up being the
      mac address of another slave. On release from the bond, the original mac
      address is supposed to get restored via a dev_set_mac_address() call in
      the bonding driver's __bond_release_one() function, which calls the
      slave's ndo_set_mac_address function, which for qlcnic, is
      qlcnic_set_mac().
      
      Now, this function tries to be somewhat intelligent and exit early if
      you're trying to set the mac address to the same thing that is already
      set. The problem here is that adapter->mac_addr isn't in sync with
      netdev->dev_addr. The qlcnic driver still has the original mac stored in
      adapter->mac_addr, while the bonding driver has updated netdev->dev_addr,
      so qlcnic thinks we're trying to set the same address it already has.
      
      I think the way to go here, since the function updates both netdev and
      adapter's stored mac addresses, is to check if either of them doesn't
      match the newly requested mac. Simply checking netdev's value only could
      result in a similar mismatch and non-update, so look at both.
      
      CC: Dept-GELinuxNICDev@qlogic.com
      CC: netdev@vger.kernel.org
      CC: Manish Chopra <manish.chopra@qlogic.com>
      Signed-off-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e824de8a
    • Markus Elfring's avatar
      fjes: Delete an unnecessary check before the function call "vfree" · f7b5964d
      Markus Elfring authored
      The vfree() function performs also input parameter validation.
      Thus the test around the call is not needed.
      
      This issue was detected by using the Coccinelle software.
      Signed-off-by: default avatarMarkus Elfring <elfring@users.sourceforge.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f7b5964d
  4. 05 Nov, 2015 16 commits