1. 22 4月, 2012 3 次提交
    • P
      tcp: Initial repair mode · ee995283
      Pavel Emelyanov 提交于
      This includes (according the the previous description):
      
      * TCP_REPAIR sockoption
      
      This one just puts the socket in/out of the repair mode.
      Allowed for CAP_NET_ADMIN and for closed/establised sockets only.
      When repair mode is turned off and the socket happens to be in
      the established state the window probe is sent to the peer to
      'unlock' the connection.
      
      * TCP_REPAIR_QUEUE sockoption
      
      This one sets the queue which we're about to repair. The
      'no-queue' is set by default.
      
      * TCP_QUEUE_SEQ socoption
      
      Sets the write_seq/rcv_nxt of a selected repaired queue.
      Allowed for TCP_CLOSE-d sockets only. When the socket changes
      its state the other seq-s are changed by the kernel according
      to the protocol rules (most of the existing code is actually
      reused).
      
      * Ability to forcibly bind a socket to a port
      
      The sk->sk_reuse is set to SK_FORCE_REUSE.
      
      * Immediate connect modification
      
      The connect syscall initializes the connection, then directly jumps
      to the code which finalizes it.
      
      * Silent close modification
      
      The close just aborts the connection (similar to SO_LINGER with 0
      time) but without sending any FIN/RST-s to peer.
      Signed-off-by: NPavel Emelyanov <xemul@parallels.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ee995283
    • P
      tcp: Move code around · 370816ae
      Pavel Emelyanov 提交于
      This is just the preparation patch, which makes the needed for
      TCP repair code ready for use.
      Signed-off-by: NPavel Emelyanov <xemul@parallels.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      370816ae
    • P
      sock: Introduce named constants for sk_reuse · 4a17fd52
      Pavel Emelyanov 提交于
      Name them in a "backward compatible" manner, i.e. reuse or not
      are still 1 and 0 respectively. The reuse value of 2 means that
      the socket with it will forcibly reuse everyone else's port.
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a17fd52
  2. 21 4月, 2012 9 次提交
  3. 17 4月, 2012 3 次提交
  4. 16 4月, 2012 1 次提交
  5. 15 4月, 2012 3 次提交
  6. 14 4月, 2012 8 次提交
  7. 13 4月, 2012 10 次提交
  8. 12 4月, 2012 3 次提交
    • T
      cfg80211: add channel switch notify event · 5314526b
      Thomas Pedersen 提交于
      The firmware may decide to switch channels while already beaconing, e.g.
      in response to a cfg80211 connect request on a different vif. Add this
      event to notify userspace when an AP or GO interface has successfully
      migrated to a new channel, so it can update its configuration
      accordingly.
      Signed-off-by: NThomas Pedersen <c_tpeder@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5314526b
    • J
      cfg80211/mac80211: enable proper device_set_wakeup_enable handling · 6d52563f
      Johannes Berg 提交于
      In WoWLAN, we only get the triggers when we actually get
      to suspend. As a consequence, drivers currently don't
      know that the device should enable wakeup. However, the
      device_set_wakeup_enable() API is intended to be called
      when the wakeup is enabled, not later when needed.
      
      Add a new set_wakeup() call to cfg80211 and mac80211 to
      allow drivers to properly call device_set_wakeup_enable.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6d52563f
    • J
      mac80211: add improved HW queue control · 3a25a8c8
      Johannes Berg 提交于
      mac80211 currently only supports one hardware queue
      per AC. This is already problematic for off-channel
      uses since if we go off channel while the BE queue
      is full and then try to send an off-channel frame
      the frame will never go out. This will become worse
      when we support multi-channel since then a queue on
      one channel might be full, but we have to stop the
      software queue for all channels. That is obviously
      not desirable.
      
      To address this problem allow drivers to register
      more hardware queues, and allow them to map them to
      virtual interfaces. When they stop a hardware queue
      the corresponding AC software queues on the correct
      interfaces will be stopped as well. Additionally,
      there's an off-channel queue to solve that problem
      and a per-interface after-DTIM beacon queue. This
      allows drivers to manage software queues closer to
      how the hardware works.
      
      Currently, there's a limit of 16 hardware queues.
      This may or may not be sufficient, we can adjust it
      as needed.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3a25a8c8