On 8/8/19 1:37 PM, Eric Dumazet wrote:
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 ;)
Yep fair enough, makes sense. I'll fix it :)
