linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dean Jenkins <Dean_Jenkins@mentor.com>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
	Marcel Holtmann <marcel@holtmann.org>
Cc: BlueZ development <linux-bluetooth@vger.kernel.org>,
	"Gustavo F. Padovan" <gustavo@padovan.org>,
	Johan Hedberg <johan.hedberg@gmail.com>,
	<Joshua_Frkuska@mentor.com>,
	"Craske, Mark" <Mark_Craske@mentor.com>
Subject: Re: [PATCH v1 0/7] Avoid L2CAP ERTM shutdown hung tasks
Date: Wed, 7 Oct 2015 15:43:44 +0100	[thread overview]
Message-ID: <56152FA0.50808@mentor.com> (raw)
In-Reply-To: <CABBYNZ+YvTZMwg7O8TAJ10GZda-DnP1QJYudSesc1W1ENVNCQw@mail.gmail.com>

Hi Luiz,

On 07/10/15 15:09, Luiz Augusto von Dentz wrote:
> Hi Dean,
>
> On Sat, Jun 6, 2015 at 7:13 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
>> Hi Dean,
>>
>>> Details of the issue are described in the thread
>>> [RFC] Bluetooth ERTM L2CAP deadlocks (hung tasks) due to l2cap_sock_shutdown()
>>> and kernel.org Bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=99301
> Are you still working on this? I can still lock bluetoothd on close,
> btw it seems you are not aware of the following:
>
>         SO_LINGER
>                When enabled, a close(2) or shutdown(2) will not return
> until all queued messages for the socket have been successfully sent
> or the linger timeout  has  been  reached.   Otherwise,  the  call
> returns immediately and the closing is done in the background.
>
> So according to the text above we should never call __l2cap_wait_ack
> on l2cap_sock_shutdown since it should return immediately, only when
> SO_LINGER is used it is allowed to block. Also there doesn't seems to
> be anything prevent us to send a L2CAP Disconnect request while there
> are unacked packets, at least I could find anything on the core about
> waiting for unacked nor the test spec has any test for it.
>
Thanks for the information about SO_LINGER time. So it sounds like 
further changes to the logic of the code are needed.

Yes, we are still working on this issue. We have devised a fix for our 
commercial ARM kernel 3.14. and so far we have no reported failures.

In our fix, we had to ensure "L2CAP Disconnect request" took precedence 
over shutdown.

Note that ACKS are only used for L2CAP ERTM and so only some BT services 
risk getting hung such as audio media browsing over BT.

We are currently preparing a patchset for bluetooth-next of our 2nd 
attempt at resolving the locking issue.

Thanks,

Regards,
Dean

-- 
Dean Jenkins
Embedded Software Engineer
Linux Transportation Solutions
Mentor Embedded Software Division
Mentor Graphics (UK) Ltd.

  reply	other threads:[~2015-10-07 14:43 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-05 23:11 [PATCH v1 0/7] Avoid L2CAP ERTM shutdown hung tasks Dean Jenkins
2015-06-05 23:11 ` [PATCH v1 1/7] Bluetooth: L2CAP ERTM shutdown protect sk and chan Dean Jenkins
2015-06-05 23:11 ` [PATCH v1 2/7] Bluetooth: Make __l2cap_wait_ack more efficient Dean Jenkins
2015-06-05 23:11 ` [PATCH v1 3/7] Bluetooth: Unwind l2cap_sock_shutdown() Dean Jenkins
2015-06-09  9:55   ` Szymon Janc
2015-06-09 10:13     ` Dean Jenkins
2015-06-05 23:11 ` [PATCH v1 4/7] Bluetooth: l2cap_sock_shutdown() remove mutex_lock calls Dean Jenkins
2015-06-05 23:11 ` [PATCH v1 5/7] Bluetooth: l2cap_sock_shutdown() reduce scope of chan locking Dean Jenkins
2015-06-05 23:11 ` [PATCH v1 6/7] Bluetooth: Add BT_DBG to l2cap_sock_shutdown() Dean Jenkins
2015-06-05 23:11 ` [PATCH v1 7/7] Bluetooth: __l2cap_wait_ack() limit max waiting time Dean Jenkins
2015-06-06  4:21   ` Marcel Holtmann
2015-06-10 10:31     ` Dean Jenkins
2015-06-10 11:18       ` Marcel Holtmann
2015-06-06  4:13 ` [PATCH v1 0/7] Avoid L2CAP ERTM shutdown hung tasks Marcel Holtmann
2015-10-07 14:09   ` Luiz Augusto von Dentz
2015-10-07 14:43     ` Dean Jenkins [this message]
2015-10-08  8:59       ` Luiz Augusto von Dentz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56152FA0.50808@mentor.com \
    --to=dean_jenkins@mentor.com \
    --cc=Joshua_Frkuska@mentor.com \
    --cc=Mark_Craske@mentor.com \
    --cc=gustavo@padovan.org \
    --cc=johan.hedberg@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).