summaryrefslogtreecommitdiffstats
path: root/net/bluetooth
Commit message (Collapse)AuthorAgeFilesLines
...
| | * [Bluetooth] Update class of device value whenever possibleMarcel Holtmann2008-07-141-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The class of device value can only be retrieved via inquiry or during an incoming connection request. Outgoing connections can't ask for the class of device. To compensate for this the value is stored and copied via the inquiry cache, but currently only updated via inquiry. This update should also happen during an incoming connection request. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * [Bluetooth] Some cleanups for HCI event handlingMarcel Holtmann2008-07-141-16/+23
| | | | | | | | | | | | | | | | | | | | | Some minor cosmetic cleanups to the HCI event handling to make the code easier to read and understand. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * [Bluetooth] Make use of the default link policy settingsMarcel Holtmann2008-07-143-23/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Marcel Holtmann <marcel@holtmann.org>
| | * [Bluetooth] Track connection packet type changesMarcel Holtmann2008-07-142-15/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Marcel Holtmann <marcel@holtmann.org>
| | * [Bluetooth] Support the case when headset falls back to SCO linkMarcel Holtmann2008-07-141-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When trying to establish an eSCO link between two devices then it can happen that the remote device falls back to a SCO link. Currently this case is not handled correctly and the message dispatching will break since it is looking for eSCO packets. So in case the configured link falls back to SCO overwrite the link type with the correct value. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * [Bluetooth] Update authentication status after successful encryptionMarcel Holtmann2008-07-141-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The authentication status is not communicated to both parties. This is actually a flaw in the Bluetooth specification. Only the requesting side really knows if the authentication was successful or not. This piece of information is however needed on the other side to know if it has to trigger the authentication procedure or not. Worst case is that both sides will request authentication at different times, but this should be avoided since it costs extra time when setting up a new connection. For Bluetooth encryption it is required to authenticate the link first and the encryption status is communicated to both sides. So when a link is switched to encryption it is possible to update the authentication status since it implies an authenticated link. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * [Bluetooth] Disconnect when encryption gets disabledMarcel Holtmann2008-07-142-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Marcel Holtmann <marcel@holtmann.org>
| | * [Bluetooth] Enforce security for outgoing RFCOMM connectionsMarcel Holtmann2008-07-142-34/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Marcel Holtmann <marcel@holtmann.org>
| | * [Bluetooth] Change retrieval of L2CAP features maskMarcel Holtmann2008-07-141-48/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Getting the remote L2CAP features mask is really important, but doing this as less intrusive as possible is tricky. To play nice with older systems and Bluetooth qualification testing, the features mask is now only retrieved in two specific cases and only once per lifetime of an ACL link. When trying to establish a L2CAP connection and the remote features mask is unknown, the L2CAP information request is sent when the ACL link goes into connected state. This applies only to outgoing connections and also only for the connection oriented channels. The second case is when a connection request has been received. In this case a connection response with the result pending and the information request will be send. After receiving an information response or if the timeout gets triggered, the normal connection setup process with security setup will be initiated. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | net: remove CVS keywordsAdrian Bunk2008-06-127-22/+0Star
| |/ | | | | | | | | | | | | | | This patch removes CVS keywords that weren't updated for a long time from comments. Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* / tty: Ldisc revampAlan Cox2008-07-211-11/+2Star
|/ | | | | | | | | | | | Move the line disciplines towards a conventional ->ops arrangement. For the moment the actual 'tty_ldisc' struct in the tty is kept as part of the tty struct but this can then be changed if it turns out that when it all settles down we want to refcount ldiscs separately to the tty. Pull the ldisc code out of /proc and put it with our ldisc code. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* bluetooth: rfcomm_dev_state_change deadlock fixDave Young2008-06-031-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's logic in __rfcomm_dlc_close: rfcomm_dlc_lock(d); d->state = BT_CLOSED; d->state_changed(d, err); rfcomm_dlc_unlock(d); In rfcomm_dev_state_change, it's possible that rfcomm_dev_put try to take the dlc lock, then we will deadlock. Here fixed it by unlock dlc before rfcomm_dev_get in rfcomm_dev_state_change. why not unlock just before rfcomm_dev_put? it's because there's another problem. rfcomm_dev_get/rfcomm_dev_del will take rfcomm_dev_lock, but in rfcomm_dev_add the lock order is : rfcomm_dev_lock --> dlc lock so I unlock dlc before the taken of rfcomm_dev_lock. Actually it's a regression caused by commit 1905f6c736cb618e07eca0c96e60e3c024023428 ("bluetooth : __rfcomm_dlc_close lock fix"), the dlc state_change could be two callbacks : rfcomm_sk_state_change and rfcomm_dev_state_change. I missed the rfcomm_sk_state_change that time. Thanks Arjan van de Ven <arjan@linux.intel.com> for the effort in commit 4c8411f8c115def968820a4df6658ccfd55d7f1a ("bluetooth: fix locking bug in the rfcomm socket cleanup handling") but he missed the rfcomm_dev_state_change lock issue. Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* bluetooth: fix locking bug in the rfcomm socket cleanup handlingArjan van de Ven2008-05-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in net/bluetooth/rfcomm/sock.c, rfcomm_sk_state_change() does the following operation: if (parent && sock_flag(sk, SOCK_ZAPPED)) { /* We have to drop DLC lock here, otherwise * rfcomm_sock_destruct() will dead lock. */ rfcomm_dlc_unlock(d); rfcomm_sock_kill(sk); rfcomm_dlc_lock(d); } } which is fine, since rfcomm_sock_kill() will call sk_free() which will call rfcomm_sock_destruct() which takes the rfcomm_dlc_lock()... so far so good. HOWEVER, this assumes that the rfcomm_sk_state_change() function always gets called with the rfcomm_dlc_lock() taken. This is the case for all but one case, and in that case where we don't have the lock, we do a double unlock followed by an attempt to take the lock, which due to underflow isn't going anywhere fast. This patch fixes this by moving the stragling case inside the lock, like the other usages of the same call are doing in this code. This was found with the help of the www.kerneloops.org project, where this deadlock was observed 51 times at this point in time: http://www.kerneloops.org/search.php?search=rfcomm_sock_destruct Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* bluetooth: use get/put_unaligned_* helpersHarvey Harrison2008-05-034-11/+10Star
| | | | | | Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'master' of ↵David S. Miller2008-04-037-10/+45
|\ | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: drivers/net/s2io.c
| * bluetooth : __rfcomm_dlc_close lock fixDave Young2008-04-022-6/+1Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lockdep warning will be trigged while rfcomm connection closing. The locks taken in rfcomm_dev_add: rfcomm_dev_lock --> d->lock In __rfcomm_dlc_close: d->lock --> rfcomm_dev_lock (in rfcomm_dev_state_change) There's two way to fix it, one is in rfcomm_dev_add we first locking d->lock then the rfcomm_dev_lock The other (in this patch), remove the locking of d->lock for rfcomm_dev_state_change because just locking "d->state = BT_CLOSED;" is enough. [ 295.002046] ======================================================= [ 295.002046] [ INFO: possible circular locking dependency detected ] [ 295.002046] 2.6.25-rc7 #1 [ 295.002046] ------------------------------------------------------- [ 295.002046] krfcommd/2705 is trying to acquire lock: [ 295.002046] (rfcomm_dev_lock){-.--}, at: [<f89a090a>] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm] [ 295.002046] [ 295.002046] but task is already holding lock: [ 295.002046] (&d->lock){--..}, at: [<f899c533>] __rfcomm_dlc_close+0x43/0xd0 [rfcomm] [ 295.002046] [ 295.002046] which lock already depends on the new lock. [ 295.002046] [ 295.002046] [ 295.002046] the existing dependency chain (in reverse order) is: [ 295.002046] [ 295.002046] -> #1 (&d->lock){--..}: [ 295.002046] [<c0149b23>] check_prev_add+0xd3/0x200 [ 295.002046] [<c0149ce5>] check_prevs_add+0x95/0xe0 [ 295.002046] [<c0149f6f>] validate_chain+0x23f/0x320 [ 295.002046] [<c014b7b1>] __lock_acquire+0x1c1/0x760 [ 295.002046] [<c014c349>] lock_acquire+0x79/0xb0 [ 295.002046] [<c03d6b99>] _spin_lock+0x39/0x80 [ 295.002046] [<f89a01c0>] rfcomm_dev_add+0x240/0x360 [rfcomm] [ 295.002046] [<f89a047e>] rfcomm_create_dev+0x6e/0xe0 [rfcomm] [ 295.002046] [<f89a0823>] rfcomm_dev_ioctl+0x33/0x60 [rfcomm] [ 295.002046] [<f899facc>] rfcomm_sock_ioctl+0x2c/0x50 [rfcomm] [ 295.002046] [<c0363d38>] sock_ioctl+0x118/0x240 [ 295.002046] [<c0194196>] vfs_ioctl+0x76/0x90 [ 295.002046] [<c0194446>] do_vfs_ioctl+0x56/0x140 [ 295.002046] [<c0194569>] sys_ioctl+0x39/0x60 [ 295.002046] [<c0104faa>] syscall_call+0x7/0xb [ 295.002046] [<ffffffff>] 0xffffffff [ 295.002046] [ 295.002046] -> #0 (rfcomm_dev_lock){-.--}: [ 295.002046] [<c0149a84>] check_prev_add+0x34/0x200 [ 295.002046] [<c0149ce5>] check_prevs_add+0x95/0xe0 [ 295.002046] [<c0149f6f>] validate_chain+0x23f/0x320 [ 295.002046] [<c014b7b1>] __lock_acquire+0x1c1/0x760 [ 295.002046] [<c014c349>] lock_acquire+0x79/0xb0 [ 295.002046] [<c03d6639>] _read_lock+0x39/0x80 [ 295.002046] [<f89a090a>] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm] [ 295.002046] [<f899c548>] __rfcomm_dlc_close+0x58/0xd0 [rfcomm] [ 295.002046] [<f899d44f>] rfcomm_recv_ua+0x6f/0x120 [rfcomm] [ 295.002046] [<f899e061>] rfcomm_recv_frame+0x171/0x1e0 [rfcomm] [ 295.002046] [<f899e357>] rfcomm_run+0xe7/0x550 [rfcomm] [ 295.002046] [<c013c18c>] kthread+0x5c/0xa0 [ 295.002046] [<c0105c07>] kernel_thread_helper+0x7/0x10 [ 295.002046] [<ffffffff>] 0xffffffff [ 295.002046] [ 295.002046] other info that might help us debug this: [ 295.002046] [ 295.002046] 2 locks held by krfcommd/2705: [ 295.002046] #0: (rfcomm_mutex){--..}, at: [<f899e2eb>] rfcomm_run+0x7b/0x550 [rfcomm] [ 295.002046] #1: (&d->lock){--..}, at: [<f899c533>] __rfcomm_dlc_close+0x43/0xd0 [rfcomm] [ 295.002046] [ 295.002046] stack backtrace: [ 295.002046] Pid: 2705, comm: krfcommd Not tainted 2.6.25-rc7 #1 [ 295.002046] [<c0128a38>] ? printk+0x18/0x20 [ 295.002046] [<c014927f>] print_circular_bug_tail+0x6f/0x80 [ 295.002046] [<c0149a84>] check_prev_add+0x34/0x200 [ 295.002046] [<c0149ce5>] check_prevs_add+0x95/0xe0 [ 295.002046] [<c0149f6f>] validate_chain+0x23f/0x320 [ 295.002046] [<c014b7b1>] __lock_acquire+0x1c1/0x760 [ 295.002046] [<c014c349>] lock_acquire+0x79/0xb0 [ 295.002046] [<f89a090a>] ? rfcomm_dev_state_change+0x6a/0xd0 [rfcomm] [ 295.002046] [<c03d6639>] _read_lock+0x39/0x80 [ 295.002046] [<f89a090a>] ? rfcomm_dev_state_change+0x6a/0xd0 [rfcomm] [ 295.002046] [<f89a090a>] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm] [ 295.002046] [<f899c548>] __rfcomm_dlc_close+0x58/0xd0 [rfcomm] [ 295.002046] [<f899d44f>] rfcomm_recv_ua+0x6f/0x120 [rfcomm] [ 295.002046] [<f899e061>] rfcomm_recv_frame+0x171/0x1e0 [rfcomm] [ 295.002046] [<c014abd9>] ? trace_hardirqs_on+0xb9/0x130 [ 295.002046] [<c03d6e89>] ? _spin_unlock_irqrestore+0x39/0x70 [ 295.002046] [<f899e357>] rfcomm_run+0xe7/0x550 [rfcomm] [ 295.002046] [<c03d4559>] ? __sched_text_start+0x229/0x4c0 [ 295.002046] [<c0120000>] ? cpu_avg_load_per_task+0x20/0x30 [ 295.002046] [<f899e270>] ? rfcomm_run+0x0/0x550 [rfcomm] [ 295.002046] [<c013c18c>] kthread+0x5c/0xa0 [ 295.002046] [<c013c130>] ? kthread+0x0/0xa0 [ 295.002046] [<c0105c07>] kernel_thread_helper+0x7/0x10 [ 295.002046] ======================= Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * bluetooth : use lockdep sub-classes for diffrent bluetooth protocolDave Young2008-04-021-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'rfcomm connect' will trigger lockdep warnings which is caused by locking diffrent kinds of bluetooth sockets at the same time. So using sub-classes per AF_BLUETOOTH sub-type for lockdep. Thanks for the hints from dave jones. --- > From: Dave Jones <davej@codemonkey.org.uk> > Date: Thu, 27 Mar 2008 12:21:56 -0400 > > > Mar 27 08:10:57 localhost kernel: Pid: 3611, comm: obex-data-serve Not tainted 2.6.25-0.121.rc5.git4.fc9 #1 > > Mar 27 08:10:57 localhost kernel: [__lock_acquire+2287/3089] __lock_acquire+0x8ef/0xc11 > > Mar 27 08:10:57 localhost kernel: [sched_clock+8/11] ? sched_clock+0x8/0xb > > Mar 27 08:10:57 localhost kernel: [lock_acquire+106/144] lock_acquire+0x6a/0x90 > > Mar 27 08:10:57 localhost kernel: [<f8bd9321>] ? l2cap_sock_bind+0x29/0x108 [l2cap] > > Mar 27 08:10:57 localhost kernel: [lock_sock_nested+182/198] lock_sock_nested+0xb6/0xc6 > > Mar 27 08:10:57 localhost kernel: [<f8bd9321>] ? l2cap_sock_bind+0x29/0x108 [l2cap] > > Mar 27 08:10:57 localhost kernel: [security_socket_post_create+22/27] ? security_socket_post_create+0x16/0x1b > > Mar 27 08:10:57 localhost kernel: [__sock_create+388/472] ? __sock_create+0x184/0x1d8 > > Mar 27 08:10:57 localhost kernel: [<f8bd9321>] l2cap_sock_bind+0x29/0x108 [l2cap] > > Mar 27 08:10:57 localhost kernel: [kernel_bind+10/13] kernel_bind+0xa/0xd > > Mar 27 08:10:57 localhost kernel: [<f8dad3d7>] rfcomm_dlc_open+0xc8/0x294 [rfcomm] > > Mar 27 08:10:57 localhost kernel: [lock_sock_nested+187/198] ? lock_sock_nested+0xbb/0xc6 > > Mar 27 08:10:57 localhost kernel: [<f8dae18c>] rfcomm_sock_connect+0x8b/0xc2 [rfcomm] > > Mar 27 08:10:57 localhost kernel: [sys_connect+96/125] sys_connect+0x60/0x7d > > Mar 27 08:10:57 localhost kernel: [__lock_acquire+1370/3089] ? __lock_acquire+0x55a/0xc11 > > Mar 27 08:10:57 localhost kernel: [sys_socketcall+140/392] sys_socketcall+0x8c/0x188 > > Mar 27 08:10:57 localhost kernel: [syscall_call+7/11] syscall_call+0x7/0xb --- Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * bluetooth: replace deprecated RW_LOCK_UNLOCKED macrosRobert P. J. Day2008-03-294-4/+4
| | | | | | | | | | | | | | | | | | | | The older RW_LOCK_UNLOCKED macros defeat lockdep state tracing so replace them with the newer __RW_LOCK_UNLOCKED macros. Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* | [NET] NETNS: Omit sock->sk_net without CONFIG_NET_NS.YOSHIFUJI Hideaki2008-03-253-3/+3
|/ | | | | | | | | Introduce per-sock inlines: sock_net(), sock_net_set() and per-inet_timewait_sock inlines: twsk_net(), twsk_net_set(). Without CONFIG_NET_NS, no namespace other than &init_net exists. Let's explicitly define them to help compiler optimizations. Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
* bluetooth: make bnep_sock_cleanup() return voidTobias Klauser2008-03-062-4/+2Star
| | | | | | | | | bnep_sock_cleanup() always returns 0 and its return value isn't used anywhere in the code. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* bluetooth: Make hci_sock_cleanup() return voidTobias Klauser2008-03-061-3/+1Star
| | | | | | | | | | | hci_sock_cleanup() always returns 0 and its return value isn't used anywhere in the code. Compile-tested with 'make allyesconfig && make net/bluetooth/bluetooth.ko' Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Marcel Holtmann <marcel@holtmann.org>
* bluetooth: hci_core: defer hci_unregister_sysfs()Dave Young2008-03-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Alon Bar-Lev reports: Feb 16 23:41:33 alon1 usb 3-1: configuration #1 chosen from 1 choice Feb 16 23:41:33 alon1 BUG: unable to handle kernel NULL pointer dereference at virtual address 00000008 Feb 16 23:41:33 alon1 printing eip: c01b2db6 *pde = 00000000 Feb 16 23:41:33 alon1 Oops: 0000 [#1] PREEMPT Feb 16 23:41:33 alon1 Modules linked in: ppp_deflate zlib_deflate zlib_inflate bsd_comp ppp_async rfcomm l2cap hci_usb vmnet(P) vmmon(P) tun radeon drm autofs4 ipv6 aes_generic crypto_algapi ieee80211_crypt_ccmp nf_nat_irc nf_nat_ftp nf_conntrack_irc nf_conntrack_ftp ipt_MASQUERADE iptable_nat nf_nat ipt_REJECT xt_tcpudp ipt_LOG xt_limit xt_state nf_conntrack_ipv4 nf_conntrack iptable_filter ip_tables x_tables snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device bluetooth ppp_generic slhc ioatdma dca cfq_iosched cpufreq_powersave cpufreq_ondemand cpufreq_conservative acpi_cpufreq freq_table uinput fan af_packet nls_cp1255 nls_iso8859_1 nls_utf8 nls_base pcmcia snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm nsc_ircc snd_timer ipw2200 thinkpad_acpi irda snd ehci_hcd yenta_socket uhci_hcd psmouse ieee80211 soundcore intel_agp hwmon rsrc_nonstatic pcspkr e1000 crc_ccitt snd_page_alloc i2c_i801 ieee80211_crypt pcmcia_core agpgart thermal bat! tery nvram rtc sr_mod ac sg firmware_class button processor cdrom unix usbcore evdev ext3 jbd ext2 mbcache loop ata_piix libata sd_mod scsi_mod Feb 16 23:41:33 alon1 Feb 16 23:41:33 alon1 Pid: 4, comm: events/0 Tainted: P (2.6.24-gentoo-r2 #1) Feb 16 23:41:33 alon1 EIP: 0060:[<c01b2db6>] EFLAGS: 00010282 CPU: 0 Feb 16 23:41:33 alon1 EIP is at sysfs_get_dentry+0x26/0x80 Feb 16 23:41:33 alon1 EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: f48a2210 Feb 16 23:41:33 alon1 ESI: f72eb900 EDI: f4803ae0 EBP: f4803ae0 ESP: f7c49efc Feb 16 23:41:33 alon1 hcid[7004]: HCI dev 0 registered Feb 16 23:41:33 alon1 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 Feb 16 23:41:33 alon1 Process events/0 (pid: 4, ti=f7c48000 task=f7c3efc0 task.ti=f7c48000) Feb 16 23:41:33 alon1 Stack: f7cb6140 f4822668 f7e71e10 c01b304d ffffffff ffffffff fffffffe c030ba9c Feb 16 23:41:33 alon1 f7cb6140 f4822668 f6da6720 f7cb6140 f4822668 f6da6720 c030ba8e c01ce20b Feb 16 23:41:33 alon1 f6e9dd00 c030ba8e f6da6720 f6e9dd00 f6e9dd00 00000000 f4822600 00000000 Feb 16 23:41:33 alon1 Call Trace: Feb 16 23:41:33 alon1 [<c01b304d>] sysfs_move_dir+0x3d/0x1f0 Feb 16 23:41:33 alon1 [<c01ce20b>] kobject_move+0x9b/0x120 Feb 16 23:41:33 alon1 [<c0241711>] device_move+0x51/0x110 Feb 16 23:41:33 alon1 [<f9aaed80>] del_conn+0x0/0x70 [bluetooth] Feb 16 23:41:33 alon1 [<f9aaed99>] del_conn+0x19/0x70 [bluetooth] Feb 16 23:41:33 alon1 [<c012c1a1>] run_workqueue+0x81/0x140 Feb 16 23:41:33 alon1 [<c02c0c88>] schedule+0x168/0x2e0 Feb 16 23:41:33 alon1 [<c012fc70>] autoremove_wake_function+0x0/0x50 Feb 16 23:41:33 alon1 [<c012c9cb>] worker_thread+0x9b/0xf0 Feb 16 23:41:33 alon1 [<c012fc70>] autoremove_wake_function+0x0/0x50 Feb 16 23:41:33 alon1 [<c012c930>] worker_thread+0x0/0xf0 Feb 16 23:41:33 alon1 [<c012f962>] kthread+0x42/0x70 Feb 16 23:41:33 alon1 [<c012f920>] kthread+0x0/0x70 Feb 16 23:41:33 alon1 [<c0104c2f>] kernel_thread_helper+0x7/0x18 Feb 16 23:41:33 alon1 ======================= Feb 16 23:41:33 alon1 Code: 26 00 00 00 00 57 89 c7 a1 50 1b 3a c0 56 53 8b 70 38 85 f6 74 08 8b 0e 85 c9 74 58 ff 06 8b 56 50 39 fa 74 47 89 fb eb 02 89 c3 <8b> 43 08 39 c2 75 f7 8b 46 08 83 c0 68 e8 98 e7 10 00 8b 43 10 Feb 16 23:41:33 alon1 EIP: [<c01b2db6>] sysfs_get_dentry+0x26/0x80 SS:ESP 0068:f7c49efc Feb 16 23:41:33 alon1 ---[ end trace aae864e9592acc1d ]--- Defer hci_unregister_sysfs because hci device could be destructed while hci conn devices still there. Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Tested-by: Stefan Seyfried <seife@suse.de> Acked-by: Alon Bar-Lev <alon.barlev@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Marcel Holtmann <marcel@holtmann.org>
* [BLUETOOTH]: l2cap info_timer delete fix in hci_conn_delDave Young2008-03-031-1/+2
| | | | | | | | | | | | | When the l2cap info_timer is active the info_state will be set to L2CAP_INFO_FEAT_MASK_REQ_SENT, and it will be unset after the timer is deleted or timeout triggered. Here in l2cap_conn_del only call del_timer_sync when the info_state is set to L2CAP_INFO_FEAT_MASK_REQ_SENT. Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* bluetooth: delete timer in l2cap_conn_del()Thomas Gleixner2008-02-271-0/+2
| | | | | | | | | | Delete a possibly armed timer before kfree'ing the connection object. Solves: http://lkml.org/lkml/2008/2/15/514 Reported-by:Quel Qun <kelk1@comcast.net> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6Linus Torvalds2008-02-193-12/+18
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (60 commits) [NIU]: Bump driver version and release date. [NIU]: Fix BMAC alternate MAC address indexing. net: fix kernel-doc warnings in header files [IPV6]: Use BUG_ON instead of if + BUG in fib6_del_route. [IPV6]: dst_entry leak in ip4ip6_err. (resend) bluetooth: do not move child device other than rfcomm bluetooth: put hci dev after del conn [NET]: Elminate spurious print_mac() calls. [BLUETOOTH] hci_sysfs.c: Kill build warning. [NET]: Remove MAC_FMT net/8021q/vlan_dev.c: Use print_mac. [XFRM]: Fix ordering issue in xfrm_dst_hash_transfer(). [BLUETOOTH] net/bluetooth/hci_core.c: Use time_* macros [IPV6]: Fix hardcoded removing of old module code [NETLABEL]: Move some initialization code into __init section. [NETLABEL]: Shrink the genl-ops registration code. [AX25] ax25_out: check skb for NULL in ax25_kick() [TCP]: Fix tcp_v4_send_synack() comment [IPV4]: fix alignment of IP-Config output Documentation: fix tcp.txt ...
| * bluetooth: do not move child device other than rfcommDave Young2008-02-191-7/+6Star
| | | | | | | | | | | | | | | | hci conn child devices other than rfcomm tty should not be moved here. This is my lost, thanks for Barnaby's reporting and testing. Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * bluetooth: put hci dev after del connDave Young2008-02-192-1/+3
| | | | | | | | | | | | | | Move hci_dev_put to del_conn to avoid hci dev going away before hci conn. Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * [BLUETOOTH] hci_sysfs.c: Kill build warning.David S. Miller2008-02-181-2/+6
| | | | | | | | | | | | | | net/bluetooth/hci_sysfs.c: In function ‘del_conn’: net/bluetooth/hci_sysfs.c:339: warning: suggest parentheses around assignment used as truth value Signed-off-by: David S. Miller <davem@davemloft.net>
| * [BLUETOOTH] net/bluetooth/hci_core.c: Use time_* macrosS.Çağlar Onur2008-02-181-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values. So following patch implements usage of the time_after() macro, defined at linux/jiffies.h, which deals with wrapping correctly Signed-off-by: S.Çağlar Onur <caglar@pardus.org.tr> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* | remove final fastcall usersHarvey Harrison2008-02-141-2/+2
|/ | | | | | | | fastcall always expands to empty, remove it. Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* bluetooth rfcomm tty: destroy before tty_close()Dave Young2008-02-051-1/+2
| | | | | | | | | | rfcomm dev could be deleted in tty_hangup, so we must not call rfcomm_dev_del again to prevent from destroying rfcomm dev before tty close. Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* bluetooth: uninliningAndrew Morton2008-02-051-11/+19
| | | | | | | | | | | | Remove all those inlines which were either a) unneeded or b) increased code size. text data bss dec hex filename before: 6997 74 8 7079 1ba7 net/bluetooth/hidp/core.o after: 6492 74 8 6574 19ae net/bluetooth/hidp/core.o Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* bluetooth: hidp_process_hid_control remove unnecessary parameter dealingDave Young2008-02-051-18/+1Star
| | | | | | | | | | | | | | | | | | According to the bluetooth HID spec v1.0 chapter 7.4.2 "This code requests a major state change in a BT-HID device. A HID_CONTROL request does not generate a HANDSHAKE response." "A HID_CONTROL packet with a parameter of VIRTUAL_CABLE_UNPLUG is the only HID_CONTROL packet a device can send to a host. A host will ignore all other packets." So in the hidp_precess_hid_control function, we just need to deal with the UNLUG packet. Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* [BLUETOOTH]: Fix bugs in previous conn add/del workqueue changes.Dave Young2008-02-011-2/+6
| | | | | | | | Jens Axboe noticed that we were queueing &conn->work on both btaddconn and keventd_wq. Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* [BLUETOOTH]: Add conn add/del workqueues to avoid connection fail.Dave Young2008-02-011-11/+37
| | | | | | | | | | | | The bluetooth hci_conn sysfs add/del executed in the default workqueue. If the del_conn is executed after the new add_conn with same target, add_conn will failed with warning of "same kobject name". Here add btaddconn & btdelconn workqueues, flush the btdelconn workqueue in the add_conn function to avoid the issue. Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* [BLUETOOTH]: Use sockfd_put()Julia Lawall2008-01-293-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | The function sockfd_lookup uses fget on the value that is stored in the file field of the returned structure, so fput should ultimately be applied to this value. This can be done directly, but it seems better to use the specific macro sockfd_put, which does the same thing. The problem was fixed using the following semantic patch. (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ expression s; @@ s = sockfd_lookup(...) ... + sockfd_put(s); ?- fput(s->file); // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
* [NET]: Convert init_timer into setup_timerPavel Emelyanov2008-01-285-33/+7Star
| | | | | | | | | | | | | Many-many code in the kernel initialized the timer->function and timer->data together with calling init_timer(timer). There is already a helper for this. Use it for networking code. The patch is HUGE, but makes the code 130 lines shorter (98 insertions(+), 228 deletions(-)). Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* [BLUETOOTH]: Move children of connection device to NULL before connection down.Dave Young2008-01-232-1/+19
| | | | | | | | | | | | The rfcomm tty device will possibly retain even when conn is down, and sysfs doesn't support zombie device moving, so this patch move the tty device before conn device is destroyed. For the bug refered please see : http://lkml.org/lkml/2007/12/28/87 Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* [BLUETOOTH]: rfcomm tty BUG_ON() code fixDave Young2008-01-111-9/+13
| | | | | | | | | | | | | | | | 1) In tty.c the BUG_ON at line 115 will never be called, because the the before list_del_init in this same function. 115 BUG_ON(!list_empty(&dev->list)); So move the list_del_init to rfcomm_dev_del 2) The rfcomm_dev_del could be called from diffrent path (rfcomm_tty_hangup/rfcomm_dev_state_change/rfcomm_release_dev), So add another BUG_ON when the rfcomm_dev_del is called more than one time. Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* [BLUETOOTH]: put_device before device_del fixDave Young2007-12-302-9/+2Star
| | | | | | | | Because of workqueue delay, the put_device could be called before device_del, so move it to del_conn. Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* [NET]: Forget the zero_it argument of sk_alloc()Pavel Emelyanov2007-11-017-7/+7
| | | | | | | | | | | | | | | Finally, the zero_it argument can be completely removed from the callers and from the function prototype. Besides, fix the checkpatch.pl warnings about using the assignments inside if-s. This patch is rather big, and it is a part of the previous one. I splitted it wishing to make the patches more readable. Hope this particular split helped. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* [Bluetooth] Convert RFCOMM to use kthread APIMarcel Holtmann2007-10-221-39/+21Star
| | | | | | | | | This patch does the full kthread conversion for the RFCOMM protocol. It makes the code slightly simpler and more maintainable. Based on a patch from Christoph Hellwig <hch@lst.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Add support for handling simple eSCO linksMarcel Holtmann2007-10-224-22/+150
| | | | | | | | | | With the Bluetooth 1.2 specification the Extended SCO feature for better audio connections was introduced. So far the Bluetooth core wasn't able to handle any eSCO connections correctly. This patch adds simple eSCO support while keeping backward compatibility with older devices. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Add address and channel attribute to RFCOMM TTY deviceMarcel Holtmann2007-10-221-0/+25
| | | | | | | | Export the remote device address and channel of RFCOMM TTY device via sysfs attributes. This allows udev to create better naming rules for configured RFCOMM devices. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Fix wrong argument in debug code of HIDPDave Young2007-10-221-1/+1
| | | | | | | | In the debug code of the hidp_queue_report function, the device variable does not exist, replace it with session->hid. Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Fall back to L2CAP in basic modeMarcel Holtmann2007-10-221-8/+24
| | | | | | | In case the remote entity tries to negogiate retransmission or flow control mode, reject it and fall back to basic mode. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Advertise L2CAP features mask supportMarcel Holtmann2007-10-221-5/+18
| | | | | | | Indicate the support for the L2CAP features mask value when the remote entity tries to negotiate Bluetooth 1.2 specific features. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Retrieve L2CAP features mask on connection setupMarcel Holtmann2007-10-221-82/+151
| | | | | | | | | | The Bluetooth 1.2 specification introduced a specific features mask value to interoperate with newer versions of the specification. So far this piece of information was never needed, but future extensions will rely on it. This patch adds a generic way to retrieve this information only once per connection setup. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Remove global conf_mtu variable from L2CAPMarcel Holtmann2007-10-221-6/+6
| | | | | | | After the change to the L2CAP configuration parameter handling the global conf_mtu variable is no longer needed and so remove it. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Finish L2CAP configuration only with acceptable settingsMarcel Holtmann2007-10-221-6/+10
| | | | | | | | The parameters of the L2CAP output configuration might not be accepted after the first configuration round. So only indicate a finished output configuration when acceptable settings are provided. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-16 08:00:09 +0200