All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Hurley <peter@hurleysoftware.com>
To: Gianluca Anzolin <gianluca@sottospazio.it>
Cc: gustavo@padovan.org, linux-bluetooth@vger.kernel.org,
	marcel@holtmann.org
Subject: Re: [PATCH 6/8] Fix the reference counting of tty_port
Date: Wed, 17 Jul 2013 10:02:31 -0400	[thread overview]
Message-ID: <51E6A3F7.20202@hurleysoftware.com> (raw)
In-Reply-To: <1373661649-1385-6-git-send-email-gianluca@sottospazio.it>

On 07/12/2013 04:40 PM, Gianluca Anzolin wrote:
> The tty_port can be released in two places: in rfcomm_tty_hangup when the flag
> RFCOMM_RELEASE_ONHUP is set and there is a HUP and in rfcomm_release_dev.
>
> There we set the flag RFCOMM_TTY_RELEASED so that no other function can get a
> reference of the tty_port.
>


> The destructor is changed to remove the device from the list

Such a simple and elegant solution -- good work.

I think these changes related to rfcomm_dev_list should be in a
separate, earlier patch though.

>
> Remove also rfcomm_dev_del which isn't used anymore.
>
> Signed-off-by: Gianluca Anzolin <gianluca@sottospazio.it>
> ---
>   net/bluetooth/rfcomm/tty.c | 56 ++++++++++++++--------------------------------
>   1 file changed, 17 insertions(+), 39 deletions(-)
>
> diff --git a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c
> index c8ef06d..0d61d65 100644
> --- a/net/bluetooth/rfcomm/tty.c
> +++ b/net/bluetooth/rfcomm/tty.c
> @@ -77,11 +77,7 @@ static void rfcomm_dev_modem_status(struct rfcomm_dlc *dlc, u8 v24_sig);
>   /* ---- Device functions ---- */
>
>   /*
> - * The reason this isn't actually a race, as you no doubt have a little voice
> - * screaming at you in your head, is that the refcount should never actually
> - * reach zero unless the device has already been taken off the list, in
> - * rfcomm_dev_del(). And if that's not true, we'll hit the BUG() in
> - * rfcomm_dev_destruct() anyway.
> + * the port destructor is called when the tty_port refcount reaches zero
>    */
>   static void rfcomm_dev_destruct(struct tty_port *port)
>   {
> @@ -90,10 +86,10 @@ static void rfcomm_dev_destruct(struct tty_port *port)
>
>   	BT_DBG("dev %p dlc %p", dev, dlc);
>
> -	/* Refcount should only hit zero when called from rfcomm_dev_del()
> -	   which will have taken us off the list. Everything else are
> -	   refcounting bugs. */
> -	BUG_ON(!list_empty(&dev->list));
> +	/* remove the dev from the list */
> +	spin_lock(&rfcomm_dev_lock);
> +	list_del_init(&dev->list);
> +	spin_unlock(&rfcomm_dev_lock);
>
>   	rfcomm_dlc_lock(dlc);
>   	/* Detach DLC if it's owned by this dev */
> @@ -394,27 +390,6 @@ free:
>   	return err;
>   }
>
> -static void rfcomm_dev_del(struct rfcomm_dev *dev)
> -{
> -	unsigned long flags;
> -	BT_DBG("dev %p", dev);
> -
> -	BUG_ON(test_and_set_bit(RFCOMM_TTY_RELEASED, &dev->flags));
> -
> -	spin_lock_irqsave(&dev->port.lock, flags);
> -	if (dev->port.count > 0) {
> -		spin_unlock_irqrestore(&dev->port.lock, flags);
> -		return;
> -	}
> -	spin_unlock_irqrestore(&dev->port.lock, flags);
> -
> -	spin_lock(&rfcomm_dev_lock);
> -	list_del_init(&dev->list);
> -	spin_unlock(&rfcomm_dev_lock);
> -
> -	tty_port_put(&dev->port);
> -}
> -
>   /* ---- Send buffer ---- */
>   static inline unsigned int rfcomm_room(struct rfcomm_dlc *dlc)
>   {
> @@ -530,8 +505,10 @@ static int rfcomm_release_dev(void __user *arg)
>   		tty_kref_put(tty);
>   	}
>
> -	if (!test_bit(RFCOMM_RELEASE_ONHUP, &dev->flags))
> -		rfcomm_dev_del(dev);
> +	/* release the TTY if not already done in hangup */
> +	if (!test_and_set_bit(RFCOMM_TTY_RELEASED, &dev->flags))
> +		tty_port_put(&dev->port);
> +
>   	tty_port_put(&dev->port);
>   	return 0;
>   }
> @@ -662,6 +639,7 @@ static void rfcomm_dev_state_change(struct rfcomm_dlc *dlc, int err)
>   {
>   	struct rfcomm_dev *dev = dlc->owner;
>   	struct tty_struct *tty;
> +
>   	if (!dev)
>   		return;
>
> @@ -687,7 +665,9 @@ static void rfcomm_dev_state_change(struct rfcomm_dlc *dlc, int err)
>   					return;
>   				}
>
> -				rfcomm_dev_del(dev);
> +				set_bit(RFCOMM_TTY_RELEASED, &dev->flags);
> +				tty_port_put(&dev->port);
> +
>   				tty_port_put(&dev->port);
>   				rfcomm_dlc_lock(dlc);
>   			}

While this is functionally correct, it ignores the larger issue in
rfcomm_dev_state_change(); namely, what prevents the rfcomm_dev from being
destructed immediately after

	struct rfcomm_dev *dev = dlc->owner;

If the answer to that question is the dlc lock, then the whole function is
_broken_.

No amount of reference counting will prevent the rfcomm_dev destructor
from completing once the dlc lock is dropped. (Presumably the dlc is not
subject to destruction once the lock is dropped. Is this true?)

This means:
1. Holding the dlc lock from the caller is pointless and should be dropped.
2. Some other solution is required to either preserve rfcomm_dev lifetime
    or determine that destruction is already in progress.


> @@ -754,9 +734,9 @@ static void rfcomm_tty_cleanup(struct tty_struct *tty)
>   {
>   	struct rfcomm_dev *dev = tty->driver_data;
>
> -        /* Remove driver data */
> -        clear_bit(RFCOMM_TTY_ATTACHED, &dev->flags);
> -        rfcomm_dlc_lock(dev->dlc);
> +	/* Remove driver data */
> +	clear_bit(RFCOMM_TTY_ATTACHED, &dev->flags);
> +	rfcomm_dlc_lock(dev->dlc);
>           tty->driver_data = NULL;
>           rfcomm_dlc_unlock(dev->dlc);
>
> @@ -1087,9 +1067,7 @@ static void rfcomm_tty_hangup(struct tty_struct *tty)
>   	tty_port_hangup(&dev->port);
>
>   	if (test_bit(RFCOMM_RELEASE_ONHUP, &dev->flags)) {
> -		if (rfcomm_dev_get(dev->id) == NULL)
> -			return;
> -		rfcomm_dev_del(dev);
> +		set_bit(RFCOMM_TTY_RELEASED, &dev->flags);
>   		tty_port_put(&dev->port);
>   	}
>   }
>

  reply	other threads:[~2013-07-17 14:02 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-12 20:40 [PATCH 1/8] Take proper tty references in net/bluetooth/rfcomm/tty.c Gianluca Anzolin
2013-07-12 20:40 ` [PATCH 2/8] Move functions before the definition of rfcomm_port_ops Gianluca Anzolin
2013-07-16 15:14   ` Peter Hurley
2013-07-12 20:40 ` [PATCH 3/8] Move device initialization and shutdown to tty_port_operations Gianluca Anzolin
2013-07-16 20:48   ` Peter Hurley
2013-07-20  7:10     ` Gianluca Anzolin
2013-07-20 14:11       ` Peter Hurley
2013-07-21  8:08         ` Gianluca Anzolin
2013-07-21 17:04           ` Peter Hurley
2013-07-21 17:31             ` Gianluca Anzolin
2013-07-12 20:40 ` [PATCH 4/8] Move tty initialization and cleanup out of open/close Gianluca Anzolin
2013-07-16 19:07   ` Peter Hurley
2013-07-12 20:40 ` [PATCH 5/8] Use the tty_port_* functions in tty_open/tty_close/tty_hangup Gianluca Anzolin
2013-07-16 20:51   ` Peter Hurley
2013-07-17  8:03     ` Gianluca Anzolin
2013-07-12 20:40 ` [PATCH 6/8] Fix the reference counting of tty_port Gianluca Anzolin
2013-07-17 14:02   ` Peter Hurley [this message]
2013-07-17 17:05     ` Gianluca Anzolin
2013-07-17 18:10       ` Peter Hurley
2013-07-18 12:45         ` Peter Hurley
2013-07-18 14:13           ` Gianluca Anzolin
2013-07-18 15:19             ` Peter Hurley
2013-07-12 20:40 ` [PATCH 7/8] Avoid a circular dependency between dev and dev->dlc Gianluca Anzolin
2013-07-12 20:40 ` [PATCH 8/8] Add module_put in rfcomm_dev_add error path Gianluca Anzolin
2013-07-17 15:20   ` Peter Hurley
2013-07-16 14:53 ` [PATCH 1/8] Take proper tty references in net/bluetooth/rfcomm/tty.c 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=51E6A3F7.20202@hurleysoftware.com \
    --to=peter@hurleysoftware.com \
    --cc=gianluca@sottospazio.it \
    --cc=gustavo@padovan.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --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 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.