I want to report the following bug: If you create sets or add an element with a big timeout this can result in a wrong timeout or even no entry. This occurs on 32 and 64 Bit and the problem comes from the msecs_to_jiffies function. But first the steps to reproduce the bug: x86_64/amd64: > ipset create test1 hash:net timeout 4294967 > ipset create test2 hash:net timeout 4294968 > ipset add test1 192.168.0.0/24 > ipset add test2 192.168.0.0/24 > ipset list this will result in an empty test2 set and in an test1 set with the entry and correct timeout. Another example > ipset create test hash:net timeout 1 > ipset add test 192.168.0.0/24 timeout 4294968 > ipset list empty list, but > ipset add test 192.168.0.0/24 timeout 42949680 > ipset list results in > 192.168.0.0/24 timeout 5 so an overflow. x86/32-Bit: > ipset create test hash:net timeout 1000 > ipset add test 192.168.0.0/24 timeout 2147484 > ipset list results in: > 192.168.0.0/24 timeout 1073741 it's working up to 2147483. This is imho a bug as ipset says > ipset v6.11: Syntax error: '4294967296' is out of range 0-4294967295 so 4294967295 should be the maximum and it isn't. I checked the source code and i think the following fix could help: in kernel/include/linux/netfilter/ipset/ip_set_timeout.h the ip_set_timeout_set needs to look like this: > if ((timeout > (INT_MAX/1000)) || ((int)(timeout*1000) < 0)) timeout = > (INT_MAX/1000); > t = msecs_to_jiffies(timeout * 1000) + jiffies; I added this if clause so "t" won't get bigger then 2147483 (32-Bit) or 4294967 (64-Bit). The problem is, that msecs_to_jiffies() returns "MAX_JIFFY_OFFSET" in the case mentioned at 32-Bit, this explains the 1073741 value. And with the other values there is an overflow. My fix may be wrong, so no guarantee, i'm still testing around and the overflow isn't clear to me right now, i just figured out the problem with "MAX_JIFFY_OFFSET". Any help or recommendations welcome. -- Andreas Herz -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html