All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Holler <holler@ahsoftware.de>
To: Gianluca Anzolin <gianluca@sottospazio.it>
Cc: linux-bluetooth@vger.kernel.org, linux-serial@vger.kernel.org,
	peter@hurleysoftware.com
Subject: Re: [RFC] PATCH: rfcomm tty refcount fixes
Date: Fri, 12 Jul 2013 17:20:20 +0200	[thread overview]
Message-ID: <51E01EB4.3090406@ahsoftware.de> (raw)
In-Reply-To: <20130706084343.GA10500@debian.seek.priv>

Am 06.07.2013 10:43, schrieb Gianluca Anzolin:
> Hi,
> 
> I'm getting panics and OOPS with the vanilla kernel 3.10 using rfcomm with a
> bluetooth module connected to a microcontroller: this occurs when I poweroff
> the microcontroller without closing first the rfcomm device.
> 
> Searching the web I found that I'm not alone with this issue:
> 
> http://marc.info/?l=linux-bluetooth&m=136868678418771&w=2
> 
> In the thread the issue seems to be a refcounting problem.
> 
> Indeed looking at the source there are places where dev->port.tty is accessed
> directly without taking references of the tty_struct.
> 
> So I inspected every dev->port.tty access and changed the code to use
> tty_port_tty_get which gets the references properly.
> 
> In other places I used directly the tty_port_* helpers already in place.
> 
> I the process I changed also the tty_port_hangup helper because it seems to me
> that it could leak references in some cases (I sent another email for that).
> 
> I attach the patch against net/bluetooth/rfcomm/tty.c and
> drivers/tty/tty_port.c
> 
> With this patch I cannot reproduce the oopses I was getting before: I was able
> to trigger the panics very easily and now I cannot trigger them anymore.

The patches with BUG_ON or WARN_ON don't work with 3.10 anymore and do
make things worse, at least here. They are fine for 3.7-3.9, but not
with 3.10.

> 
> I cannot tell however if the problem is really fixed so I'm here request for
> comments from people who know this code better than me.

I've just had the chance to test a 3.10(.0) kernel with your two patches
applied, they doesn't seem to help. The machine I've used to test just
stood still after the first or second disconnect. Unfortunatley I can't
provide any debug output, the machine I've just used doesn't have a
serial and without debugging such stuff is a pain.

> To them I'd like also to have a look at rfcomm_tty_close: in some situations
> tty_port_put could be called two times: is that right?

That doesn't sound sane.

Regards,

Alexander Holler

  reply	other threads:[~2013-07-12 15:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-06  8:43 [RFC] PATCH: rfcomm tty refcount fixes Gianluca Anzolin
2013-07-12 15:20 ` Alexander Holler [this message]
2013-07-12 15:37   ` Peter Hurley
2013-07-12 15:37     ` Peter Hurley

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=51E01EB4.3090406@ahsoftware.de \
    --to=holler@ahsoftware.de \
    --cc=gianluca@sottospazio.it \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=peter@hurleysoftware.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.