From: Mat Martineau <mathewm@codeaurora.org>
To: Andrei Emeltchenko <andrei.emeltchenko.news@gmail.com>
Cc: linux-bluetooth@vger.kernel.org, gustavo@padovan.org,
marcel@holtmann.org, pkrystad@codeaurora.org
Subject: Re: [RFC 6/8] Bluetooth: Lock the L2CAP channel when sending
Date: Thu, 26 Apr 2012 16:48:42 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.02.1204261647490.13179@mathewm-linux> (raw)
In-Reply-To: <20120426082214.GC2659@aemeltch-MOBL1>
Andrei -
On Thu, 26 Apr 2012, Andrei Emeltchenko wrote:
> Hi Mat,
>
> On Wed, Apr 25, 2012 at 04:36:17PM -0700, Mat Martineau wrote:
>> The ERTM and streaming mode transmit queue must only be accessed while
>> the L2CAP channel lock is held. Adding this lock ensures that
>> multiple threads cannot simultaneously manipulate the queue when
>> sending and receiving concurrently.
>
> I think the lock shall be added in l2cap_sock_sendmsg like:
>
> lock()
> err = l2cap_chan_send(chan, msg, len, sk->sk_priority);
> unlock()
>
> I actually use this l2cap_chan_send in A2MP code already because it gets
> locked in l2cap_data_channel.
>
You're right.
There's still a problem where the lock needs to be released when
bt_skb_send_alloc is called, because that function can block. What do
you think about releasing and reacquiring the channel lock in
l2cap_sock_alloc_skb_cb() instead?
>
>>
>> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
>> ---
>> net/bluetooth/l2cap_core.c | 40 ++++++++++++++++++++++++++++++----------
>> 1 file changed, 30 insertions(+), 10 deletions(-)
>>
>> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
>> index 6aefeaa..8ed6a74 100644
>> --- a/net/bluetooth/l2cap_core.c
>> +++ b/net/bluetooth/l2cap_core.c
>> @@ -2035,26 +2035,35 @@ int l2cap_chan_send(struct l2cap_chan *chan, struct msghdr *msg, size_t len,
>> u32 control;
>> int err;
>>
>> + l2cap_chan_hold(chan);
>> +
>> /* Connectionless channel */
>> if (chan->chan_type == L2CAP_CHAN_CONN_LESS) {
>> skb = l2cap_create_connless_pdu(chan, msg, len, priority);
>> - if (IS_ERR(skb))
>> - return PTR_ERR(skb);
>> + if (IS_ERR(skb)) {
>> + err = PTR_ERR(skb);
>> + goto done;
>> + }
>>
>> l2cap_do_send(chan, skb);
>> - return len;
>> + err = len;
>> + goto done;
>> }
>>
>> switch (chan->mode) {
>> case L2CAP_MODE_BASIC:
>> /* Check outgoing MTU */
>> - if (len > chan->omtu)
>> - return -EMSGSIZE;
>> + if (len > chan->omtu) {
>> + err = -EMSGSIZE;
>> + break;
>> + }
>>
>> /* Create a basic PDU */
>> skb = l2cap_create_basic_pdu(chan, msg, len, priority);
>> - if (IS_ERR(skb))
>> - return PTR_ERR(skb);
>> + if (IS_ERR(skb)) {
>> + err = PTR_ERR(skb);
>> + break;
>> + }
>>
>> l2cap_do_send(chan, skb);
>> err = len;
>> @@ -2067,30 +2076,38 @@ int l2cap_chan_send(struct l2cap_chan *chan, struct msghdr *msg, size_t len,
>> control = __set_ctrl_sar(chan, L2CAP_SAR_UNSEGMENTED);
>> skb = l2cap_create_iframe_pdu(chan, msg, len, control,
>> 0);
>> - if (IS_ERR(skb))
>> - return PTR_ERR(skb);
>> + if (IS_ERR(skb)) {
>> + err = PTR_ERR(skb);
>> + break;
>> + }
>>
>> + l2cap_chan_lock(chan);
>> __skb_queue_tail(&chan->tx_q, skb);
>>
>> if (chan->tx_send_head == NULL)
>> chan->tx_send_head = skb;
>>
>> + l2cap_chan_unlock(chan);
>> } else {
>> /* Segment SDU into multiples PDUs */
>> err = l2cap_sar_segment_sdu(chan, msg, len);
>> if (err < 0)
>> - return err;
>> + break;
>> }
>>
>> if (chan->mode == L2CAP_MODE_STREAMING) {
>> + l2cap_chan_lock(chan);
>> l2cap_streaming_send(chan);
>> + l2cap_chan_unlock(chan);
>> err = len;
>> break;
>> }
>>
>> + l2cap_chan_lock(chan);
>> if (test_bit(CONN_REMOTE_BUSY, &chan->conn_state) &&
>> test_bit(CONN_WAIT_F, &chan->conn_state)) {
>> err = len;
>> + l2cap_chan_unlock(chan);
>> break;
>> }
>>
>> @@ -2098,6 +2115,7 @@ int l2cap_chan_send(struct l2cap_chan *chan, struct msghdr *msg, size_t len,
>> if (err >= 0)
>> err = len;
>>
>> + l2cap_chan_unlock(chan);
>> break;
>>
>> default:
>> @@ -2105,6 +2123,8 @@ int l2cap_chan_send(struct l2cap_chan *chan, struct msghdr *msg, size_t len,
>> err = -EBADFD;
>> }
>>
>> +done:
>> + l2cap_chan_put(chan);
>> return err;
>> }
>>
>> --
>> 1.7.10
--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
next prev parent reply other threads:[~2012-04-26 23:48 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-25 23:36 [RFC 0/8] ERTM state machine changes, part 2 Mat Martineau
2012-04-25 23:36 ` [RFC 1/8] Bluetooth: Improve ERTM sequence number offset calculation Mat Martineau
2012-04-26 6:39 ` Marcel Holtmann
2012-04-26 7:10 ` Andrei Emeltchenko
2012-04-26 23:35 ` Mat Martineau
2012-04-27 2:19 ` Gustavo Padovan
2012-04-25 23:36 ` [RFC 2/8] Bluetooth: Initialize new l2cap_chan structure members Mat Martineau
2012-04-26 6:38 ` Marcel Holtmann
2012-04-26 22:03 ` Mat Martineau
2012-04-25 23:36 ` [RFC 3/8] Bluetooth: Remove duplicate structure members from bt_skb_cb Mat Martineau
2012-04-26 6:39 ` Marcel Holtmann
2012-04-27 3:22 ` Gustavo Padovan
2012-04-25 23:36 ` [RFC 4/8] Bluetooth: Move recently-added ERTM header packing functions Mat Martineau
2012-04-26 6:40 ` Marcel Holtmann
2012-04-27 3:26 ` Gustavo Padovan
2012-04-25 23:36 ` [RFC 5/8] Bluetooth: Move recently-added ERTM header unpacking functions Mat Martineau
2012-04-26 6:40 ` Marcel Holtmann
2012-04-27 3:26 ` Gustavo Padovan
2012-04-25 23:36 ` [RFC 6/8] Bluetooth: Lock the L2CAP channel when sending Mat Martineau
2012-04-26 6:41 ` Marcel Holtmann
2012-04-26 8:22 ` Andrei Emeltchenko
2012-04-26 23:48 ` Mat Martineau [this message]
2012-04-27 13:40 ` [RFCv0] Bluetooth: Change locking logic in sock send Andrei Emeltchenko
2012-04-25 23:36 ` [RFC 7/8] Bluetooth: Refactor L2CAP ERTM and streaming transmit segmentation Mat Martineau
2012-04-26 6:43 ` Marcel Holtmann
2012-04-25 23:36 ` [RFC 8/8] Bluetooth: Add Code Aurora Forum copyright Mat Martineau
2012-04-26 6:44 ` Marcel Holtmann
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=alpine.DEB.2.02.1204261647490.13179@mathewm-linux \
--to=mathewm@codeaurora.org \
--cc=andrei.emeltchenko.news@gmail.com \
--cc=gustavo@padovan.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=marcel@holtmann.org \
--cc=pkrystad@codeaurora.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