bluetooth: rfcomm_init bug fix
Subsystems (4)
PATCH 1/1 bluetooth: rfcomm_init bug fix
rfcomm tty may be used before rfcomm_tty_driver initilized, The problem is that now socket layer init before tty layer, if userspace program do socket callback right here then oops will happen.
reporting in:
http://marc.info/?l=linux-bluetooth&m=124404919324542&w=2
make 3 changes:
1. remove #ifdef in rfcomm/core.c,
make it blank function when rfcomm tty not selected in rfcomm.h
2. tune the rfcomm_init error patch to ensure
tty driver initilized before rfcomm socket usage.
3. remove __exit for rfcomm_cleanup_sockets because above change need call it in a __init function.
--
include/net/bluetooth/rfcomm.h | 12 +++++++++++- net/bluetooth/rfcomm/core.c | 29 ++++++++++++++++++++--------- net/bluetooth/rfcomm/sock.c | 2 +- 3 files changed, 32 insertions(+), 11 deletions(-)
include/net/bluetooth/rfcomm.h +11 -1
@@ -355,7 +355,17 @@ struct rfcomm_dev_list_req { };int rfcomm_dev_ioctl (struct sock *sk,unsigned int cmd,void __user *arg); + +#ifdef CONFIG_BT_RFCOMM_TTY int rfcomm_init_ttys (void );void rfcomm_cleanup_ttys (void ); - +#else +static inline int rfcomm_init_ttys (void ) +{ +return 0 ; +} +static inline void rfcomm_cleanup_ttys (void ) +{ +} +#endif #endif /* __RFCOMM_H */
net/bluetooth/rfcomm/core.c +20 -9
@@ -2080,28 +2080,41 @@ static CLASS_ATTR(rfcomm_dlc, S_IRUGO, r/* ---- Initialization ---- */ static int __init rfcomm_init (void ) { +int ret; +l2cap_load ();hci_register_cb (&rfcomm_cb); rfcomm_thread =kthread_run (rfcomm_run,NULL ,"krfcommd" );if (IS_ERR (rfcomm_thread)) { -hci_unregister_cb (&rfcomm_cb); -return PTR_ERR (rfcomm_thread); + ret =PTR_ERR (rfcomm_thread); + goto out_thread; }if (class_create_file (bt_class, &class_attr_rfcomm_dlc) <0 )BT_ERR ("Failed to create RFCOMM info file" ); -rfcomm_init_sockets (); - -#ifdef CONFIG_BT_RFCOMM_TTY -rfcomm_init_ttys (); -#endif + ret =rfcomm_init_ttys (); +if (ret) + goto out_tty; + + ret =rfcomm_init_sockets (); +if (ret) + goto out_sock;BT_INFO ("RFCOMM ver %s" ,VERSION );return 0 ; + +out_sock: +rfcomm_cleanup_ttys (); +out_tty: +kthread_stop (rfcomm_thread); +out_thread: +hci_unregister_cb (&rfcomm_cb); + +return ret; } static void __exit rfcomm_exit(void)
@@ -2112,9 +2125,7 @@ static void __exit rfcomm_exit(void)kthread_stop (rfcomm_thread); -#ifdef CONFIG_BT_RFCOMM_TTY rfcomm_cleanup_ttys (); -#endif rfcomm_cleanup_sockets (); }
net/bluetooth/rfcomm/sock.c +1 -1
@@ -1132,7 +1132,7 @@ error:return err; } -void __exit rfcomm_cleanup_sockets(void) +void rfcomm_cleanup_sockets (void ) {class_remove_file (bt_class, &class_attr_rfcomm);
From: Dave Young <[email protected]>
Date: Mon, 3 Aug 2009 22:26:16 +0800
Quoted 6 lines
rfcomm tty may be used before
rfcomm_tty_driverinitilized, The problem is that now socket layer init before tty layer, if userspace program do socket callback right here then oops will happen.reporting in:
http://marc.info/?l=linux-bluetooth&m=124404919324542&w=2
...
Quoted 3 lines
Reported-by Oliver Hartkopp <[email protected]>Tested-by Oliver Hartkopp <[email protected]>Signed-off-by Dave Young <[email protected]>
Applied, thanks.
Marcel Holtmann
maintainerHi Dave,
Quoted 4 lines
Quoted 4 lines
rfcomm tty may be used before
rfcomm_tty_driverinitilized, The problem is that now socket layer init before tty layer, if userspace program do socket callback right here then oops will happen.
Quoted 8 lines
Quoted 2 lines
reporting in:
http://marc.info/?l=linux-bluetooth&m=124404919324542&w=2...
Quoted 3 lines
Reported-by Oliver Hartkopp <[email protected]>Tested-by Oliver Hartkopp <[email protected]>Signed-off-by Dave Young <[email protected]>Applied, thanks.
do you mind at least waiting for an ACK from my side. I haven't even looked at the final patch.
Regards
Marcel
David Miller
maintainerFrom: Marcel Holtmann <[email protected]>
Date: Mon, 03 Aug 2009 16:54:26 -0700
Quoted 2 lines
do you mind at least waiting for an ACK from my side. I haven't even looked at the final patch.
Sure, I haven't pushed it out yet, so now's your chance :)
David Miller
maintainerFrom: David Miller <[email protected]>
Date: Mon, 03 Aug 2009 19:19:16 -0700 (PDT)
Quoted 7 lines
From: Marcel Holtmann <[email protected]>
Date: Mon, 03 Aug 2009 16:54:26 -0700Quoted 2 lines
do you mind at least waiting for an ACK from my side. I haven't even looked at the final patch.
Sure, I haven't pushed it out yet, so now's your chance :)
Grumble, I accidently pushed my net-2.6 queue out before you had a chance to reply, sorry :-(
Marcel Holtmann
maintainerHi Dave,
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
do you mind at least waiting for an ACK from my side. I haven't even looked at the final patch.
Sure, I haven't pushed it out yet, so now's your chance :)
Grumble, I accidently pushed my net-2.6 queue out before you had a chance to reply, sorry :-(
not a big deal. Just have to send a cleanup patch. The patch itself is fine, but from a style perspective it is different than everything else in the Bluetooth subsystem and I would have liked to fix that before pushing it. I wait with that for 2.6.32 since it is not important.
The other Dave, please send patches to linux-bluetooth only and lets follow the normal path to get them merged into Linus' tree. Skipping bluetooth-2.6 is not an option. You have to use the same process than everybody else.
Regards
Marcel
Quoted 7 lines · Marcel Holtmann
Hi Dave,
Quoted 5 lines
Quoted 4 lines
Quoted 2 lines
do you mind at least waiting for an ACK from my side. I haven't even looked at the final patch.
Sure, I haven't pushed it out yet, so now's your chance :)
Quoted 7 lines
Quoted 2 lines
Grumble, I accidently pushed my net-2.6 queue out before you had a chance to reply, sorry :-(
not a big deal. Just have to send a cleanup patch. The patch itself is fine, but from a style perspective it is different than everything else in the Bluetooth subsystem and I would have liked to fix that before pushing it. I wait with that for 2.6.32 since it is not important.
Marcel, could you publish the bluetooth subsystem coding style somewhere? People including me are confused about it. I remembered I asked it from you, but it is still not very clear for me.
Quoted 5 lines
The other Dave, please send patches to linux-bluetooth only and lets follow the normal path to get them merged into Linus' tree. Skipping bluetooth-2.6 is not an option. You have to use the same process than everybody else.
Why linux-bluetooth only? IMHO there could be more people to comment and review if I send patches to both lkml and subsystem mailing list.
Quoted 7 lines
Regards
Marcel
Signature · 2 lines
Regards dave
Marcel Holtmann
maintainerHi Dave,
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
do you mind at least waiting for an ACK from my side. I haven't even looked at the final patch.
Sure, I haven't pushed it out yet, so now's your chance :)
Grumble, I accidently pushed my net-2.6 queue out before you had a chance to reply, sorry :-(
Quoted 8 lines
Quoted 4 lines
not a big deal. Just have to send a cleanup patch. The patch itself is fine, but from a style perspective it is different than everything else in the Bluetooth subsystem and I would have liked to fix that before pushing it. I wait with that for 2.6.32 since it is not important.
Marcel, could you publish the bluetooth subsystem coding style somewhere? People including me are confused about it. I remembered I asked it from you, but it is still not very clear for me.
it is kernel coding style like everything else, but some variable naming should be consistent. And that is nothing that is published, that is something that has been done since Max wrote it. Check the rest of the code.
Quoted 7 lines
Quoted 4 lines
The other Dave, please send patches to linux-bluetooth only and lets follow the normal path to get them merged into Linus' tree. Skipping bluetooth-2.6 is not an option. You have to use the same process than everybody else.
Why linux-bluetooth only? IMHO there could be more people to comment and review if I send patches to both lkml and subsystem mailing list.
Lets me make this perfectly clear here. Bluetooth patches are sent to the linux-bluetooth mailing list. There is no need to send them to netdev and/or LKML at the same time. Stop this cross-posting. They don't get more review there anyway. I take care of sending them for net-2.6 inclusion if I feel that they are appropriate.
Regards
Marcel
David Miller
maintainerFrom: Marcel Holtmann <[email protected]>
Date: Wed, 05 Aug 2009 08:35:55 -0700
Quoted 5 lines
Lets me make this perfectly clear here. Bluetooth patches are sent to the linux-bluetooth mailing list. There is no need to send them to netdev and/or LKML at the same time. Stop this cross-posting. They don't get more review there anyway. I take care of sending them for net-2.6 inclusion if I feel that they are appropriate.
Some of that isn't true, I was reading over his patches as he posted them. So cross-posting to netdev is absolutely not a waste of time IMHO.
Marcel Holtmann
maintainerHi Dave,
Quoted 9 lines
Quoted 5 lines
Lets me make this perfectly clear here. Bluetooth patches are sent to the linux-bluetooth mailing list. There is no need to send them to netdev and/or LKML at the same time. Stop this cross-posting. They don't get more review there anyway. I take care of sending them for net-2.6 inclusion if I feel that they are appropriate.
Some of that isn't true, I was reading over his patches as he posted them. So cross-posting to netdev is absolutely not a waste of time IMHO.
this is great and netdev might make sense from time to time, but for sure posting them to LKML is just noise. To be honest, if you wanna read Bluetooth patches before they are acked by me, you could subscribe to linux-bluetooth.
Regards
Marcel