• Neil Horman's avatar
    sctp: Fix port hash table size computation · 87042cdc
    Neil Horman authored
    commit d9749fb5 upstream.
    
    Dmitry Vyukov noted recently that the sctp_port_hashtable had an error in
    its size computation, observing that the current method never guaranteed
    that the hashsize (measured in number of entries) would be a power of two,
    which the input hash function for that table requires.  The root cause of
    the problem is that two values need to be computed (one, the allocation
    order of the storage requries, as passed to __get_free_pages, and two the
    number of entries for the hash table).  Both need to be ^2, but for
    different reasons, and the existing code is simply computing one order
    value, and using it as the basis for both, which is wrong (i.e. it assumes
    that ((1<<order)*PAGE_SIZE)/sizeof(bucket) is still ^2 when its not).
    
    To fix this, we change the logic slightly.  We start by computing a goal
    allocation order (which is limited by the maximum size hash table we want
    to support.  Then we attempt to allocate that size table, decreasing the
    order until a successful allocation is made.  Then, with the resultant
    successful order we compute the number of buckets that hash table supports,
    which we then round down to the nearest power of two, giving us the number
    of entries the table actually supports.
    
    I've tested this locally here, using non-debug and spinlock-debug kernels,
    and the number of entries in the hashtable consistently work out to be
    powers of two in all cases.
    Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
    Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
    CC: Dmitry Vyukov <dvyukov@google.com>
    CC: Vladislav Yasevich <vyasevich@gmail.com>
    CC: "David S. Miller" <davem@davemloft.net>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    [ luis: backported to 3.16: adjusted context ]
    Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
    Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
    87042cdc
protocol.c 42.9 KB