From: "Gustavo F. Padovan" <gustavo@padovan.org>
To: Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com>
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: Mon, 28 Jun 2010 13:07:51 -0300 [thread overview]
Message-ID: <20100628160751.GA5557@vigoh> (raw)
In-Reply-To: <AANLkTilQoPjrNgqjtp7xeQF-yzrE6KNgDdagEXrIIGIv@mail.gmail.com>
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.
--
Gustavo F. Padovan
http://padovan.org
next prev parent reply other threads:[~2010-06-28 16:07 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 [this message]
2010-06-29 12:48 ` Andrei Emeltchenko
-- 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=20100628160751.GA5557@vigoh \
--to=gustavo@padovan.org \
--cc=Andrei.Emeltchenko.news@gmail.com \
--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).