Let’s look inside the LoopBack
Hi guys , i just wanted to take a look inside special devices in the linux kernel , especially the loopback .
It’s a virtual device that comes with the network stack, as we talked in previous articles (https://medium.com/@garciaj.uk/the-network-stack-153c92e35b26) the network stack refers to “struct net” . To recap every time we create a new network namespace we are instantiating a struct net .
(include/net/net_namespace.h)
So that’s the first step , the second step is that the loopback device is implemented as a driver as far as i can see , so most of its methods are implemented in https://github.com/torvalds/linux/blob/master/drivers/net/loopback.c.
So let’s take a look at the transmit function:
- lb_stats, will be used to save stats as the name implies RX TX packets etc
- len will be used to store the length of the sk_buff (skb)
- skb_dst_force it’s used for “refcounting” , krefs or refcounting is a kernel design pattern where a counter is incremented by 1 when some method references it , and decremented when he reference is released , to then free() the object.
- eth_type_trans Used to determine the packet protocol id and insert it back in skb-> protocol
- this_cpu_ptr, this one is a complex one , this_cpu functions are mostly used to guarantee atomicity at the cpu level , that is to avoid the taxes to cpu switching etc (I might be totally wrong in this)
- netif_rx , receive method, called by driver when skb received on if; enqueues skb on the receiving queue and update stats etc , it returns a boolean that guarantee the reception of the frame(skb).
In the next article I would like to investigate how packets and frames look in the kernel , we have talked about sk_buffs (skb) before so that’s the clue really. Let me know if you’d like to investigate other parts but I think it’s important to learn as much as we can about namepsaces and kernel isolation due to the popularity of containers etc.
What you think?