From: Vlad Yasevich <vyasevich@xxxxxxxxx> Date: Mon, 3 Sep 2012 11:02:51 -0400 > > > On Sep 3, 2012, at 10:27 AM, Thomas Graf <tgraf@xxxxxxx> wrote: > >> SCTP charges wmem_alloc via sctp_set_owner_w() in sctp_sendmsg() and >> via >> skb_set_owner_w() in sctp_packet_transmit(). If a sender runs out of >> sndbuf it will sleep in sctp_wait_for_sndbuf() and expects to be waken >> up >> by __sctp_write_space(). >> >> Buffer space charged via sctp_set_owner_w() is released in >> sctp_wfree() >> which calls __sctp_write_space() directly. >> >> Buffer space charged via skb_set_owner_w() is released via >> sock_wfree() >> which calls sk->sk_write_space() _if_ SOCK_USE_WRITE_QUEUE is not set. >> sctp_endpoint_init() sets SOCK_USE_WRITE_QUEUE on all sockets. >> >> Therefore if sctp_packet_transmit() manages to queue up more than >> sndbuf >> bytes, sctp_wait_for_sndbuf() will never be woken up again unless it >> is >> interrupted by a signal. >> >> This could be fixed by clearing the SOCK_USE_WRITE_QUEUE flag but ... >> >> Charging for the data twice does not make sense in the first place, it >> leads to overcharging sndbuf by a factor 2. Therefore this patch only >> charges a single byte in wmem_alloc when transmitting an SCTP packet >> to >> ensure that the socket stays alive until the packet has been released. >> >> This means that control chunks are no longer accounted for in >> wmem_alloc >> which I believe is not a problem as skb->truesize will typically lead >> to overcharging anyway and thus compensates for any control overhead. > > Acked-by: Vlad Yasevich <vyasevich@xxxxxxxxx> Applied and queued up for -stable, thanks everyone. -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html