1. 12 5月, 2009 3 次提交
  2. 08 5月, 2009 2 次提交
  3. 07 5月, 2009 4 次提交
    • J
      mac80211: tell driver when idle · 5cff20e6
      Johannes Berg 提交于
      When we aren't doing anything in mac80211, we can turn off
      much of the hardware, depending on the driver/hw. Not doing
      anything, aka being idle, means:
      
       * no monitor interfaces
       * no AP/mesh/wds interfaces
       * any station interfaces are in DISABLED state
       * any IBSS interfaces aren't trying to be in a network
       * we aren't trying to scan
      
      By creating a new function that verifies these conditions and calling
      it at strategic points where the states of those conditions change,
      we can easily make mac80211 tell the driver when we are idle to save
      power.
      
      Additionally, this fixes a small quirk where a recalculated powersave
      state is passed to the driver even if the hardware is about to stopped
      completely.
      
      This patch intentionally doesn't touch radio_enabled because that is
      currently implemented to be a soft rfkill which is inappropriate here
      when we need to be able to wake up with low latency.
      
      One thing I'm not entirely sure about is this:
      
        phy0: device no longer idle - in use
        wlan0: direct probe to AP 00:11:24:91:07:4d try 1
        wlan0 direct probe responded
        wlan0: authenticate with AP 00:11:24:91:07:4d
        wlan0: authenticated
      > phy0: device now idle
      > phy0: device no longer idle - in use
        wlan0: associate with AP 00:11:24:91:07:4d
        wlan0: RX AssocResp from 00:11:24:91:07:4d (capab=0x401 status=0 aid=1)
        wlan0: associated
      
      Is it appropriate to go into idle state for a short time when we have
      just authenticated, but not associated yet? This happens only with the
      userspace SME, because we cannot really know how long it will wait
      before asking us to associate. Would going idle after a short timeout
      be more appropriate? We may need to revisit this, depending on what
      happens.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5cff20e6
    • J
      mac80211: unify config_interface and bss_info_changed · 2d0ddec5
      Johannes Berg 提交于
      The config_interface method is a little strange, it contains the
      BSSID and beacon updates, while bss_info_changed contains most
      other BSS information for each interface. This patch removes
      config_interface and rolls all the information it previously
      passed to drivers into bss_info_changed.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2d0ddec5
    • J
      mac80211: clean up beacon interval settings · 57c4d7b4
      Johannes Berg 提交于
      We currently have two beacon interval configuration knobs:
      hw.conf.beacon_int and vif.bss_info.beacon_int. This is
      rather confusing, even though the former is used when we
      beacon ourselves and the latter when we are associated to
      an AP.
      
      This just deprecates the hw.conf.beacon_int setting in favour
      of always using vif.bss_info.beacon_int. Since it touches all
      the beaconing IBSS code anyway, we can also add support for
      the cfg80211 IBSS beacon interval configuration easily.
      
      NOTE: The hw.conf.beacon_int setting is retained for now due
            to drivers still using it -- I couldn't untangle all
            drivers, some are updated in this patch.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      57c4d7b4
    • J
      mac80211: rename max_sleep_interval to max_sleep_period · 9ccebe61
      Johannes Berg 提交于
      Kalle points out that max_sleep_interval is somewhat confusing
      because the value is measured in beacon intervals, and not in
      TU. Rename it to max_sleep_period to be consistent with things
      like DTIM period that are also measured in beacon intervals.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9ccebe61
  4. 05 5月, 2009 2 次提交
    • M
      Bluetooth: Fix issue with sysfs handling for connections · a67e899c
      Marcel Holtmann 提交于
      Due to a semantic changes in flush_workqueue() the current approach of
      synchronizing the sysfs handling for connections doesn't work anymore. The
      whole approach is actually fully broken and based on assumptions that are
      no longer valid.
      
      With the introduction of Simple Pairing support, the creation of low-level
      ACL links got changed. This change invalidates the reason why in the past
      two independent work queues have been used for adding/removing sysfs
      devices. The adding of the actual sysfs device is now postponed until the
      host controller successfully assigns an unique handle to that link. So
      the real synchronization happens inside the controller and not the host.
      
      The only left-over problem is that some internals of the sysfs device
      handling are not initialized ahead of time. This leaves potential access
      to invalid data and can cause various NULL pointer dereferences. To fix
      this a new function makes sure that all sysfs details are initialized
      when an connection attempt is made. The actual sysfs device is only
      registered when the connection has been successfully established. To
      avoid a race condition with the registration, the check if a device is
      registered has been moved into the removal work.
      
      As an extra protection two flush_work() calls are left in place to
      make sure a previous add/del work has been completed first.
      
      Based on a report by Marc Pignat <marc.pignat@hevs.ch>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Tested-by: NJustin P. Mattock <justinmattock@gmail.com>
      Tested-by: NRoger Quadros <ext-roger.quadros@nokia.com>
      Tested-by: NMarc Pignat <marc.pignat@hevs.ch>
      a67e899c
    • S
      tcp: Fix tcp_prequeue() to get correct rto_min value · 0c266898
      Satoru SATOH 提交于
      tcp_prequeue() refers to the constant value (TCP_RTO_MIN) regardless of
      the actual value might be tuned. The following patches fix this and make
      tcp_prequeue get the actual value returns from tcp_rto_min().
      Signed-off-by: NSatoru SATOH <satoru.satoh@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c266898
  5. 04 5月, 2009 1 次提交
  6. 29 4月, 2009 2 次提交
    • M
      Bluetooth: Add different pairing timeout for Legacy Pairing · 052b30b0
      Marcel Holtmann 提交于
      The Bluetooth stack uses a reference counting for all established ACL
      links and if no user (L2CAP connection) is present, the link will be
      terminated to save power. The problem part is the dedicated pairing
      when using Legacy Pairing (Bluetooth 2.0 and before). At that point
      no user is present and pairing attempts will be disconnected within
      10 seconds or less. In previous kernel version this was not a problem
      since the disconnect timeout wasn't triggered on incoming connections
      for the first time. However this caused issues with broken host stacks
      that kept the connections around after dedicated pairing. When the
      support for Simple Pairing got added, the link establishment procedure
      needed to be changed and now causes issues when using Legacy Pairing
      
      When using Simple Pairing it is possible to do a proper reference
      counting of ACL link users. With Legacy Pairing this is not possible
      since the specification is unclear in some areas and too many broken
      Bluetooth devices have already been deployed. So instead of trying to
      deal with all the broken devices, a special pairing timeout will be
      introduced that increases the timeout to 60 seconds when pairing is
      triggered.
      
      If a broken devices now puts the stack into an unforeseen state, the
      worst that happens is the disconnect timeout triggers after 120 seconds
      instead of 4 seconds. This allows successful pairings with legacy and
      broken devices now.
      
      Based on a report by Johan Hedberg <johan.hedberg@nokia.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      052b30b0
    • R
      Bluetooth: Ensure that HCI sysfs add/del is preempt safe · f3784d83
      Roger Quadros 提交于
      Use a different work_struct variables for add_conn() and del_conn() and
      use single work queue instead of two for adding and deleting connections.
      
      It eliminates the following error on a preemptible kernel:
      
      [  204.358032] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
      [  204.370697] pgd = c0004000
      [  204.373443] [0000000c] *pgd=00000000
      [  204.378601] Internal error: Oops: 17 [#1] PREEMPT
      [  204.383361] Modules linked in: vfat fat rfcomm sco l2cap sd_mod scsi_mod iphb pvr2d drm omaplfb ps
      [  204.438537] CPU: 0    Not tainted  (2.6.28-maemo2 #1)
      [  204.443664] PC is at klist_put+0x2c/0xb4
      [  204.447601] LR is at klist_put+0x18/0xb4
      [  204.451568] pc : [<c0270f08>]    lr : [<c0270ef4>]    psr: a0000113
      [  204.451568] sp : cf1b3f10  ip : cf1b3f10  fp : cf1b3f2c
      [  204.463104] r10: 00000000  r9 : 00000000  r8 : bf08029c
      [  204.468353] r7 : c7869200  r6 : cfbe2690  r5 : c78692c8  r4 : 00000001
      [  204.474945] r3 : 00000001  r2 : cf1b2000  r1 : 00000001  r0 : 00000000
      [  204.481506] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment kernel
      [  204.488861] Control: 10c5387d  Table: 887fc018  DAC: 00000017
      [  204.494628] Process btdelconn (pid: 515, stack limit = 0xcf1b22e0)
      Signed-off-by: NRoger Quadros <ext-roger.quadros@nokia.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      f3784d83
  7. 27 4月, 2009 2 次提交
  8. 23 4月, 2009 20 次提交
  9. 20 4月, 2009 1 次提交
  10. 17 4月, 2009 1 次提交
    • P
      netfilter: nf_nat: add support for persistent mappings · 98d500d6
      Patrick McHardy 提交于
      The removal of the SAME target accidentally removed one feature that is
      not available from the normal NAT targets so far, having multi-range
      mappings that use the same mapping for each connection from a single
      client. The current behaviour is to choose the address from the range
      based on source and destination IP, which breaks when communicating
      with sites having multiple addresses that require all connections to
      originate from the same IP address.
      
      Introduce a IP_NAT_RANGE_PERSISTENT option that controls whether the
      destination address is taken into account for selecting addresses.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=12954Signed-off-by: NPatrick McHardy <kaber@trash.net>
      98d500d6
  11. 11 4月, 2009 1 次提交
    • V
      ipv6: Fix NULL pointer dereference with time-wait sockets · 499923c7
      Vlad Yasevich 提交于
      Commit b2f5e7cd
      (ipv6: Fix conflict resolutions during ipv6 binding)
      introduced a regression where time-wait sockets were
      not treated correctly.  This resulted in the following:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000062
      IP: [<ffffffff805d7d61>] ipv4_rcv_saddr_equal+0x61/0x70
      ...
      Call Trace:
      [<ffffffffa033847b>] ipv6_rcv_saddr_equal+0x1bb/0x250 [ipv6]
      [<ffffffffa03505a8>] inet6_csk_bind_conflict+0x88/0xd0 [ipv6]
      [<ffffffff805bb18e>] inet_csk_get_port+0x1ee/0x400
      [<ffffffffa0319b7f>] inet6_bind+0x1cf/0x3a0 [ipv6]
      [<ffffffff8056d17c>] ? sockfd_lookup_light+0x3c/0xd0
      [<ffffffff8056ed49>] sys_bind+0x89/0x100
      [<ffffffff80613ea2>] ? trace_hardirqs_on_thunk+0x3a/0x3c
      [<ffffffff8020bf9b>] system_call_fastpath+0x16/0x1b
      Tested-by: NBrian Haley <brian.haley@hp.com>
      Tested-by: NEd Tomlinson <edt@aei.ca>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      499923c7
  12. 06 4月, 2009 1 次提交