1. 15 7月, 2008 11 次提交
    • M
      [Bluetooth] Store remote modem status for RFCOMM TTY · 8b6b3da7
      Marcel Holtmann 提交于
      When switching a RFCOMM socket to a TTY, the remote modem status might
      be needed later. Currently it is lost since the original configuration
      is done via the socket interface. So store the modem status and reply
      it when the socket has been converted to a TTY.
      Signed-off-by: NDenis Kenzior <denis.kenzior@trolltech.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      8b6b3da7
    • M
      [Bluetooth] Add timestamp support to L2CAP, RFCOMM and SCO · 3241ad82
      Marcel Holtmann 提交于
      Enable the common timestamp functionality that the network subsystem
      provides for L2CAP, RFCOMM and SCO sockets. It is possible to either
      use SO_TIMESTAMP or the IOCTLs to retrieve the timestamp of the
      current packet.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      3241ad82
    • M
      [Bluetooth] Export details about authentication requirements · 40be492f
      Marcel Holtmann 提交于
      With the Simple Pairing support, the authentication requirements are
      an explicit setting during the bonding process. Track and enforce the
      requirements and allow higher layers like L2CAP and RFCOMM to increase
      them if needed.
      
      This patch introduces a new IOCTL that allows to query the current
      authentication requirements. It is also possible to detect Simple
      Pairing support in the kernel this way.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      40be492f
    • M
      [Bluetooth] Use ACL config stage to retrieve remote features · 769be974
      Marcel Holtmann 提交于
      The Bluetooth technology introduces new features on a regular basis
      and for some of them it is important that the hardware on both sides
      support them. For features like Simple Pairing it is important that
      the host stacks on both sides have switched this feature on. To make
      valid decisions, a config stage during ACL link establishment has been
      introduced that retrieves remote features and if needed also the remote
      extended features (known as remote host features) before signalling
      this link as connected.
      
      This change introduces full reference counting of incoming and outgoing
      ACL links and the Bluetooth core will disconnect both if no owner of it
      is present. To better handle interoperability during the pairing phase
      the disconnect timeout for incoming connections has been increased to
      10 seconds. This is five times more than for outgoing connections.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      769be974
    • M
      [Bluetooth] Track status of remote Simple Pairing mode · 41a96212
      Marcel Holtmann 提交于
      The Simple Pairing process can only be used if both sides have the
      support enabled in the host stack. The current Bluetooth specification
      has three ways to detect this support.
      
      If an Extended Inquiry Result has been sent during inquiry then it
      is safe to assume that Simple Pairing is enabled. It is not allowed
      to enable Extended Inquiry without Simple Pairing. During the remote
      name request phase a notification with the remote host supported
      features will be sent to indicate Simple Pairing support. Also the
      second page of the remote extended features can indicate support for
      Simple Pairing.
      
      For all three cases the value of remote Simple Pairing mode is stored
      in the inquiry cache for later use.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      41a96212
    • M
      [Bluetooth] Track status of Simple Pairing mode · 333140b5
      Marcel Holtmann 提交于
      The Simple Pairing feature is optional and needs to be enabled by the
      host stack first. The Linux kernel relies on the Bluetooth daemon to
      either enable or disable it, but at any time it needs to know the
      current state of the Simple Pairing mode. So track any changes made
      by external entities and store the current mode in the HCI device
      structure.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      333140b5
    • M
      [Bluetooth] Disable disconnect timer during Simple Pairing · 0493684e
      Marcel Holtmann 提交于
      During the Simple Pairing process the HCI disconnect timer must be
      disabled. The way to do this is by holding a reference count of the
      HCI connection. The Simple Pairing process on both sides starts with
      an IO Capabilities Request and ends with Simple Pairing Complete.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      0493684e
    • M
      [Bluetooth] Make use of the default link policy settings · e4e8e37c
      Marcel Holtmann 提交于
      The Bluetooth specification supports the default link policy settings
      on a per host controller basis. For every new connection the link
      manager would then use these settings. It is better to use this instead
      of bothering the controller on every connection setup to overwrite the
      default settings.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      e4e8e37c
    • M
      [Bluetooth] Track connection packet type changes · a8746417
      Marcel Holtmann 提交于
      The connection packet type can be changed after the connection has been
      established and thus needs to be properly tracked to ensure that the
      host stack has always correct and valid information about it.
      
      On incoming connections the Bluetooth core switches the supported packet
      types to the configured list for this controller. However the usefulness
      of this feature has been questioned a lot. The general consent is that
      every Bluetooth host stack should enable as many packet types as the
      hardware actually supports and leave the decision to the link manager
      software running on the Bluetooth chip.
      
      When running on Bluetooth 2.0 or later hardware, don't change the packet
      type for incoming connections anymore. This hardware likely supports
      Enhanced Data Rate and thus leave it completely up to the link manager
      to pick the best packet type.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      a8746417
    • M
      [Bluetooth] Disconnect when encryption gets disabled · 9719f8af
      Marcel Holtmann 提交于
      The Bluetooth specification allows to enable or disable the encryption
      of an ACL link at any time by either the peer or the remote device. If
      a L2CAP or RFCOMM connection requested an encrypted link, they will now
      disconnect that link if the encryption gets disabled. Higher protocols
      that don't care about encryption (like SDP) are not affected.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      9719f8af
    • M
      [Bluetooth] Enforce security for outgoing RFCOMM connections · 77db1980
      Marcel Holtmann 提交于
      Recent tests with various Bluetooth headsets have shown that some of
      them don't enforce authentication and encryption when connecting. All
      of them leave it up to the host stack to enforce it. Non of them should
      allow unencrypted connections, but that is how it is. So in case the
      link mode settings require authentication and/or encryption it will now
      also be enforced on outgoing RFCOMM connections. Previously this was
      only done for incoming connections.
      
      This support has a small drawback from a protocol level point of view
      since the host stack can't really tell with 100% certainty if a remote
      side is already authenticated or not. So if both sides are configured
      to enforce authentication it will be requested twice. Most Bluetooth
      chips are caching this information and thus no extra authentication
      procedure has to be triggered over-the-air, but it can happen.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      77db1980
  2. 06 7月, 2008 1 次提交
  3. 05 7月, 2008 7 次提交
  4. 04 7月, 2008 2 次提交
  5. 02 7月, 2008 2 次提交
  6. 01 7月, 2008 2 次提交
    • J
      Properly notify block layer of sync writes · 18ce3751
      Jens Axboe 提交于
      fsync_buffers_list() and sync_dirty_buffer() both issue async writes and
      then immediately wait on them. Conceptually, that makes them sync writes
      and we should treat them as such so that the IO schedulers can handle
      them appropriately.
      
      This patch fixes a write starvation issue that Lin Ming reported, where
      xx is stuck for more than 2 minutes because of a large number of
      synchronous IO in the system:
      
      INFO: task kjournald:20558 blocked for more than 120 seconds.
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
      message.
      kjournald     D ffff810010820978  6712 20558      2
      ffff81022ddb1d10 0000000000000046 ffff81022e7baa10 ffffffff803ba6f2
      ffff81022ecd0000 ffff8101e6dc9160 ffff81022ecd0348 000000008048b6cb
      0000000000000086 ffff81022c4e8d30 0000000000000000 ffffffff80247537
      Call Trace:
      [<ffffffff803ba6f2>] kobject_get+0x12/0x17
      [<ffffffff80247537>] getnstimeofday+0x2f/0x83
      [<ffffffff8029c1ac>] sync_buffer+0x0/0x3f
      [<ffffffff8066d195>] io_schedule+0x5d/0x9f
      [<ffffffff8029c1e7>] sync_buffer+0x3b/0x3f
      [<ffffffff8066d3f0>] __wait_on_bit+0x40/0x6f
      [<ffffffff8029c1ac>] sync_buffer+0x0/0x3f
      [<ffffffff8066d48b>] out_of_line_wait_on_bit+0x6c/0x78
      [<ffffffff80243909>] wake_bit_function+0x0/0x23
      [<ffffffff8029e3ad>] sync_dirty_buffer+0x98/0xcb
      [<ffffffff8030056b>] journal_commit_transaction+0x97d/0xcb6
      [<ffffffff8023a676>] lock_timer_base+0x26/0x4b
      [<ffffffff8030300a>] kjournald+0xc1/0x1fb
      [<ffffffff802438db>] autoremove_wake_function+0x0/0x2e
      [<ffffffff80302f49>] kjournald+0x0/0x1fb
      [<ffffffff802437bb>] kthread+0x47/0x74
      [<ffffffff8022de51>] schedule_tail+0x28/0x5d
      [<ffffffff8020cac8>] child_rip+0xa/0x12
      [<ffffffff80243774>] kthread+0x0/0x74
      [<ffffffff8020cabe>] child_rip+0x0/0x12
      
      Lin Ming confirms that this patch fixes the issue. I've run tests with
      it for the past week and no ill effects have been observed, so I'm
      proposing it for inclusion into 2.6.26.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      18ce3751
    • E
      mac80211: don't accept WEP keys other than WEP40 and WEP104 · 23976efe
      Emmanuel Grumbach 提交于
      This patch makes mac80211 refuse a WEP key whose length is not WEP40 nor
      WEP104.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      23976efe
  7. 30 6月, 2008 1 次提交
  8. 28 6月, 2008 3 次提交
  9. 27 6月, 2008 3 次提交
  10. 26 6月, 2008 2 次提交
  11. 25 6月, 2008 5 次提交
  12. 24 6月, 2008 1 次提交