1. 17 Apr, 2013 3 commits
    • David Herrmann's avatar
      Bluetooth: hidp: remove unused session->state field · dcc07647
      David Herrmann authored
      This field is always BT_CONNECTED. Remove it and set it to BT_CONNECTED in
      hidp_copy_session() unconditionally.
      
      Also note that this field is totally bogus. Userspace can query an
      hidp-session for its state. However, whenever user-space queries us, this
      field should be BT_CONNECTED. If it wasn't BT_CONNECTED, then we would be
      currently cleaning up the session and the session itself would exit in the
      next few milliseconds. Hence, there is no reason to let user-space know
      that the session will exit now if they cannot make _any_ use of that.
      
      Thus, remove the field and let user-space think that a session is always
      BT_CONNECTED as long as they can query it.
      Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      dcc07647
    • David Herrmann's avatar
      Bluetooth: introduce hci_conn ref-counting · 8d12356f
      David Herrmann authored
      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: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      8d12356f
    • David Herrmann's avatar
      Bluetooth: remove unneeded hci_conn_hold/put_device() · fc225c3f
      David Herrmann authored
      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: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      fc225c3f
  2. 11 Apr, 2013 7 commits
  3. 06 Apr, 2013 2 commits
  4. 04 Apr, 2013 14 commits
  5. 03 Apr, 2013 14 commits