Double lock issue of unp_link_rwlock in usrreq.c observed
Steve Kiernan
stevek at juniper.net
Thu May 19 21:18:02 UTC 2016
On Thu, 19 May 2016 17:06:34 -0400
Raviprakash Darbha <rdarbha at juniper.net> wrote:
> Hello Andre
>
> I encountered a double lock issue in unp_connectat function. After looking at the code , I think the unp_link_rwlock is being locked once unp_connectat and once again in unp_detach (called from sofree ). Would like to get your opinion on the issue and the fix. Below is the exact call stack.
>
>
Just to clarify, this is uipc_connect() at this point...
> UNP_LINK_WLOCK(); <—————————— 1 st call
> …..
> …..
...and unp_connectat() at this point.
> if (so->so_proto->pr_flags & PR_CONNREQUIRED) {
> if (so2->so_options & SO_ACCEPTCONN
> CURVNET_SET(so2->so_vnet);
> so3 = sonewconn(so2, 0);
> // Expanding sonewconn
> {
> sonewconn
> {
> ……
> soalloc
> …….
> pru_attach
> …….
> if (!(head->so_options & SO_ACCEPTCONN) &&
> ((head->so_proto->pr_protocol != IPPROTO_SCTP) ||
> (head->so_type != SOCK_SEQPACKET))) {
> ……….
> sofree(so); /* NB: returns ACCEPT_UNLOCK'ed. */
>
> // Expanding sofree
>
> {
>
> …….
>
> pru_detach
>
> // expanding pru_detach
>
> {
>
> // Recursive wlock acquiring.
>
> UNP_LINK_WLOCK() <—————————— 2nd Call
>
> Let me know your thoughts or if you need more information. Thanks !
I suspect that this UNP_LINK_WLOCK() should become an assert.
However, I'm not clear on the implications of removing the UNP_LINK_WUNLOCK() farther down in pru_detach, then.
Considering there's potentially a taskqueue call and vn_rele, depending on what is set in the unpcb structure.
--
Steve Kiernan
Principal Engineer, Core OS/Kernel Group
Juniper Networks, Inc.
More information about the freebsd-net
mailing list