Thread (7 messages) 7 messages, 2 authors, 2012-01-21

Re: [PATCH] Bluetooth: silence lockdep warning

From: Purdila, Octavian <hidden>
Date: 2012-01-21 18:44:25

On Sat, Jan 21, 2012 at 8:29 PM, Marcel Holtmann [off-list ref] wrot=
e:
Hi Octavian,
quoted
quoted
quoted
+void bt_sock_reclassify_lock(struct sock *sk, int proto)
=A0{
- =A0 =A0 struct sock *sk =3D sock->sk;
-
=A0 =A0 =A0 if (!sk)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 return;
Why are we keeping the !sk check here if we already hand in the sk. It
is most likely checked by the caller already.
In rfcomm_sock_create (called from bt_sock_create) sock->sk can be set
to NULL so I think we should keep the check.
it has been too long since I looked at this part of the code. You need
to walk me through it why this is still true.
Hi Marcel,

In bt_sock_create we have:

        if (bt_proto[proto] && try_module_get(bt_proto[proto]->owner)) {
        	err =3D bt_proto[proto]->create(net, sock, proto, kern);
                bt_sock_reclassify_lock(sock->sk, proto);

and create can be rfcomm_sock_create where we have

        sk =3D rfcomm_sock_alloc(net, sock, protocol, GFP_ATOMIC);
        if (!sk)
                return -ENOMEM;

So after calling ->create() sock->sk can be NULL and thus we can call
bt_sock_reclassify with a NULL parameter.

Does this make sense?

Thanks,
Tavi
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help