Re: Preemption Problem

[Martin Röhricht <ml@xxxxxxxxxxx>]

On Thursday, June 08, 2006 at 22:15 +0200, Martin RÃhricht wrote:
> So I assume I don't get any information out of the register values,
> right? But what seems to be quite interesting is the message about the
> spin_lock -- so I will investigate further on any calls to spin_locks.
> 
> If anybody knows how to solve this issue, feel free to post any
> suggestions.

WOW, I think I fixed it!!!
The preamble: For handling an incoming information response I had major
problems to find the corresponding socket (that I used earlier to
initiate the request) because the fields in an information request in
Bluetooth's L2CAP layer do not provide appropriate information that may
help to retrieve the socket. Finally I found out (some weeks ago) that I
can get the socket by using one of the existing functions:
	sk = l2cap_get_chan_by_ident(&conn->chan_list, cmd->ident)
This code worked on a single processor with a non-preemptible kernel as
expected.

Today I found out that this socket gets locked by using this function
call ("if (s) bh_lock_sock(s);"):

static inline struct sock *l2cap_get_chan_by_ident(struct
l2cap_chan_list *l, u8 ident)
{
        struct sock *s;
        read_lock(&l->lock);
        s = __l2cap_get_chan_by_ident(l, ident);
        if (s) bh_lock_sock(s);
        read_unlock(&l->lock);
        return s;
}

And this tiny little line of code caused my kernel to deadlock as I had
to unlock the socket. So I inserted a call
	bh_unlock_sock(sk);
at the end of l2cap_information_rsp() and it seems to work and makes
sense to me ;-)

Ufff, that was a nice lesson ...

Martin


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