1. 25 Jun, 2014 1 commit
  2. 24 Jun, 2014 1 commit
    • Li RongQing's avatar
      cxgb4: Not need to hold the adap_rcu_lock lock when read adap_rcu_list · ee9a33b2
      Li RongQing authored
      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: default avatarBen Greear <greearb@candelatech.com>
      Cc: Casey Leedom <leedom@chelsio.com>
      Cc: Hariprasad Shenai <hariprasad@chelsio.com>
      Signed-off-by: default avatarLi RongQing <roy.qing.li@gmail.com>
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Acked-by: default avatarCasey Leedom <leedom@chelsio.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee9a33b2
  3. 23 Jun, 2014 6 commits
  4. 22 Jun, 2014 2 commits
    • Bjørn Mork's avatar
      net: huawei_cdc_ncm: increase command buffer size · 3acc7461
      Bjørn Mork authored
      Messages from the modem exceeding 256 bytes cause communication
      failure.
      
      The WDM protocol is strictly "read on demand", meaning that we only
      poll for unread data after receiving a notification from the modem.
      Since we have no way to know how much data the modem has to send,
      we must make sure that the buffer we provide is "big enough".
      Message truncation does not work. Truncated messages are left unread
      until the modem has another message to send.  Which often won't
      happen until the userspace application has given up waiting for the
      final part of the last message, and therefore sends another command.
      
      With a proper CDC WDM function there is a descriptor telling us
      which buffer size the modem uses. But with this vendor specific
      implementation there is no known way to calculate the exact "big
      enough" number.  It is an unknown property of the modem firmware.
      Experience has shown that 256 is too small.  The discussion of
      this failure ended up concluding that 512 might be too small as
      well. So 1024 seems like a reasonable value for now.
      
      Fixes: 41c47d8c ("net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver")
      Cc: Enrico Mioso <mrkiko.rs@gmail.com>
      Reported-by: default avatarDan Williams <dcbw@redhat.com>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Acked-By: default avatarEnrico Mioso <mrkiko.rs@gmail.com>
      Tested-by: default avatarDan Williams <dcbw@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3acc7461
    • Mugunthan V N's avatar
      drivers: net: cpsw: fix dual EMAC stall when connected to same switch · e6afea0b
      Mugunthan V N authored
      In commit 629c9a8f (drivers: net: cpsw: Add
      default vlan for dual emac case also), api cpsw_add_default_vlan() also
      changes the port vlan which is required to seperate the ports which results
      in the following behavior
      
      In Dual EMAC mode, when both the Etnernet connected is connected to same
      switch, it creates a loop in the switch and when a broadcast packet is
      received it is forwarded to the other port which stalls the whole switch
      and needs a reset/power cycle to the switch to recover. So intead of using
      the api, add only the default VLAN entry in dual EMAC case.
      
      Cc: Yegor Yefremov <yegorslists@googlemail.com>
      Cc: Felipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarMugunthan V N <mugunthanvnm@ti.com>
      Tested-by: default avatarYegor Yefremov <yegorslists@googlemail.com>
      Tested-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e6afea0b
  5. 21 Jun, 2014 8 commits
  6. 20 Jun, 2014 5 commits
    • David S. Miller's avatar
      Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless · 1b0608fd
      David S. Miller authored
      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: default avatarDavid S. Miller <davem@davemloft.net>
      1b0608fd
    • Daniel Borkmann's avatar
      net: sctp: check proc_dointvec result in proc_sctp_do_auth · 24599e61
      Daniel Borkmann authored
      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: default avatarFlorian Westphal <fwestpha@redhat.com>
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      24599e61
    • Prashant Sreedharan's avatar
      tg3: Clear NETIF_F_TSO6 flag before doing software GSO · 40c1deaf
      Prashant Sreedharan authored
      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: default avatarPrashant Sreedharan <prashant@broadcom.com>
      Signed-off-by: default avatarMichael Chan <mchan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      40c1deaf
    • Neal Cardwell's avatar
      tcp: fix tcp_match_skb_to_sack() for unaligned SACK at end of an skb · 2cd0d743
      Neal Cardwell authored
      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: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarNeal 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: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2cd0d743
    • David S. Miller's avatar
      Revert "net: return actual error on register_queue_kobjects" · 8e4946cc
      David S. Miller authored
      This reverts commit d36a4f4b.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8e4946cc
  7. 19 Jun, 2014 2 commits
  8. 18 Jun, 2014 7 commits
    • Jie Liu's avatar
      net: return actual error on register_queue_kobjects · d36a4f4b
      Jie Liu authored
      Return the actual error code if call kset_create_and_add() failed
      
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJie Liu <jeff.liu@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d36a4f4b
    • Or Gerlitz's avatar
      bonding: Advertize vxlan offload features when supported · 5a7baa78
      Or Gerlitz authored
      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: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5a7baa78
    • Mirko Lindner's avatar
      skge: Added FS A8NE-FM to the list of 32bit DMA boards · ee14eb7b
      Mirko Lindner authored
      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: default avatarMirko Lindner <mlindner@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee14eb7b
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · 3a3ec1b2
      David S. Miller authored
      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: default avatarDavid S. Miller <davem@davemloft.net>
      3a3ec1b2
    • John W. Linville's avatar
      Merge branch 'master' of... · 2ee3f63d
      John W. Linville authored
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
      2ee3f63d
    • Pablo Neira Ayuso's avatar
      MAINTAINERS: merge ebtables into netfilter entry · db9cf3a3
      Pablo Neira Ayuso authored
      Moreover, remove reference to the netfilter users mailing list,
      so they don't receive patches.
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      db9cf3a3
    • Fugang Duan's avatar
      net: fec: Don't clear IPV6 header checksum field when IP accelerator enable · 62a02c98
      Fugang Duan authored
      The commit 96c50caa (net: fec: Enable IP header hardware checksum)
      enable HW IP header checksum for IPV4 and IPV6, which causes IPV6 TCP/UDP
      cannot work. (The issue is reported by Russell King)
      
      For FEC IP header checksum function: Insert IP header checksum. This "IINS"
      bit is written by the user. If set, IP accelerator calculates the IP header
      checksum and overwrites the IINS corresponding header field with the calculated
      value. The checksum field must be cleared by user, otherwise the checksum
      always is 0xFFFF.
      
      So the previous patch clear IP header checksum field regardless of IP frame
      type.
      
      In fact, IP HW detect the packet as IPV6 type, even if the "IINS" bit is set,
      the IP accelerator is not triggered to calculates IPV6 header checksum because
      IPV6 frame format don't have checksum.
      
      So this results in the IPV6 frame being corrupted.
      
      The patch just add software detect the current packet type, if it is IPV6
      frame, it don't clear IP header checksum field.
      
      Cc: Russell King <linux@arm.linux.org.uk>
      Reported-and-tested-by: default avatarRussell King <linux@arm.linux.org.uk>
      Signed-off-by: default avatarFugang Duan <B38611@freescale.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      62a02c98
  9. 17 Jun, 2014 8 commits