On Tue, 18 Jun 2019 at 20:22, Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > On Tue, Jun 18, 2019 at 11:32:07AM +0200, Ard Biesheuvel wrote: > > Use an explicit little endian representation of the fastopen > > cookie, so that the value no longer depends on the endianness > > of the system. This fixes a theoretical issue only, since > > fastopen keys are unlikely to be shared across load balancing > > server farms that are mixed in endiannes, but it might pop up > > in validation/selftests as well, so let's just settle on little > > endian across the board. > > > > Note that this change only affects big endian systems. > > > > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > > --- > > include/linux/tcp.h | 2 +- > > net/ipv4/tcp_fastopen.c | 16 ++++++++-------- > > 2 files changed, 9 insertions(+), 9 deletions(-) > > > > What about the TCP_FASTOPEN_KEY option for setsockopt and getsockopt? Those > APIs treat the key as an array of bytes (let's say it's little endian), so > doesn't it need to be converted to/from the CPU endianness of siphash_key_t? > Yeah, good point. Can we first agree on whether we care about this or not? If so, i can spin a v2.
