1. 22 11月, 2014 1 次提交
  2. 21 11月, 2014 8 次提交
  3. 20 11月, 2014 6 次提交
    • A
      cxgb4i : Don't block unload/cxgb4 unload when remote closes TCP connection · ee7255ad
      Anish Bhatt 提交于
      cxgb4i was returning wrong error and not releasing module reference if remote
      end abruptly closed TCP connection. This prevents the cxgb4 network module from
      being unloaded, further affecting other network drivers dependent on cxgb4
      
      Sending to net as this affects all cxgb4 based network drivers.
      Signed-off-by: NAnish Bhatt <anish@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ee7255ad
    • D
      ipv6: delete protocol and unregister rtnetlink when cleanup · ffb1388a
      Duan Jiong 提交于
      pim6_protocol was added when initiation, but it not deleted.
      Similarly, unregister RTNL_FAMILY_IP6MR rtnetlink.
      Signed-off-by: NDuan Jiong <duanj.fnst@cn.fujitsu.com>
      Reviewed-by: NCong Wang <cwang@twopensource.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ffb1388a
    • J
      Merge tag 'mac80211-for-john-2014-11-18' of... · 6158fb37
      John W. Linville 提交于
      Merge tag 'mac80211-for-john-2014-11-18' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
      
      Johannes Berg <johannes@sipsolutions.net> says:
      
      "Here's another last minute fix, for minstrel HT crashing
      depending on the value of some uninitialised stack."
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6158fb37
    • D
      Merge tag 'linux-can-fixes-for-3.18-20141118' of git://gitorious.org/linux-can/linux-can · ddecab1a
      David S. Miller 提交于
      Marc Kleine-Budde says:
      
      ====================
      pull-request: can 2014-11-18
      
      this is a pull request of 17 patches for net/master for the v3.18 release
      cycle.
      
      The last patch of this pull request ("can: m_can: update to support CAN FD
      features") adds, as the description says, a new feature to the m_can driver. As
      the m_can driver has been added in v3.18 there is no risk of causing a
      regression. Give me a note if this is not okay and I'll create a new pull
      request without it.
      
      There is a patch for the CAN infrastructure by Thomas Körper which fixes
      calling kfree_skb() from interrupt context. Roman Fietze fixes a typo also in
      the infrastructure. A patch by Dong Aisheng adds a generic helper function to
      tell if a skb is normal CAN or CAN-FD frame. Alexey Khoroshilov of the Linux
      Driver Verification project fixes a memory leak in the esd_usb2 driver. Two
      patches by Sudip Mukherjee remove unused variables and fixe the signess of a
      variable. Three patches by me add the missing .ndo_change_mtu callback to the
      xilinx_can, rcar_can and gs_usb driver.
      
      The remaining patches improve the m_can driver: David Cohen adds the missing
      CONFIG_HAS_IOMEM dependency. Dong Aisheng provides 6 bugfix patches (most
      important: missing RAM init, sleep in NAPI poll, dlc in RTR). While the last of
      his patches adds CAN FD support to the driver.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ddecab1a
    • 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
  4. 19 11月, 2014 14 次提交
  5. 18 11月, 2014 8 次提交
  6. 17 11月, 2014 3 次提交
    • L
      bridge: fix netfilter/NF_BR_LOCAL_OUT for own, locally generated queries · f0b4eece
      Linus Lüssing 提交于
      Ebtables on the OUTPUT chain (NF_BR_LOCAL_OUT) would not work as expected
      for both locally generated IGMP and MLD queries. The IP header specific
      filter options are off by 14 Bytes for netfilter (actual output on
      interfaces is fine).
      
      NF_HOOK() expects the skb->data to point to the IP header, not the
      ethernet one (while dev_queue_xmit() does not). Luckily there is an
      br_dev_queue_push_xmit() helper function already - let's just use that.
      
      Introduced by eb1d1641
      ("bridge: Add core IGMP snooping support")
      
      Ebtables example:
      
      $ ebtables -I OUTPUT -p IPv6 -o eth1 --logical-out br0 \
      	--log --log-level 6 --log-ip6 --log-prefix="~EBT: " -j DROP
      
      before (broken):
      
      ~EBT:  IN= OUT=eth1 MAC source = 02:04:64:a4:39:c2 \
      	MAC dest = 33:33:00:00:00:01 proto = 0x86dd IPv6 \
      	SRC=64a4:39c2:86dd:6000:0000:0020:0001:fe80 IPv6 \
      	DST=0000:0000:0000:0004:64ff:fea4:39c2:ff02, \
      	IPv6 priority=0x3, Next Header=2
      
      after (working):
      
      ~EBT:  IN= OUT=eth1 MAC source = 02:04:64:a4:39:c2 \
      	MAC dest = 33:33:00:00:00:01 proto = 0x86dd IPv6 \
      	SRC=fe80:0000:0000:0000:0004:64ff:fea4:39c2 IPv6 \
      	DST=ff02:0000:0000:0000:0000:0000:0000:0001, \
      	IPv6 priority=0x0, Next Header=0
      Signed-off-by: NLinus Lüssing <linus.luessing@web.de>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      f0b4eece
    • P
      netfilter: nfnetlink: fix insufficient validation in nfnetlink_bind · 97840cb6
      Pablo Neira Ayuso 提交于
      Make sure the netlink group exists, otherwise you can trigger an out
      of bound array memory access from the netlink_bind() path. This splat
      can only be triggered only by superuser.
      
      [  180.203600] UBSan: Undefined behaviour in ../net/netfilter/nfnetlink.c:467:28
      [  180.204249] index 9 is out of range for type 'int [9]'
      [  180.204697] CPU: 0 PID: 1771 Comm: trinity-main Not tainted 3.18.0-rc4-mm1+ #122
      [  180.205365] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org
      +04/01/2014
      [  180.206498]  0000000000000018 0000000000000000 0000000000000009 ffff88007bdf7da8
      [  180.207220]  ffffffff82b0ef5f 0000000000000092 ffffffff845ae2e0 ffff88007bdf7db8
      [  180.207887]  ffffffff8199e489 ffff88007bdf7e18 ffffffff8199ea22 0000003900000000
      [  180.208639] Call Trace:
      [  180.208857] dump_stack (lib/dump_stack.c:52)
      [  180.209370] ubsan_epilogue (lib/ubsan.c:174)
      [  180.209849] __ubsan_handle_out_of_bounds (lib/ubsan.c:400)
      [  180.210512] nfnetlink_bind (net/netfilter/nfnetlink.c:467)
      [  180.210986] netlink_bind (net/netlink/af_netlink.c:1483)
      [  180.211495] SYSC_bind (net/socket.c:1541)
      
      Moreover, define the missing nf_tables and nf_acct multicast groups too.
      Reported-by: NAndrey Ryabinin <a.ryabinin@samsung.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      97840cb6
    • D
      ipv6: mld: fix add_grhead skb_over_panic for devs with large MTUs · feb91a02
      Daniel Borkmann 提交于
      It has been reported that generating an MLD listener report on
      devices with large MTUs (e.g. 9000) and a high number of IPv6
      addresses can trigger a skb_over_panic():
      
      skbuff: skb_over_panic: text:ffffffff80612a5d len:3776 put:20
      head:ffff88046d751000 data:ffff88046d751010 tail:0xed0 end:0xec0
      dev:port1
       ------------[ cut here ]------------
      kernel BUG at net/core/skbuff.c:100!
      invalid opcode: 0000 [#1] SMP
      Modules linked in: ixgbe(O)
      CPU: 3 PID: 0 Comm: swapper/3 Tainted: G O 3.14.23+ #4
      [...]
      Call Trace:
       <IRQ>
       [<ffffffff80578226>] ? skb_put+0x3a/0x3b
       [<ffffffff80612a5d>] ? add_grhead+0x45/0x8e
       [<ffffffff80612e3a>] ? add_grec+0x394/0x3d4
       [<ffffffff80613222>] ? mld_ifc_timer_expire+0x195/0x20d
       [<ffffffff8061308d>] ? mld_dad_timer_expire+0x45/0x45
       [<ffffffff80255b5d>] ? call_timer_fn.isra.29+0x12/0x68
       [<ffffffff80255d16>] ? run_timer_softirq+0x163/0x182
       [<ffffffff80250e6f>] ? __do_softirq+0xe0/0x21d
       [<ffffffff8025112b>] ? irq_exit+0x4e/0xd3
       [<ffffffff802214bb>] ? smp_apic_timer_interrupt+0x3b/0x46
       [<ffffffff8063f10a>] ? apic_timer_interrupt+0x6a/0x70
      
      mld_newpack() skb allocations are usually requested with dev->mtu
      in size, since commit 72e09ad1 ("ipv6: avoid high order allocations")
      we have changed the limit in order to be less likely to fail.
      
      However, in MLD/IGMP code, we have some rather ugly AVAILABLE(skb)
      macros, which determine if we may end up doing an skb_put() for
      adding another record. To avoid possible fragmentation, we check
      the skb's tailroom as skb->dev->mtu - skb->len, which is a wrong
      assumption as the actual max allocation size can be much smaller.
      
      The IGMP case doesn't have this issue as commit 57e1ab6e
      ("igmp: refine skb allocations") stores the allocation size in
      the cb[].
      
      Set a reserved_tailroom to make it fit into the MTU and use
      skb_availroom() helper instead. This also allows to get rid of
      igmp_skb_size().
      Reported-by: NWei Liu <lw1a2.jing@gmail.com>
      Fixes: 72e09ad1 ("ipv6: avoid high order allocations")
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Cc: David L Stevens <david.stevens@oracle.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      feb91a02