Possible UDP deadlock/panic fix - FreeBSD

This is a discussion on Possible UDP deadlock/panic fix - FreeBSD ; Attached is an MFC candidate for a patch I just merged to 8.x, which corrects the UDP lock recursion issue both of you were running into. If it settles well for a couple of days in HEAD then I'll go ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Possible UDP deadlock/panic fix

  1. Possible UDP deadlock/panic fix


    Attached is an MFC candidate for a patch I just merged to 8.x, which corrects
    the UDP lock recursion issue both of you were running into. If it settles
    well for a couple of days in HEAD then I'll go ahead and request an MFC from
    re@, but your confirmation as to whether or not this corrects the specific
    symptoms you are seeing would be very helpful. I was able to confirm that it
    eliminated what appeared to be the same problem here when I attempted to
    reproduce it based on the information you provided, so I'm hopeful.\

    Thanks,

    Robert N M Watson
    Computer Laboratory
    University of Cambridge


    Property changes on: .
    __________________________________________________ _________________
    Modified: svn:mergeinfo
    Merged /head/sys:r183265

    Index: netinet6/udp6_usrreq.c
    ================================================== =================
    --- netinet6/udp6_usrreq.c (revision 183265)
    +++ netinet6/udp6_usrreq.c (working copy)
    @@ -975,13 +975,23 @@
    error = EINVAL;
    goto out;
    }
    +
    + /*
    + * XXXRW: We release UDP-layer locks before calling
    + * udp_send() in order to avoid recursion. However,
    + * this does mean there is a short window where inp's
    + * fields are unstable. Could this lead to a
    + * potential race in which the factors causing us to
    + * select the UDPv4 output routine are invalidated?
    + */
    + INP_WUNLOCK(inp);
    + INP_INFO_WUNLOCK(&udbinfo);
    if (sin6)
    in6_sin6_2_sin_in_sock(addr);
    pru = inetsw[ip_protox[IPPROTO_UDP]].pr_usrreqs;
    - error = ((*pru->pru_send)(so, flags, m, addr, control,
    + /* addr will just be freed in sendit(). */
    + return ((*pru->pru_send)(so, flags, m, addr, control,
    td));
    - /* addr will just be freed in sendit(). */
    - goto out;
    }
    }
    #endif
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  2. Re: Possible UDP deadlock/panic fix

    Hi,

    That seems to be working. I've been up and running for 7 hours now
    with your patch.

    The machine is a bit slow but I have both WITNESS and INVARIANTS
    enabled so as to make sure everything is fine.

    Rergads,
    Mario

    Robert Watson wrote:
    >
    > Attached is an MFC candidate for a patch I just merged to 8.x, which
    > corrects the UDP lock recursion issue both of you were running into. If
    > it settles well for a couple of days in HEAD then I'll go ahead and
    > request an MFC from re@, but your confirmation as to whether or not this
    > corrects the specific symptoms you are seeing would be very helpful. I
    > was able to confirm that it eliminated what appeared to be the same
    > problem here when I attempted to reproduce it based on the information
    > you provided, so I'm hopeful.\
    >
    > Thanks,
    >
    > Robert N M Watson
    > Computer Laboratory
    > University of Cambridge
    >
    >
    > Property changes on: .
    > __________________________________________________ _________________
    > Modified: svn:mergeinfo
    > Merged /head/sys:r183265
    >
    > Index: netinet6/udp6_usrreq.c
    > ================================================== =================
    > --- netinet6/udp6_usrreq.c (revision 183265)
    > +++ netinet6/udp6_usrreq.c (working copy)
    > @@ -975,13 +975,23 @@
    > error = EINVAL;
    > goto out;
    > }
    > +
    > + /*
    > + * XXXRW: We release UDP-layer locks before calling
    > + * udp_send() in order to avoid recursion. However,
    > + * this does mean there is a short window where inp's
    > + * fields are unstable. Could this lead to a
    > + * potential race in which the factors causing us to
    > + * select the UDPv4 output routine are invalidated?
    > + */
    > + INP_WUNLOCK(inp);
    > + INP_INFO_WUNLOCK(&udbinfo);
    > if (sin6)
    > in6_sin6_2_sin_in_sock(addr);
    > pru = inetsw[ip_protox[IPPROTO_UDP]].pr_usrreqs;
    > - error = ((*pru->pru_send)(so, flags, m, addr, control,
    > + /* addr will just be freed in sendit(). */
    > + return ((*pru->pru_send)(so, flags, m, addr, control,
    > td));
    > - /* addr will just be freed in sendit(). */
    > - goto out;
    > }
    > }
    > #endif
    > _______________________________________________
    > freebsd-stable@freebsd.org mailing list
    > http://lists.freebsd.org/mailman/lis...freebsd-stable
    > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
    >


    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


+ Reply to Thread