Return-Path: <cyrus@holtmann.org>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Subject: Re: shutdown(3) and bluetooth.
From: Marcel Holtmann <marcel@holtmann.org>
In-Reply-To: <20131112224819.GE9057@redhat.com>
Date: Wed, 13 Nov 2013 08:37:15 +0900
Cc: netdev@vger.kernel.org,
	"linux-bluetooth@vger.kernel.org development"
	<linux-bluetooth@vger.kernel.org>
Message-Id: <D8BE686E-E81D-48CD-8D67-2B138191E0CC@holtmann.org>
References: <20131112211125.GA2912@redhat.com> <DF4C2B40-BD87-4E88-911D-E3E5F488CAE4@holtmann.org> <20131112221038.GA6689@redhat.com> <FC5CE013-B077-4EA5-81C1-A7D8B4A5EF85@holtmann.org> <20131112224819.GE9057@redhat.com>
To: Dave Jones <davej@redhat.com>
Sender: linux-bluetooth-owner@vger.kernel.org
List-ID: <linux-bluetooth.vger.kernel.org>

Hi Dave,

>>> Here's the info I found in the logs, it looks like this was the only bluetooth socket.
>>> 
>>> fd[195] = domain:31 (PF_BLUETOOTH) type:0x5 protocol:2
>>> Setsockopt(1 d 2134000 8) on fd 195
>> 
>> this is a bit confusing. Protocol 2 is actually SCO, but the stack trace shows RFCOMM.
> 
> Sorry, mixed up two separate runs. In the log above, the stack trace is actually..
> 
> [<ffffffffa0492dca>] bt_sock_wait_state+0xda/0x240 [bluetooth]
> [<ffffffffa04c86d8>] sco_sock_release+0xb8/0xf0 [bluetooth]
> [<ffffffff815cb1ff>] sock_release+0x1f/0x90
> [<ffffffff815cb282>] sock_close+0x12/0x20
> 
> 
>>> ./trinity -P PF_BLUETOOTH -l off -c setsockopt
>>> 
>>> let it run a few seconds, and then ctrl-c.  The main process will never exit.
>>> 
>>> 5814 pts/6    Ss     0:00              |       \_ bash
>>> 5876 pts/6    S+     0:00              |       |   \_ ./trinity -P PF_BLUETOOTH -l off -c setsockopt
>>> 5877 pts/6    Z+     0:00              |       |       \_ [trinity] <defunct>
>>> 5878 pts/6    S+     0:01              |       |       \_ [trinity-main]
>>> 
>>> $ sudo cat /proc/5878/stack
>>> [<ffffffffa04397a2>] bt_sock_wait_state+0xc2/0x190 [bluetooth]
>>> [<ffffffffa0847a75>] rfcomm_sock_shutdown+0x85/0xb0 [rfcomm]
>>> [<ffffffffa0847ad9>] rfcomm_sock_release+0x39/0xb0 [rfcomm]
> 
> So it seems it affects both SCO and RFCOMM.
> 
>> What kernel did you run this against? It is a shot in the dark, but can you try linux-next quickly.
>> There was a socket related fix for the socket options where we confused RFCOMM vs L2CAP struct sock.
> 
> first noticed it on Linus' latest HEAD, and then reproduced it on 3.11.6
> I'll look at linux-next tomorrow.

I looked through the code and only call bt_sock_wait_state when SOCK_LINGER and sk_lingertime is set. In that case we actually block until the socket state changes to BT_CLOSED.

The only way I see this could happen is if you have a huge linger timeout and confused the socket state before. What is actually the list of system calls that you are throwing at this socket.

Regards

Marcel