Change Details

- The SCTP_PCB_FLAGS_SND_ITERATOR_UP check was racy, since two threads could observe that the flag is not set and then both set it. I'm not sure if this is actually a problem in practice, i.e., maybe there's no problem having multiple sends for a single PCB in the iterator list? - sctp_sendall() was modifying sctp_flags without the inp lock held. The change simply acquires the PCB write lock before toggling the flag, fixing both problems. N.B., sctp_sendall() seems buggy for other reasons: it appears to handle uio == NULL (taking the input mbuf instead) but unconditionally dereferences uio.

``` - The SCTP_PCB_FLAGS_SND_ITERATOR_UP check was racy, since two threads could observe that the flag is not set and then both set it. I'm not sure if this is actually a problem in practice, i.e., maybe there's no problem having multiple sends for a single PCB in the iterator list? - sctp_sendall() was modifying sctp_flags without the inp lock held. ``` The change simply acquires the PCB write lock before toggling the flag, fixing both problems. N.B., sctp_sendall() seems buggy for other reasons: it appears to handle uio == NULL (taking the input mbuf instead) but unconditionally dereferences uio.

``` - The SCTP_PCB_FLAGS_SND_ITERATOR_UP check was racy, since two threads could observe that the flag is not set and then both set it. I'm not sure if this is actually a problem in practice, i.e., maybe there's no problem having multiple sends for a single PCB in the iterator list? - sctp_sendall() was modifying sctp_flags without the inp lock held. ``` The change simply acquires the PCB write lock before toggling the flag, fixing both problems. N.B., sctp_sendall() seems buggy for other reasons: it appears to handle uio == NULL (taking the input mbuf instead) but unconditionally dereferences uio.