Re: Preemption Problem

[Martin Röhricht <ml@xxxxxxxxxxx>]

On Wednesday, May 31, 2006 at 13:26 +0200, Martin RÃhricht wrote:
> But thanks for your reply. Any more help is appreciated and welcome.

I may have located the trouble maker, but I am still unsure how to solve
it. My current l2cap.c and l2cap.h can be found here:
http://studwww.ira.uka.de/~s_roehr/
The original source handles a successful connection request in
l2cap_connect_rsp() by the following lines to issue a configuration
request:

case L2CAP_CR_SUCCESS:
        sk->sk_state = BT_CONFIG;
        l2cap_pi(sk)->ident = 0;
        l2cap_pi(sk)->dcid = dcid;
        l2cap_pi(sk)->conf_state |= L2CAP_CONF_REQ_SENT;

        l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_CONF_REQ,
                                l2cap_build_conf_req(sk, req), req);
        break;

I need to issue an information request first and since a hardcoded ident
of 0 doesn't work with each device, I rewrote this part as follows:

case L2CAP_CR_SUCCESS:
        sk->sk_state = BT_CONFIG;
        l2cap_pi(sk)->ident = l2cap_get_ident(conn);
        l2cap_pi(sk)->dcid = dcid;
        /* send information request first */
        l2cap_pi(sk)->conf_state |= L2CAP_INFO_REQ_SENT;
        l2cap_send_cmd(conn, l2cap_pi(sk)->ident, L2CAP_INFO_REQ,
                                l2cap_build_info_req(&info), &info);
        break;

Now I did some testing on this part. I know that one of my devices (a
mobile phone) expects Â2Â as the initial ident after the connection
establishement. In case I write
        l2cap_pi(sk)->ident = 2;
and pass this l2cap_pi(sk)->ident into the l2cap_send_cmd() function, I
get the deadlock again. But in case I don't use the above and write Â2Â
directly into l2cap_send_cmd() I don't get a deadlock anymore
(unfortunately this is hardcoded for just one device and the control
flow doesn't continue after an information response).
So there must be some locking issues that I do not get handled yet
properly. The logic seems to be fine as it works on a single processor
with a non-preemptable kernel.

RafaÅ, do you see the problem? It might have something to do with the
Âbh_unlock_sock(sk);Â that comes into play after the switch statement.

Thanks a lot for any help,
Martin


--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/