On Thu, Aug 8, 2019 at 1:09 PM Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote: > > On 8/8/19 12:45 PM, Eric Dumazet wrote: > > On Thu, Aug 8, 2019 at 11:50 AM Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote: > > > >> Socket cookie consumers must assume the value as opqaue in any case. > >> The cookie does not guarantee an always unique identifier since it > >> could wrap in fabricated corner cases where two sockets could end up > >> holding the same cookie, > > > > What do you mean by this ? > > > > Cookie is guaranteed to be unique, it is from a 64bit counter... > > > > There should be no collision. > > I meant the [theoretical] corner case where socket_1 has cookie X and > we'd create, trigger sock_gen_cookie() to increment, close socket in a > loop until we wrap and get another cookie X for socket_2; agree it's > impractical and for little gain anyway. So in practice there should be > no collision which is what I tried to say. If a 64bit counter, updated by one unit at a time could overflow during the lifetime of a host, I would agree with you, but this can not happen, even if we succeed to make 1 billion locked increments per second (this would still need 584 years) I would prefer not mentioning something that can not possibly happen in your changelog ;)
