1. 18 4月, 2013 1 次提交
  2. 17 4月, 2013 2 次提交
    • D
      Bluetooth: introduce hci_conn ref-counting · 8d12356f
      David Herrmann 提交于
      We currently do not allow using hci_conn from outside of HCI-core.
      However, several other users could make great use of it. This includes
      HIDP, rfcomm and all other sub-protocols that rely on an active
      connection.
      
      Hence, we now introduce hci_conn ref-counting. We currently never call
      get_device(). put_device() is exclusively used in hci_conn_del_sysfs().
      Hence, we currently never have a greater device-refcnt than 1.
      Therefore, it is safe to move the put_device() call from
      hci_conn_del_sysfs() to hci_conn_del() (it's the only caller). In fact,
      this even fixes a "use-after-free" bug as we access hci_conn after calling
      hci_conn_del_sysfs() in hci_conn_del().
      
      From now on we can add references to hci_conn objects in other layers
      (like l2cap_sock, HIDP, rfcomm, ...) and grab a reference via
      hci_conn_get(). This does _not_ guarantee, that the connection is still
      alive. But, this isn't what we want. We can simply lock the hci_conn
      device and use "device_is_registered(hci_conn->dev)" to test that.
      However, this is hardly necessary as outside users should never rely on
      the HCI connection to be alive, anyway. Instead, they should solely rely
      on the device-object to be available.
      But if sub-devices want the hci_conn object as sysfs parent, they need to
      be notified when the connection drops. This will be introduced in later
      patches with l2cap_users.
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      8d12356f
    • D
      Bluetooth: remove unneeded hci_conn_hold/put_device() · fc225c3f
      David Herrmann 提交于
      hci_conn_hold/put_device() is used to control when hci_conn->dev is no
      longer needed and can be deleted from the system. Lets first look how they
      are currently used throughout the code (excluding HIDP!).
      
      All code that uses hci_conn_hold_device() looks like this:
          ...
          hci_conn_hold_device();
          hci_conn_add_sysfs();
          ...
      On the other side, hci_conn_put_device() is exclusively used in
      hci_conn_del().
      
      So, considering that hci_conn_del() must not be called twice (which would
      fail horribly), we know that hci_conn_put_device() is only called _once_
      (which is in hci_conn_del()).
      On the other hand, hci_conn_add_sysfs() must not be called twice, either
      (it would call device_add twice, which breaks the device, see
      drivers/base/core.c). So we know that hci_conn_hold_device() is also
      called only once (it's only called directly before hci_conn_add_sysfs()).
      
      So hold and put are known to be called only once. That means we can safely
      remove them and directly call hci_conn_del_sysfs() in hci_conn_del().
      
      But there is one issue left: HIDP also uses hci_conn_hold/put_device().
      However, this case can be ignored and simply removed as it is totally
      broken. The issue is, the only thing HIDP delays with
      hci_conn_hold_device() is the removal of the hci_conn->dev from sysfs.
      But, the hci_conn device has no mechanism to get notified when its own
      parent (hci_dev) gets removed from sysfs. hci_dev_hold/put() does _not_
      control when it is removed but only when the device object is created
      and destroyed.
      And hci_dev calls hci_conn_flush_*() when it removes itself from sysfs,
      which itself causes hci_conn_del() to be called, but it does _not_ cause
      hci_conn_del_sysfs() to be called, which is wrong.
      
      Hence, we fix it to call hci_conn_del_sysfs() in hci_conn_del(). This
      guarantees that a hci_conn object is removed from sysfs _before_ its
      parent hci_dev is removed.
      
      The changes to HIDP look scary, wrong and broken. However, if you look at
      the HIDP session management, you will notice they're already broken in the
      exact _same_ way (ever tried "unplugging" HIDP devices? Breaks _all_ the
      time).
      So this patch only makes HIDP look _scary_ and _obviously broken_. It does
      not break HIDP itself, it already is!
      
      See later patches in this series which fix HIDP to use proper
      session-management.
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      fc225c3f
  3. 12 4月, 2013 1 次提交
    • D
      Bluetooth: rename hci_conn_put to hci_conn_drop · 76a68ba0
      David Herrmann 提交于
      We use _get() and _put() for device ref-counting in the kernel. However,
      hci_conn_put() is _not_ used for ref-counting, hence, rename it to
      hci_conn_drop() so we can later fix ref-counting and introduce
      hci_conn_put().
      
      hci_conn_hold() and hci_conn_put() are currently used to manage how long a
      connection should be held alive. When the last user drops the connection,
      we spawn a delayed work that performs the disconnect. Obviously, this has
      nothing to do with ref-counting for the _object_ but rather for the
      keep-alive of the connection.
      
      But we really _need_ proper ref-counting for the _object_ to allow
      connection-users like rfcomm-tty, HIDP or others.
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      76a68ba0
  4. 05 4月, 2013 6 次提交
  5. 04 4月, 2013 1 次提交
  6. 19 3月, 2013 2 次提交
  7. 10 3月, 2013 2 次提交
  8. 08 3月, 2013 6 次提交
  9. 02 2月, 2013 1 次提交
  10. 23 1月, 2013 3 次提交
  11. 18 1月, 2013 1 次提交
  12. 04 12月, 2012 3 次提交
  13. 19 11月, 2012 1 次提交
  14. 02 11月, 2012 4 次提交
  15. 24 10月, 2012 2 次提交
  16. 11 10月, 2012 4 次提交