1. 09 Sep, 2010 1 commit
    • Eric Dumazet's avatar
      udp: add rehash on connect() · 719f8358
      Eric Dumazet authored
      commit 30fff923
      
       introduced in linux-2.6.33 (udp: bind() optimisation)
      added a secondary hash on UDP, hashed on (local addr, local port).
      
      Problem is that following sequence :
      
      fd = socket(...)
      connect(fd, &remote, ...)
      
      not only selects remote end point (address and port), but also sets
      local address, while UDP stack stored in secondary hash table the socket
      while its local address was INADDR_ANY (or ipv6 equivalent)
      
      Sequence is :
       - autobind() : choose a random local port, insert socket in hash tables
                    [while local address is INADDR_ANY]
       - connect() : set remote address and port, change local address to IP
                    given by a route lookup.
      
      When an incoming UDP frame comes, if more than 10 sockets are found in
      primary hash table, we switch to secondary table, and fail to find
      socket because its local address changed.
      
      One solution to this problem is to rehash datagram socket if needed.
      
      We add a new rehash(struct socket *) method in "struct proto", and
      implement this method for UDP v4 & v6, using a common helper.
      
      This rehashing only takes care of secondary hash table, since primary
      hash (based on local port only) is not changed.
      Reported-by: default avatarKrzysztof Piotr Oledzki <ole@ans.pl>
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Tested-by: default avatarKrzysztof Piotr Oledzki <ole@ans.pl>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      719f8358
  2. 08 Sep, 2010 5 commits
    • Jianzhao Wang's avatar
      net: blackhole route should always be recalculated · ae2688d5
      Jianzhao Wang authored
      Blackhole routes are used when xfrm_lookup() returns -EREMOTE (error
      triggered by IKE for example), hence this kind of route is always
      temporary and so we should check if a better route exists for next
      packets.
      Bug has been introduced by commit d11a4dc1
      
      .
      Signed-off-by: default avatarJianzhao Wang <jianzhao.wang@6wind.com>
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ae2688d5
    • Jarek Poplawski's avatar
      ipv4: Suppress lockdep-RCU false positive in FIB trie (3) · f6b085b6
      Jarek Poplawski authored
      Hi,
      Here is one more of these warnings and a patch below:
      
      Sep  5 23:52:33 del kernel: [46044.244833] ===================================================
      Sep  5 23:52:33 del kernel: [46044.269681] [ INFO: suspicious rcu_dereference_check() usage. ]
      Sep  5 23:52:33 del kernel: [46044.277000] ---------------------------------------------------
      Sep  5 23:52:33 del kernel: [46044.285185] net/ipv4/fib_trie.c:1756 invoked rcu_dereference_check() without protection!
      Sep  5 23:52:33 del kernel: [46044.293627]
      Sep  5 23:52:33 del kernel: [46044.293632] other info that might help us debug this:
      Sep  5 23:52:33 del kernel: [46044.293634]
      Sep  5 23:52:33 del kernel: [46044.325333]
      Sep  5 23:52:33 del kernel: [46044.325335] rcu_scheduler_active = 1, debug_locks = 0
      Sep  5 23:52:33 del kernel: [46044.348013] 1 lock held by pppd/1717:
      Sep  5 23:52:33 del kernel: [46044.357548]  #0:  (rtnl_mutex){+.+.+.}, at: [<c125dc1f>] rtnl_lock+0xf/0x20
      Sep  5 23:52:33 del kernel: [46044.367647]
      Sep  5 23:52:33 del kernel: [46044.367652] stack backtrace:
      Sep  5 23:52:33 del kernel: [46044.387429] Pid: 1717, comm: pppd Not tainted 2.6.35.4.4a #3
      Sep  5 23:52:33 del kernel: [46044.398764] Call Trace:
      Sep  5 23:52:33 del kernel: [46044.409596]  [<c12f9aba>] ? printk+0x18/0x1e
      Sep  5 23:52:33 del kernel: [46044.420761]  [<c1053969>] lockdep_rcu_dereference+0xa9/0xb0
      Sep  5 23:52:33 del kernel: [46044.432229]  [<c12b7235>] trie_firstleaf+0x65/0x70
      Sep  5 23:52:33 del kernel: [46044.443941]  [<c12b74d4>] fib_table_flush+0x14/0x170
      Sep  5 23:52:33 del kernel: [46044.455823]  [<c1033e92>] ? local_bh_enable_ip+0x62/0xd0
      Sep  5 23:52:33 del kernel: [46044.467995]  [<c12fc39f>] ? _raw_spin_unlock_bh+0x2f/0x40
      Sep  5 23:52:33 del kernel: [46044.480404]  [<c12b24d0>] ? fib_sync_down_dev+0x120/0x180
      Sep  5 23:52:33 del kernel: [46044.493025]  [<c12b069d>] fib_flush+0x2d/0x60
      Sep  5 23:52:33 del kernel: [46044.505796]  [<c12b06f5>] fib_disable_ip+0x25/0x50
      Sep  5 23:52:33 del kernel: [46044.518772]  [<c12b10d3>] fib_netdev_event+0x73/0xd0
      Sep  5 23:52:33 del kernel: [46044.531918]  [<c1048dfd>] notifier_call_chain+0x2d/0x70
      Sep  5 23:52:33 del kernel: [46044.545358]  [<c1048f0a>] raw_notifier_call_chain+0x1a/0x20
      Sep  5 23:52:33 del kernel: [46044.559092]  [<c124f687>] call_netdevice_notifiers+0x27/0x60
      Sep  5 23:52:33 del kernel: [46044.573037]  [<c124faec>] __dev_notify_flags+0x5c/0x80
      Sep  5 23:52:33 del kernel: [46044.586489]  [<c124fb47>] dev_change_flags+0x37/0x60
      Sep  5 23:52:33 del kernel: [46044.599394]  [<c12a8a8d>] devinet_ioctl+0x54d/0x630
      Sep  5 23:52:33 del kernel: [46044.612277]  [<c12aabb7>] inet_ioctl+0x97/0xc0
      Sep  5 23:52:34 del kernel: [46044.625208]  [<c123f6af>] sock_ioctl+0x6f/0x270
      Sep  5 23:52:34 del kernel: [46044.638046]  [<c109d2b0>] ? handle_mm_fault+0x420/0x6c0
      Sep  5 23:52:34 del kernel: [46044.650968]  [<c123f640>] ? sock_ioctl+0x0/0x270
      Sep  5 23:52:34 del kernel: [46044.663865]  [<c10c3188>] vfs_ioctl+0x28/0xa0
      Sep  5 23:52:34 del kernel: [46044.676556]  [<c10c38fa>] do_vfs_ioctl+0x6a/0x5c0
      Sep  5 23:52:34 del kernel: [46044.688989]  [<c1048676>] ? up_read+0x16/0x30
      Sep  5 23:52:34 del kernel: [46044.701411]  [<c1021376>] ? do_page_fault+0x1d6/0x3a0
      Sep  5 23:52:34 del kernel: [46044.714223]  [<c10b6588>] ? fget_light+0xf8/0x2f0
      Sep  5 23:52:34 del kernel: [46044.726601]  [<c1241f98>] ? sys_socketcall+0x208/0x2c0
      Sep  5 23:52:34 del kernel: [46044.739140]  [<c10c3eb3>] sys_ioctl+0x63/0x70
      Sep  5 23:52:34 del kernel: [46044.751967]  [<c12fca3d>] syscall_call+0x7/0xb
      Sep  5 23:52:34 del kernel: [46044.764734]  [<c12f0000>] ? cookie_v6_check+0x3d0/0x630
      
      -------------->
      
      This patch fixes the warning:
       ===================================================
       [ INFO: suspicious rcu_dereference_check() usage. ]
       ---------------------------------------------------
       net/ipv4/fib_trie.c:1756 invoked rcu_dereference_check() without protection!
      
       other info that might help us debug this:
      
       rcu_scheduler_active = 1, debug_locks = 0
       1 lock held by pppd/1717:
        #0:  (rtnl_mutex){+.+.+.}, at: [<c125dc1f>] rtnl_lock+0xf/0x20
      
       stack backtrace:
       Pid: 1717, comm: pppd Not tainted 2.6.35.4a #3
       Call Trace:
        [<c12f9aba>] ? printk+0x18/0x1e
        [<c1053969>] lockdep_rcu_dereference+0xa9/0xb0
        [<c12b7235>] trie_firstleaf+0x65/0x70
        [<c12b74d4>] fib_table_flush+0x14/0x170
        ...
      
      Allow trie_firstleaf() to be called either under rcu_read_lock()
      protection or with RTNL held. The same annotation is added to
      node_parent_rcu() to prevent a similar warning a bit later.
      
      Followup of commits 634a4b20 and 4eaa0e3c
      
      .
      Signed-off-by: default avatarJarek Poplawski <jarkao2@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f6b085b6
    • Ben Hutchings's avatar
      niu: Fix kernel buffer overflow for ETHTOOL_GRXCLSRLALL · ee9c5cfa
      Ben Hutchings authored
      
      
      niu_get_ethtool_tcam_all() assumes that its output buffer is the right
      size, and warns before returning if it is not.  However, the output
      buffer size is under user control and ETHTOOL_GRXCLSRLALL is an
      unprivileged ethtool command.  Therefore this is at least a local
      denial-of-service vulnerability.
      
      Change it to check before writing each entry and to return an error if
      the buffer is already full.
      
      Compile-tested only.
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee9c5cfa
    • Julian Anastasov's avatar
      ipvs: fix active FTP · 6523ce15
      Julian Anastasov authored
      
      
      - Do not create expectation when forwarding the PORT
        command to avoid blocking the connection. The problem is that
        nf_conntrack_ftp.c:help() tries to create the same expectation later in
        POST_ROUTING and drops the packet with "dropping packet" message after
        failure in nf_ct_expect_related.
      
      - Change ip_vs_update_conntrack to alter the conntrack
        for related connections from real server. If we do not alter the reply in
        this direction the next packet from client sent to vport 20 comes as NEW
        connection. We alter it but may be some collision happens for both
        conntracks and the second conntrack gets destroyed immediately. The
        connection stucks too.
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6523ce15
    • Jarek Poplawski's avatar
      gro: Re-fix different skb headrooms · 64289c8e
      Jarek Poplawski authored
      The patch: "gro: fix different skb headrooms" in its part:
      "2) allocate a minimal skb for head of frag_list" is buggy. The copied
      skb has p->data set at the ip header at the moment, and skb_gro_offset
      is the length of ip + tcp headers. So, after the change the length of
      mac header is skipped. Later skb_set_mac_header() sets it into the
      NET_SKB_PAD area (if it's long enough) and ip header is misaligned at
      NET_SKB_PAD + NET_IP_ALIGN offset. There is no reason to assume the
      original skb was wrongly allocated, so let's copy it as it was.
      
      bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=16626
      fixes commit: 3d3be433
      
      Reported-by: default avatarPlamen Petrov <pvp-lsts@fs.uni-ruse.bg>
      Signed-off-by: default avatarJarek Poplawski <jarkao2@gmail.com>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      Acked-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Tested-by: default avatarPlamen Petrov <pvp-lsts@fs.uni-ruse.bg>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      64289c8e
  3. 07 Sep, 2010 11 commits
  4. 03 Sep, 2010 4 commits
  5. 02 Sep, 2010 6 commits
  6. 01 Sep, 2010 9 commits
  7. 31 Aug, 2010 4 commits
    • Luis R. Rodriguez's avatar
      ath9k_hw: fix parsing of HT40 5 GHz CTLs · 90487974
      Luis R. Rodriguez authored
      
      
      The 5 GHz CTL indexes were not being read for all hardware
      devices due to the masking out through the CTL_MODE_M mask
      being one bit too short. Without this the calibrated regulatory
      maximum values were not being picked up when devices operate
      on 5 GHz in HT40 mode. The final output power used for Atheros
      devices is the minimum between the calibrated CTL values and
      what CRDA provides.
      
      Cc: stable@kernel.org [2.6.27+]
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      90487974
    • Luis R. Rodriguez's avatar
      ath9k_hw: Fix EEPROM uncompress block reading on AR9003 · 803288e6
      Luis R. Rodriguez authored
      
      
      The EEPROM is compressed on AR9003, upon decompression
      the wrong upper limit was being used for the block which
      prevented the 5 GHz CTL indexes from being used, which are
      stored towards the end of the EEPROM block. This fix allows
      the actual intended regulatory limits to be used on AR9003
      hardware.
      
      Cc: stable@kernel.org [2.6.36+]
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      803288e6
    • John W. Linville's avatar
      wireless: register wiphy rfkill w/o holding cfg80211_mutex · c3d34d5d
      John W. Linville authored
      Otherwise lockdep complains...
      
      https://bugzilla.kernel.org/show_bug.cgi?id=17311
      
      
      
      [ INFO: possible circular locking dependency detected ]
      2.6.36-rc2-git4 #12
      -------------------------------------------------------
      kworker/0:3/3630 is trying to acquire lock:
       (rtnl_mutex){+.+.+.}, at: [<ffffffff813396c7>] rtnl_lock+0x12/0x14
      
      but task is already holding lock:
       (rfkill_global_mutex){+.+.+.}, at: [<ffffffffa014b129>]
      rfkill_switch_all+0x24/0x49 [rfkill]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #2 (rfkill_global_mutex){+.+.+.}:
             [<ffffffff81079ad7>] lock_acquire+0x120/0x15b
             [<ffffffff813ae869>] __mutex_lock_common+0x54/0x52e
             [<ffffffff813aede9>] mutex_lock_nested+0x34/0x39
             [<ffffffffa014b4ab>] rfkill_register+0x2b/0x29c [rfkill]
             [<ffffffffa0185ba0>] wiphy_register+0x1ae/0x270 [cfg80211]
             [<ffffffffa0206f01>] ieee80211_register_hw+0x1b4/0x3cf [mac80211]
             [<ffffffffa0292e98>] iwl_ucode_callback+0x9e9/0xae3 [iwlagn]
             [<ffffffff812d3e9d>] request_firmware_work_func+0x54/0x6f
             [<ffffffff81065d15>] kthread+0x8c/0x94
             [<ffffffff8100ac24>] kernel_thread_helper+0x4/0x10
      
      -> #1 (cfg80211_mutex){+.+.+.}:
             [<ffffffff81079ad7>] lock_acquire+0x120/0x15b
             [<ffffffff813ae869>] __mutex_lock_common+0x54/0x52e
             [<ffffffff813aede9>] mutex_lock_nested+0x34/0x39
             [<ffffffffa018605e>] cfg80211_get_dev_from_ifindex+0x1b/0x7c [cfg80211]
             [<ffffffffa0189f36>] cfg80211_wext_giwscan+0x58/0x990 [cfg80211]
             [<ffffffff8139a3ce>] ioctl_standard_iw_point+0x1a8/0x272
             [<ffffffff8139a529>] ioctl_standard_call+0x91/0xa7
             [<ffffffff8139a687>] T.723+0xbd/0x12c
             [<ffffffff8139a727>] wext_handle_ioctl+0x31/0x6d
             [<ffffffff8133014e>] dev_ioctl+0x63d/0x67a
             [<ffffffff8131afd9>] sock_ioctl+0x48/0x21d
             [<ffffffff81102abd>] do_vfs_ioctl+0x4ba/0x509
             [<ffffffff81102b5d>] sys_ioctl+0x51/0x74
             [<ffffffff81009e02>] system_call_fastpath+0x16/0x1b
      
      -> #0 (rtnl_mutex){+.+.+.}:
             [<ffffffff810796b0>] __lock_acquire+0xa93/0xd9a
             [<ffffffff81079ad7>] lock_acquire+0x120/0x15b
             [<ffffffff813ae869>] __mutex_lock_common+0x54/0x52e
             [<ffffffff813aede9>] mutex_lock_nested+0x34/0x39
             [<ffffffff813396c7>] rtnl_lock+0x12/0x14
             [<ffffffffa0185cb5>] cfg80211_rfkill_set_block+0x1a/0x7b [cfg80211]
             [<ffffffffa014aed0>] rfkill_set_block+0x80/0xd5 [rfkill]
             [<ffffffffa014b07e>] __rfkill_switch_all+0x3f/0x6f [rfkill]
             [<ffffffffa014b13d>] rfkill_switch_all+0x38/0x49 [rfkill]
             [<ffffffffa014b821>] rfkill_op_handler+0x105/0x136 [rfkill]
             [<ffffffff81060708>] process_one_work+0x248/0x403
             [<ffffffff81062620>] worker_thread+0x139/0x214
             [<ffffffff81065d15>] kthread+0x8c/0x94
             [<ffffffff8100ac24>] kernel_thread_helper+0x4/0x10
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      c3d34d5d
    • David S. Miller's avatar
      netlink: Make NETLINK_USERSOCK work again. · b963ea89
      David S. Miller authored
      
      
      Once we started enforcing the a nl_table[] entry exist for
      a protocol, NETLINK_USERSOCK stopped working.  Add a dummy
      table entry so that it works again.
      Reported-by: default avatarThomas Voegtle <tv@lio96.de>
      Tested-by: default avatarThomas Voegtle <tv@lio96.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b963ea89