04 Jun, 2008
1 commit
-
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 lockso 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 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
Acked-by: Marcel Holtmann
Signed-off-by: David S. Miller
29 May, 2008
1 commit
-
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_destructSigned-off-by: Arjan van de Ven
Acked-by: Marcel Holtmann
Signed-off-by: David S. Miller
03 May, 2008
1 commit
-
Signed-off-by: Harvey Harrison
Acked-by: Marcel Holtmann
Signed-off-by: David S. Miller
03 Apr, 2008
1 commit
-
Conflicts:
drivers/net/s2io.c
02 Apr, 2008
2 commits
-
Lockdep warning will be trigged while rfcomm connection closing.
The locks taken in rfcomm_dev_add:
rfcomm_dev_lock --> d->lockIn __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_lockThe 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: [] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm]
[ 295.002046]
[ 295.002046] but task is already holding lock:
[ 295.002046] (&d->lock){--..}, at: [] __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] [] check_prev_add+0xd3/0x200
[ 295.002046] [] check_prevs_add+0x95/0xe0
[ 295.002046] [] validate_chain+0x23f/0x320
[ 295.002046] [] __lock_acquire+0x1c1/0x760
[ 295.002046] [] lock_acquire+0x79/0xb0
[ 295.002046] [] _spin_lock+0x39/0x80
[ 295.002046] [] rfcomm_dev_add+0x240/0x360 [rfcomm]
[ 295.002046] [] rfcomm_create_dev+0x6e/0xe0 [rfcomm]
[ 295.002046] [] rfcomm_dev_ioctl+0x33/0x60 [rfcomm]
[ 295.002046] [] rfcomm_sock_ioctl+0x2c/0x50 [rfcomm]
[ 295.002046] [] sock_ioctl+0x118/0x240
[ 295.002046] [] vfs_ioctl+0x76/0x90
[ 295.002046] [] do_vfs_ioctl+0x56/0x140
[ 295.002046] [] sys_ioctl+0x39/0x60
[ 295.002046] [] syscall_call+0x7/0xb
[ 295.002046] [] 0xffffffff
[ 295.002046]
[ 295.002046] -> #0 (rfcomm_dev_lock){-.--}:
[ 295.002046] [] check_prev_add+0x34/0x200
[ 295.002046] [] check_prevs_add+0x95/0xe0
[ 295.002046] [] validate_chain+0x23f/0x320
[ 295.002046] [] __lock_acquire+0x1c1/0x760
[ 295.002046] [] lock_acquire+0x79/0xb0
[ 295.002046] [] _read_lock+0x39/0x80
[ 295.002046] [] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm]
[ 295.002046] [] __rfcomm_dlc_close+0x58/0xd0 [rfcomm]
[ 295.002046] [] rfcomm_recv_ua+0x6f/0x120 [rfcomm]
[ 295.002046] [] rfcomm_recv_frame+0x171/0x1e0 [rfcomm]
[ 295.002046] [] rfcomm_run+0xe7/0x550 [rfcomm]
[ 295.002046] [] kthread+0x5c/0xa0
[ 295.002046] [] kernel_thread_helper+0x7/0x10
[ 295.002046] [] 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: [] rfcomm_run+0x7b/0x550 [rfcomm]
[ 295.002046] #1: (&d->lock){--..}, at: [] __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] [] ? printk+0x18/0x20
[ 295.002046] [] print_circular_bug_tail+0x6f/0x80
[ 295.002046] [] check_prev_add+0x34/0x200
[ 295.002046] [] check_prevs_add+0x95/0xe0
[ 295.002046] [] validate_chain+0x23f/0x320
[ 295.002046] [] __lock_acquire+0x1c1/0x760
[ 295.002046] [] lock_acquire+0x79/0xb0
[ 295.002046] [] ? rfcomm_dev_state_change+0x6a/0xd0 [rfcomm]
[ 295.002046] [] _read_lock+0x39/0x80
[ 295.002046] [] ? rfcomm_dev_state_change+0x6a/0xd0 [rfcomm]
[ 295.002046] [] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm]
[ 295.002046] [] __rfcomm_dlc_close+0x58/0xd0 [rfcomm]
[ 295.002046] [] rfcomm_recv_ua+0x6f/0x120 [rfcomm]
[ 295.002046] [] rfcomm_recv_frame+0x171/0x1e0 [rfcomm]
[ 295.002046] [] ? trace_hardirqs_on+0xb9/0x130
[ 295.002046] [] ? _spin_unlock_irqrestore+0x39/0x70
[ 295.002046] [] rfcomm_run+0xe7/0x550 [rfcomm]
[ 295.002046] [] ? __sched_text_start+0x229/0x4c0
[ 295.002046] [] ? cpu_avg_load_per_task+0x20/0x30
[ 295.002046] [] ? rfcomm_run+0x0/0x550 [rfcomm]
[ 295.002046] [] kthread+0x5c/0xa0
[ 295.002046] [] ? kthread+0x0/0xa0
[ 295.002046] [] kernel_thread_helper+0x7/0x10
[ 295.002046] =======================Signed-off-by: Dave Young
Signed-off-by: David S. Miller -
'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
> 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: [] ? 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: [] ? 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: [] 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: [] 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: [] 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
Signed-off-by: David S. Miller
29 Mar, 2008
1 commit
-
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
Acked-by: Marcel Holtmann
Signed-off-by: Andrew Morton
Signed-off-by: David S. Miller
26 Mar, 2008
1 commit
-
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
06 Mar, 2008
3 commits
-
bnep_sock_cleanup() always returns 0 and its return value isn't used
anywhere in the code.Signed-off-by: Tobias Klauser
Signed-off-by: Andrew Morton
Signed-off-by: David S. Miller -
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
Signed-off-by: Andrew Morton
Acked-by: Marcel Holtmann -
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:[] 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 [] sysfs_move_dir+0x3d/0x1f0
Feb 16 23:41:33 alon1 [] kobject_move+0x9b/0x120
Feb 16 23:41:33 alon1 [] device_move+0x51/0x110
Feb 16 23:41:33 alon1 [] del_conn+0x0/0x70 [bluetooth]
Feb 16 23:41:33 alon1 [] del_conn+0x19/0x70 [bluetooth]
Feb 16 23:41:33 alon1 [] run_workqueue+0x81/0x140
Feb 16 23:41:33 alon1 [] schedule+0x168/0x2e0
Feb 16 23:41:33 alon1 [] autoremove_wake_function+0x0/0x50
Feb 16 23:41:33 alon1 [] worker_thread+0x9b/0xf0
Feb 16 23:41:33 alon1 [] autoremove_wake_function+0x0/0x50
Feb 16 23:41:33 alon1 [] worker_thread+0x0/0xf0
Feb 16 23:41:33 alon1 [] kthread+0x42/0x70
Feb 16 23:41:33 alon1 [] kthread+0x0/0x70
Feb 16 23:41:33 alon1 [] 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 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: [] 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
Tested-by: Stefan Seyfried
Acked-by: Alon Bar-Lev
Signed-off-by: Andrew Morton
Acked-by: Marcel Holtmann
04 Mar, 2008
1 commit
-
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
Acked-by: Marcel Holtmann
Signed-off-by: David S. Miller
27 Feb, 2008
1 commit
-
Delete a possibly armed timer before kfree'ing the connection object.
Solves: http://lkml.org/lkml/2008/2/15/514
Reported-by:Quel Qun
Signed-off-by: Thomas Gleixner
Signed-off-by: David S. Miller
19 Feb, 2008
3 commits
-
* 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
... -
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
Signed-off-by: David S. Miller -
Move hci_dev_put to del_conn to avoid hci dev going away before hci conn.
Signed-off-by: Dave Young
Signed-off-by: David S. Miller
18 Feb, 2008
2 commits
-
net/bluetooth/hci_sysfs.c: In function ‘del_conn’:
net/bluetooth/hci_sysfs.c:339: warning: suggest parentheses around assignment used as truth valueSigned-off-by: David S. Miller
-
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 correctlySigned-off-by: S.Çağlar Onur
Acked-by: Marcel Holtmann
Signed-off-by: David S. Miller
14 Feb, 2008
1 commit
-
fastcall always expands to empty, remove it.
Signed-off-by: Harvey Harrison
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
05 Feb, 2008
3 commits
-
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
Signed-off-by: Andrew Morton
Signed-off-by: David S. Miller -
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.oSigned-off-by: Andrew Morton
Signed-off-by: David S. Miller -
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
Signed-off-by: Andrew Morton
Signed-off-by: David S. Miller
01 Feb, 2008
2 commits
-
Jens Axboe noticed that we were queueing &conn->work on both btaddconn
and keventd_wq.Signed-off-by: Dave Young
Signed-off-by: David S. Miller -
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
Signed-off-by: David S. Miller
29 Jan, 2008
2 commits
-
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/)//
@@
expression s;
@@s = sockfd_lookup(...)
...
+ sockfd_put(s);
?- fput(s->file);
//Signed-off-by: Julia Lawall
Signed-off-by: David S. Miller -
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
Acked-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller
23 Jan, 2008
1 commit
-
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/87Signed-off-by: Dave Young
Signed-off-by: David S. Miller
11 Jan, 2008
1 commit
-
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_del2) 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
Signed-off-by: David S. Miller
30 Dec, 2007
1 commit
-
Because of workqueue delay, the put_device could be called before
device_del, so move it to del_conn.Signed-off-by: Dave Young
Signed-off-by: David S. Miller
01 Nov, 2007
1 commit
-
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
Signed-off-by: David S. Miller
22 Oct, 2007
10 commits
-
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
Signed-off-by: Marcel Holtmann
-
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
-
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
-
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
Signed-off-by: Marcel Holtmann -
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
-
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
-
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
-
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
-
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
-
The Bluetooth HCI commands are divided into logical OGF groups for
easier identification of their purposes. While this still makes sense
for the written specification, its makes the code only more complex
and harder to read. So instead of using separate OGF and OCF values
to identify the commands, use a common 16-bit opcode that combines
both values. As a side effect this also reduces the complexity of
OGF and OCF calculations during command header parsing.Signed-off-by: Marcel Holtmann
