Re: Oops involving RFCOMM and sysfs

Cornelia Huck <[email protected]>
Newsgroups gmane.linux.bluez.devel
Organization IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Herbert Kircher Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
Message-ID <20080117124259.19a88129__23838.171552825$1200602910$gmane$org@gondolin.boeblingen.de.ibm.com>
On Thu, 17 Jan 2008 16:15:04 +0800,
Dave Young <[email protected]> wrote:

> On Thu, Jan 17, 2008 at 03:24:50PM +0800, Dave Young wrote:
> > On Jan 17, 2008 7:06 AM, Gabor Gombas <[email protected]> wrote:
> > > Hi,
> > >
> > > On Wed, Jan 16, 2008 at 09:02:05AM +0800, Dave Young wrote:
> > >
> > > > 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.
> > > >
> > > > Signed-off-by: Dave Young <[email protected]>
> > >
> > > This seems to work, both the oops and the hang are gone. I get these
> > > messages in syslog when the Bluetooth link hangs and I want to kill pppd
> > > with "poff":
> > >
> > > Jan 16 23:55:59 twister kernel: unregister_netdevice: waiting for ppp0 to become free. Usage count = 1
> > > Jan 16 23:56:09 twister kernel: unregister_netdevice: waiting for ppp0 to become free. Usage count = 1

Might be helpful to try with CONFIG_DEBUG_DRIVER=y and
CONFIG_KOBJECT_DEBUG=y to spot where a reference is not dropped.

> > >
> > > But a "killall -9 pppd" seems to help and then the re-connect (after the
> > > phone got power-cycled) works.
> > 
> > Weird, I guess "device_move(dev, NULL) two times" cause the problem.
> > 
> > Anyway, device_move should check the old_parent and new_parent , if
> > they equal to each other then just return.

sysfs_move_dir() does this (to avoid a loop later in the function).
Don't know if that's a good thing to check at a higher level as well,
because the calling code should really know where their devices are.

Anyway, if this "move in place" exposes a refcounting bug, we must fix
it.

> > 
> > Am I right?
> 
> Could you apply this patch as well to test? Thanks.
> 
> diff -upr linux/net/bluetooth/rfcomm/tty.c linux.new/net/bluetooth/rfcomm/tty.c
> --- linux/net/bluetooth/rfcomm/tty.c	2008-01-17 16:09:34.000000000 +0800
> +++ linux.new/net/bluetooth/rfcomm/tty.c	2008-01-17 16:10:22.000000000 +0800
> @@ -692,7 +692,8 @@ static void rfcomm_tty_close(struct tty_
>  	BT_DBG("tty %p dev %p dlc %p opened %d", tty, dev, dev->dlc, dev->opened);
> 
>  	if (--dev->opened == 0) {
> -		device_move(dev->tty_dev, NULL);
> +		if (dev->tty_dev->parent)
> +			device_move(dev->tty_dev, NULL);
> 
>  		/* Close DLC and dettach TTY */
>  		rfcomm_dlc_close(dev->dlc, 0);
> 

Avoiding to move devices when there is nothing to be moved nevertheless
sounds like a good idea :)

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.