...
> > All this is really defining the behaviour for 'broken' apps.
> > It wouldn't be completely unreasonable if a single message sent with 'MSG_MORE'
> > never actually got sent.
>
> Actually, this code opens up a way to eat kernel memory. Consider an application
> that does:
> while (1) {
> socket(IPPROTO_SCTP);
> connect()
> sendmsg(MSG_MORE); <- write 1 byte
> close();
> }
>
> Because we send with MSG_MORE, the 1 byte gets queued to the association. The close()
> causes us to enter SHUTDOWN_PENDING state and we never flush the buffer and close
> the association.
>
> This is a malicious example. Similarly, a broken application could just forget to
> clear MSG_MORE and when we end up in a condition where the amount of queued data is
> smaller then MTU and all inflight data has been acked, we'd once again be stuck.
>From a system point of view that one doesn't really matter.
> Just because application isn't doing the right thing, we can't assume it's broken. It
> could be malicious. We need to make this behavior robust.
Hmmm....
The amount of data per-socket is limited by the mtu and socket buffer size,
so a malicious app would have to create a lot of sockets to use a significant
amount of kernel memory.
If close() blocks forever, isn't there a worse problem with a remote app
that causes the window to be zero - and so data can't be sent and the
close will block forever anyway?
I've never liked protocols that wait forever for send data to drain on disconnect.
Seems like an 'accident' waiting to happen.
I'm not sure what would be needed to be done to cause queued send data to be
sent when SCTP_F_TX_MSG_MORE is cleared by close() or set/clear SCTP_NODELAY.
It is probably a simple call to the correct function.
David
--
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
