Re: [Bluez-devel] [PATCH]bluetooth rfcomm_dev refcount bug fix

Re: [Bluez-devel] [PATCH]bluetooth rfcomm_dev refcount bug fix

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

Hi Dave,

> In the rfcomm_tty_hangup the rfcomm_dev refcnt should be dropped later.
> 
> If rfcomm_dev is destructed in tty_hangup function, then the later tty_close function will oops.

your patch removes the complete release on hangup logic. That can't be
right. I think the problem is with calling tty_vhangup() and then
decrementing the reference count. In case we call tty_vhangup and we
have release on hangup we should not delete the device here. What about
the attached patch? Does it solve it?

What are the steps to reproduce this?

Regards

Marcel


[-- Attachment #2: patch --]
[-- Type: text/x-patch, Size: 449 bytes --]

diff --git a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c
index e447651..b405b9a 100644
--- a/net/bluetooth/rfcomm/tty.c
+++ b/net/bluetooth/rfcomm/tty.c
@@ -425,8 +425,11 @@ static int rfcomm_release_dev(void __user *arg)
 	if (dev->tty)
 		tty_vhangup(dev->tty);
 
-	rfcomm_dev_del(dev);
-	rfcomm_dev_put(dev);
+	if (!test_bit(RFCOMM_RELEASE_ONHUP, &dev->flags)) {
+		rfcomm_dev_del(dev);
+		rfcomm_dev_put(dev);
+	}
+
 	return 0;
 }
 

[-- Attachment #3: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] [PATCH]bluetooth rfcomm_dev refcount bug fix

[Marcel Holtmann]

Hi Dave,

> I'm afraid to be considered as spam ;)
> 
> (Due to timezone offset, I have to mail again and cann't wait for your
> reply, sorry for the annoying)

I am in a different timezone every other week. So nevermind ;)

> I think the rfcomm_dev_put could be seperated from the rfcomm_dev_put,
> it will be more straitforward then.
> 
> please consider below patch, tested on my side. thanks.

That one looks totally wrong to me. Without even testing it, it will
have side effects that you haven't run into yet. Unless the TTY core
changed so much, this comments are there for a really good reason and
the code is tested a lot.

Also if you have to do two rfcomm_dev_put() in a row, then we are doing
something really wrong and this tries to hide a real bug somewhere.

Regards

Marcel



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel