1. 27 11月, 2014 6 次提交
  2. 26 11月, 2014 2 次提交
  3. 25 11月, 2014 1 次提交
  4. 24 11月, 2014 3 次提交
    • C
      igb: Fixes needed for surprise removal support · 17a402a0
      Carolyn Wyborny 提交于
      This patch adds some checks in order to prevent panic's on surprise
      removal of devices during S0, S3, S4.  Without this patch, Thunderbolt
      type device removal will panic the system.
      Signed-off-by: NYanir Lubetkin <yanirx.lubetkin@intel.com>
      Signed-off-by: NCarolyn Wyborny <carolyn.wyborny@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      17a402a0
    • D
      ixgbe: fix use after free adapter->state test in ixgbe_remove/ixgbe_probe · b5b2ffc0
      Daniel Borkmann 提交于
      While working on a different issue, I noticed an annoying use
      after free bug on my machine when unloading the ixgbe driver:
      
      [ 8642.318797] ixgbe 0000:02:00.1: removed PHC on p2p2
      [ 8642.742716] ixgbe 0000:02:00.1: complete
      [ 8642.743784] BUG: unable to handle kernel paging request at ffff8807d3740a90
      [ 8642.744828] IP: [<ffffffffa01c77dc>] ixgbe_remove+0xfc/0x1b0 [ixgbe]
      [ 8642.745886] PGD 20c6067 PUD 81c1f6067 PMD 81c15a067 PTE 80000007d3740060
      [ 8642.746956] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
      [ 8642.748039] Modules linked in: [...]
      [ 8642.752929] CPU: 1 PID: 1225 Comm: rmmod Not tainted 3.18.0-rc2+ #49
      [ 8642.754203] Hardware name: Supermicro X10SLM-F/X10SLM-F, BIOS 1.1b 11/01/2013
      [ 8642.755505] task: ffff8807e34d3fe0 ti: ffff8807b7204000 task.ti: ffff8807b7204000
      [ 8642.756831] RIP: 0010:[<ffffffffa01c77dc>]  [<ffffffffa01c77dc>] ixgbe_remove+0xfc/0x1b0 [ixgbe]
      [...]
      [ 8642.774335] Stack:
      [ 8642.775805]  ffff8807ee824098 ffff8807ee824098 ffffffffa01f3000 ffff8807ee824000
      [ 8642.777326]  ffff8807b7207e18 ffffffff8137720f ffff8807ee824098 ffff8807ee824098
      [ 8642.778848]  ffffffffa01f3068 ffff8807ee8240f8 ffff8807b7207e38 ffffffff8144180f
      [ 8642.780365] Call Trace:
      [ 8642.781869]  [<ffffffff8137720f>] pci_device_remove+0x3f/0xc0
      [ 8642.783395]  [<ffffffff8144180f>] __device_release_driver+0x7f/0xf0
      [ 8642.784876]  [<ffffffff814421f8>] driver_detach+0xb8/0xc0
      [ 8642.786352]  [<ffffffff814414a9>] bus_remove_driver+0x59/0xe0
      [ 8642.787783]  [<ffffffff814429d0>] driver_unregister+0x30/0x70
      [ 8642.789202]  [<ffffffff81375c65>] pci_unregister_driver+0x25/0xa0
      [ 8642.790657]  [<ffffffffa01eb38e>] ixgbe_exit_module+0x1c/0xc8e [ixgbe]
      [ 8642.792064]  [<ffffffff810f93a2>] SyS_delete_module+0x132/0x1c0
      [ 8642.793450]  [<ffffffff81012c61>] ? do_notify_resume+0x61/0xa0
      [ 8642.794837]  [<ffffffff816d2029>] system_call_fastpath+0x12/0x17
      
      The issue is that test_and_set_bit() done on adapter->state is being
      performed *after* the netdevice has been freed via free_netdev().
      
      When netdev is being allocated on initialization time, it allocates
      a private area, here struct ixgbe_adapter, that resides after the
      net_device structure. In ixgbe_probe(), the device init routine,
      we set up the adapter after alloc_etherdev_mq() on the private area
      and add a reference for the pci_dev as well via pci_set_drvdata().
      
      Both in the error path of ixgbe_probe(), but also on module unload
      when ixgbe_remove() is being called, commit 41c62843 ("ixgbe:
      Fix rcu warnings induced by LER") accesses adapter after free_netdev().
      The patch stores the result in a bool and thus fixes above oops on my
      side.
      
      Fixes: 41c62843 ("ixgbe: Fix rcu warnings induced by LER")
      Cc: stable <stable@vger.kernel.org>
      Cc: Mark Rustad <mark.d.rustad@intel.com>
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b5b2ffc0
    • V
      ixgbe: Correctly disable VLAN filter in promiscuous mode · 4556dc59
      Vlad Yasevich 提交于
      IXGBE adapter seems to require that VLAN filtering be enabled if
      VMDQ or SRIOV are enabled.  When those functions are disabled,
      VLAN filtering may be disabled in promiscuous mode.
      
      Prior to commit a9b8943e ("ixgbe: remove vlan_filter_disable
      and enable functions")
      
      The logic was correct.  However, after the commit the logic
      got reversed and VLAN filtered in now turned on when VMDQ/SRIOV
      is disabled.
      
      This patch changes the condition to enable hw vlan filtered
      when VMDQ or SRIOV is enabled.
      
      Fixes: a9b8943e ("ixgbe: remove vlan_filter_disable and enable functions")
      Cc: stable <stable@vger.kernel.org>
      CC: Jacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Acked-by: NEmil Tantilov <emil.s.tantilov@intel.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4556dc59
  5. 21 11月, 2014 4 次提交
  6. 20 11月, 2014 2 次提交
    • O
      net/mlx4_en: Add VXLAN ndo calls to the PF net device ops too · 9737c6ab
      Or Gerlitz 提交于
      This is currently missing, which results in a crash when one attempts
      to set VXLAN tunnel over the mlx4_en when acting as PF.
      
      	[ 2408.785472] BUG: unable to handle kernel NULL pointer dereference at (null)
      	[...]
      	[ 2408.994104] Call Trace:
      	[ 2408.996584]  [<ffffffffa021f7f5>] ? vxlan_get_rx_port+0xd6/0x103 [vxlan]
      	[ 2409.003316]  [<ffffffffa021f71f>] ? vxlan_lowerdev_event+0xf2/0xf2 [vxlan]
      	[ 2409.010225]  [<ffffffffa0630358>] mlx4_en_start_port+0x862/0x96a [mlx4_en]
      	[ 2409.017132]  [<ffffffffa063070f>] mlx4_en_open+0x17f/0x1b8 [mlx4_en]
      
      While here, make sure to invoke vxlan_get_rx_port() only when VXLAN
      offloads are actually enabled and not when they are only supported.
      Reported-by: NIdo Shamay <idos@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9737c6ab
    • N
      bonding: fix curr_active_slave/carrier with loadbalance arp monitoring · b8e4500f
      Nikolay Aleksandrov 提交于
      Since commit 6fde8f03 ("bonding: fix locking in
      bond_loadbalance_arp_mon()") we can have a stale bond carrier state and
      stale curr_active_slave when using arp monitoring in loadbalance modes. The
      reason is that in bond_loadbalance_arp_mon() we can't have
      do_failover == true but slave_state_changed == false, whenever do_failover
      is true then slave_state_changed is also true. Then the following piece
      from bond_loadbalance_arp_mon():
                      if (slave_state_changed) {
                              bond_slave_state_change(bond);
                              if (BOND_MODE(bond) == BOND_MODE_XOR)
                                      bond_update_slave_arr(bond, NULL);
                      } else if (do_failover) {
                              block_netpoll_tx();
                              bond_select_active_slave(bond);
                              unblock_netpoll_tx();
                      }
      
      will execute only the first branch, always and regardless of do_failover.
      Since these two events aren't related in such way, we need to decouple and
      consider them separately.
      
      For example this issue could lead to the following result:
      Bonding Mode: load balancing (round-robin)
      *MII Status: down*
      MII Polling Interval (ms): 0
      Up Delay (ms): 0
      Down Delay (ms): 0
      ARP Polling Interval (ms): 100
      ARP IP target/s (n.n.n.n form): 192.168.9.2
      
      Slave Interface: ens12
      *MII Status: up*
      Speed: 10000 Mbps
      Duplex: full
      Link Failure Count: 2
      Permanent HW addr: 00:0f:53:01:42:2c
      Slave queue ID: 0
      
      Slave Interface: eth1
      *MII Status: up*
      Speed: Unknown
      Duplex: Unknown
      Link Failure Count: 70
      Permanent HW addr: 52:54:00:2f:0f:8e
      Slave queue ID: 0
      
      Since some interfaces are up, then the status of the bond should also be
      up, but it will never change unless something invokes bond_set_carrier()
      (i.e. enslave, bond_select_active_slave etc). Now, if I force the
      calling of bond_select_active_slave via for example changing
      primary_reselect (it can change in any mode), then the MII status goes to
      "up" because it calls bond_select_active_slave() which should've been done
      from bond_loadbalance_arp_mon() itself.
      
      CC: Veaceslav Falico <vfalico@gmail.com>
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Ding Tianhong <dingtianhong@huawei.com>
      
      Fixes: 6fde8f03 ("bonding: fix locking in bond_loadbalance_arp_mon()")
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Acked-by: NVeaceslav Falico <vfalico@gmail.com>
      Acked-by: NAndy Gospodarek <gospo@cumulusnetworks.com>
      Acked-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b8e4500f
  7. 19 11月, 2014 13 次提交
  8. 18 11月, 2014 7 次提交
    • S
      can: remove unused variable · 4e2061b1
      Sudip Mukherjee 提交于
      these variable were only assigned some values, but then never
      reused again.
      so they are safe to be removed.
      Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      4e2061b1
    • A
      can: esd_usb2: fix memory leak on disconnect · efbd50d2
      Alexey Khoroshilov 提交于
      It seems struct esd_usb2 dev is not deallocated on disconnect. The patch adds
      the missing deallocation.
      
      Found by Linux Driver Verification project (linuxtesting.org).
      Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
      Acked-by: NMatthias Fuchs <matthias.fuchs@esd.eu>
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      efbd50d2
    • R
      can: dev: fix typo CIA -> CiA, CAN in Automation · 67b5909e
      Roman Fietze 提交于
      This patch fixes a typo in CAN's dev.c:
      
          CIA -> CiA
      
      which stands for CAN in Automation.
      Signed-off-by: NRoman Fietze <roman.fietze@telemotive.de>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      67b5909e
    • T
      can: dev: avoid calling kfree_skb() from interrupt context · 5247a589
      Thomas Körper 提交于
      ikfree_skb() is Called in can_free_echo_skb(), which might be called from (TX
      Error) interrupt, which triggers the folloing warning:
      
      [ 1153.360705] ------------[ cut here ]------------
      [ 1153.360715] WARNING: CPU: 0 PID: 31 at net/core/skbuff.c:563 skb_release_head_state+0xb9/0xd0()
      [ 1153.360772] Call Trace:
      [ 1153.360778]  [<c167906f>] dump_stack+0x41/0x52
      [ 1153.360782]  [<c105bb7e>] warn_slowpath_common+0x7e/0xa0
      [ 1153.360784]  [<c158b909>] ? skb_release_head_state+0xb9/0xd0
      [ 1153.360786]  [<c158b909>] ? skb_release_head_state+0xb9/0xd0
      [ 1153.360788]  [<c105bc42>] warn_slowpath_null+0x22/0x30
      [ 1153.360791]  [<c158b909>] skb_release_head_state+0xb9/0xd0
      [ 1153.360793]  [<c158be90>] skb_release_all+0x10/0x30
      [ 1153.360795]  [<c158bf06>] kfree_skb+0x36/0x80
      [ 1153.360799]  [<f8486938>] ? can_free_echo_skb+0x28/0x40 [can_dev]
      [ 1153.360802]  [<f8486938>] can_free_echo_skb+0x28/0x40 [can_dev]
      [ 1153.360805]  [<f849a12c>] esd_pci402_interrupt+0x34c/0x57a [esd402]
      [ 1153.360809]  [<c10a75b5>] handle_irq_event_percpu+0x35/0x180
      [ 1153.360811]  [<c10a7623>] ? handle_irq_event_percpu+0xa3/0x180
      [ 1153.360813]  [<c10a7731>] handle_irq_event+0x31/0x50
      [ 1153.360816]  [<c10a9c7f>] handle_fasteoi_irq+0x6f/0x120
      [ 1153.360818]  [<c10a9c10>] ? handle_edge_irq+0x110/0x110
      [ 1153.360822]  [<c1011b61>] handle_irq+0x71/0x90
      [ 1153.360823]  <IRQ>  [<c168152c>] do_IRQ+0x3c/0xd0
      [ 1153.360829]  [<c1680b6c>] common_interrupt+0x2c/0x34
      [ 1153.360834]  [<c107d277>] ? finish_task_switch+0x47/0xf0
      [ 1153.360836]  [<c167c27b>] __schedule+0x35b/0x7e0
      [ 1153.360839]  [<c10a5334>] ? console_unlock+0x2c4/0x4d0
      [ 1153.360842]  [<c13df500>] ? n_tty_receive_buf_common+0x890/0x890
      [ 1153.360845]  [<c10707b6>] ? process_one_work+0x196/0x370
      [ 1153.360847]  [<c167c723>] schedule+0x23/0x60
      [ 1153.360849]  [<c1070de1>] worker_thread+0x161/0x460
      [ 1153.360852]  [<c1090fcf>] ? __wake_up_locked+0x1f/0x30
      [ 1153.360854]  [<c1070c80>] ? rescuer_thread+0x2f0/0x2f0
      [ 1153.360856]  [<c1074f01>] kthread+0xa1/0xc0
      [ 1153.360859]  [<c1680401>] ret_from_kernel_thread+0x21/0x30
      [ 1153.360861]  [<c1074e60>] ? kthread_create_on_node+0x110/0x110
      [ 1153.360863] ---[ end trace 5ff83639cbb74b35 ]---
      
      This patch replaces the kfree_skb() by dev_kfree_skb_any().
      Signed-off-by: NThomas Körper <thomas.koerper@esd.eu>
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      5247a589
    • D
      brcmfmac: fix error handling of irq_of_parse_and_map · 4c69f05e
      Dmitry Torokhov 提交于
      Return value of irq_of_parse_and_map() is unsigned int, with 0
      indicating failure, so testing for negative result never works.
      Signed-off-by: NDmitry Torokhov <dtor@chromium.org>
      Cc: stable@vger.kernel.org # v3.17
      Acked-by: NArend van Spriel <arend@broadcom.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4c69f05e
    • M
      brcmfmac: kill URB when request timed out · 8180bd47
      Mathy Vanhoef 提交于
      Kill the submitted URB in brcmf_usb_dl_cmd if the request timed out. This
      assures the URB is never submitted twice. It also prevents a possible
      use-after-free of the URB transfer buffer if a timeout occurs.
      Signed-off-by: NMathy Vanhoef <vanhoefm@gmail.com>
      Acked-by: NArend van Spriel <arend@broadcom.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8180bd47
    • B
      ath9k: fix regression in bssidmask calculation · daad1660
      Ben Greear 提交于
      The commit that went into 3.17:
      
          ath9k: Summarize hw state per channel context
      
          Group and set hw state (opmode, primary_sta, beacon conf) per
          channel context instead of whole list of vifs. This would allow
          each channel context to run in different mode (STA/AP).
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      
      broke multi-vif configuration due to not properly calculating
      the bssid mask.
      
      The test case that caught this was:
      
       create wlan0 and sta0-4 (6 total), not sure how much that matters.
       associate all 6 (works fine)
       disconnect 5 of them, leaving sta0 up
       Start trying to bring up the other 5 one at a time.  It will
       fail, with iw events looking like this (in these logs, several
       sta are trying to come up, but symptom is the same with just one)
      
      The patch causing the regression made quite a few changes, but
      the part I think caused this particular problem was not
      recalculating the bssid mask when adding and removing interfaces.
      
      Re-adding those calls fixes my test case.  Fix bad comment
      as well.
      Signed-off-by: NBen Greear <greearb@candelatech.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      daad1660
  9. 17 11月, 2014 2 次提交