1. 14 10月, 2013 1 次提交
  2. 26 9月, 2013 1 次提交
  3. 19 9月, 2013 1 次提交
  4. 10 4月, 2013 4 次提交
  5. 08 4月, 2013 1 次提交
  6. 03 4月, 2013 1 次提交
  7. 01 4月, 2013 1 次提交
    • K
      net: add option to enable error queue packets waking select · 7d4c04fc
      Keller, Jacob E 提交于
      Currently, when a socket receives something on the error queue it only wakes up
      the socket on select if it is in the "read" list, that is the socket has
      something to read. It is useful also to wake the socket if it is in the error
      list, which would enable software to wait on error queue packets without waking
      up for regular data on the socket. The main use case is for receiving
      timestamped transmit packets which return the timestamp to the socket via the
      error queue. This enables an application to select on the socket for the error
      queue only instead of for the regular traffic.
      
      -v2-
      * Added the SO_SELECT_ERR_QUEUE socket option to every architechture specific file
      * Modified every socket poll function that checks error queue
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Cc: Jeffrey Kirsher <jeffrey.t.kirsher@intel.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Matthew Vick <matthew.vick@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7d4c04fc
  8. 08 3月, 2013 1 次提交
    • D
      Bluetooth: change bt_sock_unregister() to return void · be9f97f0
      David Herrmann 提交于
      There is no reason a caller ever wants to check the return type of this
      call. _Iff_ a user successfully called bt_sock_register(), they're allowed
      to call bt_sock_unregister().
      All other calls in the kernel (device_del, device_unregister, kfree(), ..)
      that are logically equivalent return void. Lets not make callers think
      they have to check the return type of this call and instead simply return
      void.
      
      We guarantee that after bt_sock_unregister() is called, the socket type
      _is_ unregistered. If that is not what the caller wants, they're using the
      wrong function, anyway.
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      be9f97f0
  9. 19 2月, 2013 2 次提交
  10. 13 10月, 2012 1 次提交
    • E
      userns: Properly print bluetooth socket uids · 1bbb3095
      Eric W. Biederman 提交于
      With user namespace support enabled building bluetooth generated the warning.
      net/bluetooth/af_bluetooth.c: In function ‘bt_seq_show’:
      net/bluetooth/af_bluetooth.c:598:7: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 7 has type ‘kuid_t’ [-Wformat]
      
      Convert sock_i_uid from a kuid_t to a uid_t before printing, to avoid
      this problem.
      Reported-by: NFengguang Wu <fengguang.wu@intel.com>
      Cc: Masatake YAMATO <yamato@redhat.com>
      Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      1bbb3095
  11. 28 9月, 2012 1 次提交
  12. 22 8月, 2012 1 次提交
  13. 15 8月, 2012 1 次提交
  14. 07 8月, 2012 1 次提交
    • M
      Bluetooth: /proc/net/ entries for bluetooth protocols · 256a06c8
      Masatake YAMATO 提交于
      lsof command can tell the type of socket processes are using.
      Internal lsof uses inode numbers on socket fs to resolve the type of
      sockets. Files under /proc/net/, such as tcp, udp, unix, etc provides
      such inode information.
      
      Unfortunately bluetooth related protocols don't provide such inode
      information. This patch series introduces /proc/net files for the protocols.
      
      This patch against af_bluetooth.c provides facility to the implementation
      of protocols. This patch extends bt_sock_list and introduces two exported
      function bt_procfs_init, bt_procfs_cleanup.
      
      The type bt_sock_list is already used in some of implementation of
      protocols. bt_procfs_init prepare seq_operations which converts
      protocol own bt_sock_list data to protocol own proc entry when the
      entry is accessed.
      
      What I, lsof user, need is just inode number of bluetooth
      socket. However, people may want more information. The bt_procfs_init
      takes a function pointer for customizing the show handler of
      seq_operations.
      
      In v4 patch, __acquires and __releases attributes are added to suppress
      sparse warning. Suggested by Andrei Emeltchenko.
      
      In v5 patch, linux/proc_fs.h is included to use PDE. Build error is
      reported by Fengguang Wu.
      Signed-off-by: NMasatake YAMATO <yamato@redhat.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      256a06c8
  15. 05 6月, 2012 4 次提交
  16. 17 5月, 2012 1 次提交
  17. 15 5月, 2012 1 次提交
  18. 15 2月, 2012 1 次提交
    • O
      Bluetooth: silence lockdep warning · b5a30dda
      Octavian Purdila 提交于
      Since bluetooth uses multiple protocols types, to avoid lockdep
      warnings, we need to use different lockdep classes (one for each
      protocol type).
      
      This is already done in bt_sock_create but it misses a couple of cases
      when new connections are created. This patch corrects that to fix the
      following warning:
      
      <4>[ 1864.732366] =======================================================
      <4>[ 1864.733030] [ INFO: possible circular locking dependency detected ]
      <4>[ 1864.733544] 3.0.16-mid3-00007-gc9a0f62 #3
      <4>[ 1864.733883] -------------------------------------------------------
      <4>[ 1864.734408] t.android.btclc/4204 is trying to acquire lock:
      <4>[ 1864.734869]  (rfcomm_mutex){+.+.+.}, at: [<c14970ea>] rfcomm_dlc_close+0x15/0x30
      <4>[ 1864.735541]
      <4>[ 1864.735549] but task is already holding lock:
      <4>[ 1864.736045]  (sk_lock-AF_BLUETOOTH){+.+.+.}, at: [<c1498bf7>] lock_sock+0xa/0xc
      <4>[ 1864.736732]
      <4>[ 1864.736740] which lock already depends on the new lock.
      <4>[ 1864.736750]
      <4>[ 1864.737428]
      <4>[ 1864.737437] the existing dependency chain (in reverse order) is:
      <4>[ 1864.738016]
      <4>[ 1864.738023] -> #1 (sk_lock-AF_BLUETOOTH){+.+.+.}:
      <4>[ 1864.738549]        [<c1062273>] lock_acquire+0x104/0x140
      <4>[ 1864.738977]        [<c13d35c1>] lock_sock_nested+0x58/0x68
      <4>[ 1864.739411]        [<c1493c33>] l2cap_sock_sendmsg+0x3e/0x76
      <4>[ 1864.739858]        [<c13d06c3>] __sock_sendmsg+0x50/0x59
      <4>[ 1864.740279]        [<c13d0ea2>] sock_sendmsg+0x94/0xa8
      <4>[ 1864.740687]        [<c13d0ede>] kernel_sendmsg+0x28/0x37
      <4>[ 1864.741106]        [<c14969ca>] rfcomm_send_frame+0x30/0x38
      <4>[ 1864.741542]        [<c1496a2a>] rfcomm_send_ua+0x58/0x5a
      <4>[ 1864.741959]        [<c1498447>] rfcomm_run+0x441/0xb52
      <4>[ 1864.742365]        [<c104f095>] kthread+0x63/0x68
      <4>[ 1864.742742]        [<c14d5182>] kernel_thread_helper+0x6/0xd
      <4>[ 1864.743187]
      <4>[ 1864.743193] -> #0 (rfcomm_mutex){+.+.+.}:
      <4>[ 1864.743667]        [<c1061ada>] __lock_acquire+0x988/0xc00
      <4>[ 1864.744100]        [<c1062273>] lock_acquire+0x104/0x140
      <4>[ 1864.744519]        [<c14d2c70>] __mutex_lock_common+0x3b/0x33f
      <4>[ 1864.744975]        [<c14d303e>] mutex_lock_nested+0x2d/0x36
      <4>[ 1864.745412]        [<c14970ea>] rfcomm_dlc_close+0x15/0x30
      <4>[ 1864.745842]        [<c14990d9>] __rfcomm_sock_close+0x5f/0x6b
      <4>[ 1864.746288]        [<c1499114>] rfcomm_sock_shutdown+0x2f/0x62
      <4>[ 1864.746737]        [<c13d275d>] sys_socketcall+0x1db/0x422
      <4>[ 1864.747165]        [<c14d42f0>] syscall_call+0x7/0xb
      Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      b5a30dda
  19. 13 2月, 2012 1 次提交
    • O
      Bluetooth: silence lockdep warning · d22015aa
      Octavian Purdila 提交于
      Since bluetooth uses multiple protocols types, to avoid lockdep
      warnings, we need to use different lockdep classes (one for each
      protocol type).
      
      This is already done in bt_sock_create but it misses a couple of cases
      when new connections are created. This patch corrects that to fix the
      following warning:
      
      <4>[ 1864.732366] =======================================================
      <4>[ 1864.733030] [ INFO: possible circular locking dependency detected ]
      <4>[ 1864.733544] 3.0.16-mid3-00007-gc9a0f62 #3
      <4>[ 1864.733883] -------------------------------------------------------
      <4>[ 1864.734408] t.android.btclc/4204 is trying to acquire lock:
      <4>[ 1864.734869]  (rfcomm_mutex){+.+.+.}, at: [<c14970ea>] rfcomm_dlc_close+0x15/0x30
      <4>[ 1864.735541]
      <4>[ 1864.735549] but task is already holding lock:
      <4>[ 1864.736045]  (sk_lock-AF_BLUETOOTH){+.+.+.}, at: [<c1498bf7>] lock_sock+0xa/0xc
      <4>[ 1864.736732]
      <4>[ 1864.736740] which lock already depends on the new lock.
      <4>[ 1864.736750]
      <4>[ 1864.737428]
      <4>[ 1864.737437] the existing dependency chain (in reverse order) is:
      <4>[ 1864.738016]
      <4>[ 1864.738023] -> #1 (sk_lock-AF_BLUETOOTH){+.+.+.}:
      <4>[ 1864.738549]        [<c1062273>] lock_acquire+0x104/0x140
      <4>[ 1864.738977]        [<c13d35c1>] lock_sock_nested+0x58/0x68
      <4>[ 1864.739411]        [<c1493c33>] l2cap_sock_sendmsg+0x3e/0x76
      <4>[ 1864.739858]        [<c13d06c3>] __sock_sendmsg+0x50/0x59
      <4>[ 1864.740279]        [<c13d0ea2>] sock_sendmsg+0x94/0xa8
      <4>[ 1864.740687]        [<c13d0ede>] kernel_sendmsg+0x28/0x37
      <4>[ 1864.741106]        [<c14969ca>] rfcomm_send_frame+0x30/0x38
      <4>[ 1864.741542]        [<c1496a2a>] rfcomm_send_ua+0x58/0x5a
      <4>[ 1864.741959]        [<c1498447>] rfcomm_run+0x441/0xb52
      <4>[ 1864.742365]        [<c104f095>] kthread+0x63/0x68
      <4>[ 1864.742742]        [<c14d5182>] kernel_thread_helper+0x6/0xd
      <4>[ 1864.743187]
      <4>[ 1864.743193] -> #0 (rfcomm_mutex){+.+.+.}:
      <4>[ 1864.743667]        [<c1061ada>] __lock_acquire+0x988/0xc00
      <4>[ 1864.744100]        [<c1062273>] lock_acquire+0x104/0x140
      <4>[ 1864.744519]        [<c14d2c70>] __mutex_lock_common+0x3b/0x33f
      <4>[ 1864.744975]        [<c14d303e>] mutex_lock_nested+0x2d/0x36
      <4>[ 1864.745412]        [<c14970ea>] rfcomm_dlc_close+0x15/0x30
      <4>[ 1864.745842]        [<c14990d9>] __rfcomm_sock_close+0x5f/0x6b
      <4>[ 1864.746288]        [<c1499114>] rfcomm_sock_shutdown+0x2f/0x62
      <4>[ 1864.746737]        [<c13d275d>] sys_socketcall+0x1db/0x422
      <4>[ 1864.747165]        [<c14d42f0>] syscall_call+0x7/0xb
      Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      d22015aa
  20. 03 1月, 2012 1 次提交
  21. 23 12月, 2011 1 次提交
  22. 28 9月, 2011 1 次提交
  23. 12 8月, 2011 1 次提交
  24. 26 2月, 2011 1 次提交
  25. 18 2月, 2011 1 次提交
  26. 15 2月, 2011 1 次提交
    • G
      Bluetooth: Merge L2CAP and SCO modules into bluetooth.ko · 64274518
      Gustavo F. Padovan 提交于
      Actually doesn't make sense have these modules built separately.
      The L2CAP layer is needed by almost all Bluetooth protocols and profiles.
      There isn't any real use case without having L2CAP loaded.
      SCO is only essential for Audio transfers, but it is so small that we can
      have it loaded always in bluetooth.ko without problems.
      If you really doesn't want it you can disable SCO in the kernel config.
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      64274518
  27. 08 2月, 2011 2 次提交
    • A
      Bluetooth: fix crash by disabling tasklet in sock accept · d37f50e1
      Andrei Emeltchenko 提交于
      Crash can happen when tasklet handling connect/disconnect requests
      preempts socket accept. Can be reproduced with "l2test -r" on one
      side and several "l2test -c -b 1000 -i hci0 -P 10 <bdaddr>" on the
      other side.
      
      disable taskets in socket accept and change lock_sock and release_sock
      to bh_lock_sock and bh_unlock_sock since we have to use spinlocks and
      there is no need to mark sock as owned by user.
      
      ...
      [ 3555.897247] Unable to handle kernel NULL pointer dereference at virtual
      address 000000bc
      [ 3555.915039] pgd = cab9c000
      [ 3555.917785] [000000bc] *pgd=8bf3d031, *pte=00000000, *ppte=00000000
      [ 3555.928314] Internal error: Oops: 17 [#1] PREEMPT
      [ 3555.999786] CPU: 0    Not tainted  (2.6.32.21-13874-g67918ef #65)
      ...
      [ 3556.005981] PC is at bt_accept_unlink+0x20/0x58 [bluetooth]
      [ 3556.011627] LR is at bt_accept_dequeue+0x3c/0xe8 [bluetooth]
      ...
      [ 3556.161285] [<bf0007fc>] (bt_accept_unlink+0x20/0x58 [bluetooth]) from
      [<bf000870>] (bt_accept_dequeue+0x3c/0xe8 [bluetooth])
      [ 3556.172729] [<bf000870>] (bt_accept_dequeue+0x3c/0xe8 [bluetooth]) from
      [<bf324df8>] (l2cap_sock_accept+0x100/0x15c [l2cap])
      [ 3556.184082] [<bf324df8>] (l2cap_sock_accept+0x100/0x15c [l2cap]) from
      [<c026a0a8>] (sys_accept4+0x120/0x1e0)
      [ 3556.193969] [<c026a0a8>] (sys_accept4+0x120/0x1e0) from [<c002c9a0>]
      (ret_fast_syscall+0x0/0x2c)
      [ 3556.202819] Code: e5813000 e5901164 e580c160 e580c15c (e1d13bbc)
      ...
      Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@nokia.com>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      d37f50e1
    • A
      Bluetooth: Do not use assignments in IF conditions · 5a08ecce
      Andrei Emeltchenko 提交于
      Fix checkpatch warnings concerning assignments in if conditions.
      Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@nokia.com>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      5a08ecce
  28. 12 10月, 2010 1 次提交
    • M
      Bluetooth: Add common code for stream-oriented recvmsg() · 796c86ee
      Mat Martineau 提交于
      This commit adds a bt_sock_stream_recvmsg() function for use by any
      Bluetooth code that uses SOCK_STREAM sockets.  This code is copied
      from rfcomm_sock_recvmsg() with minimal modifications to remove
      RFCOMM-specific functionality and improve readability.
      
      L2CAP (with the SOCK_STREAM socket type) and RFCOMM have common needs
      when it comes to reading data.  Proper stream read semantics require
      that applications can read from a stream one byte at a time and not
      lose any data.  The RFCOMM code already operated on and pulled data
      from the underlying L2CAP socket, so very few changes were required to
      make the code more generic for use with non-RFCOMM data over L2CAP.
      
      Applications that need more awareness of L2CAP frame boundaries are
      still free to use SOCK_SEQPACKET sockets, and may verify that they
      connection did not fall back to basic mode by calling getsockopt().
      Signed-off-by: NMat Martineau <mathewm@codeaurora.org>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      796c86ee
  29. 07 9月, 2010 1 次提交
  30. 21 4月, 2010 1 次提交
  31. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  32. 06 11月, 2009 1 次提交