Hi Gianluca, 2013-08-27 Gianluca Anzolin <gianluca@xxxxxxxxxxxxxx>: > When the dlc is closed, rfcomm_dev_state_change() tries to release the > port in the case it cannot get a reference to the tty. However this is > racy and not even needed. > > Infact as Peter Hurley points out: > > 1. Only consider dlcs that are 'stolen' from a connected socket, ie. > reused. Allocated dlcs cannot have been closed prior to port > activate and so for these dlcs a tty reference will always be avail > in rfcomm_dev_state_change() -- except for the conditions covered by > #2b below. > 2. If a tty was at some point previously created for this rfcomm, then > either > (a) the tty reference is still avail, so rfcomm_dev_state_change() > will perform a hangup. So nothing to do, or, > (b) the tty reference is no longer avail, and the tty_port will be > destroyed by the last tty_port_put() in rfcomm_tty_cleanup. > Again, no action required. > 3. Prior to obtaining the dlc lock in rfcomm_dev_add(), > rfcomm_dev_state_change() will not 'see' a rfcomm_dev so nothing to > do here. > 4. After releasing the dlc lock in rfcomm_dev_add(), > rfcomm_dev_state_change() will 'see' an incomplete rfcomm_dev if a > tty reference could not be obtained. Again, the best thing to do here > is nothing. Any future attempted open() will block on > rfcomm_dev_carrier_raised(). The unconnected device will exist until > released by ioctl(RFCOMMRELEASEDEV). > > The patch removes the aforementioned code and uses the > tty_port_tty_hangup() helper to hangup the tty. > > Signed-off-by: Gianluca Anzolin <gianluca@xxxxxxxxxxxxxx> > --- > net/bluetooth/rfcomm/tty.c | 35 ++--------------------------------- > 1 file changed, 2 insertions(+), 33 deletions(-) Patch has been applied to bluetooth.git. Thanks. Gustavo -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
