sctp: properly latch and use autoclose value from sock to association

Currently, sctp associations latch a sockets autoclose value to an association
at association init time, subject to capping constraints from the max_autoclose
sysctl value.  This leads to an odd situation where an application may set a
socket level autoclose timeout, but sliently sctp will limit the autoclose
timeout to something less than that.

Fix this by modifying the autoclose setsockopt function to check the limit, cap
it and warn the user via syslog that the timeout is capped.  This will allow
getsockopt to return valid autoclose timeout values that reflect what subsequent
associations actually use.

While were at it, also elimintate the assoc->autoclose variable, it duplicates
whats in the timeout array, which leads to multiple sources for the same
information, that may differ (as the former isn't subject to any capping).  This
gives us the timeout information in a canonical place and saves some space in
the association structure as well.

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
CC: Wang Weidong <wangweidong1@huawei.com>
CC: David Miller <davem@davemloft.net>
CC: Vlad Yasevich <vyasevich@gmail.com>
CC: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>

1 files changed, 0 insertions, 6 deletions

diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index ea0ca5f6e629..67b5d0068273 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -1726,12 +1726,6 @@ struct sctp_association {
         /* How many duplicated TSNs have we seen?  */
         int numduptsns;
 
-        /* Number of seconds of idle time before an association is closed.
-         * In the association context, this is really used as a boolean
-         * since the real timeout is stored in the timeouts array
-         */
-        __u32 autoclose;
-
         /* These are to support
          * "SCTP Extensions for Dynamic Reconfiguration of IP Addresses
          *  and Enforcement of Flow and Message Limits"