Re: [PATCH net] sctp: fix a success return may hide an error

On Wed, Aug 17, 2016 at 09:01:38AM +0000, David Laight wrote:

From: Marcelo Ricardo Leitner

quoted

Sent: 16 August 2016 18:25

...

quoted

quoted

That doesn't seem a good idea.
You don't want to abort the association if there is a transient
memory allocation failure.
You also can't drop data chunks.

From a system-wise POV, this behavior - to free the new asoc in case of
transient memory allocation failure - doesn't seem bad to me.
That's what will have to happen if any allocation before it failed and
also it helps the system to reduce the stress a little bit. I don't see
any inconsistency/problems here because we are not dropping a single
random chunk but instead we are actually refusing to initialize a new
asoc in such conditions.

Failing a new association should be ok, whether purists will like
connect() failing ENOMEM is another matter.

Good point.

quoted

Nevertheless, I agree that letting the application see ENOMEM errors when
the data actually got queued and is being fully handled, as in, it will
be retransmitted later, is not be wise, as the application probably
won't be able to distinguish from ENOMEMs that it should retry or not.

I think an application would be justified in thinking that an ENOMEM return
meant that the system call had no effect.

Yep

For send() even ENOMEM is really wrong, it should be treated as 'flow control'
and either block or return EAGAIN/EWOULDBLOCK.

Agreed.

Getting POLLOUT set is left as an exercise to the reader :-)

:-)

...

quoted

Well, it may be, but we are trying to improve it.  Please continue
discussing the fixes so we can keep improving it. :)

Indeed, we have customers who use sctp (for M3UA).
We don't do anything 'complicated', but do end up sending a lot of short
data chunks.

	David

--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html