1. 25 5月, 2010 1 次提交
  2. 24 5月, 2010 1 次提交
    • L
      Revert "ath9k: Group Key fix for VAPs" · a69eee49
      Linus Torvalds 提交于
      This reverts commit 03ceedea, since it
      breaks resume from suspend-to-ram on Rafael's Acer Ferrari One.
      NetworkManager thinks everything is ok, but it can't connect to the AP
      to get an IP address after the resume.
      
      In fact, it even breaks resume for non-ath9k chipsets: reverting it also
      fixes Rafael's Toshiba Protege R500 with the iwlagn driver.  As Johannes
      says:
      
        "Indeed, this patch needs to be reverted. That mac80211 change is wrong
         and completely unnecessary."
      Reported-and-requested-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Cc: Daniel Yingqiang Ma <yma.cool@gmail.com>
      Cc: John W. Linville <linville@tuxdriver.com>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a69eee49
  3. 22 5月, 2010 2 次提交
  4. 19 5月, 2010 1 次提交
  5. 18 5月, 2010 6 次提交
  6. 16 5月, 2010 3 次提交
  7. 13 5月, 2010 2 次提交
  8. 11 5月, 2010 4 次提交
    • P
      ipv6: ip6mr: support multiple tables · d1db275d
      Patrick McHardy 提交于
      This patch adds support for multiple independant multicast routing instances,
      named "tables".
      
      Userspace multicast routing daemons can bind to a specific table instance by
      issuing a setsockopt call using a new option MRT6_TABLE. The table number is
      stored in the raw socket data and affects all following ip6mr setsockopt(),
      getsockopt() and ioctl() calls. By default, a single table (RT6_TABLE_DFLT)
      is created with a default routing rule pointing to it. Newly created pim6reg
      devices have the table number appended ("pim6regX"), with the exception of
      devices created in the default table, which are named just "pim6reg" for
      compatibility reasons.
      
      Packets are directed to a specific table instance using routing rules,
      similar to how regular routing rules work. Currently iif, oif and mark
      are supported as keys, source and destination addresses could be supported
      additionally.
      
      Example usage:
      
      - bind pimd/xorp/... to a specific table:
      
      uint32_t table = 123;
      setsockopt(fd, SOL_IPV6, MRT6_TABLE, &table, sizeof(table));
      
      - create routing rules directing packets to the new table:
      
      # ip -6 mrule add iif eth0 lookup 123
      # ip -6 mrule add oif eth0 lookup 123
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      d1db275d
    • P
      6bd52143
    • P
      f30a7784
    • P
      ipv6: ip6mr: move unres_queue and timer to per-namespace data · c476efbc
      Patrick McHardy 提交于
      The unres_queue is currently shared between all namespaces. Following patches
      will additionally allow to create multiple multicast routing tables in each
      namespace. Having a single shared queue for all these users seems to excessive,
      move the queue and the cleanup timer to the per-namespace data to unshare it.
      
      As a side-effect, this fixes a bug in the seq file iteration functions: the
      first entry returned is always from the current namespace, entries returned
      after that may belong to any namespace.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      c476efbc
  9. 10 5月, 2010 11 次提交
  10. 08 5月, 2010 4 次提交
    • N
      ipv4: remove ip_rt_secret timer (v4) · 3ee94372
      Neil Horman 提交于
      A while back there was a discussion regarding the rt_secret_interval timer.
      Given that we've had the ability to do emergency route cache rebuilds for awhile
      now, based on a statistical analysis of the various hash chain lengths in the
      cache, the use of the flush timer is somewhat redundant.  This patch removes the
      rt_secret_interval sysctl, allowing us to rely solely on the statistical
      analysis mechanism to determine the need for route cache flushes.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3ee94372
    • J
      mac80211: improve HT channel handling · 0aaffa9b
      Johannes Berg 提交于
      Currently, when one interface switches HT mode,
      all others will follow along. This is clearly
      undesirable, since the new one might switch to
      no-HT while another one is operating in HT.
      
      Address this issue by keeping track of the HT
      mode per interface, and allowing only changes
      that are compatible, i.e. switching into HT40+
      is not possible when another interface is in
      HT40-, in that case the second one needs to
      fall back to HT20.
      
      Also, to allow drivers to know what's going on,
      store the per-interface HT mode (channel type)
      in the virtual interface's bss_conf.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0aaffa9b
    • J
      cfg80211/mac80211: better channel handling · f444de05
      Johannes Berg 提交于
      Currently (all tested with hwsim) you can do stupid
      things like setting up an AP on a certain channel,
      then adding another virtual interface and making
      that associate on another channel -- this will make
      the beaconing to move channel but obviously without
      the necessary IEs data update.
      
      In order to improve this situation, first make the
      configuration APIs (cfg80211 and nl80211) aware of
      multi-channel operation -- we'll eventually need
      that in the future anyway. There's one userland API
      change and one API addition. The API change is that
      now SET_WIPHY must be called with virtual interface
      index rather than only wiphy index in order to take
      effect for that interface -- luckily all current
      users (hostapd) do that. For monitor interfaces, the
      old setting is preserved, but monitors are always
      slaved to other devices anyway so no guarantees.
      
      The second userland API change is the introduction
      of a per virtual interface SET_CHANNEL command, that
      hostapd should use going forward to make it easier
      to understand what's going on (it can automatically
      detect a kernel with this command).
      
      Other than mac80211, no existing cfg80211 drivers
      are affected by this change because they only allow
      a single virtual interface.
      
      mac80211, however, now needs to be aware that the
      channel settings are per interface now, and needs
      to disallow (for now) real multi-channel operation,
      which is another important part of this patch.
      
      One of the immediate benefits is that you can now
      start hostapd to operate on a hardware that already
      has a connection on another virtual interface, as
      long as you specify the same channel.
      
      Note that two things are left unhandled (this is an
      improvement -- not a complete fix):
      
       * different HT/no-HT modes
      
         currently you could start an HT AP and then
         connect to a non-HT network on the same channel
         which would configure the hardware for no HT;
         that can be fixed fairly easily
      
       * CSA
      
         An AP we're connected to on a virtual interface
         might indicate switching channels, and in that
         case we would follow it, regardless of how many
         other interfaces are operating; this requires
         more effort to fix but is pretty rare after all
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f444de05
    • J
      mac80211: fix BSS info reconfiguration · ac8dd506
      Johannes Berg 提交于
      When reconfiguring an interface due to a previous
      hardware restart, mac80211 will currently include
      the new IBSS flag on non-IBSS interfaces which may
      confuse drivers.
      
      Instead of doing the ~0 trick, simply spell out
      which things are going to be reconfigured.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ac8dd506
  11. 06 5月, 2010 1 次提交
    • V
      sctp: Fix a race between ICMP protocol unreachable and connect() · 50b5d6ad
      Vlad Yasevich 提交于
      ICMP protocol unreachable handling completely disregarded
      the fact that the user may have locked the socket.  It proceeded
      to destroy the association, even though the user may have
      held the lock and had a ref on the association.  This resulted
      in the following:
      
      Attempt to release alive inet socket f6afcc00
      
      =========================
      [ BUG: held lock freed! ]
      -------------------------
      somenu/2672 is freeing memory f6afcc00-f6afcfff, with a lock still held
      there!
       (sk_lock-AF_INET){+.+.+.}, at: [<c122098a>] sctp_connect+0x13/0x4c
      1 lock held by somenu/2672:
       #0:  (sk_lock-AF_INET){+.+.+.}, at: [<c122098a>] sctp_connect+0x13/0x4c
      
      stack backtrace:
      Pid: 2672, comm: somenu Not tainted 2.6.32-telco #55
      Call Trace:
       [<c1232266>] ? printk+0xf/0x11
       [<c1038553>] debug_check_no_locks_freed+0xce/0xff
       [<c10620b4>] kmem_cache_free+0x21/0x66
       [<c1185f25>] __sk_free+0x9d/0xab
       [<c1185f9c>] sk_free+0x1c/0x1e
       [<c1216e38>] sctp_association_put+0x32/0x89
       [<c1220865>] __sctp_connect+0x36d/0x3f4
       [<c122098a>] ? sctp_connect+0x13/0x4c
       [<c102d073>] ? autoremove_wake_function+0x0/0x33
       [<c12209a8>] sctp_connect+0x31/0x4c
       [<c11d1e80>] inet_dgram_connect+0x4b/0x55
       [<c11834fa>] sys_connect+0x54/0x71
       [<c103a3a2>] ? lock_release_non_nested+0x88/0x239
       [<c1054026>] ? might_fault+0x42/0x7c
       [<c1054026>] ? might_fault+0x42/0x7c
       [<c11847ab>] sys_socketcall+0x6d/0x178
       [<c10da994>] ? trace_hardirqs_on_thunk+0xc/0x10
       [<c1002959>] syscall_call+0x7/0xb
      
      This was because the sctp_wait_for_connect() would aqcure the socket
      lock and then proceed to release the last reference count on the
      association, thus cause the fully destruction path to finish freeing
      the socket.
      
      The simplest solution is to start a very short timer in case the socket
      is owned by user.  When the timer expires, we can do some verification
      and be able to do the release properly.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      50b5d6ad
  12. 03 5月, 2010 1 次提交
  13. 02 5月, 2010 1 次提交
    • E
      net: sock_def_readable() and friends RCU conversion · 43815482
      Eric Dumazet 提交于
      sk_callback_lock rwlock actually protects sk->sk_sleep pointer, so we
      need two atomic operations (and associated dirtying) per incoming
      packet.
      
      RCU conversion is pretty much needed :
      
      1) Add a new structure, called "struct socket_wq" to hold all fields
      that will need rcu_read_lock() protection (currently: a
      wait_queue_head_t and a struct fasync_struct pointer).
      
      [Future patch will add a list anchor for wakeup coalescing]
      
      2) Attach one of such structure to each "struct socket" created in
      sock_alloc_inode().
      
      3) Respect RCU grace period when freeing a "struct socket_wq"
      
      4) Change sk_sleep pointer in "struct sock" by sk_wq, pointer to "struct
      socket_wq"
      
      5) Change sk_sleep() function to use new sk->sk_wq instead of
      sk->sk_sleep
      
      6) Change sk_has_sleeper() to wq_has_sleeper() that must be used inside
      a rcu_read_lock() section.
      
      7) Change all sk_has_sleeper() callers to :
        - Use rcu_read_lock() instead of read_lock(&sk->sk_callback_lock)
        - Use wq_has_sleeper() to eventually wakeup tasks.
        - Use rcu_read_unlock() instead of read_unlock(&sk->sk_callback_lock)
      
      8) sock_wake_async() is modified to use rcu protection as well.
      
      9) Exceptions :
        macvtap, drivers/net/tun.c, af_unix use integrated "struct socket_wq"
      instead of dynamically allocated ones. They dont need rcu freeing.
      
      Some cleanups or followups are probably needed, (possible
      sk_callback_lock conversion to a spinlock for example...).
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      43815482
  14. 01 5月, 2010 2 次提交