linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ulisses Furquim <ulisses@profusion.mobi>
To: Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com>,
	Ulisses Furquim <ulisses@profusion.mobi>,
	linux-bluetooth@vger.kernel.org
Subject: Re: [RFCv0 1/5] Bluetooth: Use locks in RCU updater code
Date: Tue, 31 Jan 2012 10:37:38 -0200	[thread overview]
Message-ID: <CAA37ikZ2zio7D6_r1==b7YKr3Rv9RXw1BBuKTgOqDcW3iSOxiQ@mail.gmail.com> (raw)
In-Reply-To: <20120131075928.GA15048@aemeltch-MOBL1>

Hi Andrei,

On Tue, Jan 31, 2012 at 5:59 AM, Emeltchenko Andrei
<Andrei.Emeltchenko.news@gmail.com> wrote:
> On Mon, Jan 30, 2012 at 03:17:15PM -0200, Ulisses Furquim wrote:

<snip>

>> I was under the impression you'd remove RCU for conn->chan_l
>> completely. You're adding a lock only in the updaters? If so, please
>> take a look at commit 3d57dc680 which shows all changes from mutex to
>> RCU. I don't think just adding a lock/unlock in l2cap_conn_start and
>> l2cap_conn_del will be enough. l2cap_chan_add seems to be called from
>> other contexts and it does a list_add_rcu(). Have you thought of that?
>
> I am adding lock to updaters and to the places we need to sleep and
> rcu_read_lock cannot be used. This patch adds locks to updaters and
> following patches cover other places. Maybe I need to split them better.

It needs to be split better, yes. And if you're adding a mutex also in
some readers of the list instead of using RCU I believe it'd be better
to just use a mutex and remove RCU usage altogether. That will be
possibly just a revert of 3d57dc6806, but you need to check that.

Regards,

-- 
Ulisses Furquim
ProFUSION embedded systems
http://profusion.mobi
Mobile: +55 19 9250 0942
Skype: ulissesffs

  reply	other threads:[~2012-01-31 12:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-30 15:09 [RFCv0 0/5] Bluetooth: Change socket lock to l2cap_chan lock Emeltchenko Andrei
2012-01-30 15:09 ` [RFCv0 1/5] Bluetooth: Use locks in RCU updater code Emeltchenko Andrei
2012-01-30 17:17   ` Ulisses Furquim
2012-01-31  7:59     ` Emeltchenko Andrei
2012-01-31 12:37       ` Ulisses Furquim [this message]
2012-01-31 12:58         ` Emeltchenko Andrei
2012-01-30 15:09 ` [RFCv0 2/5] Bluetooth: Add l2cap_chan_lock Emeltchenko Andrei
2012-01-30 17:18   ` Ulisses Furquim
2012-01-30 15:09 ` [RFCv0 3/5] Bluetooth: Helper functions for locking change Emeltchenko Andrei
2012-01-30 17:25   ` Ulisses Furquim
2012-01-30 15:09 ` [RFCv0 4/5] Bluetooth: Remove unneeded sk variable Emeltchenko Andrei
2012-01-30 17:26   ` Ulisses Furquim
2012-01-30 15:09 ` [RFCv0 5/5] Bluetooth: Change sk lock to l2cap_chan lock Emeltchenko Andrei
2012-01-30 17:46   ` Ulisses Furquim
2012-01-31  8:11     ` 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='CAA37ikZ2zio7D6_r1==b7YKr3Rv9RXw1BBuKTgOqDcW3iSOxiQ@mail.gmail.com' \
    --to=ulisses@profusion.mobi \
    --cc=Andrei.Emeltchenko.news@gmail.com \
    --cc=linux-bluetooth@vger.kernel.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 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).