From: Johan Hedberg <johan.hedberg@gmail.com>
To: JAGANATH KANAKKASSERY <jaganath.k@samsung.com>
Cc: Marcel Holtmann <marcel@holtmann.org>,
"linux-bluetooth@vger.kernel.org"
<linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH] Bluetooth: Fix missing hci_dev_lock/unlock
Date: Wed, 10 Dec 2014 14:37:52 +0200 [thread overview]
Message-ID: <20141210123752.GA30555@t440s.lan> (raw)
In-Reply-To: <935145568.61511418213470087.JavaMail.weblogic@epmlwas05a>
Hi Jaganath & Marcel,
On Wed, Dec 10, 2014, JAGANATH KANAKKASSERY wrote:
> >> err = hci_dev_do_open(hdev);
> >> if (err < 0) {
> >> + hci_dev_lock(hdev);
> >> mgmt_set_powered_failed(hdev, err);
> >> + hci_dev_unlock(hdev);
> >> return;
> >> }
>
> >I wonder is some of the mgmt_ function should just take the hci_dev
> >lock. Are there cases where we don't want them to take the look?
>
> There are many mgmt_functions called from hci_event.c which don't
> require lock. You prefer moving the lock inside
> mgmt_set_powered_failed()?
This should be kept consistent imo. Either all mgmt_* functions called
from hci_core/event.c should be responsible for taking the lock
themselves or none should be. I think right now the general rule is that
hci_core/event.c take the lock first, and this is mainly because a lot
of code that needed calling into mgmt.c was already holding the lock.
I.e. moving the taking into mgmt.c would for many places have required
awkward looking hdev_unlock(); mgmt_foo(); hdev_lock(); constructions.
Johan
next prev parent reply other threads:[~2014-12-10 12:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-10 12:11 Re: [PATCH] Bluetooth: Fix missing hci_dev_lock/unlock JAGANATH KANAKKASSERY
2014-12-10 12:37 ` Johan Hedberg [this message]
2014-12-10 12:41 ` Marcel Holtmann
-- strict thread matches above, loose matches on Subject: below --
2014-12-10 9:31 Jaganath Kanakkassery
2014-12-10 11:36 ` 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=20141210123752.GA30555@t440s.lan \
--to=johan.hedberg@gmail.com \
--cc=jaganath.k@samsung.com \
--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.