__cancel_delayed_work() is being used in some paths where we cannot
sleep waiting for the delayed work to finish. However, that function
might return while the timer is running and the work will be queued
again. Replace the calls with safer cancel_delayed_work() version
which spins until the timer handler finishes on other CPUs and
cancels the delayed work.
Signed-off-by: Ulisses Furquim <[email protected]>
---
include/net/bluetooth/l2cap.h | 4 ++--
net/bluetooth/l2cap_core.c | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index e7a8cc7..42fdbb8 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -614,7 +614,7 @@ static inline void l2cap_set_timer(struct l2cap_chan *chan,
{
BT_DBG("chan %p state %d timeout %ld", chan, chan->state, timeout);
- if (!__cancel_delayed_work(work))
+ if (!cancel_delayed_work(work))
l2cap_chan_hold(chan);
schedule_delayed_work(work, timeout);
}
@@ -624,7 +624,7 @@ static inline bool l2cap_clear_timer(struct l2cap_chan *chan,
{
bool ret;
- ret = __cancel_delayed_work(work);
+ ret = cancel_delayed_work(work);
if (ret)
l2cap_chan_put(chan);
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 942ba1d..ae7fb27 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -2588,7 +2588,7 @@ static inline int l2cap_command_rej(struct l2cap_conn *conn, struct l2cap_cmd_hd
if ((conn->info_state & L2CAP_INFO_FEAT_MASK_REQ_SENT) &&
cmd->ident == conn->info_ident) {
- __cancel_delayed_work(&conn->info_timer);
+ cancel_delayed_work(&conn->info_timer);
conn->info_state |= L2CAP_INFO_FEAT_MASK_REQ_DONE;
conn->info_ident = 0;
@@ -3135,7 +3135,7 @@ static inline int l2cap_information_rsp(struct l2cap_conn *conn, struct l2cap_cm
conn->info_state & L2CAP_INFO_FEAT_MASK_REQ_DONE)
return 0;
- __cancel_delayed_work(&conn->info_timer);
+ cancel_delayed_work(&conn->info_timer);
if (result != L2CAP_IR_SUCCESS) {
conn->info_state |= L2CAP_INFO_FEAT_MASK_REQ_DONE;
@@ -4509,7 +4509,7 @@ int l2cap_security_cfm(struct hci_conn *hcon, u8 status, u8 encrypt)
if (hcon->type == LE_LINK) {
smp_distribute_keys(conn, 0);
- __cancel_delayed_work(&conn->security_timer);
+ cancel_delayed_work(&conn->security_timer);
}
rcu_read_lock();
--
1.7.8.rc4
Hi Ulisses,
On Mon, Jan 30, 2012, Ulisses Furquim wrote:
> __cancel_delayed_work() is being used in some paths where we cannot
> sleep waiting for the delayed work to finish. However, that function
> might return while the timer is running and the work will be queued
> again. Replace the calls with safer cancel_delayed_work() version
> which spins until the timer handler finishes on other CPUs and
> cancels the delayed work.
>
> Signed-off-by: Ulisses Furquim <[email protected]>
> ---
> include/net/bluetooth/l2cap.h | 4 ++--
> net/bluetooth/l2cap_core.c | 6 +++---
> 2 files changed, 5 insertions(+), 5 deletions(-)
Both patches have bee applied to my bluetooth-next tree. Thanks.
Johan
Hi Marcel,
On Mon, Jan 30, 2012 at 7:29 PM, Marcel Holtmann <[email protected]> wrot=
e:
> Hi Ulisses,
>
>> __cancel_delayed_work() is being used in some paths where we cannot
>> sleep waiting for the delayed work to finish. However, that function
>> might return while the timer is running and the work will be queued
>> again. Replace the calls with safer cancel_delayed_work() version
>> which spins until the timer handler finishes on other CPUs and
>> cancels the delayed work.
>>
>> Signed-off-by: Ulisses Furquim <[email protected]>
>> ---
>
> I have the feeling that I already looked at this patch before. And given
> that it is v4, that might be true actually ;)
>
> Use the space between --- and diffstat to have some small changelog so I
> know what was different to the previous version.
Yes, you already seen this but I removed part of the patch to fix
another problem. Sorry, forgot to include a message so you could know
what has changed.
>> =A0include/net/bluetooth/l2cap.h | =A0 =A04 ++--
>> =A0net/bluetooth/l2cap_core.c =A0 =A0| =A0 =A06 +++---
>> =A02 files changed, 5 insertions(+), 5 deletions(-)
>
> Acked-by: Marcel Holtmann <[email protected]>
>
> Regards
>
> Marcel
Regards,
--=20
Ulisses Furquim
ProFUSION embedded systems
http://profusion.mobi
Mobile: +55 19 9250 0942
Skype: ulissesffs
Hi Ulisses,
> We need to use the _sync() version for cancelling the info and security
> timer in the L2CAP connection delete path. Otherwise the delayed work
> handler might run after the connection object is freed.
>
> Signed-off-by: Ulisses Furquim <[email protected]>
> ---
> net/bluetooth/l2cap_core.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
Acked-by: Marcel Holtmann <[email protected]>
Regards
Marcel
Hi Ulisses,
> __cancel_delayed_work() is being used in some paths where we cannot
> sleep waiting for the delayed work to finish. However, that function
> might return while the timer is running and the work will be queued
> again. Replace the calls with safer cancel_delayed_work() version
> which spins until the timer handler finishes on other CPUs and
> cancels the delayed work.
>
> Signed-off-by: Ulisses Furquim <[email protected]>
> ---
I have the feeling that I already looked at this patch before. And given
that it is v4, that might be true actually ;)
Use the space between --- and diffstat to have some small changelog so I
know what was different to the previous version.
> include/net/bluetooth/l2cap.h | 4 ++--
> net/bluetooth/l2cap_core.c | 6 +++---
> 2 files changed, 5 insertions(+), 5 deletions(-)
Acked-by: Marcel Holtmann <[email protected]>
Regards
Marcel
We need to use the _sync() version for cancelling the info and security
timer in the L2CAP connection delete path. Otherwise the delayed work
handler might run after the connection object is freed.
Signed-off-by: Ulisses Furquim <[email protected]>
---
net/bluetooth/l2cap_core.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index ae7fb27..09cd860 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -1016,10 +1016,10 @@ static void l2cap_conn_del(struct hci_conn *hcon, int err)
hci_chan_del(conn->hchan);
if (conn->info_state & L2CAP_INFO_FEAT_MASK_REQ_SENT)
- __cancel_delayed_work(&conn->info_timer);
+ cancel_delayed_work_sync(&conn->info_timer);
if (test_and_clear_bit(HCI_CONN_LE_SMP_PEND, &hcon->flags)) {
- __cancel_delayed_work(&conn->security_timer);
+ cancel_delayed_work_sync(&conn->security_timer);
smp_chan_destroy(conn);
}
--
1.7.8.rc4
Hi Andrei,
On Thu, Mar 1, 2012 at 6:10 AM, Andrei Emeltchenko
<[email protected]> wrote:
> Hi All,
>
> On Mon, Jan 30, 2012 at 06:26:28PM -0200, Ulisses Furquim wrote:
>> __cancel_delayed_work() is being used in some paths where we cannot
>> sleep waiting for the delayed work to finish. However, that function
>> might return while the timer is running and the work will be queued
>> again. Replace the calls with safer cancel_delayed_work() version
>> which spins until the timer handler finishes on other CPUs and
>> cancels the delayed work.
>>
>> Signed-off-by: Ulisses Furquim <[email protected]>
Well, these comments are not really related to this specific patch.
This change was just a replace of functions to cancel delayed work.
> I have some questions about delayed_work usage:
>
> When setting timer with l2cap_set_timer() we hold_chan if work may be
> running. So if previous work is cancelled OK we do not hold chan.
>
> Didn't we miss hold_chan here?
>
> Then in l2cap_clear_chan we put_chan if work cancelled OK, otherwise
> put_chan is done in delayed_work so we always put_chan.
>
> I am actually seeing some crashes in rare cases related to delayed work.
Do you have a log or something? Have you added the debug info to check
hold/put usage? It'd be good to really understand the problem and fix
it. It might be we're trying to be overly smart here and left some
races. This code is very similar (if not equal) to the one we had
before with timers.
Regards,
--
Ulisses Furquim
ProFUSION embedded systems
http://profusion.mobi
Mobile: +55 19 9250 0942
Skype: ulissesffs
Hi,
> > __cancel_delayed_work() is being used in some paths where we cannot
> > sleep waiting for the delayed work to finish. However, that function
> > might return while the timer is running and the work will be queued
> > again. Replace the calls with safer cancel_delayed_work() version
> > which spins until the timer handler finishes on other CPUs and
> > cancels the delayed work.
> >
> > Signed-off-by: Ulisses Furquim <[email protected]>
> > ---
> > include/net/bluetooth/l2cap.h | 4 ++--
> > net/bluetooth/l2cap_core.c | 6 +++---
> > 2 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> > index e7a8cc7..42fdbb8 100644
> > --- a/include/net/bluetooth/l2cap.h
> > +++ b/include/net/bluetooth/l2cap.h
> > @@ -614,7 +614,7 @@ static inline void l2cap_set_timer(struct l2cap_chan *chan,
> > {
> > BT_DBG("chan %p state %d timeout %ld", chan, chan->state, timeout);
> >
> > - if (!__cancel_delayed_work(work))
> > + if (!cancel_delayed_work(work))
> > l2cap_chan_hold(chan);
> > schedule_delayed_work(work, timeout);
> > }
> > @@ -624,7 +624,7 @@ static inline bool l2cap_clear_timer(struct l2cap_chan *chan,
> > {
> > bool ret;
> >
> > - ret = __cancel_delayed_work(work);
> > + ret = cancel_delayed_work(work);
> > if (ret)
> > l2cap_chan_put(chan);
> >
>
>
> I have some questions about delayed_work usage:
>
> When setting timer with l2cap_set_timer() we hold_chan if work may be
> running. So if previous work is cancelled OK we do not hold chan.
>
> Didn't we miss hold_chan here?
>
> Then in l2cap_clear_chan we put_chan if work cancelled OK, otherwise
> put_chan is done in delayed_work so we always put_chan.
What about following change:
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index a357336..d61e158 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -628,17 +628,6 @@ static inline void l2cap_chan_unlock(struct
l2cap_chan *chan)
mutex_unlock(&chan->lock);
}
-static inline void l2cap_set_timer(struct l2cap_chan *chan,
- struct delayed_work *work, long
timeout)
-{
- BT_DBG("chan %p state %s timeout %ld", chan,
- state_to_string(chan->state),
timeout);
-
- if (!cancel_delayed_work(work))
- l2cap_chan_hold(chan);
- schedule_delayed_work(work, timeout);
-}
-
static inline bool l2cap_clear_timer(struct l2cap_chan *chan,
struct delayed_work *work)
{
@@ -651,6 +640,18 @@ static inline bool l2cap_clear_timer(struct
l2cap_chan *chan,
return ret;
}
+static inline void l2cap_set_timer(struct l2cap_chan *chan,
+ struct delayed_work *work, long
timeout)
+{
+ BT_DBG("chan %p state %s timeout %ld", chan,
+ state_to_string(chan->state),
timeout);
+
+ l2cap_clear_timer(chan, work);
+
+ l2cap_chan_hold(chan);
+ schedule_delayed_work(work, timeout);
+}
+
#define __set_chan_timer(c, t) l2cap_set_timer(c, &c->chan_timer, (t))
#define __clear_chan_timer(c) l2cap_clear_timer(c, &c->chan_timer)
#define __set_retrans_timer(c) l2cap_set_timer(c, &c->retrans_timer, \
Best regards
Andrei Emeltchenko
Hi All,
On Mon, Jan 30, 2012 at 06:26:28PM -0200, Ulisses Furquim wrote:
> __cancel_delayed_work() is being used in some paths where we cannot
> sleep waiting for the delayed work to finish. However, that function
> might return while the timer is running and the work will be queued
> again. Replace the calls with safer cancel_delayed_work() version
> which spins until the timer handler finishes on other CPUs and
> cancels the delayed work.
>
> Signed-off-by: Ulisses Furquim <[email protected]>
> ---
> include/net/bluetooth/l2cap.h | 4 ++--
> net/bluetooth/l2cap_core.c | 6 +++---
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> index e7a8cc7..42fdbb8 100644
> --- a/include/net/bluetooth/l2cap.h
> +++ b/include/net/bluetooth/l2cap.h
> @@ -614,7 +614,7 @@ static inline void l2cap_set_timer(struct l2cap_chan *chan,
> {
> BT_DBG("chan %p state %d timeout %ld", chan, chan->state, timeout);
>
> - if (!__cancel_delayed_work(work))
> + if (!cancel_delayed_work(work))
> l2cap_chan_hold(chan);
> schedule_delayed_work(work, timeout);
> }
> @@ -624,7 +624,7 @@ static inline bool l2cap_clear_timer(struct l2cap_chan *chan,
> {
> bool ret;
>
> - ret = __cancel_delayed_work(work);
> + ret = cancel_delayed_work(work);
> if (ret)
> l2cap_chan_put(chan);
>
I have some questions about delayed_work usage:
When setting timer with l2cap_set_timer() we hold_chan if work may be
running. So if previous work is cancelled OK we do not hold chan.
Didn't we miss hold_chan here?
Then in l2cap_clear_chan we put_chan if work cancelled OK, otherwise
put_chan is done in delayed_work so we always put_chan.
I am actually seeing some crashes in rare cases related to delayed work.
Best regards
Andrei Emeltchenko