On 12/13/2011 05:00 PM, Xi Wang wrote: > On Dec 12, 2011, at 5:18 PM, Vladislav Yasevich wrote: >> Hm.. this is a bit strange. This makes it so that on 32 bit platforms >> we have one upper bound for autoclose and on 64 we have another even though >> the type is platform dependent. This could be considered a regression by >> applications. > > Either looks good to me. Timeout limit is essentially different on 32/64 > platforms. I don't think it really should be different. Notice that our rto values remain consistent. I really thing that this should be consistent from the user's point of view. > > Another (probably uglier) option is to limit the value on 32-bit platform > only, like sock_setsockopt() in net/core/sock.c. > > #if (BITS_PER_LONG == 32) > if (sp->autoclose > MAX_SCHEDULE_TIMEOUT / HZ) > sp->autoclose = MAX_SCHEDULE_TIMEOUT / HZ; > #endif I agree, this is ugly. It might make more sense to define a max autoclose value and expose it through /sys. That way the values remains consistent. -vlad > >> In addition this would result in confusion to user since the values >> between setsockopt() and getsockopt() for autoclose would be different. > > Are you suggesting to reject the value and return -EINVAL, rather than > silently limiting the autoclose value? > > - xi > -- 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
