Hi Dean,
On Mon, Jul 13, 2015, Dean Jenkins wrote:
> The use of the
>
> mutex_lock(&conn->chan_lock)
>
> is troublesome because the underlying conn connection can disappear whilst
> waiting for acks, that is why I eliminated the conn variable and used
> chan->state instead. Is there an atomic method to check conn and take the
> lock ?
There might be some more elegant way to solve this whole issue (maybe
with RCU helpers or something like that), but at least the following
could work, I think:
static struct l2cap_conn *lock_conn(struct l2cap_chan *chan)
{
struct l2cap_conn *conn;
l2cap_chan_lock(chan);
if (chan->conn)
conn = l2cap_conn_get(chan->conn);
else
conn = NULL;
l2cap_chan_unlock(chan);
if (conn)
mutex_lock(&conn->chan_lock);
return conn;
}
static void unlock_conn(struct l2cap_conn *conn)
{
if (conn) {
mutex_unlock(&conn->chan_lock);
l2cap_conn_put(conn);
}
}
{
...
conn = lock_conn(chan);
l2cap_chan_lock(chan);
l2cap_chan_close(chan, 0);
l2cap_chan_unlock(chan);
unlock_conn(conn);
...
}
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
