1. 26 6月, 2014 5 次提交
  2. 25 6月, 2014 1 次提交
    • L
      cxgb4: Not need to hold the adap_rcu_lock lock when read adap_rcu_list · ee9a33b2
      Li RongQing 提交于
      cxgb4_netdev maybe lead to dead lock, since it uses a spin lock, and be called
      in both thread and softirq context, but not disable BH, the lockdep report is
      below; In fact, cxgb4_netdev only reads adap_rcu_list with RCU protection, so
      not need to hold spin lock again.
      	=================================
      	[ INFO: inconsistent lock state ]
      	3.14.7+ #24 Tainted: G         C O
      	---------------------------------
      	inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
      	radvd/3794 [HC0[0]:SC1[1]:HE1:SE0] takes:
      	 (adap_rcu_lock){+.?...}, at: [<ffffffffa09989ea>] clip_add+0x2c/0x116 [cxgb4]
      	{SOFTIRQ-ON-W} state was registered at:
      	  [<ffffffff810fca81>] __lock_acquire+0x34a/0xe48
      	  [<ffffffff810fd98b>] lock_acquire+0x82/0x9d
      	  [<ffffffff815d6ff8>] _raw_spin_lock+0x34/0x43
      	  [<ffffffffa09989ea>] clip_add+0x2c/0x116 [cxgb4]
      	  [<ffffffffa0998beb>] cxgb4_inet6addr_handler+0x117/0x12c [cxgb4]
      	  [<ffffffff815da98b>] notifier_call_chain+0x32/0x5c
      	  [<ffffffff815da9f9>] __atomic_notifier_call_chain+0x44/0x6e
      	  [<ffffffff815daa32>] atomic_notifier_call_chain+0xf/0x11
      	  [<ffffffff815b1356>] inet6addr_notifier_call_chain+0x16/0x18
      	  [<ffffffffa01f72e5>] ipv6_add_addr+0x404/0x46e [ipv6]
      	  [<ffffffffa01f8df0>] addrconf_add_linklocal+0x5f/0x95 [ipv6]
      	  [<ffffffffa01fc3e9>] addrconf_notify+0x632/0x841 [ipv6]
      	  [<ffffffff815da98b>] notifier_call_chain+0x32/0x5c
      	  [<ffffffff810e09a1>] __raw_notifier_call_chain+0x9/0xb
      	  [<ffffffff810e09b2>] raw_notifier_call_chain+0xf/0x11
      	  [<ffffffff8151b3b7>] call_netdevice_notifiers_info+0x4e/0x56
      	  [<ffffffff8151b3d0>] call_netdevice_notifiers+0x11/0x13
      	  [<ffffffff8151c0a6>] netdev_state_change+0x1f/0x38
      	  [<ffffffff8152f004>] linkwatch_do_dev+0x3b/0x49
      	  [<ffffffff8152f184>] __linkwatch_run_queue+0x10b/0x144
      	  [<ffffffff8152f1dd>] linkwatch_event+0x20/0x27
      	  [<ffffffff810d7bc0>] process_one_work+0x1cb/0x2ee
      	  [<ffffffff810d7e3b>] worker_thread+0x12e/0x1fc
      	  [<ffffffff810dd391>] kthread+0xc4/0xcc
      	  [<ffffffff815dc48c>] ret_from_fork+0x7c/0xb0
      	irq event stamp: 3388
      	hardirqs last  enabled at (3388): [<ffffffff810c6c85>]
      	__local_bh_enable_ip+0xaa/0xd9
      	hardirqs last disabled at (3387): [<ffffffff810c6c2d>]
      	__local_bh_enable_ip+0x52/0xd9
      	softirqs last  enabled at (3288): [<ffffffffa01f1d5b>]
      	rcu_read_unlock_bh+0x0/0x2f [ipv6]
      	softirqs last disabled at (3289): [<ffffffff815ddafc>]
      	do_softirq_own_stack+0x1c/0x30
      
      	other info that might help us debug this:
      	 Possible unsafe locking scenario:
      
      	       CPU0
      	       ----
      	  lock(adap_rcu_lock);
      	  <Interrupt>
      	    lock(adap_rcu_lock);
      
      	 *** DEADLOCK ***
      
      	5 locks held by radvd/3794:
      	 #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffffa020b85a>]
      	rawv6_sendmsg+0x74b/0xa4d [ipv6]
      	 #1:  (rcu_read_lock){.+.+..}, at: [<ffffffff8151ac6b>]
      	rcu_lock_acquire+0x0/0x29
      	 #2:  (rcu_read_lock){.+.+..}, at: [<ffffffffa01f4cca>]
      	rcu_lock_acquire.constprop.16+0x0/0x30 [ipv6]
      	 #3:  (rcu_read_lock){.+.+..}, at: [<ffffffff810e09b4>]
      	rcu_lock_acquire+0x0/0x29
      	 #4:  (rcu_read_lock){.+.+..}, at: [<ffffffffa0998782>]
      	rcu_lock_acquire.constprop.40+0x0/0x30 [cxgb4]
      
      	stack backtrace:
      	CPU: 7 PID: 3794 Comm: radvd Tainted: G         C O 3.14.7+ #24
      	Hardware name: Supermicro X7DBU/X7DBU, BIOS 6.00 12/03/2007
      	 ffffffff81f15990 ffff88012fdc36a8 ffffffff815d0016 0000000000000006
      	 ffff8800c80dc2a0 ffff88012fdc3708 ffffffff815cc727 0000000000000001
      	 0000000000000001 ffff880100000000 ffffffff81015b02 ffff8800c80dcb58
      	Call Trace:
      	 <IRQ>  [<ffffffff815d0016>] dump_stack+0x4e/0x71
      	 [<ffffffff815cc727>] print_usage_bug+0x1ec/0x1fd
      	 [<ffffffff81015b02>] ? save_stack_trace+0x27/0x44
      	 [<ffffffff810fbfaa>] ? check_usage_backwards+0xa0/0xa0
      	 [<ffffffff810fc640>] mark_lock+0x11b/0x212
      	 [<ffffffff810fca0b>] __lock_acquire+0x2d4/0xe48
      	 [<ffffffff810fbfaa>] ? check_usage_backwards+0xa0/0xa0
      	 [<ffffffff810fbff6>] ? check_usage_forwards+0x4c/0xa6
      	 [<ffffffff810c6c8a>] ? __local_bh_enable_ip+0xaf/0xd9
      	 [<ffffffff810fd98b>] lock_acquire+0x82/0x9d
      	 [<ffffffffa09989ea>] ? clip_add+0x2c/0x116 [cxgb4]
      	 [<ffffffffa0998782>] ? rcu_read_unlock+0x23/0x23 [cxgb4]
      	 [<ffffffff815d6ff8>] _raw_spin_lock+0x34/0x43
      	 [<ffffffffa09989ea>] ? clip_add+0x2c/0x116 [cxgb4]
      	 [<ffffffffa09987b0>] ? rcu_lock_acquire.constprop.40+0x2e/0x30 [cxgb4]
      	 [<ffffffffa0998782>] ? rcu_read_unlock+0x23/0x23 [cxgb4]
      	 [<ffffffffa09989ea>] clip_add+0x2c/0x116 [cxgb4]
      	 [<ffffffffa0998beb>] cxgb4_inet6addr_handler+0x117/0x12c [cxgb4]
      	 [<ffffffff810fd99d>] ? lock_acquire+0x94/0x9d
      	 [<ffffffff810e09b4>] ? raw_notifier_call_chain+0x11/0x11
      	 [<ffffffff815da98b>] notifier_call_chain+0x32/0x5c
      	 [<ffffffff815da9f9>] __atomic_notifier_call_chain+0x44/0x6e
      	 [<ffffffff815daa32>] atomic_notifier_call_chain+0xf/0x11
      	 [<ffffffff815b1356>] inet6addr_notifier_call_chain+0x16/0x18
      	 [<ffffffffa01f72e5>] ipv6_add_addr+0x404/0x46e [ipv6]
      	 [<ffffffff810fde6a>] ? trace_hardirqs_on+0xd/0xf
      	 [<ffffffffa01fb634>] addrconf_prefix_rcv+0x385/0x6ea [ipv6]
      	 [<ffffffffa0207950>] ndisc_rcv+0x9d3/0xd76 [ipv6]
      	 [<ffffffffa020d536>] icmpv6_rcv+0x592/0x67b [ipv6]
      	 [<ffffffff810c6c85>] ? __local_bh_enable_ip+0xaa/0xd9
      	 [<ffffffff810c6c85>] ? __local_bh_enable_ip+0xaa/0xd9
      	 [<ffffffff810fd8dc>] ? lock_release+0x14e/0x17b
      	 [<ffffffffa020df97>] ? rcu_read_unlock+0x21/0x23 [ipv6]
      	 [<ffffffff8150df52>] ? rcu_read_unlock+0x23/0x23
      	 [<ffffffffa01f4ede>] ip6_input_finish+0x1e4/0x2fc [ipv6]
      	 [<ffffffffa01f540b>] ip6_input+0x33/0x38 [ipv6]
      	 [<ffffffffa01f5557>] ip6_mc_input+0x147/0x160 [ipv6]
      	 [<ffffffffa01f4ba3>] ip6_rcv_finish+0x7c/0x81 [ipv6]
      	 [<ffffffffa01f5397>] ipv6_rcv+0x3a1/0x3e2 [ipv6]
      	 [<ffffffff8151ef96>] __netif_receive_skb_core+0x4ab/0x511
      	 [<ffffffff810fdc94>] ? mark_held_locks+0x71/0x99
      	 [<ffffffff8151f0c0>] ? process_backlog+0x69/0x15e
      	 [<ffffffff8151f045>] __netif_receive_skb+0x49/0x5b
      	 [<ffffffff8151f0cf>] process_backlog+0x78/0x15e
      	 [<ffffffff8151f571>] ? net_rx_action+0x1a2/0x1cc
      	 [<ffffffff8151f47b>] net_rx_action+0xac/0x1cc
      	 [<ffffffff810c69b7>] ? __do_softirq+0xad/0x218
      	 [<ffffffff810c69ff>] __do_softirq+0xf5/0x218
      	 [<ffffffff815ddafc>] do_softirq_own_stack+0x1c/0x30
      	 <EOI>  [<ffffffff810c6bb6>] do_softirq+0x38/0x5d
      	 [<ffffffffa01f1d5b>] ? ip6_copy_metadata+0x156/0x156 [ipv6]
      	 [<ffffffff810c6c78>] __local_bh_enable_ip+0x9d/0xd9
      	 [<ffffffffa01f1d88>] rcu_read_unlock_bh+0x2d/0x2f [ipv6]
      	 [<ffffffffa01f28b4>] ip6_finish_output2+0x381/0x3d8 [ipv6]
      	 [<ffffffffa01f49ef>] ip6_finish_output+0x6e/0x73 [ipv6]
      	 [<ffffffffa01f4a70>] ip6_output+0x7c/0xa8 [ipv6]
      	 [<ffffffff815b1bfa>] dst_output+0x18/0x1c
      	 [<ffffffff815b1c9e>] ip6_local_out+0x1c/0x21
      	 [<ffffffffa01f2489>] ip6_push_pending_frames+0x37d/0x427 [ipv6]
      	 [<ffffffff81558af8>] ? skb_orphan+0x39/0x39
      	 [<ffffffffa020b85a>] ? rawv6_sendmsg+0x74b/0xa4d [ipv6]
      	 [<ffffffffa020ba51>] rawv6_sendmsg+0x942/0xa4d [ipv6]
      	 [<ffffffff81584cd2>] inet_sendmsg+0x3d/0x66
      	 [<ffffffff81508930>] __sock_sendmsg_nosec+0x25/0x27
      	 [<ffffffff8150b0d7>] sock_sendmsg+0x5a/0x7b
      	 [<ffffffff810fd8dc>] ? lock_release+0x14e/0x17b
      	 [<ffffffff8116d756>] ? might_fault+0x9e/0xa5
      	 [<ffffffff8116d70d>] ? might_fault+0x55/0xa5
      	 [<ffffffff81508cb1>] ? copy_from_user+0x2a/0x2c
      	 [<ffffffff8150b70c>] ___sys_sendmsg+0x226/0x2d9
      	 [<ffffffff810fcd25>] ? __lock_acquire+0x5ee/0xe48
      	 [<ffffffff810fde01>] ? trace_hardirqs_on_caller+0x145/0x1a1
      	 [<ffffffff8118efcb>] ? slab_free_hook.isra.71+0x50/0x59
      	 [<ffffffff8115c81f>] ? release_pages+0xbc/0x181
      	 [<ffffffff810fd99d>] ? lock_acquire+0x94/0x9d
      	 [<ffffffff81115e97>] ? read_seqcount_begin.constprop.25+0x73/0x90
      	 [<ffffffff8150c408>] __sys_sendmsg+0x3d/0x5b
      	 [<ffffffff8150c433>] SyS_sendmsg+0xd/0x19
      	 [<ffffffff815dc53d>] system_call_fastpath+0x1a/0x1f
      Reported-by: NBen Greear <greearb@candelatech.com>
      Cc: Casey Leedom <leedom@chelsio.com>
      Cc: Hariprasad Shenai <hariprasad@chelsio.com>
      Signed-off-by: NLi RongQing <roy.qing.li@gmail.com>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Acked-by: NCasey Leedom <leedom@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ee9a33b2
  3. 24 6月, 2014 1 次提交
    • S
      be2net: fix qnq mode detection on VFs · 66064dbc
      Suresh Reddy 提交于
      The driver (on PF or VF) needs to detect if the function is in qnq mode for
      a HW hack in be_rx_compl_get() to work.
      
      The driver queries this information using the GET_PROFILE_CONFIG cmd
      (since the commit below can caused this regression.) But this cmd is not
      available on VFs and so the VFs fail to detect qnq mode. This causes
      vlan traffic to not work.
      
      The fix is to use the the adapter->function_mode value queried via
      QUERY_FIRMWARE_CONFIG cmd on both PFs and VFs to detect the qnq mode.
      
      Also QNQ_MODE was incorrectly named FLEX10_MODE; correcting that too as the
      fix reads much better with the name change.
      
      Fixes: f93f160b ("refactor multi-channel config code for Skyhawk-R chip")
      Signed-off-by: NSuresh Reddy <Suresh.Reddy@emulex.com>
      Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      66064dbc
  4. 23 6月, 2014 5 次提交
  5. 22 6月, 2014 10 次提交
  6. 20 6月, 2014 5 次提交
    • D
      Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless · 1b0608fd
      David S. Miller 提交于
      John W. Linville says:
      
      ====================
      pull request: wireless 2014-06-18
      
      Please pull this batch of fixes intended for the 3.16 stream!
      
      For the Bluetooth bits, Gustavo says:
      
      "This is our first batch of fixes for 3.16. Be aware that two patches here
      are not exactly bugfixes:
      
      * 71f28af57066 Bluetooth: Add clarifying comment for conn->auth_type
      This commit just add some important security comments to the code, we found
      it important enough to include it here for 3.16 since it is security related.
      
      * 9f7ec8871132 Bluetooth: Refactor discovery stopping into its own function
      This commit is just a refactor in a preparation for a fix in the next
      commit (f8680f12).
      
      All the other patches are fixes for deadlocks and for the Bluetooth protocols,
      most of them related to authentication and encryption."
      
      On top of that...
      
      Chin-Ran Lo fixes a problems with overlapping DMA areas in mwifiex.
      
      Michael Braun corrects a couple of issues in order to enable a new
      device in rt2800usb.
      
      Rafał Miłecki reverts a b43 patch that caused a regression, fixes a
      Kconfig typo, and corrects a frequency reporting error with the G-PHY.
      
      Stanislaw Grsuzka fixes an rfkill regression for rt2500pci, and avoids
      a rt2x00 scheduling while atomic BUG.
      
      Please let me know if there are problems!
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1b0608fd
    • D
      net: sctp: check proc_dointvec result in proc_sctp_do_auth · 24599e61
      Daniel Borkmann 提交于
      When writing to the sysctl field net.sctp.auth_enable, it can well
      be that the user buffer we handed over to proc_dointvec() via
      proc_sctp_do_auth() handler contains something other than integers.
      
      In that case, we would set an uninitialized 4-byte value from the
      stack to net->sctp.auth_enable that can be leaked back when reading
      the sysctl variable, and it can unintentionally turn auth_enable
      on/off based on the stack content since auth_enable is interpreted
      as a boolean.
      
      Fix it up by making sure proc_dointvec() returned sucessfully.
      
      Fixes: b14878cc ("net: sctp: cache auth_enable per endpoint")
      Reported-by: NFlorian Westphal <fwestpha@redhat.com>
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Acked-by: NVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      24599e61
    • P
      tg3: Clear NETIF_F_TSO6 flag before doing software GSO · 40c1deaf
      Prashant Sreedharan 提交于
      Commit d3f6f3a1 ("tg3: Prevent page
      allocation failure during TSO workaround") modified driver logic
      to use tg3_tso_bug() for any TSO fragment that hits hardware bug
      conditions thus the patch increased the scope of work for tg3_tso_bug()
      to cover devices that support NETIF_F_TSO6 as well. Prior to the
      patch, tg3_tso_bug() would only be used on devices supporting
      NETIF_F_TSO.
      
      A regression was introduced for IPv6 packets requiring the workaround.
      To properly perform GSO on SKBs with TCPV6 gso_type, we need to call
      skb_gso_segment() with NETIF_F_TSO6 feature flag cleared, or the
      function will return NULL and cause a kernel oops as tg3 is not handling
      a NULL return value. This patch fixes the problem.
      Signed-off-by: NPrashant Sreedharan <prashant@broadcom.com>
      Signed-off-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      40c1deaf
    • N
      tcp: fix tcp_match_skb_to_sack() for unaligned SACK at end of an skb · 2cd0d743
      Neal Cardwell 提交于
      If there is an MSS change (or misbehaving receiver) that causes a SACK
      to arrive that covers the end of an skb but is less than one MSS, then
      tcp_match_skb_to_sack() was rounding up pkt_len to the full length of
      the skb ("Round if necessary..."), then chopping all bytes off the skb
      and creating a zero-byte skb in the write queue.
      
      This was visible now because the recently simplified TLP logic in
      bef1909e ("tcp: fixing TLP's FIN recovery") could find that 0-byte
      skb at the end of the write queue, and now that we do not check that
      skb's length we could send it as a TLP probe.
      
      Consider the following example scenario:
      
       mss: 1000
       skb: seq: 0 end_seq: 4000  len: 4000
       SACK: start_seq: 3999 end_seq: 4000
      
      The tcp_match_skb_to_sack() code will compute:
      
       in_sack = false
       pkt_len = start_seq - TCP_SKB_CB(skb)->seq = 3999 - 0 = 3999
       new_len = (pkt_len / mss) * mss = (3999/1000)*1000 = 3000
       new_len += mss = 4000
      
      Previously we would find the new_len > skb->len check failing, so we
      would fall through and set pkt_len = new_len = 4000 and chop off
      pkt_len of 4000 from the 4000-byte skb, leaving a 0-byte segment
      afterward in the write queue.
      
      With this new commit, we notice that the new new_len >= skb->len check
      succeeds, so that we return without trying to fragment.
      
      Fixes: adb92db8 ("tcp: Make SACK code to split only at mss boundaries")
      Reported-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NNeal Cardwell <ncardwell@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Cc: Ilpo Jarvinen <ilpo.jarvinen@helsinki.fi>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2cd0d743
    • D
      Revert "net: return actual error on register_queue_kobjects" · 8e4946cc
      David S. Miller 提交于
      This reverts commit d36a4f4b.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8e4946cc
  7. 19 6月, 2014 7 次提交
    • K
      net: filter: fix upper BPF instruction limit · 6f9a093b
      Kees Cook 提交于
      The original checks (via sk_chk_filter) for instruction count uses ">",
      not ">=", so changing this in sk_convert_filter has the potential to break
      existing seccomp filters that used exactly BPF_MAXINSNS many instructions.
      
      Fixes: bd4cf0ed ("net: filter: rework/optimize internal BPF interpreter's instruction set")
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Cc: stable@vger.kernel.org # v3.15+
      Acked-by: NDaniel Borkmann <dborkman@redhat.com>
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6f9a093b
    • D
      net: sctp: propagate sysctl errors from proc_do* properly · ff5e92c1
      Daniel Borkmann 提交于
      sysctl handler proc_sctp_do_hmac_alg(), proc_sctp_do_rto_min() and
      proc_sctp_do_rto_max() do not properly reflect some error cases
      when writing values via sysctl from internal proc functions such
      as proc_dointvec() and proc_dostring().
      
      In all these cases we pass the test for write != 0 and partially
      do additional work just to notice that additional sanity checks
      fail and we return with hard-coded -EINVAL while proc_do*
      functions might also return different errors. So fix this up by
      simply testing a successful return of proc_do* right after
      calling it.
      
      This also allows to propagate its return value onwards to the user.
      While touching this, also fix up some minor style issues.
      
      Fixes: 4f3fdf3b ("sctp: add check rto_min and rto_max in sysctl")
      Fixes: 3c68198e ("sctp: Make hmac algorithm selection for cookie generation dynamic")
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ff5e92c1
    • J
      net: return actual error on register_queue_kobjects · d36a4f4b
      Jie Liu 提交于
      Return the actual error code if call kset_create_and_add() failed
      
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: NJie Liu <jeff.liu@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d36a4f4b
    • O
      bonding: Advertize vxlan offload features when supported · 5a7baa78
      Or Gerlitz 提交于
      When the underlying device supports TCP offloads for VXLAN/UDP
      encapulated traffic, we need to reflect that through the hw_enc_features
      field of the bonding net-device. This will cause the xmit path
      in the core networking stack to provide bonding with encapsulated
      GSO frames to offload into the HW etc.
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a7baa78
    • M
      skge: Added FS A8NE-FM to the list of 32bit DMA boards · ee14eb7b
      Mirko Lindner 提交于
      Added FUJITSU SIEMENS A8NE-FM to the list of 32bit DMA boards
      
      >From Tomi O.:
      After I added an entry to this MB into the skge.c
      driver in order to enable the mentioned 64bit dma disable quirk,
      the network data corruptions ended and everything is fine again.
      Signed-off-by: NMirko Lindner <mlindner@marvell.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ee14eb7b
    • D
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · 3a3ec1b2
      David S. Miller 提交于
      Pablo Neira Ayuso says:
      
      ====================
      netfilter fixes for net
      
      The following patchset contains netfilter updates for your net tree,
      they are:
      
      1) Fix refcount leak when dumping the dying/unconfirmed conntrack lists,
         from Florian Westphal.
      
      2) Fix crash in NAT when removing a netnamespace, also from Florian.
      
      3) Fix a crash in IPVS when trying to remove an estimator out of the
         sysctl scope, from Julian Anastasov.
      
      4) Add zone attribute to the routing to calculate the message size in
         ctnetlink events, from Ken-ichirou MATSUZAWA.
      
      5) Another fix for the dying/unconfirmed list which was preventing to
         dump more than one memory page of entries (~17 entries in x86_64).
      
      6) Fix missing RCU-safe list insertion in the rule replacement code
         in nf_tables.
      
      7) Since the new transaction infrastructure is in place, we have to
         upgrade the chain use counter from u16 to u32 to avoid overflow
         after more than 2^16 rules are added.
      
      8) Fix refcount leak when replacing rule in nf_tables. This problem
         was also introduced in new transaction.
      
      9) Call the ->destroy() callback when releasing nft-xt rules to fix
         module refcount leaks.
      
      10) Set the family in the netlink messages that contain set elements
          in nf_tables to make it consistent with other object types.
      
      11) Don't dump NAT port information if it is unset in nft_nat.
      
      12) Update the MAINTAINERS file, I have merged the ebtables entry
          into netfilter. While at it, also removed the netfilter users
          mailing list, the development list should be enough.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3a3ec1b2
    • J
      Merge branch 'master' of... · 2ee3f63d
      John W. Linville 提交于
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
      2ee3f63d
  8. 18 6月, 2014 6 次提交