From: Andrei Emeltchenko <andrei.emeltchenko.news@gmail.com>
To: "Gustavo F. Padovan" <gustavo@padovan.org>
Cc: Ville Tervo <ville.tervo@iki.fi>,
linux-bluetooth <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCHv2 1/2] Bluetooth: Check sk is not owned before freeing l2cap_conn
Date: Tue, 29 Jun 2010 15:48:22 +0300 [thread overview]
Message-ID: <AANLkTikfe4uO54VzkyYDCPWmOO30jTtQFxFdQuoancg1@mail.gmail.com> (raw)
In-Reply-To: <20100628160751.GA5557@vigoh>
Hi Gustavo,
On Mon, Jun 28, 2010 at 7:07 PM, Gustavo F. Padovan <gustavo@padovan.org> wrote:
> Hi Andrei,
>
> * Ville Tervo <ville.tervo@iki.fi> [2010-05-28 10:14:31 +0300]:
>
>> Hi,
>>
>> On Sun, May 23, 2010 at 5:39 AM, Gustavo F. Padovan <gustavo@padovan.org> wrote:
>>
>> > Using the sock timer like you are you using looks too hackish, there are
>> > kernel struct for such defer works. I still prefer the first solution,
>> > that avoids the call to l2cap_chan_del() only.
>> > But we have to solve the problem with the sock_kill() call, I'm
>> > wondering if add a check inside l2cap_sock_kill is good idea. So we
>> > check if the socket is owned by user and if yes, we just return, however
>> > may have problem with socket refcnt doing that.
>> >
>> > Looking to the rfcomm code I found something that could be cause of the
>> > problem, there isn't any sock_hold() in the rfcomm code, maybe is it
>> > missing? Nevertheless it does the sock_put() without call sock_hold().
>> >
>> > Like you I'm trying to figure out how to fix this issue, I don't know
>> > yet how to fix it properly. I advice to take a look on the rfcomm code
>> > and check if we really are missing a sock_hold() there.
>>
>> Wouldn't backlogging of destructive operations (l2cap disc rsp and
>> req) solve these issues? All operations cannot be backlogged since
>> they cannot mapped to certain sock.
>
> I've been thinking about this issue and now I agree that backlog them is
> the better solution. We're already using backlog queue for ERTM, so you
> will have to extend it only. Check the branch for-next of my tree to see
> how I did that.
IMO The case we are talking about is different. Personally I do not
think we need to backlog
packets for removed connection. Those packets will be discarded anyway
since there will
be no connection and this operation will consume CPU just for nothing.
Regards,
Andrei
next prev parent reply other threads:[~2010-06-29 12:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-21 10:04 [PATCHv2 1/2] Bluetooth: Check sk is not owned before freeing l2cap_conn Emeltchenko Andrei
2010-05-21 10:04 ` [PATCHv2 2/2] Bluetooth: timer check sk is not owned before freeing Emeltchenko Andrei
2010-05-23 2:39 ` [PATCHv2 1/2] Bluetooth: Check sk is not owned before freeing l2cap_conn Gustavo F. Padovan
2010-05-24 12:14 ` Andrei Emeltchenko
2010-05-28 7:14 ` Ville Tervo
2010-06-28 16:07 ` Gustavo F. Padovan
2010-06-29 12:48 ` Andrei Emeltchenko [this message]
-- strict thread matches above, loose matches on Subject: below --
2010-08-12 13:25 [PATCHv2 0/2] Fix kernel crash in rfcomm/l2cap Emeltchenko Andrei
2010-08-12 13:25 ` [PATCHv2 1/2] Bluetooth: Check sk is not owned before freeing l2cap_conn Emeltchenko Andrei
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=AANLkTikfe4uO54VzkyYDCPWmOO30jTtQFxFdQuoancg1@mail.gmail.com \
--to=andrei.emeltchenko.news@gmail.com \
--cc=gustavo@padovan.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=ville.tervo@iki.fi \
/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).