endianess of ip address data from __sk_buff

[kckeiks]

Hello, When I first looked at the mask below (0xffffff00), I thought that it would incorrectly mask the MSB because I thought that the IP address would be in network byte order but when I printed the IP address, I realized that it was masking off the right byte but the address was backwards (1.0.0.127 instead of 127.0.0.1 for instance). It would seem that the address is in little endian (which in my case is the host endianness) given the mask and the bytes being masked off (after the mask I get 0.0.0.127). Why isn't the IP address in network byte order?

static FORCE_INLINE void ipv4_hash(struct in_addr ip, struct address_hash *a, struct address_hash *b)
{
        bpf_printk("IP: %pI4", &ip.s_addr);
	
        a->vals[ADDRESS_IP] = fasthash64(&ip, sizeof(ip), FH_SEED);
	b->vals[ADDRESS_IP] = hashlittle(&ip, sizeof(ip), L3_SEED);
	ip.s_addr &= 0xffffff00;
	a->vals[ADDRESS_NET] = fasthash64(&ip, sizeof(ip), FH_SEED);
	b->vals[ADDRESS_NET] = hashlittle(&ip, sizeof(ip), L3_SEED);
}

I also noticed that __sk_buff has a some ip address fields. Couldn't we use those fields instead of load_word and load_ipv6?

...
	__u32 remote_ip4;	/* Stored in network byte order */
	__u32 local_ip4;	/* Stored in network byte order */
...

[lmb]

If I remember correctly this is because we use load_word to load the ipv4 addresses, which does a byte swap. So rather than swapping again we just deal with little endian ips.

remote_ip4 and local_ip4 are not available from the socket filter context if I remember correctly.