Re: Memory issue with kernel sctp_connectx

[Adam Endrodi <adam.endrodi@nsn.com>]

On Fri, Mar 06, 2015 at 11:52:05AM +0100, ext Danny Smit wrote:
> 
> I'm look into a possible memory issue when using sctp_connectx. This
> week I've asked to following on the CentOS mailing list:

I think you'll find this thread relevant:
http://www.spinics.net/lists/linux-sctp/msg03705.html

> ------------------------------
> I'm running into a possible memory issue with the SCTP implementation
> in CentOS 6, using lksctp-tools. So far I've not seen the problem with
> other distributions yet.
> 
> The problem is that whenever a SCTP client connection is initiated to
> a second host and port at which no SCTP server application is
> listening
> 
> The scenario is simple:
> - call socket() to create a socket.
> - call sctp_connectx() to establish a connection.
> 
> The last call is repeated periodically to retry to establish a connection.
> 
> When looking on the wire using wireshark it shows that an SCTP INIT
> packet is sent to the second host, which replies with an SCTP ABORT.
> 
> This is exactly according to the SCTP specification. However it
> appears ABORT isn't propagated into to application layer that calls
> sctp_connectx().
[...] 
> Note that the API is used in non-blocking mode.

This case sctp_connectx() doesn't wait until the connection is established.
You need to use sctp_recvmsg() to get the notification.

> Furthermore, because reconnect attempts are made, a steady memory
> increasement occurs. Looking at /proc/meminfo, the increasement occurs
> in SUnreclaim, the kernel slab cache.

Perhaps these are the event being queued up?

-- 
So if you walk away, who is gonna stay?